Сценарии взаимодействия Softswitch

Поскольку протокол BICC изначально задуман для работы в мульти­сервисной конвергентной сети, важно рассмотреть его работу в сме­шанном окружении, как это может оказаться в реальной сети NGN. Как следует из всего, написанного выше, начиная с названия книги, основным элементом такой NGN является Softswitch, поэтому в пред­ставленном на рис. 8.16 примере рассматриваются три Softswitch, которые взаимодействуют друг с другом по протоколам BICC и SIP. Таким образом, здесь Softswitch реализуют функции Interface Serving Node (ISN) протокола BICC и функции прокси-сервера SIP.

SIP-NNI (Network-Network Interface) - это модуль SIP, устанавли­ваемый на пограничном узле сигнализации SIP, взаимодействующем с внешними сетями. В примере на рис. 8.16, а также в показанных на рис. 8.17 и 8.18 сценариях этот модуль реализован в составе Softswitch и обозначен, соответственно, как SIP-NNI.

В этом примере сеанс связи устанавливается между абонентом TDM-сети, включенным в PBX, и абонентом сети IP-телефонии с SIP- телефоном, причем в обслуживании вызова участвует еще один транзитный Softswitch. Так как первый абонент включен в учрежден­ческую АТС, то ее взаимодействие с Softswitch1, реализующим фун­кции Interface Serving Node BICC, обеспечивает протокол DSS1.

l\i l\i

TSN

ISN-B CSF-N

ISN-A CSF-N

Ш

SWN-1 -►I BCF-R

SWN-2

SWN-1 BCF-R I»

SWN-2 BCF-R

BCF-N (X)

BCF-N (У)

BCF-N (z)

IAM.

IAM (COT

зп previous), (Action = Connect Forward), (BNC characteristics)_______________________

IAM (Action = Connect Forward), (BNC characteristics) APM (Action = Connect Forward, plus notification)

"AAA"

(BNC-ID =

/1), (BIWF Addr = v)

АРМ (Actic ____ (E

n = Connect Forward, p NC-ID = z1), (BIWF Add

us notification) |r = z)

Bearer-Set-up req. (ВЩС:

-ID = у 1), (BIWF-Addr = y) Bearer- Set -_up_ r_e_q_ _

Bearer-Set-up req. (^T

= z) Bearer-Set-up req

. _Bea_rer-_Setzug j;eg _

NC-ID = z1), (BIWF-Addr. B_ea_rer-S_e_t_Lu g req _

Bearer-Set-up-Con necl

3e a rer - Set-up- Co n n e ct

Be a re r_- Set -_up_-C4j[ ij i_ec

^ a r e r_- S e t -_uj>_C q[ ij i_ec

3garer-Set-up-Connec1

3|arer-Set-up-Connec1 АРМ

(Action = Connected)

PM (Action = Connected)

COT

•BBB"^ ACM

ACM

ACM

ANM

ANM

ANM

ACM --

ANM

Т11107780-00

Рис. 8.15.

Организация носителя в прямом направлении

ISN ISN SIP-NNI Рис. 8.16. Пример сети NGN под управлением трех Softswiteh

Сделано это для разнообразия, чтобы дать читателю возмож­ность отдохнуть от протокола ОКС7, постоянно присутствовавшего в этой главе, но взаимодействие Softswitch по DSS1 происходит точно по тем же правилам, что и в случае ISUP. Набор передаваемых сигналов остается неизменным.

Для взаимодействия с SIP необходима новая функциональная единица - модуль взаимодействия IWU(Interworking Unit). Этот мо­дуль может быть отдельной физической единицей, а может входить в состав узла BICC. Отметим, что при взаимодействии протоколов BICC и SIP будут поддерживаться только общие для них обоих ус­луги, а все дополнительные услуги, предоставляемые в одной сети и не поддерживаемые в другой, не будут пропущены через IWU. В связи с вышесказанным необходимо определить дополнительно следующие термины:

• Incoming IWU - физическая структурная единица, которая может быть объединена с ISN BICC, принимающая вызовы со стороны SIP-сети и обеспечивающая их дальнейшую обработку с иотоль- зованием протокола BICC;

• Outgoing IWU - структурная единица, которая выполняет обрат­ную функцию;

• Adjacent SIP Node (ASN) - смежный узел SIP, т.е прокси-сервер SIP, SIP-часть IWU которого взаимодействует с I-IWU или O-IWU. Для обмена сигнальной информацией, относящейся к одно­му вызову, модулю взаимодействия IWU необходимо установить прямую зависимость между диалогом SIP и сигнальной связью

15. Б.С. Гольдштейн

BICC/ISUP. Чтобы обеспечить обмен адресной информацией, для одной сигнальной связи BICC/ISUP может быть установлено ее вза­имодействие с последовательностью диалогов SIP, продолжающе­еся до тех пор, пока этап обмена адресной информацией не будет закончен.

Сообщения BICC/ISUP должны или инкапсулироваться, или быть преобразованы в аналогичные запросы SIP. При использовании обеими сетями (и BICC-ориентированными, и SIP-ориентированны- ми) одной транспортной технологии было бы удобно использовать дополнительную возможность BICC - возможность туннелировать информацию управления носителем. Однако текущие возможности BICC CS2 позволяют туннелировать информацию управления носи­телем средствами механизма Bearer Control Tunneling только для одного протокола - IPBCP, - о чем говорилось в параграфе 8.6.

Аналогично понятию IWU, относящемуся к управлению обслу­живанием вызова, для взаимодействия протоколов управления носителями вводится понятие функции взаимодействия управления носителями BC-IWF (Bearer Control Interworking Function). Функция BC-IWF обеспечивает взаимодействие IPBCP с SDP и предостав­ляется только для определенного вызова. При приеме запросов SDP, передаваемых в сообщениях SIP, BC-IWF должна генерировать соответствующий блок данных (Bearer Control Data Unit) для вложе­ния в сообщение BICC. Затем производится анализ того, какое из сообщений SIP, содержащих ответы, необходимо передать соглас­но полученному сообщению запроса. Передача этого сообщения задерживается до получения сообщения BICC, содержащего Bearer Control Data Unit. При получении сообщения BICC содержащего Bearer Control Data Unit, производится обратная процедура. После получения сообщения INVITE Incoming-IWU определяет, что на сто­роне BICC необходимо выполнить процедуру организации носителя (Bearer Setup Procedure). В зависимости от того, содержит ли INVITE запрос SDP или нет, канал проключается в прямом или обратном направлении, а INVITE преобразуется в IAM с соответствующими параметрами.