1

РЕКОМЕНДАЦИЯ ITU-T Q.1901 ПРОТОКОЛ BICC

Эта рекомендация описывает адаптацию пользовательской части узкополосной ISDN (ISUP) для поддержки услуг ЦИФРОВОЙ СЕТИ ИНТЕГРАЛЬНОГО ОБСЛУЖИВАНИЯ, независимых от технологии несущего канала и используемой технологии транспортировки сообщения. Рекомендация написана как набор исключений или дополнений к рекомендациям для ISUP. Протокол, определенный в соответствии с этой Рекомендацией - протокол управления вызовами, который нужно использовать между так называемыми Serving nodes (узлами обслуживания). Его название - "Протокол управления вызовом независимо от несущего канала" (BICC). Управление несущими каналами между Serving nodes обеспечивается в соответствии с другими протоколами - не указанными в этой Рекомендации. Определены три типа Serving nodes (SN): • Interface Serving Node (ISN) - этот тип узла обеспечивает интерфейс к сетям

с коммутацией каналов. • Transit Serving Node (TSN) - этот тип узла обеспечивает транзитные

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

• Gateway Serving Node (GSN) - этот тип узла обеспечивает функциональные возможности шлюза для вызова и несущего канала, используя BICC протокол.

Основная часть рекомендации определяет протокол в Transit Serving Node и Gateway Serving Node (GSN). Содержание рекомендации схематично пояснено на Рисунке 1.

T11107710-00

Serving Node (SN)

Bearer Control Signalling Bearer Control Signalling

Bearer

SCOPE OF THE MAINBODY OF THIS

RECOMMENDATION

Call Control Signalling(BICC protocol)

Call Control Signalling(BICC protocol)

Call ServiceFunction (CSF)

Bearer ControlFunction (BCF)

Рисунок 1/Q.1901 - Возможности ITU-T Q.1901

В определении процедур для BICC при Interface Serving Node (ISN) рекомендация также определяет, как BICC взаимодействует с другими протоколами. Эти описания содержатся в комментариях к этой рекомендации.

2

Эта Рекомендация также содержит приложение III, которое определяет Call Mediation Node, в котором могут быть реализованы функции управления вызовом, без управления несущим каналом. Рекомендация вводит следующие термины: 1 Функция управления несущим каналом (BCF): Четыре типа BCF определены; BCF-N, BCF-T, BCF-G и BCF-R. BCF-N, BCF-T и BCF-G обеспечивают управление относительно функции коммутации несущего канала, содержат коммуникационные возможности ассоциированной с ним CSF (Serving Node в общем случае содержит BCF и CSF), и возможности сигнализации, необходимые для установления и освобождения несущего канала к другому BCF, равному по положению. BCF-R обеспечивает управление относительно коммутирующей функции несущего канала и передает запросы управления несущим каналом к следующему BCF, для того чтобы обеспечить сигнальное соединение из конца в конец. BCF не рассматривается этой Рекомендации. 2 Функция Межсетевого взаимодействия несущих каналов (BIWF): функциональный объект, который обеспечивает функции управления несущим каналом (BCF) и функции мэппинга/коммутации в пределах Serving Node (SN). BIWF содержит один BCF. 3 Call Mediation Node (CMN): функциональный объект, который обеспечивает функциональные возможности CSF без связанного с ним BCF объекта. 4 Функция обслуживания вызовов (CSF): Четыре типа CSF определены: • Узловая функция обслуживания вызова (CSF-N): обеспечивает сервисный

контроль (управление) действиями узла, связанными с узкополосной и независимой от несущего канала сигнализацией, передачу сигналов характеристик вызова равному по положению CSF, и использование Bearer Control Nodal Functions (BCF-N), необходимых для транспортировки узкополосных несущих каналов управления через базовую сеть.

• Транзитная функция обслуживания вызовов (CSF-T): обеспечивает транзитные сервисные действия, необходимые для установления и обслуживания (поддержки) вызова в базовой сети (см. Рисунок 2), а так же связанного с ним несущего канала, ретранслируя сообщения между равными по положению CSF, с использованием Функций Bearer Control Transit Functions (BCF-T), необходимых чтобы транспортировать узкополосный несущий канал управления через базовую сеть.

• Шлюзовая функция обслуживания вызовов (CSF-G): обеспечивает управляющие межсетевые действия, необходимые для того чтобы устанавливать и обслуживать (поддерживать) вызов в базовой сети, а так же связанный с ним несущий канал, ретранслируя сообщения между равными по положению CSF, с использованием Bearer Control Gateway Functions (BCF-G), необходимых для транспортировки узкополосного канала управления между различными базовыми сетями.

• Функция координации обслуживания вызовов (CSF-C): обеспечивает координацию вызова и посреднические действия, необходимые чтобы устанавливать и обслуживать (поддерживать) вызов в базовой сети, ретранслируя сообщения между равными по положению CSF. CSF-C не имеет никакой ассоциации с каким-либо BCF. Это - только функция управления вызовом.

5 Конструктор: информационный элементный тип, содержание которого состоит из других информационных элементов, как это описано в ITU-T Q.765.5. 6 Gateway Serving Node (GSN): функциональный объект, который обеспечивает межсетевые функциональные возможности между двумя сетевыми доменами (областями). Этот функциональный объект содержит функцию обслуживания вызовов (CSF-G), и один или большее количество объектов

3

межсетевого взаимодействия несущего канала (BIWF). GSN взаимодействуют с другими GSN в других доменах (областях) базовой сети, и другими ISNs и TSNs в пределах собственного домена (области) базовой сети. 7 Interface Serving Node (ISN): функциональный объект, который обеспечивает интерфейс с SCN (сеть с коммутацией каналов). Этот функциональный объект содержит узловую функцию обслуживания вызовов (CSF-N), и один или большее количество блоков функций межсетевого взаимодействия несущего канала (BIWF), которые взаимодействуют с SCN и равными по положению блоками в пределах базовой сети. 8 Список поддерживаемых кодеков: Список кодеков, используемых между двумя SN. Он включает все кодеки поддерживаемые в SN. 9 Список доступных кодеков: Этот список содержит все кодеки, которые могут использоваться для установки вызова и в активной стадии вызова. 10 Signalling Transport Layers (STL): Любой набор протоколов, в настоящее время сертифицированных для обеспечения услуг Транспортного и/или Сетевого уровня для BICC. Их функции, протоколы и сервисные примитивы не рассматриваются в этой рекомендации. 11 Узел обслуживания (SN): функциональный объект, которым может быть или ISN, или GSN, или TSN. 12 Signalling Transport Converter (STC): протокольный уровень между STL и BICC. Этот уровень дает возможность протоколу BICC быть независимым от используемого STL. 13 simple (примитив): информационный элементный тип, описан в ITU-T Q.765.5. 14 Switching Node (SWN): функциональный объект, который обеспечивает коммутирующие функции в пределах базовой основной сети. Этот функциональный объект содержит BCF-R. SWN взаимодействуют с другими SWN и BIWF в пределах собственного домена (области) базовой сети. 15 Switched Circuit Network (SCN): универсальный термин для любой сети, которая использует технологию коммутации каналов, например: ЦИФРОВАЯ СЕТЬ ИНТЕГРАЛЬНОГО ОБСЛУЖИВАНИЯ, PSTN, PLMN. 16 Transit Serving Node (TSN): функциональный объект, который обеспечивает транзитные функциональные возможности между двумя SN. Этот функциональный объект содержит функцию обслуживания вызовов (CSF-T), и поддерживает одну или большее количество функций межсетевого взаимодействия несущего канала (BIWF). TSN взаимодействуют с другими TSN, GSN и ISN в пределах собственного домена (области) базовой сети.

4

Архитектура 1.1 Сетевая модель Рисунок 2 показывает законченную функциональную модель сети, использующей протокол BICC для передачи сигналов управления вызовом.

T11107720-00

Signalling Transport Network

CallControl

Signalling

BearerControl

Signalling

TE TEISDN-A

ISN-ACSF-N

BearerInterworking

Function(BIWF)

BackboneNetwork

ConnectionLink

CSF-T CSF-G CSF-G CSF-C CSF-N

ISDN-B

Backbone Network Connections

Network Bearer Connection (end-to-end)

TSN GSNGSN CMN ISN-B

BCF-N BCF-R

SWN-1 SWN-2 SWN-3 SWN-4

BCF-T BCF-R BCF-G BCF-G BCF-R BCF-R BCF-N

Рисунок 2/Q.1901 - Сетевая Функциональная модель 1.2 Модель Протокола Рисунок 3 показывает модель протокола, принятую для этой рекомендации.

T11107730-00

BICC procedures

genericinterface

genericinterface

SignallingTransportConverter

MappingFunction

SignallingTransport

Layers

BearerControl

transportspecificinterface

bearerspecificinterface

call controlprotocol

bearer controlprotocol

5

Рисунок 3/Q.1901 - модель Протокола Аспекты протокола функциональной модели в Рисунке 2 разъясняются элементами модели протокола в Рисунке 3. • Блок процедур BICC включает функции элемента CSF в функциональной

модели. • Функции протокольного элемента BCF функциональной модели

распределены между Функцией Мэппинга и Блоками Управления Несущим каналом как это показано на Рисунке 3. Другие функции, включенные в элемент BCF, например контроль (управление) относительно коммутирующих функций, не показываются в Рисунке 3.

• Где описание BICC касается посылки/получения сигнальных сообщений несущего канала от/на BCF, имеет место использование универсального интерфейса к блоку функции мэппинга, как это показано на Рисунке 3.

• Где описание BICC касается посылки/получения сообщения BICC, это касается использования универсального интерфейса к Signalling Transport Converter, описанного в дополнении B.

Далее в скобках будет указываться номер главы в рекомендации Q.1901. 2(7) Расширения к ITU-T Q.761 2.1(7.1) Введение Протокол BICC - адаптация ISUP, но не является однозначно совместимым с ISUP. BICC протокол включает механизм совместимости с ISUP, а так же подобный механизм для пользовательских приложений APM (Application Transport Mechanism) в пределах BICC. Таким образом: 1) Одно-ранговая совместимость версий BICC может быть достигнута в

соответствии с тем, как это описано для ISUP в приложении 6/Q.761. 2) Механизм совместимости в Serving Node (ISN/TSN/GSN) действует как при

обмене сообщениями ISUP, и таким образом введение BICC в сеть, использующую передачу сигналов ISUP не ухудшает способности вводить новые версии сигнализации в сеть. Например, ISN, принимающий неопознанный параметр ISUP, обработает его согласно правилам совместимости 2.9.5/Q.764, используя BICC если потребуется.

2.2(7.2) Прямая и обратная совместимость BICC для

пользовательских приложений APM BICC использует пользовательские приложения APM, чтобы передавать сигнальную информацию. Таким образом, чтобы обеспечивать прямую и обратную совместимость в пределах BICC, механизм совместимости представлен для информационных элементов, передаваемых APM. Этот механизм совместимости остается неизменным для всех наборов возможностей и/или подмножеств протокола BICC, определенного в Рекомендации. Это достигается передачей информации совместимости вместе с сигнальной информацией. Метод совместимости упрощает сетевые операции, например в следующих случаях: • В качестве типичного случая: несовпадение версий сигнального протокола

BICC в течение сетевого обновления; • В случае необходимости связать две сети на различных функциональных

уровнях;

6

• Для сетей, использующих различные подмножества того же самого BICC протокола, и т.д.

ПРИМЕЧАНИЕ - узел может относиться к различным функциональным уровням из-за того, что им используются различные наборы возможностей или используется различные подмножества протокола, указанного в Рекомендации. 2.2.1(7.2.1) Правила совместимости в обратном направлении Совместимое межсетевое взаимодействие между наборами возможностей протокола при определении нового набора возможностей должно быть оптимизировано, твердо придерживаясь следующих правил: 1) Существующие элементы протокола, то есть процедуры,

информационные элементы и значения подполей, не должны быть изменены (заменены), если требуется исправить ошибку протокола, или становится необходимо изменить (заменить) операцию обслуживания, которая поддерживается в соответствии с протоколом.

2) Семантика информационного элемента, или поля и подполя в пределах информационного элемента не должна быть изменена (заменена).

3) Установленные правила для форматирования и кодирования информационных элементов не должны измениться.

2.2.2(7.2.2) Механизм совместимости в прямом направлении Совместимость между существующим и будущими наборами возможности будет гарантироваться, в смысле, что любые два набора возможностей могут взаимодействовать непосредственно друг с другом, если следующие требования будут выполнены: 1) Протокольная совместимость Запросы между любыми двумя протоколами BICC не должны приводить к

ошибкам из-за не удовлетворения требованям протокола. 2) Сервисная и функциональная совместимость Эта совместимость может рассматриваться как совместимость между

конечными узлами. Услуги и функции, доступные в этих узлах, но возможно еще не принятые на промежуточных узлах, поддерживаются, при условии, что информацию, связанную с этими услугами и функциями можно пропускать прозрачно через промежуточные узлы.

3) Контроль ресурсов и возможности управления Для этих функций, встречаемых только при связи link-by-link, необходимо

по крайней мере обратное уведомление, если не возможна правильная обработка запросов и сигналов.

2.3(7.3) Поддерживаемые возможности Таблица 1 демонстрирует расширения к Таблице 1/Q.761. Элементы, включенные в Таблицу 1/Q.761, но не упомянутые в Таблице 1, применяются без исключения.

Таблица 1/Q.1901 - BICC исключения к Таблице 1/Q.761 Function/service National use International Basic call Continuity check (Note 1) (Note 1) Propagation delay determination procedure X X Enhanced echo control signalling procedures - - Blocking and unblocking X X Circuit group query X - Dual seizure X X Transmission alarm handling for digital inter-exchange circuits - -

7

Reset X X Temporary trunk blocking - - ISDN User Part signalling congestion control (Note 2) (Note 2) ISDN User Part availability control (Note 3) (Note 3) MTP pause and resume (Note 2) (Note 2) ПРИМЕЧАНИЕ 1 (Note 1) - функция проверки целостности не поддержана, но это не препятствует правильной операции процедуры проверки целостности в предшествующем или следующем SCN. ПРИМЕЧАНИЕ 2 (Note 2) - Если BICC развернут на сигнальной транспортной службе MTP3 или MTP3B, эти функции, обеспечивается подуровнем STC, см. Приложение C (Annex C). ПРИМЕЧАНИЕ 3 (Note 3) - Если BICC развернут на сигнальной транспортной службе MTP3 или MTP3B, эквивалентная процедура обеспечивается подуровнем STC. Приложение С (Annex C).

Таблица 2/Q.761 применяется со следующими исключениями: Относительно дополнительных служб MLPP: поддерживается только транзит информации MLPP. ПРИМЕЧАНИЕ - использование BICC непрерывных методов доставки сообщений (из конца в конец) SCCP – задача для дальнейшего изучения. 2.4(7.4) Интерфейс к сигнальной транспортной службе. Протокол BICC использует для транспортировки сообщений уровень STC, и таким образом предложение 4/Q.761 и Таблица 3/Q.761 заменено универсальным транспортным интерфейсом, как это описано в приложении B (Annex B). 2.5(7.4) Минимальный набор сообщений для международного

интерфейса Таблица 4/Q.761 заменена Таблицей 2. Эта таблица перечисляет сообщения, используемые BICC, которые не содержат Индикаторы Инструкций Совместимости Сообщений (Message Compatibility Instruction Indicators), и таким образом должны быть распознаны SN самостоятельно. Это не налагает требование, чтобы связанные функции были осуществлены, но функция должна быть правильно отклонена (в случае необходимости). Таблица 2/Q.1901 - Минимальный набор сообщений для международного

интерфейса

1 Address complete 2 Answer 3 Blocking 4 Blocking Acknowledgement 5 Call Progress 6 Circuit Group Blocking 7 Circuit Group Blocking Acknowledgement 8 Circuit Group Reset 9 Circuit Group Reset Acknowledgement 10 Circuit Group Unblocking 11 Circuit Group Unblocking Acknowledgement 12 Connect 13 Continuity

8

14 Confusion 15 Continuity Check Request 16 Facility Accepted 17 Facility Reject 18 Facility Request 19 Forward Transfer 20 Initial Address 21 Release 22 Release Complete 23 Reset Circuit 24 Resume 25 Subsequent Address 26 Suspend 27 Unblocking 28 Unblocking Acknowledgement 29 User-to-user information

Примечание: вычеркнутые пункты – не применяются в BICC, однако должны быть грамотно распознаны. 3(8) Исключения к ITU-T Q.762 В перечнях сообщений и параметрах нужно заменить "circuit" на "CIC value". 1) Blocking message, 2.4/Q.762, не используется. 2) Blocking Acknowledgement message, 2.5/Q.762, не используется. 3) Continuity message, 2.18/Q.762, BICC не использует Continuity message чтобы

указать на успешный результат проверки целостности на текущем участке маршрута вызова, но используется, чтобы указать успешное завершение проверки целостности на предшествующей цепи ISUP, и/или успешную установку несущего канала на предшествующем BICC участке маршрута вызова.

4) Continuity Check Request message, 2.19/Q.762, не используется. 5) Loop Back Acknowledgement message, 2.30/Q.762, не используется. 6) Overload message, 2.33/Q.762, не используется. 7) Unblocking message, 2.44/Q.762, не используется. 8) Unblocking Acknowledgement message, 2.45/Q.762, не используется. 9) User Part Available message, 2.47/Q.762, не используется. 10) User Part Test message, 2.48/Q.762, не используется. 11) Параметр Circuit Assignment Map, 3.24/Q.762, не используется. 12) Параметр circuit group Supervision message type, 3.25/Q.762, может

указывать только на "эксплуатационное" блокирование. 13) Параметр Continuity Indicators, 3.32/Q.762, не указывает успешное

завершение проверки целостности на текущем участке маршрута вызова, но указывает на успешное завершение проверки целостности на предшествующей цепи ISUP и/или успешной установке несущего канала на предшествующем BICC участке маршрута вызова.

14) Параметр hop counter, 3.45/Q.762. Нужно заменить "ISUP interexchange circuits" на "call control associations".

15) Circuit Identification Code, 4.27/Q.762, используется BICC, чтобы указать образец передачи сигналов управления вызовом. То есть это - "Код Образца Вызова" ("Call Instance Code").

16) Индикатор continuity check, 4.36/Q.762, не используется для указания, что проверка целостности будет выполнена на текущем участке маршрута вызова, но используется чтобы указать, что Continuity message может быть получен в качестве результате проверки целостности на предшествующей

9

цепи ISUP, или при установлении соединения на участке, предшествуем BICC.

17) Routing Label, 4.132/Q.762, не пропускаются от BICC до MTP. Если BICC развернут на MTP3 или MTP3B, Routing Label обеспечивается подуровнем STC. См. описание соответствующего STC в Приложении C (Annex C).

4(9) Исключения к ITU-T Q.763 4.1(9.1) Формат Сообщения Формат сообщения в BICC к интерфейсу STC - согласно ITU-T Q.763 со следующими исключениями: 1) Routing Label, как на Рисунке 1/Q.763, так и на Рисунке 3/Q.763, не

пропускаются от BICC до STC. 2) Формат circuit identification code (Рисунок 2/Q.763) изменён как показано на

Рисунке 4. (CIC является акронимом для Call Instance Code, в контексте BICC).

8 7 6 5 4 3 2 1

1 CIC LSB

2 CIC

3 CIC

4 MSB CIC

Рисунок 4/Q.1901 - поле CIC

4.2(9.2) Назначение CIC Правила распределения CIC, описанные в 1.2/Q.763 не относятся к BICC. Для распределения значений CIC требуется двусторонняя договорённость. ПРИМЕЧАНИЕ - номера CIC распределяются между парой смежных узлов при помощи определённого числа параллельных запросов. 4.3(9.3) Сообщения Сообщения, определенные в ITU-T Q.763 используются со следующими исключениями: 1) Blocking message не используется. 2) Blocking Acknowledgement message не используется. 3) Continuity Check Request message не используется. 4) Loop Back Acknowledgement message не используется. 5) Overload message не используется. 6) Unblocking message не используется. 7) Unblocking Acknowledgement не используется. 8) User Part Available message не используется. 9) User Part Test message не используется. 4.4(9.4) Параметры Определения параметров Q.763 применяются со следующими исключениями: 1) Значение "hardware failure oriented" индикатора circuit group Supervision

message type в параметре circuit group Supervision message type, 3.13/Q.763, не используется.

2) Аппаратные блокирующие средства, биты FE параметра Circuit state indicator, 3.14/Q.763 не используются.

10

3) Значение "continuity check required on this circuit" индикатора continuity check в параметре Nature of Connection Indicators, 3.35/Q.763, не используется.

4) Параметр Circuit Assignment Map, 3.69/Q.763 не используется, и таким образом удален из Таблицы 32/Q.763.

5(10) Исключения к ITU-T Q.764 5.1(10.1) Введение 5.1.1(10.1.1) Использование поля CIC В отличие от ITU-T Q.764, где сигнальные процедуры применимы для вызова и/или управления каналом, сигнальные процедуры в этой Рекомендации применимы к управлению вызовом и его координации с управлением несущим каналом. Услуги несущих каналов, в отличие от физических каналов в сетях с коммутацией каналов, вызываются через определённые протоколы управления несущим каналом. Роль обязательной сигнальной информации, "Circuit Identification Code" является очень важной в процедурах ISUP. И поскольку в BICC протоколе она выступает в качестве "Call Instance Code", разъяснена следующим образом: CIC в ISUP, вместе с комбинацией OPC/DPC/NI, обслуживает следующие цели: 1) Идентификация физических каналов. 2) Идентификация сигнального отношения между равными по положению

