Capability Set 2

BICC CS2 базируется на принципах, заложенных в CS1, продол­жает поддерживать большинство услуг ISUP, но ориентирован уже на работу в IP-сети. К тому же, в CS2 архитектура протокола включа­ет в себя функции оконечной АТС. Из-за этого ИК11 ITU-T пришлось определить базовый процесс обслуживания вызова уже не в виде delta-документа, как это было сделано в CS1, а в виде полных спе­цификаций. Все следующие доработки ISUP будут отныне включать в себя новые версии Q.761 и Q.764 с добавлением новых определе­ний, параметров и сообщений из Q.1902.2 и Q.1902.3. Таким обра­зом, протоколы ISUP и BICC оказываются неразрывно связанными через рекомендации ITU-T Q.7xx и Q.19xx, как это представлено в табл. 8.7.

Таблица 8.7. Рекомендации, описывающие базовый процесс обслуживания вызова в CS2 Рекомендация BICC Эквивалент в ISUP Что описывает Комментарий Q.1902.1 Q.761 Обзор Отдельный текст Q.1902.2 Q.762 Определения Совместно с ISUP Q.1902.3 Q.763 Форматы и коды Совместно с ISUP Q.1902.4 Q.764 Процедуры Отдельный текст

Поскольку BICC CS2 включает в себя функции оконечной АТС, он должен, помимо обмена входящей/исходящей информацией, под­держивать дополнительные услуги ISUP. Это достигается посредс­твом взаимодействия подсистемы BICC с ISUP так, как показано на рис. 8.9.

Помимо того, что реализация многих услуг ISUP в BICC имеет свои особенности, в BICC CS2 появились и новые, не существо­вавшие в ISUP услуги и возможности. Это может использоваться в BICC-сети при взаимодействии с услугами Интеллектуальной сети, например, при предоставлении услуги телеголосования или карт предоплаты услуг связи. В число процедур создания несущего ка­нала были добавлены сигнальные процедуры, учитывающие методы организации носителя, например, в прямом направлении, в обрат­ном направлении или создание свободного несущего канала. Это несколько усложнило сигнальные процедуры, но они по-прежнему базируются на сигнализации ISUP. Поскольку некоторые из проце­дур организации несущего канала требуют подтверждения того, что на каждом из SN, находящемся вдоль маршрута, пользовательская плоскость активна, это может привести к тому, что узел назначения надолго задержит передачу исходящего сообщения IAM, что, в свою очередь, даст неприемлемую задержку в установлении сеанса свя­зи. Чтобы преодолеть описанный недостаток, в окружение BICC была внедрена процедура проверки целостности соединения.

Сам тест целостности соединения, как он определен в ISUP, в BICC не проводится, но сообщение COT (Continuity) используется, чтобы показать, что несущий канал проключен, и IAM может выйти из области BICC.

Рис. 8.9.

Архитектура сигнального взаимодействия BICC с ISUP

Важной особенностью BICC CS2 является то, что модель этой версии позволяет одной функции CSF управлять более чем одной BIWF, а также одной BIWF быть управляемой несколькими CSF. Это значит, что количество информации, которую необходимо перенес­ти от исходного SN до следующего узла на маршруте, увеличилось. Дополнительная информация связана с корреляцией вызова/ несущего канала и с идентификацией. Для того чтобы более полно осветить вышесказанное, рассмотрим подробнее функциональную модель узла согласно BICC CS2.

Напомним рассмотренную в двух первых главах концепцию де­композиции шлюза, составляющую основу архитектуры Softswitch. Декомпозиция шлюза предполагает, что он состоит из двух ос­новных частей: медиа-шлюза MG, который преобразует данные из одного формата (например, TDM) в другой (например, IP), и Softswitch или контроллера транспортного шлюза MGC, кото­рый управляет медиа-шлюзом. Третий компонент шлюза после его декомпозиции - шлюз сигнализации SG - часто объединяется с MGC или входит в состав Softswitch. Вернувшись к архитектуре и терминологии BICC и принимая во внимание необходимость для BICC функционировать именно в этом окружении, целесообразно разделить функциональную модель единого узла SN, как он опре­делен в CS1, на части, которые могут быть наложены на архитектуру MG/MGC. Требования к сетям IP-телефонии, на которые ориенти­ровалась ИК11 при создании функциональной модели BICC CS2, предусматривающей физическое разделение функций управле­ния обслуживанием вызова и управления несущим каналом, были взяты из проекта TIPHON ETSI и MSF (Multiservice Switching Forum). Функциональная модель узла SN, физически разделенного на части согласно BICC CS2, представлена на рис. 8.10.

