Стандартизация BICC

Для взаимодействия 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 сетей.