объектами ISUP и ассоциация всех сообщений к этому отношению. Роль CIC в протоколе BICC - вторична. Размер поля CIC увеличен на 4 октета, чтобы устранить ограничение размера, следующее из назначения 12 бит для CIC в ISUP. Поскольку информация DPC/OPC/NI не видна для BICC (только в STC для MTP3, MTP3b), CIC существенен в зависимости от контекста сигнализации BICC (то есть, например, посредством STC). Для BICC число значений CIC выделяемых для пары взаимодействующих узлов представляет собой максимальное число сигнальных отношений, которые могут существовать между ними. 5.1.2(10.1.2) Использование Прикладного Транспортного Механизма

(Application Transport Mechanism) Этот подпараграф описывает, как BICC использует транспортный механизм, определенный в ITU-T Q.765.5. Процедуры BICC требуют передачи информации между равными по положению SN. Bearer Association Transport (BAT), APM ASE (Application Service Element) используются, чтобы обеспечить транспортный механизм для этой информации. Интерфейс между этой Рекомендацией, и BAT ASE обеспечивается следующими примитивными элементами:

Таблица 3/Q.1901 - интерфейс примитива BAT

Primitive name Types Direction (Note)

BICC_Data Indication/Request /

BICC_Error Indication

Примечание – поток примитива от BAT к BICC (через SACF): поток примитива от BICC к BAT (через SACF-Single Association Control Function):

11

5.1.2.1(10.1.2.1) Индикаторы инструкций транспортных приложений Индикаторы инструкций транспортных приложений (Application Transport Instruction Indicators-ATII) должны быть представлены в BICC_Data request, чтобы обеспечить правильную обработку ошибочных случаев, например, если контекст BAT неопознан при приеме в случае обмена. ATII должен содержать следующее: Бит A: индикатор Release call 1 освободить вызов Бит B: индикатор Send notification 0 Не посылать уведомление 5.1.2.2(10.1.2.2) Обработка Информации Адресования Должно использоваться неявное адресование, (см. ITU-T Q.765). 5.1.2.3(10.1.2.3) Дополнительные процедуры При приеме примитива BICC_Error indication, содержащего уведомление об ошибке, указывающего на "unidentified context/addressing error" (неопознанный контекст/ошибка адресования), вызов должен быть освобожден со значением причины #79 "service or option not implemented, unspecified" и должна быть уведомлена эксплуатационная система. При приеме примитива BICC_Error indication, содержащего уведомление об ошибке, указывающего на "reassembly error", вызов должен быть освобождён со значением причины #111 "protocol error, unspecified" и должна быть уведомлена эксплуатационная система. При приеме примитива BICC_Error indication, содержащего уведомление об ошибке, указывающего на "unrecognized information" (неопознанная информация), применяются возможности, указанные в 5.1.2.4(10.1.2.4). 5.1.2.4(10.1.2.4) Совместимость для пользовательских приложений BICC

APM 5.1.2.4.1(10.1.2.4.1) Общие требования по получению неопознанной

сигнальной информации Может случаться, что узел принимает неопознанную сигнальную информацию, то есть типы информационных элементов или значений подполей. Это как правило случается при обновлении системы сигнализации, используемой другими узлами в сети. В этих случаях вызываются следующие процедуры совместимости, чтобы гарантировать предсказуемый сетевой режим. Все элементы информации BAT включают поле совместимости как это определено в ITU-T Q.765.5 [6]. Процедуры, которые нужно задействовать при получении неопознанной информации используют: • Поле совместимости, принятое вместе с информационными элементами; • Элемент BAT Compatibility Report information, включающий Report Reason и

Diagnostics. Используются следующие Report Reason: • "Information element non-existent or not implemented" – элемент информации,

несуществующий или не реализованный;

12

• "BICC data with unrecognized information element, discarded" – данные BICC с неопознанным информационным элементом, отвергнутым.

По вышеупомянутым Report Reason и Diagnostics идентифицируются неопознанные информационные элементы.

Процедуры основаны на следующих предположениях: 1) Так как узлы могут быть и национальными, и международными, механизм

совместимости применим к национальной и международной сети. 2) Если узел принимает информационный элемент BAT Compatibility Report,

указывающий на полученный неопознанный информационный элемент, то это означает взаимодействие с узлами, поддерживающими различный функциональный уровень.

Когда принимается неопознанный информационный элемент, узел будет искать некоторые соответствующие инструкции, указанные в поле информации совместимости информационного элемента. Индикаторы инструкций состоят из двух подполей, одно, чтобы указать, как обработать неопознанные информационные элементы и другое, чтобы указать, что делать, когда неопознанный информационный элемент не может быть распознан. Следующие общие правила применяются для интерпретации этих индикаторов инструкций: a) "Зарезервированные" подполя поля совместимости не описаны. Они могут

использоваться будущими наборами возможности этой Рекомендации; в этом случае, будущие наборы возможностей установят определённые в настоящее время индикаторы инструкций в разумное значение для узлов, осуществляющих текущий набор возможностей. Это правило гарантирует, что в будущем может быть определено большее количество типов команд без создания проблемы обратной совместимости.

b) Вызов отбивается с использованием значения причины #31 "normal, unspecified" (нормальный, неопознанный), если индикатор инструкции установлен в значении "Release Call".

c) Если индикатор инструкции установлен в: "Discard information element", информационный элемент будет отвергнут, согласно инструкции. Если индикатор Send Notification установлен в значение "Send Notification", то в направлении узла, который послал неопознанную информацию будет выслан информационный элемент BAT Compatibility Report с соответствующими полями Report Reason and Diagnosis.

d) Если индикатор инструкций установлен в значении "pass-on", неопознанный информационный элемент пропускают к сигнальной ассоциации с другой стороны SN для этого вызова. Если не возможно передать этот элемент насквозь через SN, то используются индикаторы инструкций "pass-on not possible". ПРИМЕЧАНИЕ - Примеры того, где "pass-on", не возможно: В ISN или в GSN между различными операторами, где возможность применения "pass-on", может зависеть от двусторонних соглашений.

e) Для случая неопознанного информационного элемента возможна инструкция требующая, чтобы или неопознанный информационный элемент, или все информационные элементы, касающиеся полученного параметра APP (Application Transport Parameter), содержащего нераспознанный элемент были отвергнуты. Это предусматривает случай, когда отправляющий узел решает, что не приемлемо продолжать обработку данного параметра APP без этого информационного элемента.

13

5.1.2.4.2(10.1.2.4.2) Процедуры для обработки нераспознанных

информационных элементов 5.1.2.4.2.1(5.1.2.4.2) Нераспознанные информационные элементы Нераспознанные информационные элементы, принятые в BICC_Error indication primitive, обрабатываются как нераспознанные информационные элементы. Неожидаемые информационные элементы, принятые в BICC_Data indication primitive, обрабатываются подобно неопознанным информационным элементам. В зависимости от инструкций, полученных в поле Information Element Compatibility Information field, узел, принимающий нераспознанный информационный элемент выполнит одно из следующих действий: a) Отобъёт вызов; b) Сбросит все связанные информационные элементы и пошлёт

уведомление; c) Сбросит все связанные информационные элементы; d) Сбросит информационный элемент и пошлёт уведомление; e) Сбросит информационный элемент; или f) Прозрачно передаст информационный элемент. В случае d), информационный элемент BAT Compatibility Report должен включать Report Reason со значением "information element non-existent or not implemented", сопровождаемый полем Diagnostic, содержащим пару Information Element Identifier и Index subfields для каждого упоминаемого нераспознанного информационного элемента. В случае b), информационный элемент BAT Compatibility Report должен включать Report Reason со значением "BICC data with unrecognized information element, discarded", сопровождаемый полем Diagnostic, содержащим Information Element Identifier (первого обнаруженного нераспознанного информационного элемента, который привёл к отклонению примитива) и Индексное подполе (Index subfields). Индексное подполе должно быть кодировано следующим образом: Индексное подполе содержит указатель на нераспознанный октет Information Element Identifier. Таким образом: 1) Для информационного элемента типа ПРИМИТИВ, см. ITU-T Q.765.5,

Индекс всегда кодирован как "0"; 2) Для элемента информации КОНСТРУКТОР Индекс кодирован как "0", если

сам элемент информации Конструктор не распознан, но кодирован со значением смещения октета, (см. ITU-T Q.765.5), или если нераспознанный информационный элемент – под-элемент в пределах элемента информации Конструктор.

Это применительно к элементам информации Конструктор на высшем уровне структуры в пределах параметра APP. Это не должно применяться рекурсивно в пределах элемента информации Конструктора.

При приеме примитива BICC_Error indication, включающем множественные нераспознанные информационные элементы, различные индикаторы инструкций, связанные с этими информационными элементами, должны быть обработаны в приоритетном порядке, согласно списку, a) - f), приведённому выше. Когда вызов освобождён из-за процедур совместимости, информационный элемент BAT Compatibility Report должен быть передан в BICC_Data request primitive, (передача пред-освободительного сообщения) к узлу, который послал нераспознанный информационный элемент.

14

Если примитив BICC_Error indication primitive, содержащий значение "unrecognized information" (нераспознанная информация), получен относительно пред-отбойного сообщения (Pre-Release Information message), в зависимости от команд, полученных в поле Information Element Compatibility узел: a) Или откажется от всех связанных информационных элементов; b) Или откажется от информационного элемента; c) Или передаст информационный элемент прозрачно. При приеме примитива BICC_Error indication, включающего множественные нераспознанные информационные элементы, относящиеся к Pre-Release Information message, различные индикаторы инструкций, связанные с этими информационными элементами, должны быть обработаны в приоритетном порядке, согласно списку, a) c), приведённому выше. Для нераспознанной информации внутри Pre-Release Information message или для нераспознанной информации внутри информационного элемента BAT Compatibility Report внутри примитива BICC_Data indication primitive никакой информационный элемент BAT Compatibility Report не посылается. 5.1.2.4.2.2(10.1.2.4.2.2) Нераспознанные поля Не существует никакой определенной информации совместимости для каждого поля. Для всех полей, содержащихся в информационном элементе, применяется информация совместимости информационного элемента. 5.1.2.4.3(5.1.2.4.3) Процедуры для обработки ответа, указывающего на то,

что была послана нераспознанная информация Действия, принимаемые при получении информационного элемента BAT Compatibility Report, будут зависеть от того, имеет ли станция функциональные возможности, чтобы генерировать информационный элемент, указанный в диагностическом поле: a) Если станция не имеет функциональных возможностей, чтобы

генерировать информационный элемент, решение относительно того, что за действие должно быть принято, передается станции, которая содержит эти функциональные возможности. Это достигается пропуском элемента информации BAT Compatibility Report information element прозрачно через станцию.

b) Если этот станция содержит функциональные возможности, чтобы генерировать информационный элемент, любые последующие действия должен определить процедурный элемент, который создавал или изменил информацию,.

Заданное по умолчанию действие при получении информационного элемента BAT Compatibility Report – это отказаться от примитива, содержащего BAT Compatibility Report без того, чтобы прервать нормальную обработку вызова. 5.1.3(10.1.3) Общее введение в исключения к Q.764 Процедуры, описанные в ITU-T Q.764 [4] применимы с разъяснениями/исключениями, описанными в этом подпараграфе. Поскольку это общая инструкция, не во всех случаях она подходит для описания процессов возникновения и установления местных телефонных вызовов. Существуют три варианта для обработки несущих каналов: 1) Подключение несущего канала устанавливается и разрушается для

каждого вызова, устанавливаемого или освобождаемого. Несущий канал проключается в прямом направлении.

15

2) Подключение несущего канала устанавливается и разрушается для каждого вызова, устанавливаемого или освобождаемого. Несущий канал проключается в обратном направлении.

3) Подключение несущего канала не разрушается по окончании вызова, но поддерживается, и может многократно использоваться для последующего вызова. (Многократное использование неактивных несущих каналов - сетевая опция, см. приложение A.)

Необязательные процедуры обеспечиваются для поддержки возможностей переговоров кодеков и модификации. 5.1.4(10.1.4) Типы станций ITU-T Q.764 определяет процедуры ISUP, связанные с шестью типами станций:

1) Originating exchange;

2) Intermediate national exchange;

3) Outgoing international exchange;

4) Intermediate international exchange;

5) Incoming international exchange

6) Destination exchange. Функциональная модель для BICC содержит три типа SN: ISN, TSN и GSN. Таблица 4 указывает какой тип станции может поддерживать каждый из BICC SN.

Таблица 4/Q.1901 - Отношения между типом станции Q.764 и типами SN

Q.764 exchange type SN type

Originating exchange Не применим

Intermediate national exchange ISN, TSN, GSN

Outgoing international exchange ISN, GSN

Intermediate international exchange ISN, TSN

Incoming international exchange ISN, GSN

Destination exchange Не применим

5.2(10.2) Основное управление вызовом и сигнальные процедуры 5.2.1(10.2.1) Успешная установка вызова 5.2.1.1(10.2.1.1) Прямая адресная сигнализация 5.2.1.1.1(10.2.1.1.1) Действия, требуемые от вызывающей станции

(Originating exchange) Параграф 2.1.1.1/Q.764 не рассматривается в BICC. 5.2.1.1.2(10.2.1.1.2) Действия, необходимые на промежуточной

национальной станции (Intermediate national exchange, Intermediate SN) Для каждого варианта обработки несущего канала применяются следующие модифицированные процедуры 2.1.1.2/Q.764: a) Исходящее направление

16

Промежуточная национальная станция, по получении сообщения начального адреса (initial address message) анализирует номер вызываемого абонента (called party number) и другую информацию маршрутизации (см. 2.1.1.1 a) /Q.764) определяя маршрутизацию вызова. Если промежуточная национальная станция может направлять вызов, используя connection type, указанный в параметре требования среды передачи (transmission medium requirement parameter), то занимается свободное значение CIC, и применяется процедура IAM Sending Control procedure (10.2.1.1.2.3). Процедуры установления входящего вызова BICC (10.2.1.1.2.2) запускаются, когда вызов может быть смаршрутизирован. В пределах сети, если промежуточная национальная станция не может маршрутизировать вызов используя connection type, указанный в параметре запроса среды передачи (transmission medium requirement parameter), станция может также проверить служебную информацию пользователя, содержащую информацию возможностей несущего канала и/или пользовательскую телесервисную информацию, содержащую информацию совместимости верхнего уровня, если она доступна, для того чтобы определить, может ли подходящий маршрут быть выбран. В этом случае, если предоставляется новый connection type, параметр требования среды передачи изменяется соответственно новому connection type.

b) Параметры в сообщении initial address message Промежуточная национальная станция может изменять сигнальную

информацию, полученную от предшествующей станции согласно возможностям, используемым на исходящем маршруте. Сигнальная информация, которая может быть изменена – это характер индикатора подключения и счетчик задержки распространения (connection indicator и propagation delay counter). Данные BAT ASE не обязательно передаются прозрачно. Другая сигнальная информация передается прозрачно, например параметр доступа транспортировки (access transport parameter), служебная информация пользователя, и т.д. Порядок информационных элементов, которые переносятся в access transport parameter, полученном от входящей станции должен быть сохранен. Сопутствующий индикатор в параметре характера подключения должен быть увеличен, если выбранная исходящая цепь - сопутствующая цепь. Иначе, индикатор пропускают неизменным.

c) Проключение тракта передачи Сквозное проключение тракта передачи в обоих направлениях будет закончено согласно тому как это описано в 10.2.1.1.2.6.

5.2.1.1.2.1(10.2.1.1.2.1) Процедуры BICC по установке исходящего соединения

Когда процедура IAM Sending Control решает, что IAM может быть послан вперед от SN, запускается процедура установления несущего канала для вызова в прямом или обратном направлении. Выбор процедуры осуществляется SN, при помощи BIWF. Определены две разновидности установки соединения в прямом направлении. Вариант, которому нужно следовать зависит от характеристик соединения несущего канала. 5.2.1.1.2.1.1(10.2.1.1.2.1.1) Установка несущего канала для вызова в

прямом направлении В этой процедуре несущий канал устанавливается от SN, который посылает IAM. Информация, необходимая чтобы запустить адресацию и идентификацию

17

несущего канала ожидается от следующего SN прежде, чем может быть инициализирована установка несущего канала. 1) Характеристики BNC (Backbone Network Connection) определяются,

основываясь на выбранной BIWF. 2) IAM посылается с Action indicator, установленным в "Connect forward", и

характеристиками BNC, указанными в BICC_Data request primitive. 3) Могут приниматься следующие индикаторы:

3.1) A BICC_Data indication primitive, (соответственно сообщению APM): 3.1.1) Если полученный Action indicator - "Connect forward, plus

notification", то Connect Type устанавливается в "notification required", в противном случае – в "notification not required".

3.1.2) Запрос Установки несущего канала посылается выбранному BCF. Этот запрос включает:

• BNC-ИДЕНТИФИКАТОР (как получено в BICC_Data indication primitive).

• BIWF Адрес (как получено в BICC_Data indication primitive). • Характеристики несущего канала, то есть Требования

Среды Передачи – Transmission Medium Requirements – (как получено в IAM).

3.1.3) Когда принимается Bearer Set-up Connect indication, это указывает на успешное завершение исходящей процедуры установки соединения. Если Connect Type - "notification required", то высылается BICC_Data request primitive (соответственно APM message), содержащий:

• Action indicator установленный в "Connected". 3.1.4) Если принимаются ACM или CON, то, поскольку, Bearer Set-up

Connect indication еще не был получен, ACM/CON должен быть обработан согласно 10.2.1.4, и ожидается Bearer Set-up Connect или Bearer Set-up Failure indication.

5.2.1.1.2.1.2(10.2.1.1.2.1.2) Установка несущего канала для вызова в

обратном направлении В этой процедуре несущий канал устанавливается в обратном направлении от следующего SN назад к SN, который посылал IAM. Посылаемый IAM включает информацию, необходимую чтобы дать возможность несущему каналу быть адресованным назад к SN, его выславшему, и позволить идентифицировать устанавливаемый несущий канал коррелированно с вызовом. 1) BNC-ИДЕНТИФИКАТОР и адрес BIWF определяются от BCF. 2) Характеристики BNC определены, основываясь на выбранной BIWF. 3) IAM посылается вместе с a BICC_Data request primitive, содержащим:

• BNC-ИДЕНТИФИКАТОР; • BIWF Адрес; • Action indicator, установленный в "Connect backward"; • Характеристики BNC.

4) Когда подключение несущего канала достигает SN, Bearer Set-up indication принимается от BCF: 4.1) Bearer Set-up indication коррелируется с требованиями вызова. 4.2) A Bearer Set-up response посылается в BCF.

Процедура установки соединения в исходящем направлении теперь успешно закончена. 5.2.1.1.2.2(10.2.1.1.2.2) Процедуры входящего соединения BICC

18

Когда IAM (плюс SAM – Subsequent Address Message, как свойственное маршрутизации вызова) получен, выбирается BIWF, и начинается соответствующая процедура входящего соединения BICC. Выбранный BIWF должен быть способен поддерживать направление установления несущего канала, обозначенное Action indicator, и поддерживать принимаемые характеристики BNC. Определены две разновидности установления несущего канала в прямом направлении. Выбор варианта, которому нужно следовать зависит от характеристики соединения несущего канала. 5.2.1.1.2.2.1(10.2.1.1.2.2.1) Установка несущего канала для вызова в

прямом направлении В этой процедуре несущий канал устанавливается от SN, который посылает IAM. Адресация и информация идентификации несущего канала высылается назад, чтобы позволить предшествующему SN, инициализировать подключение несущего канала. 1) IAM далее обрабатывается, согласно процедурам Q.764. Процедура

установления несущего канала не задерживает обработку вызова. Обработка вызова продолжается одновременно с остальными процедурами.

Если кодекам необходимо договориться (10.2.1.1.2.4) все последующие действия задерживаются до выполнения этой процедуры.

2) BNC-ИДЕНТИФИКАТОР и адрес BIWF получают от BCF. 3) Connect Type устанавливается в "Notification not required".

ПРИМЕЧАНИЕ - Connect Type "Notification required" может быть установлен в сетях, которые используют протоколы несущего канала, не обеспечивающие обратное сквозное соединение пути несущего канала во время запроса установки несущего канала для службы телефонной связи.

4) BICC_Data request primitive формируется (соответственно APM message), с содержанием: • Action indicator устанавливается в: "Connect forward, plus notification" если

Connect Type - "Notification required", в противном случае – в "Connect forward, no notification".

• BNC-ИДЕНТИФИКАТОР. • BIWF Адрес.

5) Когда подключение несущего канала достигает SN, от BCF принимается Bearer Set-up indication: 5.1) Bearer Set-up indication коррелированна с требованиями вызова. 5.2) Bearer Set-up response посылается к BCF. 5.3) Если Connect Type - "notification not required", то процедура

установления входящего соединения успешно выполнена. 5.4) Если Connect Type - "notification required", то процедура установления

входящего соединения ждет BICC_Data indication primitive (соответствующий APM message), содержащий Action indicator, установленный в "Connected". Теперь процедура установления входящего соединения успешно выполнена.

5.2.1.1.2.2.2(10.2.1.1.2.2.2) Установка несущего канала для вызова

в обратном направлении

В этой процедуре IAM содержит адрес и информацию идентификации несущего канала. Этой информацией обеспечивается BCF. Адресная информация дает возможность несущему каналу быть направленным обратно к предшествующему SN. Информация идентификации несущего канала высылается назад, чтобы дать

19

возможность предшествующему SN указать на то, какой несущий канал предоставляется для какого вызова. 1) IAM далее обрабатывается, согласно процедурам Q.764. Процедура

установления несущего канала не задерживает обработку вызова. Обслуживание вызова продолжается одновременно с остальными процедурами.

Если кодекам необходимо договориться (10.2.1.1.2.4), то все последующие действия задерживаются до выполнения этой процедуры.