Функция CSF обеспечивает выполнение процедур BICC для каждого из вызовов, BCF выполняет общие управляющие функции в MGC. Простые же функции медиа-шлюза MG, без какой-либо уп­равляющей составляющей, поддерживаются функцией мэппинга и коммутации MMSF(Media mapping and switching function).

В предыдущих параграфах подчеркивалось, что при разработке BICC основные усилия были сконцентрированы на том, чтобы под­держивать предоставление уже устоявшихся узкополосных услуг (ISDN, Интеллектуальной сети и т.п.), используя широкополосную технологию. В частности, и по этой причине функции BCF и MMSF ло­гически объединяются вместе, чтобы сформировать функцию BIWF

i

CSF

BICC CS2

CCU

Протокол управления несущим каналом

BCU

Несущий канал (плоскость пользователя)

MGU

CBC

	BCF
i	L
	BMC г
	MCF
	MMSF	BIWF

Функции

L

Физическое устройство

Рис. 8.10. Декомпозиция узла обслуживания SN (CS2)

Разумеется, архитектура BICC позволяет сделать интерфейс между BCF и MCF открытым, но разделение функций между BCF и MMSF не рассматривалось ИК11 при стандартизации BICC CS2. Более развитая функциональная структура позволяет одному сер­веру вызовов управлять несколькими медиа-шлюзами, что отраже­но на рис. 8.11.

Рис. 8.11. Управление несколькими BIWF

С другой стороны, требования к поддержке мобильных приложе­ний, о которых говорилось выше, вылились в создание возможнос­ти управлять одним BIWF несколькими CSF. Это сделано для того, чтобы, доведя до сети подвижной связи (СПС) вызов и несущий канал, довести до конечного терминала только вызов.

На этом этапе может быть использована тональная сигнализа­ция, управляемая сервером вызовов СПС, но при помощи уже су­ществующей функции BIWF, как это показано на рис. 8.12.

Рис. 8.12. Управление BIWF несколькими CFS

Важным нововведением в функциональной структуре узлов (как SN, так и CMN) стало использование так называемой модели half call, когда блок CSF разделяется на исходящие и входящие проце­дуры. Сказанное иллюстрирует рис. 8.13.

Носитель Рис. 8.13. Модель узла SN в соответствии с CS2

Информационный обмен через интерфейс между CSF и BIWF (CBC) в BICC CS2 стандартизирован и ведется по протоколу MEGACO/H.248. Таким образом, еще раз учитывается использова­ние в BICC CS2 принципа декомпозиции шлюза. Как это было сде­лано для BICC CS1, приведем на рис. 8.14 архитектуру сети на базе BICC CS2.

м м о

Сеть транспорта сигнальных сообщений

/Сигнализация⁴, ' управления * / обслуживанием * вызова

	ISDN-B		ТЕ

CSF-N

ISN-A

TSN

GSN

GSN

ISN-B

CMN 4 CSF-C!.

CSF-N

CSF-T

CSF-G

CSF-G A

A

A

ТЕ

ISDN-A

SWN-3 BCF-R

SWN-4 BCF-R

k-

k

k-»{

|.| BCF-T |. | - -

X

X

X

X

X

X

X

X

X

rv

Функция взаимодействия носителей (BIWF)

-ЩГ-"►! Соединения опорной сети

Звено соединения опорной сети

Сетевое соединение несущего канала

со 03 ОЭ

Рис. 8.14. Архитектура сети BICCCS2