Для взаимодействия Softswitch между собой теоретически должен применяться именно протокол BICC (Bearer independent call control protocol), разработанный Международным союзом электросвязи ITU-T. И хотя на практике более популярным становится второй протокол - SIP (SIP-T), разработанный IETF и рассмотренный в главе 4 книги, протокол BICC успешно используется до сих пор, например, в весьма удачных Softswitch платформы ENGINE компании Ericsson, о чем мы еще поговорим в главе10.
Работа над созданием протокола управления обслуживанием вызова независимо от носителя (несущего канала) BICC была начата Исследовательской комиссией 11 (ИК-11) ITU-T в марте 1999 года. Обязательным требованием была поддержка сигнальных сообщений ISUP, поскольку протокол должен был облегчить Операторам переход к мультисервисным сетям и обеспечить взаимодействие новой мультисервисной сети с существующими сетями ISDN. Фактически протокол BICC рассматривался как еще одна прикладная подсистема общеканальной сигнализации ОКС7, обеспечивающая экономичный переход к мультисервисной сети с сохранением большей части сигнального оборудования ISUP сетей с временным разделением каналов TDM.
|
|
Как подчеркивает эпиграф к этой главе, протокол BICC, равноправие которого с SIP сегодня носит, в основном, теоретический характер, в свое время позволил выиграть время при решении проблемы нехватки сетевых ресурсов, возникшей перед рядом Операторов, не желавших вкладывать инвестиции в дальнейшее
развитие TDM-сетей. Для них протокол BICC должен был (и сумел) обеспечить возможность предоставлять уже существующие услуги ТфОП/ISDN в пакетных сетях, а также поддерживать взаимодействие имеющихся узлов коммутации TDM с узлами пакетной сети и взаимодействие узлов коммутации TDM через пакетную сеть.
По этой причине протокол BICC должен был базироваться исключительно на подсистеме ISUP стека ОКС7. Чтобы не пришлось разрабатывать две отдельные технологии, одна из которых переносила бы ISUP в IP-окружение, а другая обеспечивала взаимодействие между пакетной и TDM-сетью, для BICC было принято требование полной совместимости протокола с существующей сетью коммутации каналов, но, в то же время, способности работать с любой транспортной технологией, которая может обеспечить приемлемое качество передачи речевого трафика. Были сформированы основные принципы разрабатываемого протокола BICC:
• протокол основан на ISUP, чтобы быть полностью совместимым
с существующими услугами и сетями TDM;
• протокол независим от транспортной технологии;
• протокол использует уже существующие сигнальные протоколы
для установления соединений в транспортных сетях.
|
|
Единственной доработкой протокола ISUP для BICC стало усовершенствование обслуживания вызовов абонентов мобильных сетей, сделанное из-за того, что многие Операторы стационарной связи предоставляют свои сети для передачи трафика Операторов мобильной связи. Ранее качество передачи речевой информации при этом ухудшалось из-за кодирования и декодирования трафика, соответственно, на входе и на выходе проводной сети. Возможность сигнализировать об используемом кодеке и согласовать выбор наилучшего кодека для обслуживаемого вызова оказалось легко добавить в BICC, не ухудшая при этом его совместимости с ISUP.
Подготовленные ИК-11 рекомендации BICC имеют индексы Q.1900 - Q.1999, причем стандартизация протокола BICC проходила в несколько этапов, начиная с набора возможностей CS1 (Capability Set 1), ориентированного на взаимодействие узлов ISDN через сети ATM. Основная рекомендация для BICC - Q.1901 - представляет собой так называемый delta-документ, т.е. документ, описывающий отличия от существующих рекомендаций ISUP Q.761 - Q.764.
Следующий за ним CS2 уже ориентировался на сети IP, для чего в рекомендации Q.1970 был предложен новый протокол IPBCP (IP Bearer Control Protocol), и появилась еще одна рекомендация Q.1990, посвященная туннелированию сигнальной информации в IP- сети. Сам набор возможностей CS2 описывается рекомендацией Q.1902 (Q.1902.1 - Q.1902.6). Кроме того, потребовалось внести дополнения в другие, уже существующие рекомендации, в частности,
в Q.765, описывающую Application Transport Mechanism. Благодаря тому, что все процедуры, связанные с преобразованием транспортируемых сообщений, были удалены из протокола и переданы функциональной единице, получившей название Signaling Transport Converter (STC), была достигнута полная независимость BICC от транспортной технологии. Варианты STC для транспорта каждого вида описываются дополнительными рекомендациями ITU-T и документами других стандартизирующих организаций. Так, например, конвертер для транспортных услуг MTP частично рассмотрен в приложении к рекомендации Q.1901. Конвертер для транспортной технологии ATM описан руководящими документами ATM-форума (AF-CS-VMOA-0146.000). В принципе, ничто не мешает дополнять BICC новыми наборами возможностей, что позволяет этому протоколу работать с любой транспортной технологией. Так, например, набор возможностей CS3 обеспечивает поддержку новых инфоком- муникационных услуг и взаимодействие с протоколом SIP-T.
Как сказано выше, одним из принципов BICC является использование существующих сигнальных протоколов, следовательно, принимая во внимание три поддерживаемые технологии, BICC умеет взаимодействовать с сигнализацией:
• ATM Forum UNI4.0 и ITU-T DSS2 для доступа ATM;
• ITU-T B-ISUP, ATM Forum PNNI и AINI для магистральной сети
ATM;
• AAL Type 2 - для управления носителем в ATM;
• SDP - для IP сетей.