2) Запрос на установку несущего канала посылается выбранному BCF. Этот запрос включает: • BNC-ИДЕНТИФИКАТОР (полученный через BICC_Data indication

primitive, ассоциированный с IAM). • BIWF Адрес (полученный через BICC_Data indication primitive,

ассоциированный с IAM). • Характеристики несущего канала, то есть Transmission Medium

Requirements (как принято из IAM). 3) Когда принята Bearer Set-up Connect indication от BCF, то процедура

установления входящего соединения успешно завершена. 5.2.1.1.2.3(10.2.1.1.2.3) процедура контроля отправки IAM Эта процедура регулирует работу процедур установления входящих и исходящих соединений, чтобы определить, когда сообщения IAM и COT должны быть высланы, в зависимости от сообщений, полученных входящей сигнализацией. В случаях TSN/GSN IAM высылается прежде, чем завершится установка несущего канала, и поэтому используется протокол проверки целостности, чтобы задержать обслуживание вызова, пока установление несущего канала не закончено. IAM высылается согласно тому, как это определено в процедурах исходящего вызова в 10.2.1.1.2 или 10.2.1.2.2. Индикатор continuity check Nature of connection indicators parameter установлен, чтобы указать "continuity check performed on previous circuit". Посылка IAM совершается с вызовом процедур установления исходящего соединения BICC 10.2.1.1.2.1. Continuity message, с Continuity Indicators parameter установленным в "continuity check successful" высылается при удовлетворении двух следующих условий: 1) Если входящий IAM указывает на "continuity check performed on previous

circuit", то должен быть получен сигнал целостности (Continuity message), с Continuity Indicators parameter установленным в "continuity check successful".

2) В зависимости от применяемой процедуры, должно также быть получено одно из следующих событий, которые указывают на успешное завершение установки несущего канала процедурой установления входящего соединения: 2.1) Bearer Set-up indication - для случая установления несущего канала в

прямом направлении, когда входящий Connect Type указывает на "notification not required".

2.2) BICC_Data indication primitive с Action indicator установленным в "Connected" - для случая установления несущего канала в прямом направлении, когда Connect Type установлен в "notification required".

2.3) Bearer Set-up Connect indication - для случая установления несущего канала в обратном направлении.

5.2.1.1.2.4(10.2.1.1.2.4) Переговоры кодеков Поддержка процедуры переговоров Кодеков необязательна. Если поддерживается, то применяется только для случаев установления несущего

20

канала для вызова в прямом или обратном направлении. Переговоры Кодеков не применимы в случае многократного использования неактивных несущих каналов, см. приложение A (Annex A). Когда переговоры кодека не используется, установка несущего канала исполняется сегмент за сегментом для вызова, параллельно с передачей IAM через сеть. Однако, когда переговоры кодека требуются, то чтобы переговоры были выполнены необходимо взаимодействие edge-to-edge, (поперек BICC сети, которая поддерживает эту процедуру), и результат этих переговоров необходимо получить прежде, чем несущие каналы могут быть установлены. Следующие подпараграфы детализируют процедуры как набор разновидностей процедур non-codec procedures, согласно тому как это определено в предшествующих подпараграфах. 5.2.1.1.2.4.1(10.2.1.1.2.4.1) Инициализизация переговоров кодеков SN В SN процедуры IAM 10.2.1.1.2.1 применяются со следующими добавлениями: 1) Создаётся список поддерживаемых кодеков, которые предлагаются для

использования в процессе обслуживания вызова, содержащий все кодер-декодеры в приоритетном порядке,

2) Список поддерживаемых для вызова кодеков высылается в прямом направлении в BICC_Data request primitive, ассоциированном с IAM. Список кодируется как элемент информации Codec List information и не должен включать больше чем восемь элементов Single Codec information.

Последующие процедуры - согласно процедуре установки исходящего соединения, согласно тому, как это определено в 10.2.1.1.2.4.4. 5.2.1.1.2.4.2(10.2.1.1.2.4.2) Транзитные переговоры кодеков Для случая TSN в пределах одной сети, или для GSN, соединяющих две сети, которые поддерживают переговоры кодеков, IAM с BICC_Data indication primitive, который включает элемент информации Codec List information element, обрабатывается согласно процедурам Q.764, но процедуры установления входящего соединения приостанавливаются, пока не будет закончен обмен информации о кодеках. Затем: 1) BICC_Data request primitive, связанный с IAM пересылается следующему

SN, включая Supported Codec List. Этот список создаётся из полученного Supported Codec List, из которого удаляются не поддерживаемые этим узлом (транзитным или шлюзовым) кодеки.

2) Когда процедура установки соединения в исходящем направлении

(10.2.1.1.2.4.4) принимает информацию Selected Codec и Available Codecs List, то пропускает её к соответствующей процедуре установления входящего соединения (10.2.1.1.2.4.5).

В случае GSN между сетью, поддерживающей переговоры кодер-декодера и сетью, в которой нет поддержки такой возможности: • Если со входящей стороны - сеть, которая поддерживает переговоры

кодер-декодера, тогда GSN должен исполнить процедуры переговоров кодер-декодера, описанные в 10.2.1.1.2.4.3 с терминацией этого обмена SN;

• Если со входящей стороны - сеть, которая не поддерживает переговоры кодер-декодера, то GSN должен исполнить процедуры переговоров кодер-

21

декодера, описанные в 10.2.1.1.2.4.1 с инициализацией этих переговоров SN.

5.2.1.1.2.4.3(10.2.1.1.2.4.3) Процедура терминации переговоров кодеков SN Когда SN, терминирующий переговоры кодер-декодера, принимает IAM с BICC_Data indication primitive, который включает элемент информации Codec List information element, то применяют процедуры, описанные в 10.2.1.1.2.2, со следующими добавлениями: CSF исполняет следующую процедуру для выбора кодека, необходимого для обслуживания вызова ("Selected Codec") и для обнаружения списка кодеков, доступных для вызова ("Available Codec List"): a) Выбирает кодек с самым высоким приоритетом в полученном Available

Codec List который может использоваться для вызова. b) Создает Available Codec List для вызова, удаляя кодеки, которые не могут

использоваться для вызова. (Выбранный кодер-декодер также включен в список доступных кодер-декодеров.)

Последующие процедуры – согласно процедуре установления входящего соединения, как это определено в 10.2.1.1.2.4.5. 5.2.1.1.2.4.4(10.2.1.1.2.4.4) Исходящая процедура установки Когда процедура IAM Sending Control решает, что IAM может быть послан вперед от этого SN, начинается установка исходящего несущего канала в прямом или обратном направлении. Два разновидности каждой процедуры определены (прямое/обратное направление). Выбор варианта зависит от характеристики соединения несущего канала. 5.2.1.1.2.4.4.1(10.2.1.1.2.4.4.1) Установка несущего канала для вызова в

прямом направлении Процедуры в 10.2.1.1.2.1.1 применяются со следующими добавлениями: Selected Codec и Available Codecs List для вызова должны быть получены в BICC_Data indication primitive (соответственно APM) – см. 10.2.1.1.2.1.1, пункт 3.1: • Action indicator установить в "Connect forward, no notification + Selected Codec"

или "Connect forward, plus notification + Selected Codec". (Обработка этих индикаторов Action indicators такая же, как это приведено в 10.2.1.1.2.1.1 для значений "Connect forward, no notification" или "Connect forward, plus notification" соответственно).

• Выбранный Кодер-декодер (Selected Codec) кодируется как элемент информации Single Codec information element.

• Список доступных Кодер-декодеров (Available Codecs List) кодируется как элемент информации Codec List information element.

О выбранном кодеке информируется BCF, и Available Codecs List сохраняется для будущего использования. 5.2.1.1.2.4.4.2 (10.2.1.1.2.4.4.2) Установка несущего канала для вызова в

обратном направлении Процедуры, приведённые в 10.2.1.1.2.1.2, применяются со следующими добавлениями: Selected Codec и Available Codecs List для вызова должны быть получены в BICC_Data indication primitive (соответственно сообщению APM): • Action indicator установлен в "Selected codec". • Selected Codec кодируется как Single Codec information element.

22

• The Available Codecs List кодируется как Codec List information element. О выбранном кодеке информируется BCF, и Available Codecs List сохраняется для будущего использования. 5.2.1.1.2.4.5(10.2.1.1.2.4.5) Процедура установления входящего соединения 5.2.1.1.2.4.5.1(10.2.1.1.2.4.5.1) Установка несущего канала для вызова в

прямом направлении Процедуры, приведённые в 10.2.1.1.2.2.1 применяются со следующими исключениями: Процедура установления входящего соединения должна ждать (10.2.1.1.2.2.1, пункт 1), пока Selected Codec и Available Codecs List не станут доступными для вызова (об этом информирует процедура терминации узла или процедура на исходящей стороне на транзитном узле), затем процедура продолжается. Выбранный Кодер-декодер и Список Доступных Кодер-декодеров должны быть включены в высылаемый BICC_Data request primitive (10.2.1.1.2.2.1, пункт 4): • Action indicator установить в "Connect forward, no notification + Selected Codec"

или "Connect forward, plus notification + Selected Codec". (Вместо значений "Connect forward, no notification" или "Connect forward, plus notification" соответственно).

• Выбранный Кодер-декодер кодируется как Single Codec information element. • Список Доступных Кодер-декодеров кодируется как Codec List information

element. О выбранном кодеке информируется BCF, и Available Codecs List сохраняется для будущего использования. 5.2.1.1.2.4.5.2(10.2.1.1.2.4.5.2) Установка несущего канала для вызова в

обратном направлении Процедуры, описанные в 10.2.1.1.2.2.2, применяются со следующими исключениями: Процедура установления входящего соединения должна ждать (10.2.1.1.2.2.2, пункт 1), пока Selected Codec information и Available Codecs List не станут доступными для вызова (об этом информирует процедура терминации обмена или процедура на исходящей стороне при транзитном обмене), затем процедура должна продолжиться следующим образом: 1) BICC_Data request primitive (согласно сообщению APM), должен быть

выслан, включая: • Action indicator установлен в "Selected codec". • Selected Codec кодируется как Single Codec information element. • Available Codecs List кодируется как Codec List information element.

2) О выбранном кодеке информируется BCF, и Available Codecs List сохраняется для будущего использования.

3) Процедуры продолжаются с пункта 2) 10.2.1.1.2.2.2 5.2.1.1.2.4.6(10.2.1.1.2.4.6) Аварийные случаи 5.2.1.1.2.4.6.1(5.2.1.1.2.4.6.1) Неготовность Кодека Если в SN не имеется никакого кодер-декодера, который соответствует любому из кодер-декодеров, предлагаемых в полученном Списке Поддерживаемых Кодеков, тогда должны быть инициализированы процедуры отбоя вызова с кодом причины #47 " Ресурс, недоступный, неопределенный ". 5.2.1.1.2.4.6.2(10.2.1.1.2.4.6.2) Инициализация переговоров кодер-декодера

на SN

23

Всякий раз когда SN, который инициализирует процедуры переговоров кодека для вызова, принимает элемент информации BAT Compatibility Report information element в BICC_Data indication primitive от следующего узла, указывающего, что параметры переговоров кодер-декодера были отвергнуты и обслуживание вызова продолжается без этих параметров, SN должен закончить все внутренние процедуры переговоров кодер-декодера и: a) Для случая установки несущего канала в прямом направлении:

продолжить как это описано в пункте 3) 10.2.1.1.2.1.1; b) Для случая установки несущего канала в обратном направлении:

продолжить как это описано в пункте 4) 10.2.1.1.2.1.2. 5.2.1.1.2.4.6.3(10.2.1.1.2.4.6.3) Транзитные переговоры кодеков a) Случай, когда SN транслирует переговоры кодеков для вызова, как

описано в 10.2.1.1.2.4.2, при приеме элемента информации BAT Compatibility Report information element в BICC_Data indication primitive от следующего узла, указывающего, что параметры переговоров кодека были отвергнуты, и обслуживание вызова продолжается без таких параметров - для дальнейшего изучения.

5.2.1.1.2.5(10.2.1.1.2.5) Модификация Кодека Сети, поддерживающие процедуру переговоров кодер-декодера могут также поддерживать процедуру модификации Кодер-декодера. Когда опция модификации кодер-декодера поддерживается, кодек, выбранный для вызова может изменяться в любом направлении (в смысле инициации процедуры) и в любое время в течение активной стадии вызова. Модификация Кодека может происходить только после того как кодек был выбран для вызова и Список Доступных Кодеков был сохранен во всех процедурах SNS, вмешивающихся в процедуры переговоров кодеков. Выбор процедуры, сопутствующей процедуре модификации кодека, будет зависеть от того, используется ли SN для терминации, транзита или инициализации процедуры модификации. ПРИМЕЧАНИЕ - термины "предшествующие" и "следующие" SN в следующих подпараграфах относятся к направлению потока модификации и не касаются направления установки вызова. 5.2.1.1.2.5.1(10.2.1.1.2.5.1) Инициализация модификации кодека SN В SN, процедура модификации кодер-декодера может быть инициализирована в любом направлении и в любое время в течение активной стадии вызова, после того, как кодек был выбран для вызова, и Список Доступных для вызова Кодеков был сохранен в SN. Эта процедура запускается узловыми функциями, чтобы запросить: • Изменение выбранного кодека на новый, включённый в Список Доступных

Кодеков; и-или • Изменение сохраненного Списка Доступных Кодеков для вызова.

Изменяемый Список Доступных Кодеков для вызова может включать только подмножество сохраненных Списков Доступных Кодеков.

Чтобы инициализировать модификацию выбранного кодер-декодера и-или Списка Доступных Кодер-декодеров для вызова, CSF в SN должна сопровождаться следующей процедурой:

24

1) Передача BICC_Data request primitive (соответственно сообщению APM) содержит: • Action indicator установленный в "Modify codec"; • Single Codec information element, указывающий на недавно выбранный

кодер-декодер для вызова, если выбранный кодер-декодер должен быть изменён. Недавно выбранный кодер-декодер должен быть среди тех кодеков, которые в настоящее время находятся в сохраненном Списке Доступных Кодеков;

• Codec List information element, указывающий на новый Available Codec List для вызова, если сохраненный Available Codec List должен измениться.

2) В ответе должен быть получен BICC_Data indication primitive включающий Action indicator: • Если полученный Action indicator установлен в "Successful codec

modification", то модификация кодер-декодера была успешна. BCF информируется относительно нового кодер-декодера, если этого требует модификация кодека. Новый Available Codec List сохраняется для будущего использования, если этого требует модификация сохраненного Available Codec List.

• Если полученный Action indicator установлен в "Codec modification failure", то модификация кодер-декодера была отклонена, о чём уведомляются узловые функции.

5.2.1.1.2.5.2(10.2.1.1.2.5.2) SN, терминирующий модификацию кодека В SN, заканчивающем модификацию кодер-декодера, запрос модификации кодер-декодера может быть получен в любое время в течение активной стадии вызова, после того, как кодер-декодер был выбран для этого вызова, и Available Codec List был сохранен для вызова. Применяется следующая процедура: Модификация Кодер-декодера инициализируется когда получен BICC_Data indication primitive, содержащий: • Action indicator, установленный в "Modify codec"; • Single Codec information element, если используемый для вызова в

настоящее время кодек должен измениться; • Codec List information element, если сохраненный Available codec List для

вызова должен измениться. Когда требуется модификация кодека, SN выполняет следующую оценку: • Если или Single Codec или Codec List не имеют силу, то есть Single Codec не

находится среди кодеков, перечисленных в сохраненном или полученном Available codec List, или Codec List - не подмножество сохраненного Available codec List, то модификация отклоняется.

• Если Codec Information имеет силу, тогда доступность кодека проверяется владельцем ресурса кодека (например, BIWF). Если новый предложенный кодек не доступен, то модификация отклоняется.

• Иначе модификация принимается. Если модификация кодер-декодера отклонена, то BICC_Data request primitive с Action indicator установленным в Codec modification failure" отсылается к предшествующему SN. Если модификация кодер-декодера принята, то BICC_Data request primitive с Action indicator установленным в "Successful codec modification" отсылается предшествующему SN. Если выбранный для вызова кодек изменился, то запрос модификации кодека посылается выбранному BCF. Если изменяется сохраненный Available Codec List, то новый Available Codec List сохраняется для будущего использования. 5.2.1.1.2.5.3(10.2.1.1.2.5.3) Модификация кодека транзитным SN

25

В транзитном SN при модификации кодека применяют следующие процедуры: При приеме от предшествующего SN BICC_Data indication primitive, включающего: • Action indicator, установленный в "Modify codec"; • Single Codec information element, если выбранный в настоящее время для

вызова кодек должен измениться; • Элемент информации Codec List information element, если сохраненный

Available Codec List должен измениться. SN проверяет полученную информацию кодека:

1) Если или Single Codec или Codec List не имеют силу (то есть Codec Information не среди тех, что перечислены в сохраненном Available Codec List для вызова, или Codec List - не подмножество сохраненного Available Codec List), то модификация кодер-декодера отклоняется. SN отсылает BICC_Data request primitive к предшествующему SN, который содержит Action indicator, установленный в "Codec modification failure".

2) Если модификация не отклонена в пункте 1) выше, то: 2.1) Полученная информация отправляется в BICC_Data request primitive к

следующему SN. 2.2) При приеме BICC_Data indication primitive от следующего SN, который

содержит Action indicator, установленный в "Successful codec modification" или "Codec modification failure", то транзитный SN должен отправить полученную информацию в BICC_Data request primitive к предшествующему SN. Если модификация успешна и сохраненный Available Codec List изменяется, то новый Available Codec List сохраняется для будущего использования.

5.2.1.1.2.6(10.2.1.1.2.6) Сквозное соединение пути несущего канала Путь несущего канала должен быть проключён в обоих направлениях, когда удовлетворены оба из следующих условий: • Процедура установления входящего соединения успешно закончена; и • Процедура установления исходящего соединения успешно закончена. Кроме того, если процедура установки исходящего соединения BICC выполняет процедуру "Per-call bearer set-up in the forward direction" (процедура установления несущего канала для вызова в прямом направлении) с Connect Type "notification not required", то путь несущего канала должен быть проключен в обоих направлениях при удовлетворении следующих условий: • Процедура установления входящего соединения успешно закончена; и • Запрос Установки Несущего канала (Bearer Set-up request) был послан

исходящей процедурой установки (процедурой установки соединения в исходящем направлении).

5.2.1.1.3(10.2.1.1.3) Действия, требуемые от исходящей международной

станции Параграф 2.1.1.3/Q.764 применяется со следующими исключениями: a) Где Q.764 касается получения IAM, применяются процедуры, описанные

в 10.2.1.1.2.2. b) Где Q.764 касается захвата канала и посылки IAM, применяются

процедуры, описанные в 10.2.1.1.2.3. c) Сквозное соединение тракта передачи будет описано в 10.2.1.1.2.6. d) Переговоры Кодер-декодера и модификация кодер-декодера – согласно

описанию в 10.2.1.1.2.4 и 10.2.1.1.2.5 соответственно.

26

5.2.1.1.4(10.2.1.1.4) Действия, требуемые от промежуточной международной станции

Параграф 2.1.1.4/Q.764 применяется со следующими исключениями: a) Где Q.764 касается получения IAM, применяются процедуры, описанные

в 10.2.1.1.2.2. b) Где Q.764 касается захвату канала и посылки IAM, применяются

процедуры, описанные в 10.2.1.1.2.3. c) Сквозное соединение тракта передачи будет описано в 10.2.1.1.2.6. d) Переговоры Кодер-декодера и модификация кодер-декодера – согласно

описанию в 10.2.1.1.2.4 и 10.2.1.1.2.5 соответственно. 5.2.1.1.5(10.2.1.1.5) Действия, требуемые от входящей международной

станции Параграф 2.1.1.5/Q.764 принимается со следующими исключениями: a) Где Q.764 касается получения IAM, применяются процедуры, описанные

в 5.2.1.1.2.2. b) Где Q.764 касается захвату канала и посылки IAM, применяются

процедуры, описанные в 10.2.1.1.2.3. c) Сквозное соединение тракта передачи будет описано в 10.2.1.1.2.6. d) Переговоры Кодер-декодера и модификация кодер-декодера согласно

соответствующему описанию 10.2.1.1.2.4 или 10.2.1.1.2.5. 5.2.1.1.6(10.2.1.1.6) Действия, требуемые от адресуемой станции Параграф 2.1.1.6/Q.764 не применим к BICC. 5.2.1.1.7(10.2.1.1.7) Номер Вызываемого абонента (Called Party Number)

для операторских вызовов Применяется параграф 2.1.1.7/Q.764. 5.2.1.1.8(10.2.1.1.8) Номер Вызываемого абонента (Called Party Number)

для вызовов тестирующих и измерительных систем Применяется параграф 2.1.1.8/Q.764. 5.2.1.2(10.2.1.2) Сигнализация прямой адресации - операция Overlap 5.2.1.2.1(10.2.1.2.1) Действия, требуемые от вызывающей станции Параграф 2.1.2.1/Q.764 не применим к BICC. 5.2.1.2.2(10.2.1.2.2) Действия, требуемые от промежуточной национальной

станции (Промежуточный SN) Для каждого варианта обслуживания несущего канала, применяется следующие модифицированные процедуры 2.1.2.2/Q.764: a) Исходящее направление

Промежуточная национальная станция, по получении сообщения начального адреса (initial address message), анализирует доступные цифры и другую информацию маршрутизации (см. 2.1.2.1 a)/Q.764) определяя маршрутизацию вызова. Если промежуточная национальная станция может маршрутизировать вызов, используя connection type, указанный в

27

