Система транспорта сигнализации

Продолжая обсуждение архитектуры BICC CS1, рассмотрим подробнее систему транспорта сигнализации, т.к. она будет исполь­зоваться и в CS2, и в CS3. К тому же, она является одной из главных составляющих протокола BICC.

Система транспорта сигнализации находится, так сказать, на границе протокола BICC. Предусматривается по одному уже рас­сматривавшемуся выше объекту STC (signaling transport converter) на каждую сигнальную связь. Протокол BICC передает или принима­ет сообщения этой сигнальной связи, используя соответствующую точку доступа к услуге SAP (Service Access Point).

Рис. 8.6.

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

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

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

Архитектура сети BICC CS1

Два равнозначных блока CSF для уверенной передачи информа­ции между ними и индикации доступности услуг используют услугу транспорта сигнальной информации BICC (BICC Signaling Transport service). Таким образом, обмен сообщениями BICC между одноран­говыми протокольными единицами BICC происходит с использова­нием этой услуги, как показано на рис. 8.7.

Рис. 8.7. Функциональная архитектура системы транспорта сигнализации

Сигнальные транспортные конвертеры выполняют процедуры адаптации примитивов, определенных для взаимодействия ISUP и MTP3 в базовой сигнализации ОКС7, к специфическим примити­вам для той или иной системы транспорта сигнализации. Таким об­разом, сигнальный обмен между функцией обслуживания вызовов и сигнальным транспортным конвертером производится с исполь­зованием общих примитивов, а между конвертером и той или иной системой транспорта сигнализации - посредством специфических примитивов этой системы.

Примитивы переносят сообщения BICC (создаваемые функци­ей CSF), а также выполняют другие функции. Приведем описание общих примитивов, используемых системой транспорта сигнали­зации BICC:

• примитив IN-SERVICE.indication указывает, что сигнальный транспорт способен предоставить возможность обмена со­общениями между одноранговыми объектами. Эта индикация поддерживается через SAP независимо от сигнального прото­кола BICC. Примитив содержит индикатор level, определяющий уровень перегрузки;

• примитив OUT-OF-SERVICE.indication указывает, что сигнальный транспорт не способен предоставить возможность обмена со­общениями между одноранговыми объектами. Эта индикация также поддерживается через SAP;

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

• примитив TRANSFER.request используется протоколом BICC для передачи сообщений к одноранговому объекту.

• примитив TRANSFER.indication используется для предоставле­ния сигнального сообщения от однорангового объекта сигналь­ному протоколу BICC.

• примитив CONGESTION.indication используется для передачи информации о перегрузке;

• примитив START-INFO.indication сообщает протоколу BICC мак­симальную длину SDU(Service Data Unit), которые может переда­вать STC, и является ли узел ведущим в процедуре установления соединения.

Таблица 8.3. Общие примитивы системы сигнального транспорта BICC Универсальное название примитива Тип Запрос Индикация Подтверждение Отклик START-INFO - Max_Length CIC Control - - IN-SERVICE - Level - - OUT-OF-SERVICE - * - - CONGESTION - Level - - TRANSFER Sequence Control BICC Data Priority** BICC Data Priority **     - Эти примитивы не определены * - Примитив не имеет параметров ** - Этот параметр - национальная опция

Теперь перечислим параметры рассмотренных выше примитивов:

• параметр BICC Data содержит законченное сообщение BICC; оно представляется посредством SDU STC;

• параметр level указывает уровень перегрузки; значение пара­метра level зависит от реализации сети;

• параметр Sequence Control указывает для STC значение, которое может использоваться нижележащим сигнальным транспортом STC для разделения нагрузки и/или доставки сообщений с со­хранением очередности их следования (in-sequence);

• параметр MaxLength указывает максимальную длину сообще­ний, которые могут транспортироваться через используемую сигнальную связь;

• параметр CIC_Control указывает блоку BICC, является ли тот контрольным для четных или нечетных CIC текущей сигнальной связи;

• параметр Priority указывает приоритет сообщения BICC.

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

Уже не раз упоминалось, что основой для BICC является прото­кол ISUP, и, соответственно, BICC наследует его сообщения и про­цедуры. Сообщения BICC поступают от блока CSF к STC и имеют формат, представленный на рис. 8.8.

8 7 6 5 4 3 2 1

CIC

LSB

CIC

MSB

CIC

Код типа сообщения

Обязательные параметры постоянной длины

Обязательные параметры переменной длины

Необязательные параметры постоянной длины

Необязательные параметры переменной длины

Рис. 8.8. Формат сообщения BICC

CIC

Приведенная ниже табл. 8.4 содержит минимальный набор сооб­щений, поддержка которых должна быть реализована для междуна­родного интерфейса BICC. Все эти сообщения не содержат индика­торы инструкций совместимости сообщений (Message Compatibility Instruction Indicators), которые применяются, чтобы обеспечить совместимость разных версий BICC и, следовательно, должны быть распознаны SN самостоятельно.

Таблица 8.4. Сообщения протокола BICC ID Сообщение Значение сообщения   Address complete Принятый адрес достаточен   Answer Ответ   Call Progress Особенности маршрута соединения   Circuit Group Blocking Блокировка пучка   Circuit Group Blocking Acknowledgement Подтверждение блокировки пучка   Circuit Group Reset Возврат каналов пучка в исходное состояние   Circuit Group Reset Acknowledgement Подтверждение возврата каналов пучка в исходное состояние   Circuit Group Unblocking Разблокировка пучка   Circuit Group Unblocking Acknowledgement Подтверждение разблокировки пучка   Connect Ответ - соединить   Continuity Целость (индикация проключения несущего канала)   Confusion Несоответствие - прием нераспознанного сообщения/параметра   Facility Accepted Подтверждение приема запроса услуги   Facility Reject Отклонение этого запроса   Facility Request Запрос услуги   Forward Transfer Переключение связи   Initial Address Начальное адресное сообщение   Release Запрос разъединения   Release Complete Подтверждение разъединения   Reset Circuit Возврат канала в исходное состояние   Resume Возобновление связи   Subsequent Address Дополнительное адресное сообщение   Suspend Временное прерывание связи   User-to-user information Сообщения для обмена информацией между пользо­вателями