параметре требования среды передачи (transmission medium requirement parameter), то захватывается свободное значение CIC, и применяется процедура IAM Sending Control (10.2.1.1.2.3). Процедура установления входящего соединения BICC (10.2.1.1.2.2) начинается, когда вызов может быть смаршрутизирован. Если количество разрядов в номере вызываемого абонента не достаточно, чтобы маршрутизировать вызов, маршрутизация будет выполнена, когда промежуточная национальная станция примет дополнительные цифры в последующих адресных сообщениях. Любые адресные цифры, полученные в последующих адресных сообщениях в течение процесса выбора канала могут быть включены в сообщение начального адреса передаваемого последующему узлу. Любые последующие адресные сообщения, полученные после того как было послано сообщение начального адреса, могут быть отправлены следующему узлу как последующие адресные сообщения. В пределах сети, если промежуточный национальный узел не может маршрутизировать вызов используя только тип подключения (connection type), указанный в параметре требования среды передачи (transmission medium requirement parameter), узел может также использовать служебную информацию пользователя, содержащую информацию о возможностях несущего канала и/или пользовательскую телесервисную информацию, содержащую информацию совместимости верхнего уровня, если она доступна, чтобы определить, может ли быть выбран подходящий маршрут. В этом случае параметр требования среды передачи изменяется в соответствии с новым типом подключения.

b) Параметры в сообщении начального адреса Промежуточный национальный узел может изменять сигнальную информацию, полученную от предшествующего узла согласно возможностям, используемым на исходящем маршруте. Сигнальная информация, которая может быть изменена (заменена) – это индикатор характера подключения (nature of connection indicator) и счетчик задержки распространения (propagation delay counter). Данные BAT ASE data не обязательно передаются прозрачно. Другая сигнальная информация передается прозрачно, например, служебная информация пользователя, и т.д. Порядок информационных элементов, передаваемых в параметре доступа транспортировки, полученном от входящего узла должен быть сохранен. Сопутствующий индикатор в параметре характера подключения должен быть увеличен, если выбранный исходящий канал - сопутствующий канал. Иначе, индикатор пропускают на неизменяемым.

c) Проключение тракта передачи Сквозное проключение тракта передачи в обоих направлениях будет закончено согласно описанию в 10.2.1.1.2.6.

5.2.1.2.3(10.2.1.2.3) Действия, требуемые от исходящей международной

станции Параграф 2.1.2.3/Q.764 применяется со следующими исключениями: a) Где Q.764 касается получения IAM, применяются процедуры, описанные

в 10.2.1.1.2.2. b) Где Q.764 касается захвата канала и посылки IAM, применяются

процедуры, описанные в 10.2.1.1.2.3. c) Сквозное соединение тракта передачи будет происходить согласно

описанию 10.2.1.1.2.6.

28

d) Переговоры Кодер-декодера и модификация кодер-декодера описаны в 10.2.1.1.2.4 и 10.2.1.1.2.5.

5.2.1.2.4(10.2.1.2.4) Действия, требуемые от промежуточной

международной станции Параграф 2.1.2.4/Q.764 применяется со следующими исключениями: a) Где Q.764 касается получения IAM, применяются процедуры, описанные в

10.2.1.1.2.2. b) Где Q.764 касается захвата канала и посылки IAM, применяются

процедуры, описанные в 10.2.1.1.2.3. c) Сквозное проключение тракта передачи будет происходить согласно

описанию 10.2.1.1.2.6. d) Переговоры Кодер-декодера и модификация кодер-декодера описаны в

10.2.1.1.2.4 и 10.2.1.1.2.5 соответственно. 5.2.1.2.5(10.2.1.2.5) Действия, требуемые от входящей международной

станции Параграф 2.1.2.5/Q.764 применяется со следующими исключениями: a) Где Q.764 касается получения IAM, применяются процедуры, описанные

в 10.2.1.1.2.2. b) Где Q.764 касается захвата канала и посылки IAM, применяются

процедуры, описанные в 10.2.1.1.2.3. c) Сквозное проключение тракта передачи будет происходить согласно

описанию 10.2.1.1.2.6. d) Переговоры Кодер-декодера и модификация кодер-декодера описаны в

10.2.1.1.2.4 и 10.2.1.1.2.5 соответственно. 5.2.1.2.6(10.2.1.2.6) Действия, требуемые от адресуемой станции Параграф 2.1.2.6/Q.764 не применим к BICC. 5.2.1.2.7(10.2.1.2.7) Номер Вызываемого абонента (Called Party Number)

для операторских вызовов Применяется параграф 2.1.2.7/Q.764. 5.2.1.2.8(10.2.1.2.8) Номер Вызываемого абонента (Called Party Number)

для вызовов тестирующих и измерительных систем Применяется параграф 2.1.2.8/Q.764. 5.2.1.3(10.2.1.3) Номер Вызывающего абонента Применяется параграф 2.1.3/Q.764. 5.2.1.4(10.2.1.4) Address complete message или connect message Применяется параграф 2.1.4/Q.764 со следующими исключениями: a) Параграф 2.1.4.8/Q.764 рекомендации на межсетевое взаимодействие с

другими системами связи не применим, таким образом таймер T10 не применим.

b) Параграфы 2.1.4.1, 2.1.4.6 и 2.1.4.7/Q.764 не применимы к BICC.

29

5.2.1.5 Обслуживание вызова (Basic call) Параграф 2.1.5/Q.764 применяется со следующим исключением: Параграфы 2.1.5.1 и 2.1.5.3/Q.764 не применимы к BICC. 5.2.1.6(10.2.1.6) Информационные сообщения Применяется параграф 2.1.6/Q.764. 5.2.1.7(10.2.1.7) Сообщение Ответа (Answer message) Параграф 2.1.7/Q.764 применяется со следующим исключением: Параграфы 2.1.7.1, 2.1.7.6 и 2.1.7.7/Q.764 не применимы к BICC. 5.2.1.8(10.2.1.8) Проверка целостности Параграф 2.1.8/Q.764 применяется со следующими разъяснениями/исключениями: a) Инициирование проверки целостности между SN не поддержано. b) Процедура изменяются процедурой контроля посылки IAM (10.2.1.1.2.3).

5.2.1.9(10.2.1.8) Charging Применяется параграф 2.1.9/Q.764. 5.2.1.10(10.2.1.10) Прямая передача сообщения Применяется параграф 2.1.10/Q.764. 5.2.1.11(10.2.1.11) Национальный сетевой транзит Применяется параграф 2.1.11/Q.764. 5.2.1.12(10.2.1.12) Простая сегментация Параграф 2.1.12/Q.764 применяется со следующими разъяснениями/исключениями:

a) Если примитив START-INFO.indication primitive, полученный от STC (см. приложение B – Annex B), указывает, что основной механизм транспортировки сообщения может транспортировать больше чем 272 октетов, то BICC, процедура Простой Сегментации не будет вызвана.

b) ISN могут принимать сегментированные сообщения ISUP, и они должны

быть обработаны SN согласно процедурам Q.764. 5.2.1.13(10.2.1.13) Процедуры для типа соединения N X 64 кбит/сек Процедуры для мультискоростного или N x 64 кбит/сек типа соединений должны быть такими же, как для типа подключения 64 кбит/сек, со следующими исключениями/разъяснениями: a) Для мультискоростного или N х 64 кбит/с типа соединения должен

использоваться только один CIC для обслуживания вызова между двумя SN.

30

b) Параметр TMR в BICC IAM должен указывать на мультискоростной или на N х 64 кбит/сек тип подключения.

c) Непрерывные и состоящие из нескольких этапов процедуры выбора канала, указанные в 2.1.13/Q.764 не применимы.

5.2.2(10.2.2) Неудачная установка вызова Параграф 2.2/Q.764 применяется со следующими добавлениями: a) Если в ответ на запрос Установки несущего канала (Bearer Set-up request),

BCF указывает на неудачу установки несущего канала, установка канала может быть заново предпринята или вызов должен быть отклонён.

b) Если принимающий SN не может выбирать BIWF согласно критериям, указанным в 10.2.1.1.2.2, вызов должен быть отклонён с указанием значения причины #63 "service or option not available, unspecified" или #79 "service or option not implemented, unspecified".

5.2.2.1(10.2.2.1) Действия на узле, инициализирующем сообщение

освобождения (release message) Параграф 2.2.1/Q.764 применяется со следующими исключениями/разъяснениями: a) Где текст касается освобождения скоммутированного пути, это должно

интерпретироваться в смысле, что BCF требуется разъединить внутреннее сквозное соединение пути несущего канала.

b) Неудачная установка вызова может происходить, когда не был установлен никакой путь несущего канала, в этом случае освобождение проключенного пути не поддерживается.

5.2.2.2(10.2.2.2) Действия в промежуточной станции Прямое/обратное освобождение в промежуточном SN обрабатывается согласно описанию в 10.2.3.1/10.2.3.2. 5.2.2.3(10.2.2.3) Действия на управляющем узле (то есть узле,

управляющем вызовом) Параграф 2.2.3/Q.764 применяется со следующими исключениями/разъяснениями: a) Где текст касается освобождения скоммутированного пути, это должно

интерпретироваться в смысле, что BCF требуется разъединить внутреннее сквозное соединение пути несущего канала.

b) Release Complete message высылается согласно процедурам, описанным в 10.2.3.

5.2.2.4(10.2.2.4) Сообщения и объявления Параграф 2.2.4/Q.764 применяется со следующими исключениями/ разъяснениями: a) Возможны случаи отказа по вызову, когда несущий канал полностью не

установлен из-за отказа в работе процедуры установления входящего соединения BICC. В этих случаях никакие сообщения или объявления не запускаются к вызывающему абоненту от SN, обнаружившего отказ. Например, в случае установки несущего канала в обратном направлении, если установка несущего канала неудачна. В этих случаях SN должен выслать запрос, (без посылки ACM), с причиной наиболее точно описывающей причину отказа.

31

b) Возможны случаи отказа по вызову, где установление несущего канала еще не было инициализировано. Если в этом случае требуется передача объявления или голосового/тонального сообщения, то процедура установления входящего соединения должна выполнить необходимые для этого действия.

5.2.2.5(10.2.2.5) Неполный Адрес Применяется параграф 2.2.5/Q.764. 5.2.3(10.2.3) Нормальный отбой вызова Применяются следующие изменённые процедуры 2.3/Q.764: Процедуры отбоя (освобождения) основаны на двух сообщениях (Release, Release Complete), посредством которых инициализируется процедура отбоя (освобождения). ПРИМЕЧАНИЕ - индикация относительно отбоя вызова отсылается к BCF, но последующее решение инициализировать протокол освобождения - ответственность логики BCF, и не определено в этой Рекомендации. См. Добавление I и Добавление II (Appendix I, II). Те же самые процедуры используются в сети независимо от того, инициализированы ли они вызывающим абонентом, вызываемым абонентом или сетью. Для удовлетворения требования быстрой передачи сообщения освобождения через сеть, необходимо, чтобы значение CIC выбиралось от смежного узла в пределах среднего времени передачи сообщения, Tcu, согласно тому как это определено в ITU-T Q.766 [10] для простых сообщений. 5.2.3.1(10.2.3.1) Отбой, инициализированный вызывающим абонентом Применяются следующие изменённые процедуры 2.3.1/Q.764: a) Действия в вызывающей станции Не описывается в BICC. b) Действия в промежуточной станции (Промежуточные SN) По получении Release message от предшествующего узла, промежуточный

узел: 1) Просит BCF разъединить внутреннее сквозное соединение пути

несущего канала. Полученный параметр причины пропускают к BCF, и указывается отбой вызова от входящей стороны. Когда BCF подтверждает успешное разъединение пути несущего канала, то предшествующему узлу возвращается сообщение Release Complete.

2) В то же самое время, как началось освобождение скоммутированного

пути, высылается сообщение Release message следующему узлу. Запускаются таймеры Т1 и T5, чтобы гарантировать, что сообщение Release Complete будет получено от следующего узла (истечение таймеров T1 и T5 описано в 10.2.9.6).

3) Когда приходит Release Complete message - T1 и T5 сбрасываются и

останавливаются, а BCF указывается на отбой вызова от вызывающей

32

стороны. Параметр причины, указанный в первоначальном сообщении Release message пропускают к BCF.

c) Действия на адресуемой станции Не описываются в BICC. d) Charging (национальное использование)

Charging узел приостанавливает процедуру Charging по приему Release message. Остановка Charging по запрсу на освобождение вызова – не рассматривается в BICC.

e) Коллизии Release messages В случае, когда два пункта на подключении одновременно инициализируют отбой вызова, Release message может быть получено узлом от следующего или предшествующего узла после того, как освобождение скоммутированного пути инициализировано и после посылки сообщения release message к смежному узлу. В этом случае, узел возвратит Release Complete message узлу, от которого было получено сообщение Release message. Сообщение Release Complete message будет послано только после того как BCF подтвердит Bearer Release request. Узел освободит значение CIC для новых вызовов когда оба Release Complete message будут получены (ответ на посланный Release message) и будет послано Release Complete message будет (ответ на полученое Release message).

5.2.3.2(10.2.3.2) Отбой, инициализированный вызываемым абонентом Применяют процедуры, описанные в 10.2.3.1, с учётом замены терминов "предшествующий"/"следующий" на "входящий" / "исходящий". (Не описываются действия на адресуемом и исходном узлах). 5.2.3.3(10.2.3.3) Отбой, инициализированный сетью Отбой может быть инициализирован в любом SN. Отбой в прямом направлении обрабатываются как в 10.2.3.1, а отбой в обратном направлении обрабатываются как в 10.2.3.2. Отбой, инициализированный сетью может возникнуть в результате приема Bearer Release indication от BCF, например, в результате отказа в несущей сети в течение активной стадии вызова. 5.2.3.4(10.2.3.4) Хранение и освобождение информации сообщения

начального адреса (initial address message information) Применяется параграф 2.3.4/Q.764 . (Не описываются действия на адресуемом и исходном узлах). 5.2.3.5(10.2.3.5) Транспорт информации предотбойного состояния Применяется параграф 2.3.5/Q. 5.2.4(10.2.4) Приостановить, продолжить (Suspend, resume) Применяется параграф 2.4/Q.764. (Не описываются действия на адресуемом и исходном узлах).

33

5.2.5(10.2.5) Сигнальные процедуры для типа подключения, позволяющего переход на аварийный режим

Применяется параграф 2.5/Q.764. (Не описываются действия на адресуемом и исходном узлах). Некоторые действия перехода на аварийный режим не могут применяться во всех SN. Для дальнейшего изучения. 5.2.6(10.2.6) Процедура определения задержки распространения Применяется параграф 2.6/Q.764 со следующим разъяснением/исключением: Определение задержки распространения используется, когда вызов маршрутизируется через независимые/отделённые участки сети, является приблизительной и рассматривается в зависимости от специфики сети. 5.2.7(10.2.7) Сигнальные процедуры Echo control 5.2.7.1(10.2.7.1) Введение Применяется параграф 2.7.1/Q.764 со следующим исключением: Усовершенствованные сигнальные процедуры ECHO control не поддержаны 5.2.7.2(10.2.7.2) Усовершенствованные сигнальные процедуры ECHO control Не используются ПРИМЕЧАНИЕ - SN действует как узлы типа 2 Q.115 и поэтому передает параметр Echo Control Information и NRM сообщение, если они получены от ISUP. (См. 2.7.2.3/Q.764.) 5.2.7.3(10.2.7.3) Простые сигнальные процедуры ECHO control Применяется параграф 2.7.3/Q.764 со следующим исключением: Устройства Echo control не должны использоваться, когда используются переговоры кодека и результирующий кодер-декодер - не G.711. (Не описываются действия на адресуемом и исходном узлах). ПРИМЕЧАНИЕ 1 - Во всех случаях посылка IAM сообщения не должна ждать подтверждения что требуемое устройство Echo control активизировалось. Действие, которое будет принято, если BIWF не сможет предоставить требуемое устройство Echo control - ответственность оператора сети, то есть обслуживание вызова может быть продолжено или может быть выставлен отбой со значением "#41 (Temporary Failure)" (см. ITU-T Q.115). ПРИМЕЧАНИЕ 2 - из-за используемых технологий несущего канала, может быть случай, когда echo control будет запущен исходящим устройством echo control на входящей стороне SN и входящим устройства echo control на входящей стороне SN. Такие конфигурации позволяются логикой ECHO в ITU-T Q.115. 5.2.8(10.2.8) Сетевые особенности 5.2.8.1(10.2.8.1) Автоматическая попытка повтора 2.8.1/Q.764 со следующим исключением/разъяснениями:

34

a) Где текст касается приема сообщения Blocking message, то это должно означать прием a Circuit Group Blocking message, включая бит статуса для этой группы CIC, установленный в «1».

b) Пункт IV) не применим к BICC. 5.2.8.2(10.2.8.2) Блокирование и разблокирование каналов и пучков

каналов (значения CIC) Применяются модифицированные процедуры параграфа 2.8.2/Q.764: Сообщения circuit group blocking (unblocking) message используются, чтобы разрешить коммутационному оборудованию или эксплуатационной системе удалять (и возвращать) из работы значения CIC для трафика, таким образом обеспечивая средства, чтобы управлять количеством трафика, который может быть обслужен SN. Сircuit group blocking message может быть организован любым узлом. Действие этой команды будет иметь эффект запрещения предоставления соответствующих значений CIC любым вызовам, кроме тестовых, пока не будет получен сигнал снятия блокировки пучка. Эти значения CIC будут предоставляться только тестовым вызовам в исходящих и входящих направлениях. Любые вызовы, кроме тестовых приведут к аварийному отказу (см. 2.8.2.3/Q.764, пункт XIV). На сообщения circuit group blocking message и circuit group unblocking всегда требуется последовательность подтверждений. Подтверждение не будет выслано, пока соответствующее действие - или блокирование или разблокирование - не будет принято. Release message не должно отменять состояние блокирования и возвращать CIC в работу. Блокированный CIC будет возвращен в обслуживание только после прихода сообщения снятия блокировки от узла его выставившего. 5.2.8.2.1(10.2.8.2.1) Другие действия по получении сообщения

блокирования Применяется параграф 2.8.2.1/Q.764 со следующими исключениями/разъяснениями: a) Где текст касается сообщения Blocking message, это должно

интерпретироваться как Circuit Group Blocking message, включая соответствующий бит статуса CIC, установленный в «1».

b) Где текст касается сообщения blocking (unblocking) acknowledgement message, это должно интерпретироваться как circuit group blocking (unblocking) acknowledgement message.

c) Последний параграф должен быть заменен: "Когда значение CIC блокировано при помощи circuit group blocking message, эксплуатационная система должна быть информирована в оба конца сигнальной ассоциации".

5.2.8.2.2(10.2.8.2.2) Блокирование Пучка и сигналы снятия блокировки Применяется параграф 2.8.2.2/Q.764 со следующими разъяснениями/исключениями: a) Где текст касается каналов, это должно интерпретироваться как значения

CIC. b) 5-ый параграф не имеет силы. c) Процедуры аппаратного блокирования (снятия блокировки) не

поддерживается в BICC. d) Блокирование отдельного CIC поддерживается, используя Circuit Group

Blocking message. e) 7-ой параграф не применим. f) 8-ой параграф не применим.

35

5.2.8.2.3(10.2.8.2.3) Аварийное блокирование и процедуры

блокирования пучка Параграф 2.8.2.3/Q.764 применяется со следующими разъяснениями: a) Где текст касается каналов, это должно интерпретироваться как значения

CIC. b) Пункты X), XI), XII) и XIII) не имеют силы. 5.2.8.3(10.2.8.3) Запрос Пучка (национальное использование) Применяется параграф 2.8.3/Q.764 со следующими разъяснениями: a) Текст, касающийся возможностей аппаратного блокирования не имеет

силы. b) Где текст касается каналов, это должно интерпретироваться как значения

CIC. 5.2.9(10.2.9) Аварийные условия (состояния) 5.2.9.1(10.2.9.1) Двойная занятость Применяется параграф 2.9.1/Q.764 со следующими разъяснениями/исключениями: a) Где текст касается каналов, это должно интерпретироваться как значения

CIC. b) 2-ой параграф 2.9.1.2/Q.764 не применим. c) Для профилактического действия, метод 1 (2.9.1.3/Q.764) должен быть

применим для всех типов подключения (64 кбит/сек, мультискоростных или N х 64 кбит/сек). Метод 2 не применим.

d) Для определения ведущей станции метод a), 2.9.1.4/Q.764 должен быть применим независимо от типа проключения вызовов, (64 кбит/сек, мультискоростное или N х 64 кбит/сек), однако метод определения ведущего SN с помощью чётности/нечётности CIC, заменен экспертизой параметра CIC_control в примитиве START-INFO.indication primitive, см. приложение B. Этот примитив приходит от STC, то есть для сигнального маршрута. Методы b), c) и d) не применимы.

5.2.9.2(10.2.9.2) Обработка передачи вызывного сигнала (alarm) для

цифровых межстанционных каналов Не применима к BICC. 5.2.9.3(10.2.9.3) Сброс каналов и пучков (значения CIC) Применяется параграф 2.9.3/Q.764 следующими разъяснениями/исключениями: a) Где текст касается каналов, переведённых в состояние простоя, это

должно интерпретироваться как значения CIC, которые могут быть переведены в состояние многократного использования.

b) Когда приходят Reset или Circuit Group Reset message, необходимо чтобы в BCF был выслан сигнал сбросить соответсвующие несущие каналы. Это ускорит освобождение связей несущего канала.

c) Где текст касается каналов, переведённых в состояние простоя, это должно интерпретироваться как то, что значение CIC в настоящее время не может быть предоставлено для обслуживания вызова.

d) Где текст касается каналов, переведенных в состояние "idle blocked", это должно интерпретироваться, как то, что значение (я) CIC не могут быть доступными для многократного использования.

36

e) Пункт b) 2.9.3.2/Q.764 не имеет силы, так как аппаратное блокирование из-за отказа не рассматривается в BICC.

f) Пункт c) 2.9.3.2/Q.764 заменен на: "…отвечают в соответствии с сообщением подтверждения сброса пучка, в котором биты индикатора состояния CIC доступного для обслуживания кодированы 0, и биты индикатора состояния всех CICS, блокированных по эксплуатационным причинам установлены в 1".

g) Пункт h) 2.9.3.1/Q.764 и пункт g) 2.9.3.2/Q.764 не применимы, поскольку никакой специфической процедуры для мультискорстного или N х 64 кбит/сек типа подключения вызова не требуется.

h) Где текст касается "каналов, управление которыми распределено в Системе пользователей ЦИФРОВОЙ СЕТИ ИНТЕГРАЛЬНОГО ОБСЛУЖИВАНИЯ", это должно интерпретироваться как "значение (я) CIC под контролем BICC протокола".

i) Где текст касается каналов, это должно интерпретироваться как значения CIC.

j) Где текст касается использования сообщения Блокирования, это должно интерпретироваться как использование Circuit Group Blocking message.

5.2.9.4(10.2.9.4) Отказ в последовательности блокирования/снятия

блокировки Применяется параграф 2.9.4/Q.764 со следующими разъяснениями: a) Где текст касается к удалению каналов из обслуживания, это должно

интерпретироваться, как то, что значения CIC не должны использоваться для последующей передачи сигналов, пока эксплуатационное действие не исправит ситуацию.

b) Ссылки Blocking (Acknowledgement) и Unblocking (Acknowledgement) messages не имеют силы.

5.2.9.5(10.2.9.5) Получение ошибочных (неожидаемых) сообщений

сигнальной информации Применяется параграф 2.9.5/Q.764 со следующими исключениями/разъяснениями: a) Ссылки к MTP не применимы к BICC. b) Сообщения и параметры, которые обозначены как "не используемый" для

BICC, должны быть обработаны как неопознанные. c) Где текст касается каналов, это должно интерпретироваться как

значения CIC. d) Для мультискоростного и N х 64 кбит/сек типа проключения вызова

применяется пункт c) 2.9.5.1. (пункт e) 2.9.5.1 не применим). e) Текст, касающийся мультискоростного и N х 64 кбит/сек типа

проключения вызова, в третьем маркере пункта f), 2.9.5.1 не применим. f) Если сообщение получено со значением CIC, которое - не

предоставляется в SN, оно должно быть отвергнуто, однако, если SN поддерживает национальную опцию исрользования Unequipped Circuit Identification Code message (10.2.12), то процедура должна быть выполнена.

g) Если получен BICC_Data indication primitive с неожидаемым значением индикатора Action, должны быть приняты следующие действия: - Если не была закончена процедура установки (входящая или

исходящая) должна быть вызвана процедура Reset, 10.2.9.3. Любой сегмент, участвующий в обслуживании соответствующего вызова должен быть освобождён с указанием причины #111 "Protocol error, unspecified".

37

- Если процедура установки (входящая или исходящая) была закончена, примитив отвергается.

5.2.9.6(10.2.9.6) Отказ при приёме сообщения "Release Complete" - Таймеры

T1 и T5 Применяется параграф 2.9.6/Q.764 со следующими исключениями/разъяснениями: a) Где текст касается удаления каналов из обслуживания, это должно

интерпретироваться, как то, что значения CIC не должны использоваться для последующей передачи сигналов, пока эксплуатационное действие не исправит ситуацию.

b) Когда таймер T1 истекает, запрашивается BCF чтобы освободить несущий канал, как это описано в 10.2.3.1.

5.2.9.7(10.2.9.7) Неудача при приёме ответа на сообщение запроса

информации (национальное использование) Применяется параграфе 2.9.7/Q.764. 5.2.9.8(10.2.9.8) Другие состояния отказа 5.2.9.8.1(10.2.9.8.1) Невозможность отбоя в ответ на Release message Не рассматривается в BICC. ПРИМЕЧАНИЕ - успешное возвращение ресурсов несущего канала к неактивному состоянию - ответственность соответствующих функций управления несущим каналом. 5.2.9.8.2(10.2.9.8.2) Ошибка вызова Применяется параграф 2.9.8.2/Q.764. 5.2.9.8.3(10.2.9.8.3) Аварийные состояния освобождения (отбоя) Применяется параграф 2.9.8.3/Q.764. 5.2.9.9(10.2.9.9) Временное блокирование магистральной линии (TTB)

(национальное использование) Не рассматривается в BICC. 5.2.10(10.2.10) Контроль перегрузки сигнальной информации ISDN User

Part Параграф 2.10/Q.764 не применим. BICC может принимать CONGESTION.INDICATION примитив на интерфейсе к STC, см. Приложение B (Annex B). BICC корректирует телефонный трафик для этого сигнального отношения, согласно значению параметра Level, полученного в примитиве. 5.2.11(10.2.11) Автоматический контроль перегрузки Применяется параграф 2.11/Q.764.

38

5.2.12(10.2.12) Unequipped Circuit Identification Code message (национальное использование)

Параграф 2.12/Q.764 применяется со следующими разъяснениями: a) Где текст касается каналов, это должно интерпретироваться как значения

CIC. b) Где текст касается "unequipped circuit(s)", это должно интерпретироваться

как значения CIC, которые не предоставлены для использования. 5.2.13(10.2.13) Контроль доступности ISDN User Part Параграф 2.13/Q.764 не применим. (Применяются процедуры, описанные в 5.2.14). 5.2.14(10.2.14) MTP Пауза/продолжение Параграф 2.14/Q.764 не применим. BICC может принимать OUT-OF-SERVICE.indication и IN-SERVICE.indication primitives от STC, см. приложение B (Annex B). a) По получении примитива OUT-OF-SERVICE.indication никакие новые

вызовы не должны быть направлены к этому сигнальному отношению. Вызовы, находящиеся в процессе обслуживания, не должны быть отбиты даже при том условии, что сообщения сигнализации не могут быть посланы взаимодействующему узлу. (Сетевые службы могут отбить все подобные вызовы после выдержки какого-то определённого временного интервала, если требуется убедиться, что никакие фантомные вызовы не обслуживаются).

b) По получении IN-SERVICE.indication primitive трафик перезагружается. Телефонная загрузка должна быть согласно значению параметра Level, полученного в примитиве.

5.2.15(10.2.15) Сообщения Overlength Параграф 2.15/Q.764 применяется со следующим исключением: Процедура Q.764 для сокращения размера сообщения применяется, только если только длина сообщения превышает предел возможностей транспортного механизма, что обозначено в примитиве START-INFO.indication primitive, полученным от STC, см. приложение B (Annex B). 5.2.16(10.2.16) Поддержка Временного Альтернативного маршрута (TAR) Параграф 2.16/Q.764 применяется со следующим разъяснением: Процедура TAR касается только маршрутизации вызова. 5.2.17(10.2.17) Процедура Счетчика переходов по сети Параграф 2.17/Q.764 применяется со следующими исключениями/разъяснениями: a) Счетчик переходов по сети увеличивается в CSF, связан с управлением

вызовом. b) Где текст касается магистральных линии связи, это должно

интерпретироваться как значение CIC. c) Так как BICC не обязательно использует MTP для транспортировки

сигнальных сообщений, идентификация следующего/предыдущего узла - для дальнейшего изучения.

39

5.2.18(10.2.18) Процедура Call collect request Применяется параграф 2.18/Q.764. 5.2.19(10.2.19) Поддержка функций Hard To Reach Network Management Применяется параграф 2.19/Q.764. 5.2.20(10.2.20) Процедура Calling Geodetic location Применяется параграф 2.20/Q.764. Приложение А - Таймеры в ISDN UP Приложение A/Q.764 применяется со следующими исключениями/разъяснениями: a) Таймер T3 не используется. b) Таймер T4 не используется. c) Таймер T10 не используется. d) Таймеры T12, T13, T14 и T15 не используются. e) Таймеры T24, T25, T26 и T27 не используются. f) Таймеры T29 и T30 – см. Приложение C. g) Таймер T36 не используется. 5.4(10.4) Приложение В - Рисунки к базовым процедурам

обслуживания вызова Не применимы, см. Приложение I (Appendix I). 5.5(10.5) Приложение С - Примеры процедур echo control signalling Параграфы C 1, C 2, C 3, C 4.2, C 5.2 и C 7 не применяются. В параграфах C.4.1, C 5.1, C 6.1 и C 6.2 SN может действовать как станции, поддерживающие "простую" процедуру. 5.6(10.6) Приложение D - Примеры сигнальных процедур для типа

подключения, позволяющего переход на аварийный режим Применяется приложение D/Q.764. 5.7(10.7) Приложение E – Тестовые вызовы E/Q.764. 5.8(10.8) Приложение F - значения причины Применяется приложение F/Q.764. 5.9(10.9) Приложение G - процедуры Start Up Приложение G/Q.764 применяется со следующим исключением: Элемент G.3 b) не применим.

40

6.(11) Исключения к ITU-T Q.765 ITU-T Q.765 применяется со следующими исключениями: Ссылка на ОКС №7 в заголовке не уместна. Где текст относится к ISUP, это должно интерпретироваться, чтобы означать BICC. Последующие номера подпараграфов в пределах этого параграфа соответствуют нумерации в пределах ITU-T Q.765. 11.6.2.2.1 Общая модель BICC - адаптация узкополосного протокола ISUP для использования в транспортировке несущего канала и сообщения независимо от среды. Таким образом, BICC включает отличные от ISUP процедуры для основного управления вызовом. Также, BICC включает Пользовательскую часть (APM) для транспортировки специфической информации между равными по положению объектами BICC. Обобщенная модель для Прикладного Транспортного Прикладного механизма ISUP представлена в Рисунке 2/Q.765. В этой модели прикладная логика для пользователей APM рассматривается как составная часть Узловых функций (Application Process). Рекомендации ISUP для базового вызова (ITU-T Q.764) рассматривают спецификации сигнальных процедур и узловых функций ISUP вместе (не отдельно друг от друга), то есть разделение функциональных возможностей ISUP APM и функциями Nodal ISUP (узловыми функциями) не определены. ITU-T Q.765 также не разбивает базовый вызов по функциональным возможностям. Модель, приведенная на Рисунке 2/Q.765, принята для базового вызова в BICC (см. Рисунок 5).

T11107740-00

e

a

b

c

d

f

g

h

Exchange Application

Nodal functions

BICC AEI

BICCSAO

SACF BATASE

EHASE

APMASE

BICCASE

NI

Signalling Transport Converter

41

Рисунок 5/Q.1901 - модель технических требований BICC

В этой модели BAT ASE представлен для обеспечения транспортировки данных BICC (ISUP ASE был заменен a BICC ASE). Должно быть отмечено, что до сих пор не определено разбиение функциональных возможностей между BICC ASE и функциями Nodal (узловыми функциями). Замена ISUP ASE на BICC ASE только показывает что передача сигналов BICC - не тот же самый процесс, как передача сигналов ISUP. Процедуры BICC, поскольку они являются пользователем BAT ASE, должны рассматриваться как часть функций Nodal, (для соответствия модели, описанной в Q.765). Процедуры BICC, таким образом, обращаются к службам, предоставляемым BAT ASE через интерфейс (а), используя BICC_DATA примитив. Процедуры BICC, обозначенные блоком процедур BICC в Рисунке 3, и описанные текстом процедуры в параграфе 10 (ITU Q.765), представляют собой совокупность узловых функций BICC (как пользователь BAT ASE) и BICC ASE. Отдельно эти блоки не расписаны. Интерфейс (h) – это примитивный интерфейс служб транспортировки сигнализации BICC (BICC Signalling Transport Service primitive interface, согласно тому как это определено в приложении B, в то время как интерфейс (g) - определенная сигнальная транспортная служба, а в случае сигнального транспорта MTP3 - та же самая служба, что и в ITU-T Q.765. 11.10.2.1 Нормальные процедуры - Sending Параграф 10.2.1/Q.765 указывает, что предел в 272 октета для MTP - причина, которая заставила бы использовать сегментацию APM. Эта инструкция применима для BICC если примитив START-INFO.indication primitive, принимаемый от STC, см. Приложение B (Annex B), указывает, что основной механизм транспортировки сообщения может транспортировать только 272 октета. Однако, если транспорт может поддерживать больше чем 272 октета, тогда сегментация APM применима только в том случае, если информация прикладной программы BICC превышает предел в 255 октетов, наложенный параметром правил форматирования ITU-T Q.763. 11.12 Функция сетевого интерфейса Параграф 12/Q.765 применяется со следующими исключениями: 1) Когда текст касается MTP, это должно интерпретироваться, чтобы

означать фактический сигнальный транспорт. 2) Когда текст касается CIC, это должно интерпретироваться, чтобы означать

Код Образца Запроса (Call Instance Code). 3) Когда текст касается ITU-T Q.763, это должно рассматриваться как ссылка

на параграф 9 (clause 9). 4) Когда текст касается ITU-T Q.764, это должно рассматриваться как ссылка

на параграф 10 (clause 10). 5) Используется один сигнальный транспортный конвертер на сигнальный

маршрут, и таким образом функция распределения, выполняемая NI, работает только от значения CIC. Когда сигнальный транспорт - MTP, то OPC, DPC, SIO и SLS обрабатываются в пределах сигнального транспортного конвертера, как это описано в приложении C (Annex C).

6) Примитивный интерфейс (g) должен быть заменен примитивным интерфейсом, согласно тому, как это описано в соответствующем приложении к этой Рекомендации.

42

Приложение A (Annex A)

Процедуры для многократного использования неактивных несущих

каналов (сетевая опция)

А.1 Введение Это приложение описывает процедуры, которые должны быть выполнены для многократного использования неактивных несущих каналов. Когда опция многократного использования поддерживается сетью, новый несущий канал для вызова не устанавливается, а используется уже существующий ранее несущий канал. ПРИМЕЧАНИЕ - Многократное использование неактивных несущих каналов - сетевая опция. Сетевые подключения – находятся в зоне ответственности ISN, которые устанавливают их. Управлением набором неактивных несущих каналов занимается BCF, установивший эти каналы. • Эта спецификация не определяет процедуры, используемые в узле,

который ответственен за сетевое подключение, для определения, когда сетевые подключения должны быть переведены в неактивное состояние, а когда должны быть освобождены.

• Для предотвращения ситуаций, когда узел, ответственный за сетевое

подключение «забудет» освободить несущий канал, необходимо на втором (встречном) узле использовать специальный таймер, по истечении которого канал бы освобождался. Таймер должен обнуляться каждый раз, когда канал используется повторно для вызова, или когда он освобождается. По истечении таймера несущий канал освобождается со значением причины #31 "Normal unspecified". Значение таймера – локальный вопрос для каждого узла и не рассматривается в рамках этой рекомендации.

• Многократное использование несущих каналов может оказаться

неприменимым для некоторых технологий несущего канала. А.2 Процедуры Для расширения протокола BICC согласно параграфу 10 (clause 10) применяются следующие процедуры. А.2.1 Процедуры установления соединения в исходящем направлении А.2.1.1 Многократное использование «прямого» неактивного несущего

канала В течение процедуры установки соединения в прямом направлении (10.2.1.1.2.1.1), в ответ на запрос Установки несущего канала (Bearer Set-up request, пункт 3.1.2), BCF может указать, что для этого вызова может использоваться уже существующий несущий канал. В этом случае передаётся BICC_Data request primitive (соответственно сообщению APM), со следующей информацией: • BNC-ID (значение назначается BCF, указывая подключение для

многократного использования). • Action indicator, установленный в "Use idle". Исходящая процедура установки соединения ждет BICC_Data indication primitive, (соответственно сообщению APM), с Action indicator, установленным в "Switched".

43

Процедура установки исходящего соединения теперь успешно закончена. А.2.1.2 Многократное использование обратного неактивного несущего

канала В течение процедуры установления соединения в обратном направлении (10.2.1.1.2.1.2) во время ожидания Bearer Set-up indication от BCF (пункт 4), возможен прием BICC_Data indication primitive (соответственно сообщению APM message), включающий Action indicator, установленный в значение "Use idle", указывающий на то, что для этого вызова должен использоваться уже существующий несущий канал. В этом случае, к BCF направляют запрос на многократное использование неактивного несущего канала, включая BNC-ID (значение, полученное в BICC_Data indication primitive). 1) Если BCF принимает этот запрос (положительный исход), то отсылается

BICC_Data request primitive, (соответственно сообщению APM), включая: • Action indicator, установленный в значение "Switched". Это указывает на успешное завершение процедуры установки исходящего

соединения. 2) Если BCF будет не в состоянии принять этот запрос (отрицательный

исход), установка вызова будет сброшена согласно 10.2.9.3. (Используя причину – отказ из-за перераспределения системных ресурсов).

А.2.2 Процедуры установления входящего соединения А.2.2.1 Многократное использование прямого неактивного несущего

канала В течение процедуры установки в прямом направлении, 10.2.1.1.2.2.1, во время ожидания Bearer Set-up indication от BCF (пункт 5), возможен прием BICC_Data indication primitive (соответственно сообщению APM), содержащий Action indicator, установленный в значение "Use idle", указывающий, что для данного вызова должен использоваться уже существующий несущий канал. В этом случае к BCF направляют запрос на многократное использование несущего канала, включая BNC-ID (значение которого получено в BICC_Data indication primitive). 1) Если BCF принимает этот запрос (положительный исход), то отсылается

BICC_Data request primitive, (соответственно сообщению APM), включая: • Action indicator, установленный в значение "Switched". Это указывает на успешное завершение процедуры установки исходящего

соединения. 2) Если BCF будет не в состоянии принять этот запрос (отрицательный

исход), установка вызова будет сброшена согласно 10.2.9.3. (Используя причину – отказ из-за перераспределения системных ресурсов).

A.2.3 Процедура контроля посылки IAM Применяется процедура, описанная в 10.2.1.1.2.3, за исключением того, что завершение установки пути несущего канала обозначается завершением процедуры установки входящего соединения, описанной в этом приложении (Annex A), вместо различных вариантов, перечисленных в том параграфе. А.2.4 Переговоры кодеков Переговоры Кодер-декодера не применимы при многократном использовании неактивных несущих каналов. А.2.5 Процедура освобождения (Release)

44

ПРИМЕЧАНИЕ - в поддержку этой процедуры, BCF может не разрушать подключение сети несущего канала при отбое вызова.

Приложение В (Annex B)

Сигнальная транспортная служба BICC (Служба транспортировки сигнальной информации)

B.1 Архитектура Сигнальный протокол BICC может быть развернут на разных стеках сигнальных транспортных протоколов (см. рисунок В.1). Два равнозначных блока CSF (Call Service Function) для уверенной передачи информации между ними и индикаторами доступности услуг используют службу транспортировки сигнальной информации BICC (BICC Signalling Transport service). Т.е. обмен и передача сообщениями BICC между однозначными протокольными единицами BICC происходит с использованием этой службы.

Примечание – В каждом CSF сигнальный транспортный конвертер ассоциирован с транспортом сигнализации BICC, т. е отдельный транспортный сигнальный конвертер ассоциирован с каждым смежным CSF. Рисунок B.1/Q.1901 - Функциональная архитектура передачи сигналов CSF

B.2 Определения Для целей этого приложения (Annex B) и других приложений, определяющих другие специфические Сигнальные Транспортные Конвертеры, вводятся специальные определения: B.2.1 BICC signalling endpoint: конечная точка транспортировки сигнализации BICC (пункт терминации сигнального трафика). B.2.2 BICC signalling transport: функция, которая дает возможность взаимодействовать равнозначным сигнальным объектам BICC (передача информации) независимо от типа основного (ниже по уровню) сигнального транспорта. B.2.3 signalling transport: сигнальное звено или сеть, соединяющая два узла BICC. B.2.4 signalling transport converter: функция, которая конвертирует (преобразовывает) услуги, предоставляемые отдельным сигнальным

45

транспортом в соответствии с требованиями Универсального Сигнального Транспорта. B.3 Сигнальная транспортная служба BICC B.3.1 Введение Этот параграф определяет поток информации, передаваемый сигнальным транспортным конвертером – на границе протокола BICC. Концептуально, существует один объект STC (signaling transport converter) на сигнальную ассоциацию. BICC передает или принимает сообщения частной сигнальной ассоциации, используя специфический SAP. B.3.2 Определение примитивов Услуги, описанные в Таблице B.1 (см. ниже) определены следующим образом. a) IN-SERVICE.indication: Этот примитив указывает, что сигнальный

транспорт способен предоставить возможность обмена сообщениями между равными по положению объектами. Эта индикация должна поддерживаться через SAP, независимо от сигнального протокола BICC.

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

c) TRANSFER.request: Этот примитив используется сигнальным протоком BICC, для передачи сообщений между равными по положению объектами.

d) TRANSFER.indication: Этот примитив поддерживает сигнальные сообщения равного по положению объекта к сигнальному протоколу BICC.

e) CONGESTION.indication: примитив, используемый для передачи информации относительно перегрузки сети связи.

f) START-INFO.indication: Этот примитив указывает для BICC максимальную длину SDU, которые может передавать STC, а так же является ли узел ведущим в процедуре установления соединения.

Таблица B.1/Q.1901 - Примитивы и параметры сигнального транспортного подуровня BICC

Тип Универсальное название примитива Запрос Индикатор Подтверждение Ответ

START-INFO − Max_Length CIC_Control

− −

IN-SERVICE − Level − −

OUT-OF-SERVICE − (примечание 1) − −

CONGESTION − Level − −

TRANSFER Sequence Control BICC Data

Priority (примечание 2)

BICC Data

Priority (примечание 2)

− −

− Эти примитивы не определены. Примечание 1 − Примитив не имеет параметров.

Примечание 2 − Этот параметр – национальная опция.

46

B.3.3 Параметры a) BICC Data Этот параметр содержит законченное сообщение BICC; его представляет