В табл. 8.4 пропущены сообщения, которые непосредственно не применяются в BICC, однако должны быть правильно распознаны для обеспечения взаимодействия с другими сетями. Эти сообще­ния приведены в табл. 8.5.

Таблица 8.5. Сообщения, распознаваемые в протоколе BICC ID Сообщение Значение сообщения   Blocking Блокировка   Blocking Acknowledgement Подтверждение блокировки   Continuity Check Request Запрос проверки целостности   Unblocking Разблокировка   Unblocking Acknowledgement Подтверждение разблокировки

Как следует из формата сообщений BICC (рис. 8.8), каждое та­кое сообщение составляется из нескольких обязательных и необя­зательных параметров. В табл. 8.6 приведены лишь те параметры, которые необходимы для международного интерфейса.

Таблица 8.6. Параметры протокола BICC Код Параметр Значение параметра   Access transport Транспорт в доступе   Automatic congestion level Уровень перегрузки   Backward call indicator Обратные индикаторы условий обслуживания вызова   Called party number Номер вызываемого абонента   Calling party number Номер вызывающего абонента   Calling party's category Категория вызывающего абонента   Cause indicators Индикаторы причины   Circuit group supervision message type indicators Индикаторы сообщения наблюдения за группой каналов (для BICC - только эксплуатационные)   Closed user group interlock code Код закрытой группы пользователей   Connected number Подключенный номер   Continuity indicators Индикаторы проверки целостности   End of optional parameters indicator Индикатор конца необязательного параметра   Event information Информация о событии   Facility indicator Индикатор дополнительной услуги   Forward call indicators Индикаторы особенностей обслуживания вызо­ва, передаваемые в прямом направлении   Nature of connection indicators Индикаторы типа соединения   Optional backward call indicators Необязательные индикаторы, передаваемые в обратном направлении   Optional forward call indicators Необязательные индикаторы, передаваемые в прямом направлении   Original called number Исходный номер вызываемого абонента   Range and status Диапазон и статус (число и статус каналов пуч­ка)   Redirecting number Номер,на который заказана переадресация   Redirection information Информация о переадресации   Redirection number Номер, на который произведена переадресация   Subsequent number Продолжение номера (в сообщении SAM)   Suspend/Resume indicators Индикаторы прерывания/возобновления связи   Transmission medium requirement Требования к среде передачи   User service information Информация об услуге для пользователя   User-to-user indicators Индикаторы пользователь-пользователь   User-to-user information Информация пользователь-пользователь

Практически все приведенные в табл. 8.6 параметры (как и сооб­щения BICC) заимствованы из сигнализации ISUP, но есть ряд осо­бенностей при их использовании в протоколе BICC. Так, параметр Continuity Indicators не указывает, в отличие от ISUP, на успешное завершение проверки целостности на текущем участке маршрута, но указывает на успешное завершение проверки целостности на предшествующем канале ISUP и/или на успешную организацию не­сущего канала на участке маршрута, предшествующем BICC-сети.

Имеются некоторые различия и в используемых понятиях. На­пример, в параметре hop counter, передаваемом в прямом направ­лении и убывающем при прохождении сообщения через транзит­ные узлы (для подсчета длины маршрута) нужно заменить значение ISUP interexchange circuits значением call control associations. Таким образом, параметр позволяет подсчитать не количество узлов, при помощи которых образован канал, а число сигнальных связей.

Одним из главных терминологических различий является Circuit Identification Code (CIC), имевший в ISUP значение идентификатора физического канала между парой узлов, а в BICC использующийся, чтобы обозначить сигнальный сеанс для управления обслуживани­ем определенного вызова Call Instance Code (CIC). В [12] отмечено, что CIC (Circuit Identification Code) в ISUP вместе с комбинацией OPC/DPC/NI выполняет две задачи: идентификацию физических каналов и идентификацию сигнального сеанса между одноранго­выми объектами ISUP. В протоколе BICC же CIC (Call Instance Code) используется только для второй задачи. Размер поля CIC увеличен с 12 битов в ISUP до 4 октетов, чтобы увеличить количество вызовов, одновременно обслуживаемых протоколом. Поскольку информа­ция DPC/OPC/NI не используется в BICC (при необходимости STC формирует эти значения для MTP3, MTP3b), CIC идентифицирует сигнальные связи между узлами. Для BICC число значений CIC, вы­деляемых для пары взаимодействующих узлов, представляет собой максимальное число сигнальных сеансов, которые могут существо­вать между ними.

Routing Label, содержащая информацию, которая передается к MTP для маршрутизации сообщений, а в BICC не используется. Если BICC развернут на MTP3 или MTP3B, то Routing Label форми­руется на подуровне STC.

Вместе с набором параметров и сообщений BICC унаследовал от ISUP и набор процедур, определенных в рекомендации Q.764, ко­торый, правда, подвергся частичному изменению. Был определен ряд дополнительных процедур, связанных с отделением носителя. Их рассмотрение потребовало бы значительного увеличения раз­меров главы и усложнения ее структуры, но для понимания принци­пов протокола BICC знать эти процедуры не обязательно.