STC SDU. b) Level Этот параметр указывает уровень перегрузки. Значение параметра Level

зависящее от наполнения сети. c) Sequence Control Этот параметр указывает для STC значение, которое может

использоваться нижележащим (ниже уровнем) сигнальным транспортом STC для разделения нагрузки и/или доставки в режиме “in-sequence” (режим последовательности).

d) Max_Length Этот параметр указывает максимальную длину сообщений, которые могут

транспортироваться на сигнальной ассоциации. e) CIC_Control Этот параметр указывает для BICC, является ли он контрольной единицей

для чётных/нечётных CIC текущей сигнальной ассоциации. f) Priority Этот параметр указывает приоритет сообщения BICC. B.3.4 Установление (Establishment) При установлении объекта сигнальный транспортный конвертер и связанного с ним объекта пользователя сигнального транспортного конвертера, например в процессе включения (power up), начальные условия те же, как если бы через SAP только что был передан OUT-OF-SERVICE.indication. Так же в это время START-INFO.indication отсылается к BICC.

Приложение С (Annex C) Дополнительные технические требования для развертывания ITU-T Q.1901

на MTP3 и MTP3B

C.1 Обобщение Это приложение описывает взаимодействие между сигнальным транспортным конвертером (STC) и следующим вышестоящим уровнем, т.е объектом сигнального протокола BICC, а так же между STC и Частью Передачи Сообщений (MTP), и между STC и операциями управления уровнем (layer management operations). Это приложение описывает подуровень сигнального транспортного конвертера, базирующийся на МТР, описанной в ITU-T Q.704 [12] “MTP”и ITU-T Q.2210 “MTP3b”; обе рекомендации описывают одноранговый протокол для передачи информации и управления между любой парой объектов МТР 3 уровня. Это приложение (Annex C) охватывает спецификации структуры подуровня, дополнительных структур PDU подуровня сигнального транспортного конвертера, а так же процедур, требуемых для нужд сигнальной транспортной службы (универсальной сигнальной транспортной службы), описанной в приложений В (Annex B). C.2 Дополнительные Сокращения DPC Код Пункта Назначения (Адресата)

47

MTP Часть Передачи сообщения OPC Код исходного пункта PDU Единица Данных Протокола SDU Служебная Единица Данных SIO Октет Служебной информации SLS Код Выбора Сигнального Звена C.3 Структура сигнального транспортного конвертера на подуровне MTP Подуровень сигнального транспортного конвертера (STC) базируется над МТР. Эта архитектура позволяет поддерживать услуги, предоставляемые уровнем 3 МТР (ITU-T Q.704 [12] и ITU-T Q.2210 [13]). Сигнальный транспортный конвертер (STC) предоставляет услуги, запрашиваемые Сигнальной Транспортной Службой (описанной в приложении В – Annex B), когда сигнальный протокол BICC позволяет их использовать. Этот приложение описывает: • Взаимодействие между STC и BICC; • Взаимодействие между STC и подуровнем уровня 3 MTP; и • Взаимодействие между STC и управлением уровнем. C.4 Услуги, предоставляемые STC STC предусматривает прозрачную передачу данных BICC между равными по положению объектами BICC. Используемые для этих целей коммуникационные ресурсы остаются невидимыми для объектов BICC. В частности, службы STC предусматривают: a) Независимость от нижестоящих (нижних уровней) средств передачи Службы STC освобождают своих пользователей от всех проблем,

связанных с работой этой службы. Исключая возможные влияния требований качества обслуживания, передача данных по различным нижестоящим (основным) сетям была бы прозрачна (в том смысле, что для вышеуказанных пользователей не было бы никакой разницы).

b) Прозрачность переданной информации Служба STC предусматривает прозрачную передачу выровненных по

октетам данных BICC. Это не ограничивает содержание, формат, или кодирование информации и не требует изменение структуры или значений.

c) Служебное Сообщение Доступности Как только нижестоящая служба (МТР) сообщает о

готовности/неготовности службы передачи данных, после некоторого преобразования, эта информация поступает к BICC.

C.5 Функции STC STC выполняет следующие функции: a) Функция информирования BICC о готовности/неготовности службы

передачи сообщений МТР. b) Информирование BICC о перегрузке Эта функция транслирует и передаёт от MTP к BICC индикаторы

перегрузки. c) Индикация максимальная длины для BICC Эта функция указывает для BICC максимальную длину PDU, которые STC

может передавать; указывается при создании STC объекта. d) Управление индикацией CIC для BICC

48

Эта функция указывает для BICC (при создании STC объекта) служит он как узел управления для нечетных или четных значений CIC на этой сигнальной ассоциации.

C 6 Элементы для связи «уровень-к-уровню» C 6.1 Сигнальная транспортная служба BICC Сигнальная транспортная служба BICC определена в приложении B (Annex B). C 6.2 Услуги, предоставляемые МТР Примитивы и параметры показаны на Таблице C.1. ПРИМЕЧАНИЕ - Это служба соответствует "Специфической Сигнальной Транспортной Службе» на рисунке В.1.

C 1/q.1901 Таблицы – Сервисные примитивы МТР

Тип Универсальное название примитива Запрос Индикатор Ответ Подтверждение

MTP-TRANSFER OPC (см. 2.2/Q.704) DPC (см. 2.2/Q.704) SLS (см. 2.2/Q.704)

(Примечание 1) SIO (см. 4.2/Q.704)

User Data (см. 2.3.8/Q.703)

OPC (см. 2.2/Q.704) DPC (см. 2.2/Q.704) SLS (см. 2.2/Q.704)

(Примечание 1) SIO (см. 14.2/Q.704)

User Data (см. 2.3.8/Q.703)

− −

MTP-PAUSE (Stop)

− Affected DPCa) Взаимодействующий

DPC

− −

MTP-RESUME (Start)

− Affected DPCa) Взаимодействующий

DPC

− −

MTP-STATUS − Affected DPC Cause

(Примечание 2)

− −

− Примитив не определён. a) Смотреть 7.2.6/Q.701 [11].

Примечание 1 − Пользователи МТР должны принимать во внимание, что этот параметр используется для разделения нагрузки МТР, поэтому значения SLS должны быть распределены равномерно, насколько это возможно. МТР гарантирует (с высокой степенью вероятности), что последовательность сообщений с одинаковым кодом SLS при передаче будет сохранена. Примечание 2 – Параметр Cause имеет в настоящее время четыре значения: I) Signalling network congested – переполнение сети связи (плюс уровень перегрузки). Значение уровня используется, если применяются национальные параметры с

приоритетами перегрузки или множественные сигнальные звенья без этих приоритетов (согласно тому как это определено в ITU-T Q.704 [12]).

II) User Part Unavailability – неготовность системы пользователей: неизвестная. III) User Part Unavailability – неготовность системы пользователей: некорректный удалённый

пользователь (технически неподдерживаемый). IV) User Part Unavailability – неготовность системы пользователей: недоступный удалённый

пользователь.

49

C.6.2.1 Определение примитивов a) MTP-TRANSFER: примитив используется между уровнем 4 и уровнем 3

(SMH), для обеспечения нужд службы транспортировки сообщений MTP. b) MTP-PAUSE: примитив указывает для "Пользователей" полную

неспособность предоставления услуг MTP по данному направлению (см. 7.2.6/Q.701 [11]). ПРИМЕЧАНИЕ 1 - пункт сигнализации недоступен через MTP. MTP определит, когда пункт сигнализации снова станет доступным и вышлет индикатор MTP-RESUME. Пользователь должен ждать этот индикатор, ему запрещено высылать сообщения этому пункту сигнализации. Если считается, что недоступным является удалённый пользователь, то это состояние может поддерживаться или быть отменено по усмотрению локального пользователя.

c) MTP-RESUME: примитив указывает для "Пользователей" возможность предоставления услуг MTP по данному направлению (см. 7.2.6/Q.701 [11]).

Этот примитив переводит адресат в доступное состояние (ITU-T Q.704 [12]). ПРИМЕЧАНИЕ 2 - Когда индикатор MTP-RESUME дается каждому пользователю, MTP, не знает, является ли отдаленный равный по положению пользователь доступным. Определить это - ответственность каждого пользователя (В смысле – при передаче этого индикатора пользователям, МТР не знает, являются ли эти пользователи доступными или нет).

d) MTP-STATUS: примитив указывает для "Пользователей" частичную неспособность предоставления услуг MTP по данному направлению (см. 7.2.6/Q.701 [11]). Примитив также используется, чтобы указать для Пользователя, что отдаленный соответствующий Пользователь недоступен и причину этого (см. 11.2.7/Q.704 [12]).

В случае применения национальных параметров или многократных сигнальных звеньев без этих параметров (ITU-T Q.704 [12]), этот примитив так же используется для указания изменения уровня перегрузки.

Этот примитив указывает адресату на перегрузку/занятость пользовательской части (User Part) – см. ITU-T Q.704 [12]. ПРИМЕЧАНИЕ 3 - в случае неготовности удаленного пользователя, локальный пользователь ответствен за определение готовности этого равного по положению пользователя. Этот пользователь предостерегается от передачи нормального телефонного трафика недоступному удаленному пользователю, т.к. ни одно сообщение доставлено не будет, зато приведет к повторному выставлению индикатора MTP-STATUS. МТР не будет выдавать показания относительно готовности/неготовности удалённого равного по положению пользователя, пока происходит отсылка сообщений локальным пользователем.

C.6.2.2 Повторный запуск Когда заканчивается процедура повторного запуска МТР, МТР указывает на конец процедуры всем локальным пользователям МТР, указывая доступность/недоступность каждой точки сигнализации (см. предложение 9/Q.704 [12]). C.6.3 Примитивы между STC и уровнем управления

50

Этот параграф определяет поток информации STC – граница Уровня Управления. Набор примитивов между STC и уровнем управления перечислен в таблице C.2

C.2/Q.1901 Таблицы - Примитивы и параметры между STC и уровнем управления

Тип Универсальное

название примитива Запрос Индикация Ответ Подтверждение

MSTC-ERROR − Cause − −

− Примитив не определён.

C.6.3.1 Определение примитивов • MSTC-ERROR: примитивы MSTC-ERROR используются, чтобы сообщить

уровню управления данные относительно ошибок. C.6.3.2 Параметры • Cause – Причина Параметр причины может указывать на следующие ошибки:

a) Система пользователей недоступна (неизвестна); b) Система пользователей недоступна; и c) Неподдерживаемая система пользователей.

C.7 Элементы Протокола для одноранговой связи C 7.1 STC сообщения (STC-PDUs) Следующие сообщения STC (PDU) используются для обмена информации между равными по положению объектами STC: Сигнальное сообщение BICC Этот PDU используется для переноса сигнальных сообщений BICC равнозначному объекту STC через сеть МТР. Длина каждого сигнального сообщения не может превышать максимальную длину, указанную в параметре Max_Length parameter. STC не добавляет какой-либо Контрольной Протокольной Информации к этому сообщению. C.7.2 Таймеры STC Объект STC требует использования следующих таймеров: a) Timer_Long Этот таймер соответствует таймеру T30 2.10.2/Q.764 [4].

ПРИМЕЧАНИЕ 1 - Этот таймер используется процедурой индикации перегрузки. Получение повторной индикации перегрузки от MTP до истечения этого таймера интерпретируется как ухудшение ситуации перегрузки. С другой стороны, если от MTP не получена никакой индикации перегрузки до истечения таймера, это рассматривается как улучшение ситуации перегрузки.

b) Timer_Short

51

Этот таймер соответствует таймеру T29 в 2.10.2/Q.764 [4]. ПРИМЕЧАНИЕ 2 - Этот таймер используется процедурой индикации перегрузки. Роль этого таймера – решение конфликтов при приеме многократных показаний перегрузки MTP в быстрой последовательности

C.7.3 Параметры STC Параметры STC определяются при создании нового объекта STC и остаются неизменными в течение срока службы этого объекта. Определены следующие параметры: a) STC_DPC Код Пункта (точки), соответствующий пункту (точке) адресата,

обслуживаемому объектом STC. b) STC_OPC Код Пункта (точки), соответствующий исходящему пункту (точке),

обслуживаемому объектом STC. c) STC_SIO Октет служебной информации содержит служебный индикатор и

подслужебное поле. Подслужебное поле несет сетевые биты индикатора и запасные биты; запасные биты - для национального использования, для указания приоритета сообщения. Сетевой индикатор должен указать на то, к какой сети принадлежит сигнальное отношение. Служебный индикатор должен указывать "сигнализация BICC ". ПРИМЕЧАНИЕ 1 - значение Служебного индикатора для Bearer Independent Call Control - "13" (см. ITU-T Q.704 [12] и ITU-T Q.2210 [13]).

d) Значение Timer_Long Значение Timer_Long определено в 2.10.2/Q.764 [4] как значение для

таймера T30. ПРИМЕЧАНИЕ 2 - Timer_Long – обычно задаётся в диапазоне от 5 до 10 секунд.

e) Значение Timer_Short Значение Timer_Short определено в 2.10.2/Q.764 [4] как значение для

таймера T29. ПРИМЕЧАНИЕ 3 - Timer_Short - обычно задаётся в диапазоне от 0.3 до 0.6 секунд.

f) Значение Max_Length Значение Max_Length может быть установлено в или "272" или "4096".

ПРИМЕЧАНИЕ 4 - параметр Max_Length установлен следующим образом: • если BICC развернут на сигнальных отношениях MTP3, параметр Max_Length

установлен в "272". • если BICC развернут на сигнальных отношениях MTP3B, параметр

Max_Length установлен в "272" или "4096". Выбор значений предоставляется сетевым администраторам.

C.8 Процедуры STC C.8.1 Исходные данные Этот параграф описывает как STC действует при включении (power up). Инициализация STC вместе с максимально разрешённой длинной сообщения BICC индицируется параметром CIC_Control примитива START-INFO.indication. Параметр CIC_Control получают следующим образом: • Если значение параметра STC_OPC большее чем значение параметра

STC_DPC, то CIC_CONTROL укажет для узла BICC, что он – узел управления для чётных значений CIC ассоциаций вызова.

52

• Если значение параметра STC_DPC большее чем значение параметра STC_OPC, то CIC_CONTROL укажет для узла BICC, что он – узел управления для нечётных значений CIC ассоциаций вызова.

Если STC получает примитив MTP-RESUME.indication, то считается, что служба МТР для однорангового взаимодействия успешна инициализирована. Тогда STC посылает к BICC примитив IN-SERVICE.indication. Этот примитив несёт параметр Level; значение которого зависит от сети. Если параметр указывает на перегрузку, то запускается процедура индикации перегрузки (см. С.8.4.). C.8.2 Процедура передачи сигнальных сообщений BICC C.8.2.1 Посылка сигнального сообщения После получения примитива TRANSFER.REQUEST от BICC, STC должен разместить сигнальное сообщение неизменным в BICC Signalling Message PDU и получить значение Signalling Link Selection Value (SLS) из принятого параметра Sequence Control. Затем необходимо передать PDU в MTP используя примитив MTP-TRANSFER.request. Этот примитив переносит параметры, указанные в таблице С.3.

C 3/Q.1901 Таблицы - Параметры в примитиве MTP-TRANSFER.REQUEST

Параметр Содержание

MTP User Data неизменённое BICC Signalling Message, принятое в Data parameter

Point code of the originating exchange Значение предоставленного параметра STC_OPC

Point code of the destination exchange Значение предоставленного параметра STC_DPC

Service Information Octet Значение предоставленного параметра STC_SIO (Примечание)

Signalling Link Selection Value (SLS) Получено из принятого параметра Sequence Control

Примечание – SIO может быть увеличен при использовании национальной опции указания приоритетов согласно значению, принятому в параметре Priority

C.8.2.2 Прием сигнального сообщения После получения примитива MTP-TRANSFER.INDICATION, содержащего Сигнальное Сообщение BICC PDU, STC должен передать Пользовательские Данные MTP в неизменном состоянии к BICC в примитиве TRANSFER.INDICATION. Как национальная опция, примитив TRANSFER.INDICATION может указывать на приоритет, информация о котором извлекается из Октета Служебной информации. C 8.3 Процедура доступности Адресата При приеме примитива MTP-PAUSE.INDICATION, STC выполняет следующие действия: • Если взаимодействующий адресат - не является адресатом (Сигнальным

пунктом), известным STC, то не предпринимается никаких действий. • Если взаимодействующий адресат – является известным STC адресатом

(Сигнальным пунктом), то к BICC передаётся примитив OUT-OF-SERVICE.indication.

53

При приеме примитива MTP-RESUME.INDICATION, STC выполняет следующие действия: • Если взаимодействующий адресат - не является адресатом (Сигнальным

пунктом), известным STC, то не предпринимается никаких действий. • Если взаимодействующий адресат – является известным STC адресатом

(Сигнальным пунктом), то к BICC передаётся примитив IN-SERVICE.indication. Примитив IN-SERVICE.indication переносит параметр Level, значение которого определяется сетью. Если параметр указывает на перегрузку, то запускается процедура индикации перегрузки (см. С.8.4.).

C 8.4 Процедура Congestion Indication – индикация перегрузки При получении примитива MTP-STATUS.INDICATION со значением причины, установленным в "перегрузка сети связи", STC действует следующим образом: 1) При получении STC первой индикации перегрузки, к BICC должен быть

направлен примитив CONGESTION.INDICATION с параметром Level, указывающим на начало перегрузки. В то же самое время должны быть начаты таймеры Timer_Short и Timer_Long.

2) Во время выполнения Short_Timer все сообщения о перегрузке для того же destination point code должны игнорироваться, чтобы не уменьшать трафик слишком быстро.

3) Прием индикации перегрузки после истечения таймера Timer_Short, но во

время выполнения Timer_Long, должно привести к передаче примитива CONGESTION.INDICATION к BICC. Он содержит параметр Level, который увеличен относительно предыдущего уровня. В то же самое время, Timer_Short и Timer_Long будут перезапущены.

4) Это пошаговое увеличение уровня перегрузки должно продолжиться, пока не будет достигнут максимальный уровень.

5) Если Timer_Long истекает (то есть во время его выполнения не были получены никакие показания перегрузки), BICC будет послан CONGESTION.INDICATION, содержащий параметр Level, пониженный относительно предыдущего уровня. Timer_Long будет перезагружен, процедура будет продолжена до полного восстановления трафика.

C.8.5 Доступность системы пользователей При получении примитива MTP-STATUS.INDICATION с параметром причины, установленным в значение "user part unavailability – unknown", "user part unavailability – inaccessible remote user" или "user part unavailability – unequipped remote user", BICC должен быть информирован посредством примитива OUT-OF-SERVICE.indication, и должен быть выслан примитив MSTC-ERROR.INDICATION с параметром причины, установленным в значение, обозначенное в Таблице C.4. Если STC принимает примитив MTP-TRANSFER.INDICATION, то выпустит примитив IN-SERVICE.indication до выполнения процедуры, указанной в C 8.2.2. IN-SERVICE.indication примитив несет параметр LEVEL; значение параметра – определяется сетью. Если Уровень указывает перегрузку, тогда запускается процедура индикации перегрузки (C 8.3).

C 4/q.1901 Таблицы – Значения параметра Cause

Cause parameter in MTP-STATUS.indication

Cause parameter in MSTC-ERROR.indication

user part unavailability – unknown user part unavailable (unknown)

54

user part unavailability – inaccessible remote user user part unavailable (inaccessible)

user part unavailability – unequipped remote user user part unequipped

Приложение D (Annex D)

Дополнительные технические требования для развертывания ITU-T Q.1901 на SSCOP и SSCOPMCE

D.1 Обобщение Это приложение описывает подуровень сигнального транспортного конвертера, базирующегося на SSCOP (который описывает одноранговый протокол передачи информации и управления между объектами SSCOP). Взаимодействие SSCOP в режиме точка-точка описано в ITU-T Q.2110 [14]. Взаимодействие в мульти звеньевой среде описано в ITU-T Q.2111 [15]. Поскольку эта услуга уже описана в других рекомендациях, то здесь только расшифровываются или вводятся новые термины для нужд данной рекомендации. Сигнальный транспортный конвертер BICC, опирающийся на SSCOP может быть развёрнут на любом стеке протоколов, поддерживающем SSCOP. Это приложение охватывает описание структуры подуровня, структуры PDU подуровня сигнального транспортного конвертера, а так же механизмы для поддержки сигнальной транспортной службы, описанной в приложении В (Annex B). Это приложение описывает взаимодействие между STC и вышестоящим уровнем, т.е. объектом сигнального протокола BICC, а так же между STC и Service Specific Connection-Oriented Protocol (SSCOP), и между STC и уровнем управления. D.2 Определения Это приложение основано на концепциях, разработанных в ITU-T Q.2110 [1], и использует следующие термины, определенные в той Рекомендации: a) Service Specific Coordination Function - Служба специфических функций

координации. b) Service Specific Connection-Oriented Protocol – Служба специфического

протокола, ориентированного на соединение. D.3 Дополнительные Сокращения ATM Asynchronous Transfer Mode – Режим асинхронной передачи BR Buffer Release – Освобождение буфера CPCS Common Part Convergence Sublayer – Подуровень общей части

конвергенции MU Message Unit - Единица Сообщения PDU Protocol Data Unit - Единица Данных Протокола SAP Service Access Point – Точка доступа к услуге SDU Service Data Unit - Служебная Единица Данных SN Sequence Number - Порядковый номер SSCOP Service Specific Connection-Oriented Protocol (ITU-T Q.2110 [14]) –

Служба специфического (определённого) протокола, ориентированного на соединение

SSCOPMCE Service Specific Connection-Oriented Protocol in a multi-link or Connectionless Environment (ITU-T Q.2111 [15]) – Служба специфического протокола, ориентированного на соединение, в

55

мульти звеньевой среде или среде без установления соединения.

SSCOP-UU SSCOP user-to-user information - SSCOP информация пользовательского режима

SSCS Service Specific Convergence Sublayer – Служба специфического подуровня конвергенции.

D.4 Структура сигнального транспортного конвертера на подуровне

SSCOP Подуровень, на котором находится сигнальный транспортный конвертер, располагается поверх the Service Specific Convergence Sublayer (SSCS) уровня адаптации ATM (AAL). Это позволяет поддерживать услуги, предоставляемые Service Specific Connection-Oriented Protocol (SSCOP), описанные в ITU-T Q.2110 [13]. SSCOP так же базируется на SSCS. В SSCS, Service Specific Coordination Function "Нулевая" в смысле, что примитивы для AAL эквивалентны примитивам SSCOP (см. D.7.2) но идентифицируются как примитивы AAL вместо AA-сообщений, согласно с соглашениям об именах примитивов в SAP (см. 6.1/Q.2110 [13]). STC предоставляется для служб, требуемых Сигнальной Транспортной Службой, определённой в приложении B (Annex B), когда сигнальный протокол Bearer Independent Call Control задействует эти службы. STC полагается на уверенную передачу данных посредством SSCOP. Это приложение определяет: • Взаимодействие между STC и сигнальным протоколом BICC; • Взаимодействие между STC и подуровнем SSCOP; и • Взаимодействие между STC и уровнем управления. D.5 Услуги, предоставляемые STC STC обеспечивает прозрачную передачу данных, то есть данных BICC между равными по положению объектами BICC. Задействованные ресурсы остаются невидимыми для BICC. В частности службы STC предусматривают: a) Независимость от нижестоящих (нижних уровней) средств передачи Службы STC освобождают своих пользователей от всех проблем,

связанных с работой этой службы. Исключая возможные влияния требований качества обслуживания, передача данных по различным нижестоящим (основным) сетям была бы прозрачна (в том смысле, что для вышеуказанных пользователей не было бы никакой разницы).

b) Прозрачность переданной информации Служба STC предусматривает прозрачную передачу выровненных по

октетам данных BICC. Это не ограничивает содержание, формат, или кодирование информации и не требует изменение структуры или значений.

c) Установление и освобождение соединения: Служба STC предусматривает обслуживание с постоянным соединением.

Поскольку нижележащая служба (SSCOP) должна устанавливать соединения, STC устанавливает и поддерживает это подключение от имени пользователя; пользователь информируется относительно доступности (готовности) уверенного обслуживания передачи данных. ПРИМЕЧАНИЕ - учреждение любого подключения на уровне ниже SSCOP – не рассматривается в этой Рекомендации.

56

D.6 Функции STC STC исполняет следующие функции: a) Установление и поддержание соединения: Эта функция предусматривает установление и техническое обслуживание

SSCOP-ПОДКЛЮЧЕНИЯ. После освобождения подключения SSCOP, предпринимается его восстановление. ПРИМЕЧАНИЕ - подключение ниже подуровня, указанного в ITU-T Q.2110 может быть установлено или по требованию, или постоянно.

b) Доклад BICC о готовности (доступности) подключения: Эта функция сообщает о доступности (готовности) или неготовности

SSCOP-ПОДКЛЮЧЕНИЯ пользователю STC. c) Индикация максимальной длины на BICC: Эта функция указывает для BICC максимальную длину PDU, который STC

может передавать; это обозначается при создании объекта STC. d) Управляют индикацией CIC на BICC: Эта функция при создании STC объекта указывает для BICC является ли

узел BICC узлом управления для нечетных или четных значений CIC на сигнальной ассоциации.

Кроме того, используются следующие услуги SSCOP (см. ITU-T Q.2110 [1]): e) Целостность Последовательности STC-SDUS. f) Исправление Ошибок STC-SDUS. g) Управление потоком данных STC-SDUS. h) Сохранение действующим (Keep alive). D.7 Элементы межуровневой связи D.7.1 Сигнальная транспортная служба BICC Сигнальная транспортная служба BICC определена в приложении В (Annex B) . D.7.2 Услуги, предоставляемые SSCOP Этот параграф определяет поток информации от сигнального транспортного конвертера BICC к AAL подуровню AAL Service Specific Convergence Sublayer (SSCOP). ПРИМЕЧАНИЕ – Эта услуга соответствует "Specific Signalling Transport Service" на Рисунке B.1. Набор примитивов AAL между STC и SSCOP определен в Таблице D.1. D.7.2.1 Определение примитивов a) AAL-ESTABLISH: примитивы используются, чтобы установить прямое

соединение для уверенной передачи информации между равными по положению объектами пользователя.

b) AAL-RELEASE: примитивы используются, чтобы закончить прямое соединение для уверенной передачи информации равными по положению объектами пользователя.

c) AAL-DATA: примитивы используются для уверенной передачи по принципу точка-точка SDU между равными по положению объектами пользователя.

d) AAL-RESYNC: примитивы используются, чтобы восстановить синхронизацию подключения SSCOP. ПРИМЕЧАНИЕ 1 - примитивы AAL-RESYNC не используется активно в соответствии с протоколом, указанным в этой Рекомендации; однако могут

57

применяться для индикации ошибкоустойчивости и для ответа на некоторые не специфицированные примитивы.

e) AAL-RECOVER: примитивы используются в течение восстановления после ошибок протокола. ПРИМЕЧАНИЕ 2 - В отсутствии ошибок протокола, примитивы AAL-RECOVER не будут использоваться; однако однако может применяться для индикации ошибкоустойчивости и для ответа на некоторые не специфицированные примитивы. ПРИМЕЧАНИЕ 3 - примитивы AAL-UNITDATA, AAL-RETRIEVE и AAL-RETRIEVE-COMPLETE не используются объектом STC, описанным в этом приложении.

Таблица D.1/Q.1901 - примитивы и параметры SSCOP

Тип Универсальное название примитива Запрос Индикация Ответ Подтверждение

AAL-ESTABLISH SSCOP-UU BR

SSCOP-UU SSCOP-UU BR

SSCOP-UU

AAL-RELEASE SSCOP-UU (Примечание 2)

SSCOP-UU Source

− (Примечание 1) (Примечание 2)

AAL-DATA MU MU SN

− −

AAL-RESYNC SSCOP-UU (Примечание 2)

SSCOP-UU (Примечание 1) (Примечание 1) (Примечание 2)

AAL-RECOVER − (Примечание 1) (Примечание 1) −

AAL-UNITDATA MU (Примечание 2)

MU (Примечание 2)

− −

AAL-RETRIEVE RN (Примечание 2)

MU (Примечание 2)

− −

AAL-RETRIEVE COMPLETE

− (Примечание 1) (Примечание 2)

− −

− Этот примитив не определён. Примечание 1 − Примитив не имеет параметров. Примечание 2 − Примитив не используется STC.

D.7.2.2 Определение параметров Таблица D.1 перечисляет параметры, связанные с каждым SSCOP примитивом. Определение параметров следующие: a) MU (Message Unit – Единица Сообщения): Параметр Message Unit используется в течение передачи информации,

чтобы передать сообщение переменной длины. В AAL-DATA.REQUEST примитивах, этот параметр отображен очевидно в поле INFORMATION SSCOP PDU. Для AAL-DATA.INDICATION примитивов, этот параметр несёт содержание информационного поля полученного SSCOP PDU.

b) SSCOP-UU (SSCOP user-to-user information – информация пользовательского режима):

STC не использует этот параметр. При создании примитивов "запроса" или "ответа", этот параметр имеет нулевую длину; при приеме этого параметра в примитивах "индикации" или "подтверждения" этот параметр игнорируется.

c) SN (sequence number – порядковый номер):

58

STC не использует этот параметр. При приеме этого параметра в примитиве DATA.INDICATION, этот параметр игнорируется.

d) BR (buffer release): STC не использует функциональные возможности этого параметра. В

примитивах AAL-ESTABLISH.REQUEST и AAL-ESTABLISH.RESPONSE этот параметр установлен в значение "Yes".

e) Source: Исходный параметр указывает для пользователя SSCOP, кем было

инициировано освобождение подключения – уровнем SSCOP (SSCOP layer) или одноранговым пользователем (peer SSCOP user). Этот параметр принимает одно из двух значений: "SSCOP" или "User". Если стоит значение "SSCOP", пользователь должен игнорировать параметр SSCOP-UU.

Любые другие параметры игнорируются.

D.7.3 Примитивы между STC и уровнем управления Индикация ошибок для уровня управления обеспечивается нижними уровнями и не требует никаких индикаторов от STC. Не требуется никаких примитивов между STC и уровнем управления. D.8 Протокольные элементы для коммуникаций STC STC использует механизмы, обеспеченные нижним подуровнем (SSCOP, ITU-T Q.2110 [13]). В частности: • Чтобы обеспечивать уверенную передачу данных, обслуживание и

доклады о доступности (готовности) этого транспорта пользователю, STC использует установление подключения и службу освобождения соединения SSCOP, то есть примитивы AAL-ESTABLISH и AAL-RELEASE. Никакой дополнительной информации параметр SSCOP-UU не передает.

• Передача данных использует услугу уверенной передачи данных SSCOP, включая встроенный механизм управления потоком.

• Использование услуги SSCOP по ресинхронизации одноранговым объектом STC воспринимается как ошибка и игнорируется, т.е. повторно вводится состояние Data Transfer Ready.

• Услуга SCCOP по восстановлению после ошибок игнорируется, т.е. повторно вводится состояние Data Transfer Ready.

• Услуга негарантированной передачи данных SSCOP не используется, то есть STC никогда не высылает примитивы AAL-UNIT-DATA.request и игнорирует полученные AAL-UNITDATA.indication примитивы.

• Услуга поиска данных SSCOP'S не используется, то есть STC никогда не высылает примитивы AAL-RETRIEVE-request и, следовательно, никогда принимает примитивы AAL-RETRIEVE.indication и AAL-RETRIEVE-COMPLETE.INDICATION.

D.8.1 STC PDU Нет никакой потребности в введении специальных PDU для; SDU, полученные от пользователя STC передаются через примитивы AAL-DATA без примениения какого-либо дополнительного протокола, управляющего информацией. Параметр примитивов PDU TRANSFER в верхней границе STC неизменным образом отражается в параметрах MU примитивов DATA в более низкой границе и наоборот. D.8.2 Различные состояния STC

59

STC не поддерживает никаких различных состояний. D.8.3 Таймеры STC Объек STC требует применения следующих таймеров: Timer_DELAY: Если процедура STC находится в состоянии "1.1" (простой), то выполняется Timer_DELAY. Это защищает от ненужного потребления ресурсов, в случаях если подключение SSCOP не может быть установлено или было освобождено. В течение времени, когда Timer_DELAY выполняется, услуги STC недоступны. Истечение этого таймера приводит к попытке восстановления подключения SSCOP. D.8.4 Параметры STC STC параметры определяются при создании нового объекта STC и остаются неизменяемым в течение срока службы STC объекта. Определены следующие параметры: a) Значение Max_Length Значение Max_Length может быть установлено в или "272", "4096", или

"65328". Значение, чтобы быть выбрано сетевыми операторами. b) CIC_Control Это значение используется в параметре CIC_Control примитива START-

INFO; это указывает для BICC, управляет ли BICC чётными или нечётными значениями CIC для ассоциации вызова. ПРИМЕЧАНИЕ - Один STC сигнальной ассоциации должен управлять нечетными значениями CIC; другой должен управлять четными значениями CIC. Конфликт может привести к двойной занятости.

c) Значение Timer_DELAY начение Timer_DELAY может быть в диапазоне от 800 до 1 500 ms. D.9 Технические требования STC D.9.1 Исходные данные Этот параграф определяет действия STC в процессе процедуры Power Up. Когда STC инициализирован, то им, используя примитив START-INFO.indication, сразу же указывается для BICC значение CIC_CONTROL и параметр Max_Length. После высылки примитива START-INFO.indication, выполняются действия, требуемые к выполнению после истечения Timer_DELAY в состоянии простоя (Idle – см. Таблицу D.2). D.9.2 Таблица Изменения состояния В этой рекомендации используются нижеприведенные состояния. Состояния концептуальны и отражают общие кондиции объекта STC в последовательностях примитивов и обменов PDU с пользователем, а так же нижерасположенным подуровнем. Состояние 1 Простой (Idle) В этом состоянии никакая служба не доступна. Никакие данные не

принимаются, если STC пользователь представляет данные для передачи в TRANSFER.request примитиве, этот примитив игнорируется.

Состояние 2 Задержка Исходящего соединения

60

В этом состоянии никакая служба не доступна. STC инструктирует SSCOP о необходимости устанавливать новое подключение с равным по положению объектом и ждет ответа. Никакие данные не принимаются, если STC пользователь представляет данные для передачи в TRANSFER.request примитиве, этот примитив игнорируется.

Состояние 3 Готовность к передаче данных В этом состоянии обслуживание доступно и имеет место передача

данных. D.9.3 Таблица Изменения состояния Таблица Изменения состояния (Таблица D.2) для STC описывает примитивы и те примитивы, которые приводят к изменениям состояния.

Таблица D.2/Q.1901 - таблица Изменения состояния

Состояние

Событие 1

Простой 2

Задержка исходящего соединения

3 Готовность к

передаче данных

AAL-ESTABLISH.indication reset Timer_DELAY AAL-ESTABLISH.

response IN-SERVICE.

indication (Level := 0) 2.10

−

−

AAL-ESTABLISH.confirm −

IN-SERVICE. indication (Level := 0)

2.10

−

AAL-RELEASE.indication −

set Timer_DELAY

1.1

OUT-OF-SERVICE. indication

set Timer_DELAY 1.1

AAL-DATA.indication − − TRANSFER.indication 2.10

AAL-RECOVER.indication −

−

AAL-RECOVER. response

2.10

TRANSFER.request − − AAL-DATA.request 2.10

Timer_DELAY expiry AAL-ESTABLISH. request

1.2

−

−

Приложение E (Annex E)

Взаимодействие с ISUP в ISN

E.1 Обобщение

61

Это приложение определяет процедуры, которые должны быть выполнены в ISN, взаимодействующем с SCN (Switch Commutation Network) с использованием сигнализации ISUP. Такой узел проиллюстрирован на Рисунке E.1.

T11107760-00

CSF-N

ISN

BICC

BCF-N

BIWF

Bearer control

Network using separatecall and bearer signalling

SCNnetwork

N-ISUPcall/bearer

control

ISUP

Рисунок E.1/Q.1901 - ISUP ISN Функциональная модель

E.2 Основа Протокол при интерфейсе ISUP должен соответствовать согласно Рекомендациям ISUP, приведённым в ITU-T Q.761. Протокол при интерфейсе BICC должен соответствовать этой Рекомендации. Передача сигнальной информации между двумя интерфейсами сигнализации должна выполнятся, как если бы ISN был промежуточным объектом (узлом) ISUP. Так как оба протокола используют сигнальную информацию, описанную в ITU-T Q.763, то поддерживается совместный мэппинг (не учитывая частные случаи, описанные в этой рекомендации). ISN может действовать как узел Type A или Type B в целях процедуры совместимости Q.764. Следующие параграфы детализируют исключения к вышеупомянутым инструкциям. E.3 Входящий ISUP, исходящий BICC (Входящий ISN) E.3.1 Успешная установка вызова E.3.1.1 Процедура контроля посылки IAM Параграф 10.2.1.1.2.3 заменен следующей процедурой: Параграф 10.2.1.1.2.3 заменен на следующее: Эта процедура решает вопросы между входящими и исходящими процедурами установки соединения, чтобы определить, когда необходимо высылать сообщения IAM и COT, основываясь на событиях, полученных входящей сигнализацией. В ITU-T Q.764 применяются входящие процедуры ISUP continuity. Однако никакие тесты проверки на целостность не поддерживаются в BICC. IAM высылается в момент, который определяется согласно процедурам исходящего набора, которые приведены в 10.2.1.1.2 или 10.2.1.2.2. Индикатор continuity check в параметре Nature of Connection Indicators устанавливается согласно процедурам Q.764. (Может быть выслан как “continuity check performed on

62

previous circuit", так и "continuity check not required"). IAM высылается с вызовом процедуры установки соединения в исходящем направлении BICC (10.2.1.1.2.1). Сигнал целостности (Continuity message) с параметром Continuity Indicators, установленным в значение "continuity check successful" будет послан по получении от ISUP, согласно процедурам промежуточной станции ITU-T Q.764. E.3.1.2 Сквозное соединение тракта несущего канала Параграф 10.2.1.1.2.6 заменен следующей процедурой: Когда процедура BICC установки соединения в исходящем направлении успешно закончена, то тракт несущего канала должен быть проключён в обоих направлениях. Кроме того, если BICC выполняет процедуру установки соединения в исходящем направлении "Per-call bearer set-up in the forward direction" (Установление соединения для вызова в прямом направлении) с параметром Connect Type в значении "notification not required", тракт должен быть проключён в обоих направлениях при отсылке Bearer Set-up request. E.3.2 Отбой вызова Параграф 10.2.3.1 b) заменен следующей процедурой: b) Действия во входящем ISN По получении сообщения освобождения от предшествующего узла,

промежуточный узел: I) Немедленно начинает освобождение скоммутированного тракта; если

канал заново выбирается (используется повторно), то release complete message возвращается предшествующему узлу.

II) В то же самое время, как начато освобождение скоммутированного тракта, ISN посылает сообщение освобождения последующему узлу. Запускаются таймеры T1 и T5, чтобы гарантировать release complete message будет получено от последующего узла (действия по истечению таймеров T1 и T5 охвачены в 10.2.9.6).

III) После получения release complete message таймеры T1 и T5 останавливаются и для BCF обозначается отбой вызова на исходящей стороне. К BCF пропускают параметр Cause (причины) первоначального сообщения Release Message.

E.4 Входящий BICC, исходящий ISUP (Исходящий ISN) E.4.1 Успешная установка вызова E.4.1.1 Процедура контроля посылки IAM Параграф 10.2.1.1.2.3 заменен на следующее: Эта процедура решает вопросы между входящими и исходящими процедурами установки соединения, чтобы определить, когда необходимо высылать сообщения IAM и COT, основываясь на событиях, полученных входящей сигнализацией. Когда входящая сигнализация - ISUP, применяются процедуры Q.764 со следующими разъяснениями и исключениями относительно того, когда IAM и Continuity messages должны быть посланы: Предусмотрены два случая:

63

1) Ранняя посылка IAM, используя протокол continuity check, чтобы отказать в ошибочном завершении установления вызова до проключения несущего канала.

2) Отказ в посылке IAM до установления несущего канала. Для случая «раннего IAM» (при поддержке continuity check протокола) ISUP IAM высылается в момент, определённый согласно процедурам установления соединения в исходящем направлении, описанным в 10.2.1.1.2 или 10.2.1.2.2. Индикатор continuity check в параметре Nature of Connection Indicators, установленный в значения "continuity check performed on previous circuit" или "continuity required on this circuit", может быть выслан, если должна быть выполнена проверка целостности. Continuity message, с параметром Continuity Indicators, установленным в "continuity check successful", высылается при выполнении следующих условий: 1) Если входящий IAM указывает "continuity check performed on previous circuit",

то это означает что должно быть получено сообщение Continuity message, с параметром Continuity Indicators, установленным в значение "continuity check successful".

2) В зависимости от применяемой процедуры, процедурой установления входящего соединения должно быть принято одно из следующих сообщений, указывающих на успешное установление несущего канала: 2.1) Индикация установления несущего канала (Bearer Set-up indication ) -

для процедуры проключения канала в прямом направлении, если был принят параметр Connect Type, со значением "notification not required".

2.2) Примитив BICC_Data indication параметром Action indicator, установленным в значение "Connected" - для процедуры установления соединения в прямом направлении, если был принят параметр Connect Type, со значением "notification required".

2.3) Bearer Set-up Connect indication - для процедуры установления несущего канала в обратном направлении.

3) Если на исходящем канале ISUP используется проверка целостности, то этот тест должен быть успешно завершён.

Для случая поздней посылки IAM (когда в последующей сети не поддерживается протокол проверки целостности), посылка ISUP IAM задерживается, до выполнения следующих условий: 1) Если входящий IAM указывает "continuity check performed on previous circuit",

то это означает что должно быть получено сообщение Continuity message, с параметром Continuity Indicators, установленным в значение "continuity check successful".

2) Процедурой установления соединения во входящем направлении должно быть получено одно из следующих сообщений, указывающее на успешное установление несущего канала: 2.1) Индикация установления несущего канала (Bearer Set-up indication ) -

для процедуры проключения канала в прямом направлении, если был принят параметр Connect Type, со значением "notification not required".

2.2) Примитив BICC_Data indication параметром Action indicator, установленным в значение "Connected" - для процедуры установления соединения в прямом направлении, если был принят параметр Connect Type, со значением "notification required".

2.3) Bearer Set-up Connect indication - для процедуры установления несущего канала в обратном направлении.

E.4.1.2 Сквозное проключение пути несущего канала Параграф 10.2.1.1.2.6 заменен следующей процедурой:

64

Трак несущего канала должен быть проключён в обоих направлениях, при выполнении следующих условий: • Успешно завершена процедура установления соединения во входящем

направлении; и • Если применяется процедура проверки на целостность ISUP, когда

условия на исходящей сети это позволяют, см. параграф 7/Q.724. E.4.2 Отбой вызова Параграф 10.2.3.1 b) заменен следующей процедурой: b) Действия в исходящем ISN: По получении сообщения освобождения (Release Message) от предыдущего

узла, промежуточный узел: I) BCF разъединяет внутреннее сквозное проключение несущего канала.

Полученный параметр Cause пропускают к BCF, и на входящей стороне обозначается отбой вызова. Когда BCF подтверждает успешное разъединение пути несущего канала, предыдущему узлу высылается сообщение Release Complete message.

II) В то же самое время, вместе с началом освобождения проключённого тракта, последующему узлу высылается release message. Запускаются таймеры T1 и T5, чтобы гарантировать, что от последующего узла будет получено release complete message (действия по истечению таймеров T1 и T5 описаны в 10.2.9.6).

Дополнение I (Appendix I)

Примеры потоков сообщений

I.1 Введение Этот параграф содержит ряд примеров потоков сообщений. • Возможны много других последовательностей. • Потоки показываются для сетевого сценария, когда для обслуживания

вызова используются два ISN с промежуточным TSN. (Присутствие TSN между ISN необязательно, зависит от сетевой конфигурации).

• При отсутствии TSN между ISN-A и ISN-B поток описыался бы так же, как и на участке ISN-A – TSN.

• Между каждыми SN показаны два SWN. Число таких узлов зависит от сетевой конфигурации.

• Последовательность сообщения в случае подключения GSN к GSN такая же, как и между ISN и TSN, крме того что не было бы никаких SWN.

• Сигнальные потоки между BCF обобщены, не касаются какого-то определённого протокола управления несущими каналами.

• Потоки, показанные между CSF и BCF - имеют отношение непосредственно к сигнальными событиями, другие взаимодействия между CSF и BCF не показываются.

• Сообщения BICC и ISUP показываются как сплошные линии, другие потоки показываются как пунктирные линии.

• Сквозное проключение тракта несущего канала не показывается на рисунках. Оно выполняется согласно описанию в 10.2.1.1.2.6.

I.2 Содержание

65

1) Установка вызова 1.1) Установление подключения в базовой сети в прямом направлении

без уведомления об установлении несущего канала. 1.2) Установление подключения в базовой сети в прямом направлении с

уведомлением об установлении несущего канала 1.3) Установление подключения в базовой сети в обратном направлении. 1.4) Использование неактивного подключения базовой сети,

установленного в прямом направлении. 1.5) Использование неактивного подключения базовой сети,

установленного в обратном направлении. 1.6) Пример Multi-network.

2) Переговоры Кодеков 2.1) Установление подключения в базовой сети в прямом направлении с

переговорами кодеков. 2.2) Установление подключения в базовой сети в обратном направлении

с переговорами Кодеков. 2.3) Модификация Кодеков.

3) Отбой 3.1) Отбой вызова и несущего канала в прямом направлении. Несущий

канал установлен в прямом направлении. 3.2) Отбой вызова и несущего канала в прямом направлении. Несущий

канал установлен в обратном направлении. 3.3) Отбой вызова в прямом направлении. Несущий канал не

освобождается. 3.4) Отбой вызова и несущего канала в прямом направлении. Межсетевое

взаимодействие, несущий канал был установлен и в прямом и в обратном направлениях.

66

T11107770-00

ISUPISN-A

BICCTSN

BICCISN-B

ISUPCSF-N CSF-T CSF-N

BCF-N(x)

BCF-R BCF-R BCF-N(y) BCF-R BCF-R

BCF-N(z)

SWN-1 SWN-2 SWN-1 SWN-2

IAMIAM (Action = Connect Forward), (BNC characteristics)

IAM (COT on previous), (Action = Connect Forward),(BNC characteristics)APM (Action = Connect Forward, no notification)

(BNC-ID = y1), (BIWF Addr = y)APM (Action = Connect Forward, no notification)

(BNC-ID = z1), (BIWF Addr = z)Bearer-Set-up req. (BNC-ID = y1), (BIWF-Addr = y)

Bearer-Set-up req. (BNC-ID = z1), (BIWF-Addr = z)Bearer-Set-up req

Bearer-Set-up req

Bearer-Set-up reqCOT

Bearer-Set-up reqBearer-Set-up-Connect

Bearer-Set-up-ConnectBearer-Set-up-Connect

ACMACM

ANMANM

"AAA"

"BBB"

Bearer-Set-up-Connect

Bearer-Set-up-Connect

ACM

ANM

ACM

ANM

Bearer-Set-up-Connect

Рисунок I.1/Q.1901 - Установление подключения в базовой сети в прямом

направлении без уведомления об установлении несущего канала ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается

В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

67

T11107780-00

ISUPISN-A

BICCTSN

BICCISN-B

CSF-N

BCF-N(x)

SWN-1 SWN-1 SWN-2BCF-N

(z)BCF-R BCF-R BCF-R BCF-RBCF-N

(y)

SWN-2

CSF-NCSF-TISUP

IAMIAM (Action = Connect Forward), (BNC characteristics)

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

(BNC-ID = y1), (BIWF Addr = y) APM (Action = Connect Forward, plus notification)(BNC-ID = z1), (BIWF Addr = z)

"AAA"

Bearer-Set-up req. (BNC-ID = y1), (BIWF-Addr = y) Bearer-Set-up req. (BNC-ID = z1), (BIWF-Addr = z)Bearer-Set-up req

Bearer-Set-up reqBearer-Set-up req

Bearer-Set-up req

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-ConnectBearer-Set-up-Connect

Bearer-Set-up-Connect

APM (Action = Connected)

APM (Action = Connected)

ACMACM

ANM

ANM

ACM

ANMANM

ACM

"BBB"COT

Рисунок I.2/Q.1901 - Установление подключения в базовой сети в прямом направлении с уведомлением об установлении несущего

канала

ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

68

T11107790-00

ISN-A TSN ISN-BISUP

CSF-N CSF-T CSF-N

SWN-1 SWN-1SWN-2 SWN-2BCF-N

(x)BCF-R BCF-R BCF-R BCF-R BCF-N

(z)

IAM

IAM (Action = Connect backward),(BNC-ID = x1), (BIWF-Addr = x), (BNC characteristics)

IAM (Action = Connect backward), (COT on previous), (BNC-ID = y1), (BIWF-Addr = y),

(BNC characteristics)

Bearer-Set-up req. (BNC-ID = x1), (BIWF-Addr = x)Bearer-Set-up req.

Bearer-Set-up req.Bearer-Set-up req.

Bearer-Set-up req.

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-ConnectCOT

ACMACM

ANM

ANM

ACM

ANM

ACM

ANM

"BBB"

"AAA"

ISUP

BCF-N(y)

Bearer-Set-up req. (BNC-ID of BIWF y), (BIWF-Addr = y)

BICC BICC

Рисунок I.3/Q.1901 - Установление подключения в базовой сети в обратном

направлении. ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

69

T11107800-00

ISN-AISUP ISUP

TSN ISN-B

CSF-N CSF-T CSF-N

BCF-N(x)

SWN-1 SWN-1SWN-2 SWN-2

BCF-R BCF-R BCF-R BCF-RBCF-N

(z)

IAM

IAM (Action = Connect Forward), (BNC characteristics)IAM (COT on previous), (Action = Connect Forward),

(BNC characteristics)APM (Action = Connect Forward, no notification),(BNC-I = y1), (BIWF Addr = y) APM (Action = Connect Forward, no notification),

(BNC-ID = z1), (BIWF Addr = z)"AAA"

APM (Action = Use Idle), (BNC-ID = y2)APM (Action = Use Idle), (BNC-ID = z2)

APM (Action = Switched) COT

ACM

APM (Action = Switched)

ANM

ACM

ANM

ACM

ANM

ANM

ACM

"BBB"

BICC BICC

BCF-N(y)

Рисунок I.4/Q.1901 - Использование неактивного подключения базовой сети, установленного в прямом направлении.

ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

70

T11107810-00

ISUP ISUPISN-A TSN ISN-B

BICC BICCCSF-N CSF-T CSF-N

BCF-N(x) BCF-R BCF-R BCF-R BCF-R

BCF-N(z)

BCF-N(y)

IAM

SWN-1 SWN-2 SWN-1 SWN-2

IAM (Action = Connect Backward),(BNC-ID = x1), (BIWF Addr = x), (BNC characteristics)

IAM (COT on previous), (Action = Connect Backward),(BNC-ID = y1), (BIWF Addr = y), (BNC characteristics)

APM (Action = Use idle), (BNC-ID = x2)

APM (Action = Use idle), (BNC-ID = x2)

"AAA"

APM (Action = Switched)

APM (Action = Switched)

COT

"BBB"

ACM

ACM

ANM

ANM

ACM

ANMANM

ACM

Рисунок I.5/Q.1901 - Использование неактивного подключения базовой сети, установленного в обратном направлении.

ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

71

T11107820-00

ISUP ISUPBICC BICC

Network 1 Network 2

ISN-A GSN GSN ISN-B

CSF-N CSF-G CSF-G CSF-N

BCF-N(w)

BCF-N(x)

BCF-N(y)BCF-R BCF-R BCF-N

(z)

IAM IAM (Action = Connect Forward), (BNC characteristics)

APM (Action = Connect Forward, plus notification)(BNC-ID = x1), (BIWF Addr = x)

IAM (COT on previous),(Action = Connect Forward),

(BNC characteristics)

Bearer-Set-up req. (BNC-ID = x1), (BIWF-Addr = x) APM (Action = Connect Forward, no notification) (BNC-ID = y1),

(BIWF Addr = y)

IAM (Action = Connect Backward),(COT on previous), (BNC-ID = y2), (BIWF-Addr = y),

(BNC characteristics)Bearer-Set-up req

Bearer-Set-up-Connect

Bearer-Set-up-Connect

APM (Action = Connected)

ACMACM

ANMANM

Bearer-Set-up req.(BNC-ID = y1),

(BIWF-Addr = y)

COT

Bearer-Set-up-Connect

ACM

ANMANM

ACMACM

ANM

APM (Action = Use Idle), (BNC-ID = y3)

APM (Action = Switched)

"AAA"

"BBB"

SWN-1 SWN-2

COT

BICC

Рисунок I.6/Q.1901 - Пример Multi-network. Прямое соединение с

уведомлением, затем прямое соединение без уведомления, затем обратное соединение, использование неактивного несущего канала.

ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

72

T11107830-00

ISUPISN-A

BICCTSN

BICCISN-B

CSF-N

BCF-N(x)

SWN-1 SWN-1 SWN-2BCF-N

(z)BCF-R BCF-R BCF-R BCF-RBCF-N

(y)

SWN-2

CSF-NCSF-TISUP

IAM IAM (Action = Connect Forward),(BNC characteristics), (Codec list)

IAM (COT on previous), (Action = Connect Forward),(BNC characteristics), (Codec list)APM (Action = Connect Forward, plus notification

+ Selected codec), (BNC-ID = y1), (BIWF Addr = y) APM (Action = Connect Forward, plus notification)+ Selected codec), (BNC-ID = z1), (BIWF Addr = z)

"AAA"

Bearer-Set-up req. (BNC-ID = y1), (BIWF-Addr = y)Bearer-Set-up req. (BNC-ID = z1), (BIWF-Addr = z)

Bearer-Set-up reqBearer-Set-up req

Bearer-Set-up reqBearer-Set-up req

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

APM (Action = Connected)

APM (Action = Connected)

ACMACM

ANM

ANM

ACM

ANMANM

ACM

"BBB"COT

(Selected codec), (Available codec list)(Selected codec), (Available codec list)

Рисунок I.7/Q.1901 - Установление подключения в базовой сети в прямом

направлении (с уведомлением) с переговорами кодеков.

ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

73

T11107840-00

ISUP ISUPBICC BICCISN-A TSN ISN-B

CSF-N CSF-N

SWN-1 SWN-2 SWN-2SWN-1BCF-N

(x)BCF-N

(z)BCF-R BCF-R BCF-R BCF-R

IAM (Action = Connect backward), (Codec list)(BNC-ID = x1), (BIWF-Addr = x), (BNC characteristics)

IAMIAM (Action = Connect backward), (Codec list)

(COT on previous), (BNC-ID = y1), (BIWF-Addr = y),(BNC characteristics)

"AAA"

APM (Action = Selected codec),(Selected codec), (Available codec list)

APM (Action = Selected codec),(Selected codec), (Available codec list)

Bearer-Set-up req. (BNC-ID = x1), (BIWF-Addr = x)

Bearer-Set-up req

Bearer-Set-up reqBearer-Set-up req

Bearer-Set-up req. (BNC-ID = y1), (BIWF-Addr = y)

Bearer-Set-up req

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

Bearer-Set-up-Connect

COT

"BBB"

ACM

ACM

ACM

ANM

ANM

ANMANM

ACM

CSF-T

BCF-N(y)

Bearer-Set-up-Connect

Рисунок I.8/Q.1901 - Установление подключения в базовой сети в обратном направлении с переговорами Кодеков.

ПРИМЕЧАНИЕ – наличие сообщений AAA и BBB зависит от того, поддержана ли процедура Continuity в следующем SCN:

Случай Message AAA Message BBB

Continuity поддерживается В IAM указывается "continuity check performed on previous circuit"

В COT указывается "continuity check successful"

Continuity не поддерживается

Сообщение не высылается В IAM указывается "continuity check not required"

74

T11107850-00

ISUP ISUPISN-A ISN-B

BICCBICCCSF-N CSF-N

TSN

CSF-T

BCF-N(z)

BCF-N(x) BCF-R BCF-R BCF-R

BCF-N(y)

APM (Action = Modify codec), (Selected codec and/or Codec list)APM (Action = Modify codec), (Selected codec and/or Codec list)

APM (Action = Successful codec modification)

APM (Action = Successful codec modification)

SWN-1 SWN-1SWN-2 SWN-2

BCF-R

Рисунок I.9/Q.1901 - Переговоры Кодеков

T11107860-00

ISUP ISUPISN-A ISN-B

BICCBICCCSF-N CSF-N

TSN

CSF-T

BCF-R BCF-R BCF-R BCF-R BCF-NBCF-NBCF-N

REL

RELREL

RLC

RLC

RLC

RLC

REL

Bearer release req.

Bearer release req.Bearer release req.

Bearer release req.

Bearer release req.

Bearer release req.

Bearer release Ack.

Bearer release Ack.Bearer release Ack.

Bearer release Ack.

Bearer release Ack.Bearer release Ack.

SWN-1 SWN-1SWN-2 SWN-2

Рисунок I.10/Q.1901 - Отбой вызова и несущего канала в прямом направлении. Несущий канал установлен в прямом направлении.

T11107870-00

ISUP ISUPISN-A ISN-BTSN

BICC BICCCSF-N CSF-NCSF-T

BCF-N BCF-N BCF-NBCF-R BCF-R BCF-R BCF-R

SWN-1 SWN-1SWN-2 SWN-2

RELREL

RELRLC

RLC

RLCRLC

REL

Bearer release req.Bearer release req. Bearer release req.

Bearer release req.Bearer release req.

Bearer release req..

Bearer release Ack.Bearer release Ack.

Bearer release Ack.Bearer release Ack.

Bearer release Ack.

Bearer release Ack.

Рисунок I.11/Q.1901 - Отбой вызова и несущего канала в прямом направлении. Несущий канал установлен в обратном направлении.

75

T11107880-00

ISUP ISUPISN-A ISN-B

BICC BICCCSF-N CSF-NCSF-T

TSN

BCF-N BCF-NBCF-NBCF-R BCF-R BCF-R BCF-R

SWN-1 SWN-1SWN-2 SWN-2

RELREL

REL

REL

RLCRLC

RLC RLC

Рисунок I.12/Q.1901 - Отбой вызова в прямом направлении. Несущий канал не освобождается.

T11107890-00

ISUPISN-A GSN GSN

BICC BICC BICCCSF-N CSF-G CSF-G

BCF-N BCF-N BCF-NBCF-R BCF-R

RELREL

RELRELRLC

RLCRLC

RLC

Bearer release req.

Bearer release req.Bearer release req.

Bearer release req.

Bearer release Ack.Bearer release Ack. Bearer release Ack.

SWN-1 SWN-2

Bearer release Ack.

Рисунок I.13/Q.1901 - Отбой вызова и несущего канала в прямом

направлении. Межсетевое взаимодействие, несущий канал был установлен и в прямом и в обратном направлениях.

Дополнение II (Appendix II)

Универсальные функции BCF

II.1 Введение Согласно функциональной модели, рассмотренной в параграфе 6/Q.1901, BCF содержит ряд дискретных типов функциональных возможностей. Функции коммутации и сигнализации несущего канала не рассматриваются в этой рекомендации, но это дополнение описывает некоторые процедуры, выполняемые BCF, которые являются независимыми от коммутирующих функций и используемой технологии несущего канала. II.2 BNC-ID Идентификатор Подключения Сети Несущего канала (Bearer Network Connection identifier - BNC-ID), является уникальным в пределах одного BCF, идентифицирующего Подключение Сети несущего канала. SN обмениваются этими идентификаторами в целях, описанных ниже.

76

II.2.1 Использование BNC-ID в течение обслуживания вызова и установки несущего канала

Для случаев установления нового несущего канала для нового вызова, используя соответствующий протоколу тип несущего канала, BNC-ID может быть: • Распределенным BCF в одном SN, когда используется ассоциация BCF-

CSF; • Посланным смежному SN через BICC протокол; • Возвращен BCF от исходного SN через протокол установки несущего

канала; • Использоваться для идентификации соответствующего вызова для

недавно созданного подключения несущего канала. Ожидается что взаимодействие с несущими каналами без установления соединения, например IP-оприентированный транспорт, будет определено в будущем. Для этих случаев, третий пункт в вышеупомянутом списке должен пониматься в смысле соответствующих механизмов контроля координации несущего канала, используемым платформой связи без установления соединения. II.2.2 Использование BNC-ID процедурой многократного использования

неактивных несущих каналов (сетевая опция) Для сетевой опции, предусматривающей многократное использование неактивных несущих каналов, каждый BCF может управлять пулами неактивных несущих каналов к смежному SN. В пределах каждого пула имеются два набора несущих каналов: устанавливаемые, и таким образом "находящийся под ответственностью" этого BCF, и установленные удалённым BCF (и таким образом "не находящиеся под ответственностью" этого BCF). В любой момент времени любой из этих пулов может быть не существовать или быть пустым. Управление несущими каналами в пределах пулов, то есть какие несущие каналы находятся в каком пуле не описывается этой рекомендацией. Несущие каналы в пределах пулов помечаются BNC-ID. Для несущих каналов, принадлежащих этому BCF BNC-ID были распределены удалённым BCF, а для тех несущих каналов, которые принадлежат удалённому BCF, BNC-ID распределяются «ближним» BCF. В течение процедуры установки вызова при многократном использовании несущего канала, BNC-ID передаётся в соответствии с протоколом BICC, чтобы указать для удаленного BCF, какой конкретно несущий канал должен многократно использоваться. BCF может выбирать только тот несущий канал для многократного использования, который он сам установил, то есть тот, который «находится в зоне его ответственности». II.3 Управление освобождением несущего канала При нормальной обработке вызова, несущий канал может быть освобожден только тем BCF, который первоначально его установил, то есть BCF, который "владеет" несущим каналом. Таким образом, когда от процедур BICC CSF получен запрос на освобождение несущего канала, BCF должен инициализировать протокол освобождения несущего канала только если он «владеет» этим несущим каналом. BCF может также решить не освобождать «свой» несущий канал, если функцией управления BCF определено, что канал используется процедурой неоднократного использования неактивного несущего канала. (Сетевая опция.)

77

В аварийных состояниях процедуры BICC CSF могут запрашивать сброс подключения несущего канала, в этом случае BCF должен безоговорочно инициализировать протокол освобождения несущего канала. II.4 BIWF Адрес Адрес BIWF это информация, которой обмениваются SN для идентификации адреса BCF в пределах BIWF равных по положению SN. II.5 Характеристики BNC Характеристики BNC это информация, которой обмениваются SN для идентификации выбранного типа BNC, то есть AAL1 или AAL2.

Дополнение III (Appendix III)

Процедуры в Call Mediation Node (сетевая опция)

III.1 Введение Это приложение описывает функции протокола, которые должны быть выполнены узлами-посредниками вызову (CMN), если сетевой оператор использует такие узлы. Описанные процедуры необходимы для правильной работы ассоциированных с такими узлами SN в части управления несущими каналами. Другие процедуры CMN не определены в этой Рекомендации, но могут быть определены в будущем. ПРИМЕЧАНИЕ - В пределах сетевого домена (области), присутствие промежуточного узла-посредника вызову (CMN) - сетевая опция, включение которой зависит от оператора и нужд работы сети. CMN не поддерживает никакие функциональные возможности, непосредственно связанные с подключениями несущего канала. Протокол BICC не препятствует существованию такого узла.

T11107900-00

CMN

CSF CSFCSF-C(a) (a)

BIWF BIWF

BCF BCFBCF-R

SN SNSWN(s)

(b) (b)

Рисунок III.1/Q.1901 - Функциональная модель CMN III.2 Процедуры III.2.1 Адресование BAT ASE Согласно роли CMN, в этот узел может быть встроен BAT ASE. Если CMN поддерживает BAT ASE, то будет рассматриваться как адресованный узел, поскольку BAT ASE использует неявный механизм адресации APM (10.1.2.2). Прикладные процедуры в CMN узле могут передавать информацию в неизменном виде. III.2.2 Отбой вызова

78

CMN, когда сигнальная ассоциация BICC устанавливается через него, должен передать оба сообщения REL и RLC (SN, высылающий REL ожидает RLC для начала освобождения канала. CMN не может сам создавать RLC, может только транслировать его). Значения CIC должны быть освобождены в CMN при трансляции RLC. III.2.3 Сброс CMN, когда сигнальная ассоциация BICC устанавливается через него, приняв RSC, должен послать RSC следующему SN. Он не должен преобразовывать полученный RSC в REL, высылая его следующему SN. К обоим SN должна применяться нормальная процедура сброса. CMN, когда сигнальная ассоциация BICC устанавливается через него, по получении GRS, должен послать сообщение(я) RSC или GRS к следующему SN. Он не должен преобразовывать полученный GRS в RELS, высылая его следующему SN. К обоим SN должна применяться нормальная процедура сброса.