Утверждаю
Первый заместитель Министра
Российской Федерации
по связи и информатизации
Б.Д.АНТОНЮК
8 апреля 2003 года
Согласовано
Руководитель ДЭС
Минсвязи России
В.Ю.КВИЦИНСКИЙ
31 декабря 2002 года
РУКОВОДЯЩИЙ ДОКУМЕНТ ОТРАСЛИ
ОБОРУДОВАНИЕ СВЯЗИ, РЕАЛИЗУЮЩЕЕ ФУНКЦИИ ГИБКОГО
КОММУТАТОРА (SOFTSWITCH)
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
РД 45.333-2002
Предисловие
1. Разработан Федеральным государственным учреждением "Центр
научных исследований и экспертизы в области связи".
Внесен Департаментом электросвязи Министерства Российской
Федерации по связи и информатизации.
2. Утвержден Первым заместителем Министра Российской Федерации
по связи и информатизации Б.Д. Антонюком.
3. Введен в действие.
4. Введен впервые.
1. Область применения
Настоящий документ предназначен для руководства при проведении
сертификационных испытаний оборудования, реализующего функции
гибкого коммутатора (далее - Оборудование), предназначенного для
применения на Взаимоувязанной сети связи (ВCC) России.
Настоящий руководящий документ устанавливает характеристики
Оборудования, определяющие требования к сетевым интерфейсам и
протоколам, необходимые для обеспечения совместимости оборудования
различных производителей, а также общие требования, принятые на
ВCC России для аппаратуры связи. При этом регламентируются только
функции Оборудования, а способы их технической реализации не
ограничиваются.
Не все функции, содержащиеся в данных технических требованиях
(ТТ), обязательны для Оборудования данного типа, но если они
выполняются, то их реализация должна соответствовать данным ТТ.
2. Нормативные ссылки
В настоящем руководящем документе использованы ссылки на
следующие нормативные документы:
ГОСТ 12.1.004-91. CCБТ. Пожарная безопасность. Общие
требования.
ГОСТ Р 51318.22-99. Совместимость технических средств
электромагнитная. Радиопомехи индустриальные от оборудования
информационной техники. Нормы и методы испытаний.
ГОСТ 30428-96. Совместимость технических средств
электромагнитная. Радиопомехи индустриальные от аппаратуры
проводной связи. Нормы и методы испытаний.
ОСТ 45.02-97. Отраслевая система сертификации. Знак
соответствия. Порядок маркирования технических средств
электросвязи.
Нормы 8-95. Общесоюзные нормы допускаемых индустриальных
радиопомех. Электроустройства, эксплуатируемые вне жилых домов и
не связанные с их электрической сетью. Предприятия (объекты) на
выделенных территориях или в отдельных зданиях. Допускаемые
величины. Методы испытаний.
Нормы 9-93. Радиопомехи индустриальные. Аппаратура проводной
связи. Нормы и методы испытаний.
3. Обозначения и сокращения
АКД - аппаратура окончания канала данных
АЛ - абонентская линия
ИСС - интеллектуальная сеть связи
ОКС N 7 - общеканальная система сигнализации N 7
ПД - передача данных
ПЦИ - плезиохронная цифровая иерархия
СТф - стык телефонный
СЦИ - синхронная цифровая иерархия
ТфОП - телефонная сеть общего пользования
УПАТС - учрежденческая производственная автоматическая
телефонная станция
ЦСИС - цифровая сеть с интеграцией служб
AS - Application Server (сервер приложений)
BRI - Basic Rate Interface (интерфейс на базовой скорости)
CDDI - Copper Distributed Data Interface (проводной
распределенный интерфейс передачи данных)
DSS1 - Digital Subscriber Signalling System No. One (цифровая
абонентская система сигнализации N 1)
IP - Internet Protocol (протокол Интернет)
ISDN - Integrated Service Digital Network (цифровая сеть с
интеграцией служб)
ISUP - Integrated User Services Part (подсистема сигнализации
сети с интеграцией служб)
ETS - ETSI Technical Standard (стандарт ETSI)
FDDI - Fiber Distributed Data Interface (распределенный
волоконно-оптический интерфейс передачи данных)
GK - Gatekeeper (гейткипер - аппаратура управления и контроля)
MG - Media Gateway (шлюз)
MGC - Media Gateway Controller (устройство управления шлюзами)
MGCP - Media Gateway Control Protocol (протокол управления
шлюзами)
MTP - Message Transfer Part (подсистема передачи сообщений)
PRI - Primary Rate Interface (интерфейс на первичной скорости)
RAS - Registration, Admission, Status (регистрация, допуск,
состояние)
RTP - Real-time protocol (протокол передачи в режиме реального
времени)
RTCP - Real-time Control Protocol (протокол управления
передачей в режиме реального времени)
SG - Signalling Controller (шлюз сигнализации)
SIP - Session Initial Protocol (протокол инициирования сеанса
связи)
SP - SIP Proxy (конвертер протокола SIP)
SSP - Service Switched Point (узел коммутации услуг)
TCAP - Transaction Capability Application Part (подсистема
применения возможностей транзакции)
ФГР - Transmission Control Protocol (протокол управления
передачей)
UDP - User Datagram Protocol (дейтаграммный протокол
пользователя)
SCP - Service Control Point (узел управления услугами)
SCTP - Stream Control Transmission Protocol (протокол
управления потоком при передаче)
SIGTRAN - SIGnaling TRANsport (передача информации
сигнализации)
SSF - Service Switching Function (функция коммутации услуг)
STM - Synchronous Transfer Mode (синхронный режим переноса)
xDSL - Digital Subscriber Line (цифровая абонентская линия)
4. Классификация Оборудования, реализующего
функции гибкого коммутатора
4.1. Оборудование, реализующее функции гибкого коммутатора,
представляет собой масштабируемый программно-аппаратный комплекс,
построенный в соответствии с архитектурной концепцией SoftSwitch
[1]. В общем случае комплекс оборудования гибкого коммутатора
включает в себя следующие устройства (рис. 4.1) <*>:
------------------------------------
<*> Не приводится.
- шлюз (MG - Media Gateway), реализующий функции преобразования
речевой информации в пакеты IP; взаимодействия с ТфОП;
маршрутизации пакетов IP;
- устройство управления вызовами (MGC - Media Gateway
Controller), реализующее функции управления устройствами,
входящими в состав гибкого коммутатора;
- конвертер протокола SIP (SIP Proxy), реализующий функции
взаимодействия устройств, входящих в состав гибкого коммутатора, с
устройствами, работающими по протоколу SIP;
- шлюз сигнализации (SG - Signaling Gateway), реализующий
функции взаимодействия устройств, входящих в состав гибкого
коммутатора, с сетью ОКС N 7;
- сервер приложений (AS - Application Server), реализующий
функции создания управления и предоставления дополнительных видов
обслуживания.
4.2. В зависимости от исполнения Оборудования устройства,
входящие в его состав, могут совмещать несколько функций из
перечня, определенного в пункте 4.1. Взаимодействие отдельных
устройств Оборудования осуществляется через сеть с коммутацией
пакетов.
4.3. Устройства, входящие в состав Оборудования, могут быть
реализованы как специализированное оборудование или на базе
специализированного компьютера (например, сервер в промышленном
исполнении), оснащенного соответствующими аппаратными или
программными средствами.
4.4. Оборудование имеет два вида интерфейсов:
- внутренние интерфейсы, предназначенные для взаимодействия
устройств, входящих в его состав (интерфейсы 1 - 8);
- внешние интерфейсы для взаимодействия с оконечным
оборудованием пользователя или телекоммуникационными сетями
(интерфейсы 9 - 13).
4.5. К Оборудованию могут подключаться следующие типы
терминалов:
- аналоговый телефонный аппарат;
- персональный компьютер, оснащенный соответствующими
средствами;
- специализированный абонентский терминал (IP-телефон).
4.6. К телефонной сети Оборудование может подключаться по
следующим интерфейсам и протоколам:
- по абонентским аналоговым интерфейсам;
- по абонентским цифровым интерфейсам ISDN PRI и ISDN BRI;
- по межсетевому интерфейсу ОКС N 7 с применением межсетевого
экрана (firewall), входящего в состав ТфОП.
4.7. Перечень возможных интерфейсов (внешних и внутренних) и
протоколов, реализованных в Оборудовании, перечислен в таблице 4.1
(нумерация интерфейсных точек соответствует рисунку 4.1).
Таблица 4.1
ИНТЕРФЕЙСЫ И ПРОТОКОЛЫ ОБОРУДОВАНИЯ
--------T-----------------------------T--------------------------¬
¦Интер- ¦ Интерфейс ¦ Протокол ¦
¦фейсная¦ ¦ ¦
¦точка ¦ ¦ ¦
+-------+-----------------------------+--------------------------+
¦1, 2 ¦- Ethernet (10 BaseT, ¦- IP, UDP, TCP; ¦
¦ ¦10 BaseF); ¦- TCAP, SIP, XML ¦
+-------+ +--------------------------+
¦3 ¦- Fast Ethernet (100 BaseTX, ¦- IP, TCP; ¦
¦ ¦100 BaseFX, 100 BaseFL); ¦- SIP, RAS, H.225, H.245 ¦
+-------+ +--------------------------+
¦8 ¦- Gigabit Ethernet ¦- IP, UDP; ¦
¦ ¦(1000 BaseTX, 1000 BaseCX, ¦- MGCP ¦
+-------+1000 BaseLX, 1000 BaseLH, +--------------------------+
¦10 ¦1000 BaseSX); ¦- IP, UDP, TCP; ¦
¦ ¦ ¦- RAS, H.225, H.245, MGCP,¦
¦ ¦- Token Ring; ¦MEGACO ¦
+-------+ +--------------------------+
¦4, 5 ¦- FDDI, CDDI; ¦- IP, TCP; ¦
¦ ¦ ¦- SIP ¦
+-------+- сети передачи данных (V.10,+--------------------------+
¦6, 14 ¦V.11, V.24, V.28, V.35, X.21,¦- IP, UDP, TCP; ¦
¦ ¦X.21bis, Е1 ПЦИ); ¦- RAS, H.225, H.245, MGCP,¦
¦ ¦ ¦MEGACO, SIGTRAN (IUA, ¦
¦ ¦- xDSL ¦V5UA, M3UA) ¦
+-------+ +--------------------------+
¦7 ¦ ¦- IP, UDP, TCP; ¦
¦ ¦ ¦- RAS, H.225, H.245, ¦
¦ ¦ ¦SIGTRAN (V5UA, M3UA) ¦
+-------+ +--------------------------+
¦9 ¦ ¦- IP, TCP; ¦
¦ ¦ ¦- RAS, H.225, H.245, SIP ¦
+-------+ +--------------------------+
¦15 ¦ ¦- IP, TCP; ¦
¦ ¦ ¦- RAS, H.245 ¦
+-------+ +--------------------------+
¦16 ¦ ¦- RTP ¦
+-------+-----------------------------+--------------------------+
¦11 ¦- 2-проводная аналоговая ¦- частотный набор (DTMF); ¦
¦ ¦телефонная линия; ¦- DSS1 ¦
¦ ¦- ISDN BRI; ¦ ¦
+-------+-----------------------------+--------------------------+
¦12 ¦- 2-проводная аналоговая ¦- частотный набор (DTMF); ¦
¦ ¦телефонная линия; ¦- DSS1 ¦
+-------+- ISDN BRI; +--------------------------+
¦13 ¦- ISDN PRI; ¦- ОКС N 7 ¦
¦ ¦- Е1 ПЦИ, Е3 ПЦИ, STM-1, ¦ ¦
¦ ¦STM-4 СЦИ ¦ ¦
L-------+-----------------------------+---------------------------
4.9. Устройства, входящие в состав Оборудования, могут
устанавливаться на объектах связи ВСС России.
5. Применение Оборудования, реализующего
функции гибкого коммутатора
5.1. В зависимости от конкретного набора применяемых устройств
и видов обслуживаемой информации (речевая информация, данные,
видеоинформация) существует открытое множество способов применения
Оборудования. В настоящее время наиболее типичными и
распространенными способами применения Оборудования являются:
- распределенный телефонный концентратор;
- транзитная станция коммутации и распределенный SSP;
- распределенная УПАТС;
- распределенный узел телематических служб.
5.2. Схема организации распределенного телефонного
концентратора на базе Оборудования, реализующего функции гибкого
коммутатора, показана на рисунке 5.1 <*>. Распределенный
телефонный концентратор может применяться на участках абонентского
доступа, построенных с использованием технологий кабельного
телевидения, xDSL и прочих, предполагающих передачу речевой
информации по протоколу IP.
------------------------------------
<*> Рисунки 5.1 - 5.5 не приводятся.
5.2.1. Устройства, применяемые для организации распределенного
телефонного концентратора, должны обеспечивать качество
обслуживания, соответствующее качественным показателям на ТфОП.
5.2.2. Распределенный телефонный концентратор состоит из шлюзов
MG, взаимодействующих через сеть ПД. Устройство MGC обеспечивает
управление вышеуказанными устройствами, которые располагаются в
месте окончания участка абонентского доступа. Взаимодействие с
ТфОП осуществляется на правах абонентской установки по интерфейсам
до ISDN PRI включительно. Подключение распределенного телефонного
концентратора к ТфОП осуществляется в одной точке. Для реализации
дополнительных видов обслуживания и расширения возможностей
распределенного телефонного концентратора могут использоваться
сервера приложений AS и конвертеры SIP.
5.3. Схема организации транзитной станции коммутации на базе
Оборудования, реализующего функции гибкого коммутатора, показана
на рисунке 5.2.
5.3.1. Транзитный коммутатор обеспечивает взаимодействие
различных телефонных сетей через мультипротокольную транспортную
сеть. В состав транзитной станции коммутации входят шлюзы MG,
обеспечивающие преобразование речевой информации в цифровую форму,
шлюзы сигнализации SG, обеспечивающие взаимодействие телефонных
сетей по протоколу сигнализации ОКС N 7, и устройство MGC,
обеспечивающее управление перечисленными устройствами. Шлюз
сигнализации SG должен подключаться к ТфОП с использованием
межсетевого экрана (firewall), входящего в состав ТфОП.
5.3.2. На базе транзитной станции коммутации возможно создание
SSP (рисунок 5.3).
Требования к реализации функций SSF в устройстве MGC должны
соответствовать [2].
Взаимодействие с SCP должно осуществляться по протоколу INAP
системы сигнализации ОКС N 7. Подключение устройства MGC к сети
ОКС N 7 должно осуществляться с использованием шлюза сигнализации
SG.
Платформы ИСС подключаются к устройству управления шлюзами MGC
по интерфейсу ОКС N 7 с использованием шлюза сигнализации SG.
Передача сообщений ОКС N 7 должна осуществляться с использованием
межсетевого экрана, входящего в состав ТфОП. Дополнительно функции
управления услугами ИСС могут быть реализованы на серверах
приложений AS.
5.4. Схема организации распределенной УПАТС на базе
Оборудования, реализующего функции гибкого коммутатора, показана
на рисунке 5.4.
5.4.1. В состав распределенной УПАТС входят устройство SIP-
Proxy, шлюзы MG и серверы приложений AS, взаимодействующие через
корпоративную сеть ПД. Устройство MGC обеспечивает управление
указанными выше устройствами. Взаимодействие с ТфОП осуществляется
на правах абонентской установки по интерфейсам до ISDN PRI
включительно. Подключение к ТфОП должно осуществляться в одной
точке.
Оконечное оборудование (персональные компьютеры и IP-телефоны)
образуют локальные сети, которые управляются устройством MGC по
протоколу SIP или H.225. Аналоговые телефонные аппараты
подключаются к распределенной УПАТС с использованием шлюзов MG,
при этом шлюз MG может устанавливаться как непосредственно в
помещении пользователей, так и в помещении оператора,
организующего распределенную УПАТС.
Предоставление служащим организации дополнительных видов
обслуживания (ДВО) осуществляется с использованием сервера
приложений AS.
5.5. Схема организации распределенного узла телематических
служб на базе Оборудования, реализующего функции гибкого
коммутатора, показана на рисунке 5.5.
5.5.1. Распределенный узел телематических служб, организованный
с использованием гибкого коммутатора, базируется на одном или
более сервере приложений AS и шлюзах MG. Управление указанными
устройствами осуществляется с использованием устройства MGC.
Функции авторизации и аутентификации выполняет дополнительный
сервер ААА. Возможен доступ к телематическим службам со стороны
пользователей Интернет.
Распределенный узел телематических служб подключается к ТфОП в
соответствии с требованиями [3].
6. Общие функциональные требования к Оборудованию,
реализующему функции гибкого коммутатора
6.1. Технические требования к кодеку
Кодеки, реализуемые Оборудованием, должны соответствовать
пункту 6.7 [4].
6.2. Технические требования к эхокомпенсаторам
Функции эхокомпенсатора, реализованные в Оборудовании, должны
соответствовать пункту 6.5 [4].
7. Общие технические требования к интерфейсам
Оборудования, реализующего функции гибкого коммутатора
7.1. Требования к интерфейсам Ethernet
Интерфейсы Ethernet (10 BaseT, 10 BaseF, 100 BaseTX, 100
BaseFX, 100 BaseFL, 1000 BaseTX, 1000 BaseCX, 1000 BaseLX, 1000
BaseLH, 1000 BaseSX), реализованные в Оборудовании, должны
соответствовать подразделу 6.1 [5].
7.2. Требования к интерфейсам Token Ring
Интерфейсы Token Ring, реализованные в Оборудовании, должны
соответствовать подразделу 6.2 [5].
7.3. Требования к интерфейсам FDDI, CDDI
Интерфейсы FDDI и CDDI, реализованные в оборудовании, должны
соответствовать подразделу 6.3 [5].
7.4. Требования к интерфейсам сетей передачи данных
Интерфейсы сети передачи данных должны соответствовать
требованиям Рекомендаций МСЭ-Т серии V (V.10 [6], V.11 [7], V.24
[8], V.28 [9]), стыка V.35, серии G (G.703 [10], G.825 [11]),
серии X (X.21 [12], X.21bis [13]).
7.5. Требования к электрическим параметрам телефонного канала
Электрические параметры телефонного канала должны
соответствовать пункту 6.6 [4].
7.6. Требования к интерфейсам ISDN BRI/PRI
Интерфейс ISDN BRI/PRI, реализованный в аппаратуре, должен
соответствовать разделу 4 [14].
7.7. Требования к интерфейсам СЦИ и ПЦИ
Интерфейсы СЦИ (STM-N) и интерфейсы ПЦИ (Е1, Е3), реализованные
в Оборудовании, должны соответствовать подразделу 4.2 [15].
7.8. Требования к интерфейсам xDSL
Интерфейсы xDSL, реализованные в Оборудовании, должны
соответствовать пунктам 4.2.3, 4.3.15 - 4.3.20 [16].
8. Общие технические требования к протоколам,
поддерживаемым Оборудованием, реализующим функции
гибкого коммутатора
8.1. Требования к реализации функций протокола IP
Требования к реализации протокола IP (Internet Protocol -
протокол межсетевого взаимодействия) должны соответствовать
подразделу [17].
8.2. Требования к реализации протокола реального времени RTP
Требования к реализации протокола RTP (Real-time protocol -
протокол передачи в режиме реального времени) и протокола RTCP
(Real-time Control Protocol - протокол управления передачей в
режиме реального времени) должны соответствовать подразделу 6.3
[4].
8.3. Требования к протоколу сигнализации RAS
Требования к протоколу сигнализации RAS (Registration,
Admission, Status - регистрация, допуск, состояние) должны
соответствовать подразделу 6.1 [4].
8.4. Требования к реализации протокола управления Н.245
Требования к реализации протокола управления Н.245 должны
соответствовать подразделу 6.2 [4].
8.5. Требования к реализации протокола управления SIP
Требования к реализации протокола управления SIP должны
соответствовать [18].
8.6. Требования к реализации протокола управления MGCP
8.6.1. Реализация протокола управления MGCP должна
соответствовать документу IETF RFC 2705bis [19], который
определяет перечень команд управления шлюзами MG и их форматы.
8.6.2. Протокол MGCP может быть реализован в следующих
устройствах:
- устройство управления шлюзами MGC;
- шлюз MG;
- шлюз сигнализации SG, обеспечивающий преобразование команд
MGCP в другие протоколы, реализуемые в устройстве управления
шлюзами MGC.
8.6.3. Протокол управления MGCP в соответствии с [19] должен
обеспечивать:
- согласование вида модуляции сигнала между двумя шлюзами MG;
- обработку тонов DTMF, распознавание вида передаваемой
информации (речевая информация, факсимильные сообщения, данные и
др.), определение состояния оконечного оборудования;
- установление соединения;
- освобождение соединения;
- изменение конфигурации соединения;
- освобождение соединений конфигурации "точка - несколько
точек";
- контроль и диагностику портов шлюзов MG;
- контроль и диагностику соединений;
- уведомление устройства управления шлюзами MGC об освобождении
ресурсов шлюзов MG.
8.6.4. Согласование вида модуляции сигнала между двумя шлюзами
MG должно осуществляться с использованием команды
"EndpointConfiguration" в соответствии с пунктом 2.3.1 [19].
Дополнительно команда обеспечивает инициализацию шлюза MG. Команда
"EndpointConfiguration" должна передаваться в направлении от
устройства управления шлюзами MGC к шлюзу MG.
8.6.4.1. Формат команды "EndpointConfiguration" должен
соответствовать пункту 2.3.1 [19]:
EndpointConfiguration(EndpointId,BearerInformation).
Таблица 8.2
ПОЛЯ КОМАНДЫ "ENDPOINTCONFIGURATION"
--------------------T-----------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+-------------------+-----------------------------+--------------+
¦EndpointLd ¦Идентификатор шлюза MG ¦ О ¦
+-------------------+-----------------------------+--------------+
¦BeareInformation ¦Вид модуляции сигнала ¦ О ¦
+-------------------+-----------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.4.2. Назначение и требования к функциям
кодирования/декодирования полей команды EndpointConfiguration:
а) поле "EndpointId" должно идентифицировать шлюз MG, а также
его отдельные элементы (интерфейсную плату, порт и пр.). Поле
представляет собой текстовую строку, состоящую из мнемонического
имени шлюза MG в формате адреса электронной почты (должен
соответствовать RFC 821 [20]) и наименования отдельных элементов.
Наименования отдельных элементов должны отделяться от имени шлюза
символом "/". Допускается иерархическое перечисление отдельных
элементов, также разделяемых символом "/" (например,
"mg@gateway.com/module1/port1"). Для обозначения произвольного
элемента должен использоваться символ "*". Для обозначения
произвольного символа в элементе должен использоваться символ "$"
(пункт 2.1.2 [19]);
б) поле "BearerInformation" должно содержать вид модуляции
сигнала (A-law или мю-law) в формате текстовой строки.
8.6.5. Распознавание вида передаваемой информации, тонов DTMF,
определение состояний оконечного оборудования должно
осуществляться с использованием команды "NotificationRequest" в
соответствии с пунктом 2.3.2 [19]. Команда "NotificationRequest"
должна передаваться в направлении от устройства управления шлюзами
MGC к шлюзу MG.
8.6.5.1. Формат команды "NotificationRequest" должен
соответствовать пункту 2.3.2 [19]:
NotificationRequest(EndpointId,[NotifiedEntity],[RequestedEvents],
RequestIdentifier,[DigitMap],[SignalRequests],
[QuarantineHandling],[DetectEvents],
[Encapsulated EndpointConfiguration]).
Таблица 8.3
ПОЛЯ КОМАНДЫ "NOTIFICATIONREQUEST"
----------------------T-------------------------------T----------¬
¦ Название поля ¦ Значение ¦Статус ¦
¦ ¦ ¦обязатель-¦
¦ ¦ ¦ности ¦
+---------------------+-------------------------------+----------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+---------------------+-------------------------------+----------+
¦NotifiedEntity ¦Получатель уведомлений ¦ Н ¦
+---------------------+-------------------------------+----------+
¦RequestedEvents ¦Перечень событий, подлежащих ¦ Н ¦
¦ ¦контролю, и реакций на них ¦ ¦
+---------------------+-------------------------------+----------+
¦RequestIdentifier ¦Признак соответствия ¦ О ¦
+---------------------+-------------------------------+----------+
¦DigitMap ¦Набор допустимых символов ¦ Н ¦
+---------------------+-------------------------------+----------+
¦SignalRequests ¦Перечень событий, подлежащих ¦ Н ¦
¦ ¦контролю ¦ ¦
+---------------------+-------------------------------+----------+
¦QuarantineHandling ¦Способ реакции на состояния, ¦ Н ¦
¦ ¦которые не должны ¦ ¦
¦ ¦обрабатываться шлюзом MG ¦ ¦
+---------------------+-------------------------------+----------+
¦DetectEvents ¦Перечень состояний, которые не ¦ Н ¦
¦ ¦должны обрабатываться шлюзом MG¦ ¦
+---------------------+-------------------------------+----------+
¦Encapsulated ¦Команда переконфигурации шлюза ¦ Н ¦
¦EndpointConfiguration¦MG ¦ ¦
+---------------------+-------------------------------+----------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.5.2. Назначение и требования к функциям
кодирования/декодирования полей команды "NotificationRequest":
а) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
б) "NotifiedEntity" - параметр, который определяет
альтернативного получателя уведомлений. Если данное поле не
задано, уведомления должны пересылаться отправителю команды
"NotificationRequest";
в) "RequestedEvents" - перечень событий, подлежащих контролю
(вид передаваемой информации, тоны DTMF, поднятие телефонной
трубки, отбой и пр.), которые должны передаваться устройству
управления шлюзами MGC. Каждому событию должен быть сопоставлен
способ реакции (например, немедленное уведомление, отложенное
уведомление, игнорирование и др.);
г) "RequestIdentifier" - признак соответствия;
д) "DigitMap" - представляет собой текстовую строку,
предназначенную для накопления информации, вводимой абонентом с
использованием тонов DTMF;
е) "SignalRequests" - содержит перечень состояний оконечного
оборудования, которые должны контролироваться шлюзом MG. Перечень
событий, указанный в настоящем поле, должен совпадать с перечнем
событий, указанным в поле "RequestedEvents";
ж) "QuarantineHandling" - определяет способ реакции на события,
наступившие до получения команды "NotificationRequest" и
накопленные шлюзом MG: обнулить накопленные события или обработать
их в штатном режиме. Кроме того, должен быть указан способ
передачи уведомлений устройства управления шлюзами MGC: одно
уведомление в одной команде (при наступлении события) или
несколько уведомлений в одной команде (при их накоплении);
з) "DetectEvents" - должен содержать перечень событий, которые
не должны обрабатываться шлюзом MG (определенные в поле
"QuarantineHandling"), и способ реакции на них;
и) команда "Encapsulated EndpointConfiguration" - может
передаваться в составе команды "NotificationRequest" для
оперативной переконфигурации оконечного оборудования. Назначение и
формат команды должны соответствовать пункту 8.6.4.2, за
исключением поля "EndpointId", которое заполняться не должно.
8.6.6. Команда "Notify" должна передаваться в направлении от
шлюза MG к устройству управления шлюзами MGC при обнаружении
событий, описанных в поле "RequestedEvents" команды
"NotificationRequest".
8.6.6.1. Формат команды "Notify" должен соответствовать пункту
2.3.42 [19]:
Notify(EndpointId,[NotifiedEntity],RequestIdentifier,ObservedEv
ents).
Таблица 8.4
ПОЛЯ КОМАНДЫ "NOTIFY"
---------------------T----------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+--------------------+----------------------------+--------------+
¦EndpointId ¦Идентификатор устройства ¦ О ¦
¦ ¦управления шлюзами MGC ¦ ¦
+--------------------+----------------------------+--------------+
¦NotifiedEntity ¦Получатель уведомлений ¦ Н ¦
+--------------------+----------------------------+--------------+
¦RequestIdentifier ¦Признак соответствия ¦ О ¦
+--------------------+----------------------------+--------------+
¦ObservedEvents ¦Список событий, обнаруженных¦ О ¦
¦ ¦шлюзом ¦ ¦
+--------------------+----------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.6.2. Назначение и требования к функциям
кодирования/декодирования полей команды "Notify":
а) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
б) "NotifiedEntity" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать полю
"NotifiedEntity" команды "NotificationRequest", описанному в
пункте 8.6.5.2 "б";
в) "RequestIdentifier" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать полю
"RequestIdentifier", описанному в пункте 8.6.5.2 "г";
г) "ObservedEvents" - должен содержать перечень событий,
обнаруженных шлюзом MG, в порядке их обнаружения.
8.6.7. Установление соединения между двумя шлюзами MG
осуществляется с использованием сообщения "CreateConnection" в
соответствии с пунктом 2.3.3 [19]. Команда "CreateConnection"
должна передаваться в направлении от устройства управления шлюзами
MGC к шлюзу MG.
8.6.7.1. Формат сообщения "CreateConnection" должен
соответствовать пункту 2.3.5 [19]:
CreateConnection(CallId,EndpointId,[NotifiedEntity],
[LocalConnectionOptions],Mode,
[RemoteConnectionDescriptor или
SecondEndpointId],[Encapsulated
NotificationRequest],[Encapsulated
EndpointConfiguration]).
Таблица 8.5
ПОЛЯ КОМАНДЫ "CREATECONNECTION"
---------------------------T-------------------------T-----------¬
¦ Название поля ¦ Значение ¦Статус ¦
¦ ¦ ¦обязатель- ¦
¦ ¦ ¦ности ¦
+--------------------------+-------------------------+-----------+
¦CallId ¦Идентификатор вызова ¦ О ¦
+--------------------------+-------------------------+-----------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+--------------------------+-------------------------+-----------+
¦NotifiedEntity ¦Получатель уведомлений ¦ Н ¦
+--------------------------+-------------------------+-----------+
¦LocalConnectionOptions ¦Параметры соединения ¦ Н ¦
+--------------------------+-------------------------+-----------+
¦Mode ¦Режимы соединения ¦ О ¦
+--------------------------+-------------------------+-----------+
¦RemoteConnectionDescriptor¦Описатель удаленного ¦ Н ¦
¦ ¦соединения ¦ ¦
+--------------------------+-------------------------+-----------+
¦SecondEndpointId ¦Идентификатор удаленного ¦ Н ¦
¦ ¦шлюза MG ¦ ¦
+--------------------------+-------------------------+-----------+
¦Encapsulated ¦Команда контроля шлюза MG¦ Н ¦
¦NotificationRequest ¦ ¦ ¦
+--------------------------+-------------------------+-----------+
¦Encapsulated ¦Команда переконфигурации ¦ Н ¦
¦EndpointConfiguration ¦шлюза MG ¦ ¦
+--------------------------+-------------------------+-----------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.7.2. Назначение и требования к функциям
кодирования/декодирования полей команды "CreateConnection":
а) "CallId" - идентификатор вызова;
б) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
в) "NotifiedEntity" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать полю
"NotifiedEntity" команды "NotificationRequest", описанному в
пункте 8.6.5.2 "б";
г) "LocalConnectionOptions" - перечень параметров, используемый
устройством управления шлюзами MGC при создании соединения. Поле
"LocalConnectionOptions" должно содержать следующие параметры:
- наименование алгоритма кодирования речевой информации;
- период передачи пакетов с речевой информацией в
миллисекундах;
- пропускную способность соединения в кбайт/с;
- класс обслуживания в соответствии с полем ToS заголовка
пакета IP;
- использование режима эхоподавления;
- использование режимов определения и подавления пауз;
- использование режимов адаптации уровня сигнала и подавления
шума;
д) "Mode" - определяет режим соединения и представляет собой
текстовую строку, которая должна содержать одно из значений в
соответствии с таблицей 8.6:
Таблица 8.6
РЕЖИМЫ СОЕДИНЕНИЙ
------------T----------------------------------------------------¬
¦ Режим ¦ Значение ¦
+-----------+----------------------------------------------------+
¦"sendonly" ¦Шлюз MG должен только передавать пакеты ¦
+-----------+----------------------------------------------------+
¦"recvonly" ¦Шлюз MG должен только получать пакеты ¦
+-----------+----------------------------------------------------+
¦"sendrecv" ¦Шлюз MG должен отправлять и получать пакеты ¦
+-----------+----------------------------------------------------+
¦"confrnce" ¦Шлюз MG должен установить соединение в режим ¦
¦ ¦конференции ¦
+-----------+----------------------------------------------------+
¦"inactive" ¦Шлюз MG не должен отправлять и получать пакеты ¦
+-----------+----------------------------------------------------+
¦"loopback" ¦Шлюз MG должен установить режим ответа, шлейфа ¦
+-----------+----------------------------------------------------+
¦"conttest" ¦Шлюз MG должен установить режим тестирования ¦
¦ ¦целостности соединения ¦
+-----------+----------------------------------------------------+
¦"netwloop" ¦Шлюз MG должен установить соединение в режим ¦
¦ ¦сетевого шлейфа ¦
+-----------+----------------------------------------------------+
¦"netwtest" ¦Шлюз MG должен установить соединение в режим ¦
¦ ¦сетевого теста на непрерывность передачи ¦
+-----------+----------------------------------------------------+
¦"data" ¦Шлюз MG должен использовать канал для доступа к сети¦
¦ ¦передачи данных (например, по протоколу РРР, SLIP ¦
¦ ¦и т.д.) ¦
L-----------+-----------------------------------------------------
е) "RemoteConnectionDescriptor" - описатель, задающий
характеристики соединения, которые должны быть установлены
удаленным шлюзом MG;
ж) "SecondEndpointId" - задается, когда должно быть установлено
соединение между оконечным оборудованием, подключенным к одному
шлюзу MG;
з) "Encapsulated NotificationRequest" - назначение и требования
к функциям кодирования/декодирования данного поля должны
соответствовать полям команды "NotificationRequest", описанной в
пункте 8.6.5;
и) "Encapsulated EndpointConfiguration" - назначение и формат
команды должны соответствовать пункту 8.6.4.2, за исключением поля
"EndpointId", которое заполняться не должно.
8.6.8. Изменение конфигурации соединения должно осуществляться
с использованием команды "ModifyConnection" в соответствии с
пунктом 2.3.6 [19]. Команда "ModifyConnection" должна передаваться
в направлении от устройства управления шлюзами MGC к шлюзу MG.
8.6.8.1. Формат команды "ModifyConnection" должен
соответствовать пункту 2.3.4 [19]:
ModifyConnection(CallId,EndpointId,ConnectionId,[NotifiedEntity],
[LocalConnectionOptions],[Mode],
[RemoteConnectionDescriptor],
[Encapsulated NotificationRequest],
[Encapsulated EndpointConfiguration]).
Таблица 8.7
ПОЛЯ КОМАНДЫ "MODIFYCONNECTION"
----------------------------T-------------------------T----------¬
¦ Название поля ¦ Значение ¦Статус ¦
¦ ¦ ¦обязатель-¦
¦ ¦ ¦ности ¦
+---------------------------+-------------------------+----------+
¦CallId ¦Идентификатор вызова ¦ О ¦
+---------------------------+-------------------------+----------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+---------------------------+-------------------------+----------+
¦ConnectionId ¦Идентификатор соединения ¦ О ¦
+---------------------------+-------------------------+----------+
¦NotifiedEntity ¦Получатель уведомлений ¦ Н ¦
+---------------------------+-------------------------+----------+
¦LocalConnectionOptions ¦Параметры соединения ¦ Н ¦
+---------------------------+-------------------------+----------+
¦Mode ¦Режимы соединения ¦ Н ¦
+---------------------------+-------------------------+----------+
¦RemoteConnectionDescriptor ¦Описатель удаленного ¦ Н ¦
¦ ¦соединения ¦ ¦
+---------------------------+-------------------------+----------+
¦Encapsulated ¦Команда контроля шлюза MG¦ Н ¦
¦NotificationRequest ¦ ¦ ¦
+---------------------------+-------------------------+----------+
¦Encapsulated ¦Команда переконфигурации ¦ Н ¦
¦EndpointConfiguration ¦шлюза MG ¦ ¦
+---------------------------+-------------------------+----------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.8.2. Назначение и требования к функциям
кодирования/декодирования полей команды "ModifyConnection":
а) "CallId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "а";
б) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
в) "ConnectionId" - параметр, идентифицирующий соединение,
созданное шлюзом MG;
г) "NotifiedEntity" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "б";
д) "LocalConnectionOptions" - назначение и требования к
функциям кодирования/декодирования данного поля должны
соответствовать пункту 8.6.7.2 "г";
е) "Mode" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "д";
ж) "RemoteConnectionDescriptor" - назначение и требования к
функциям кодирования/декодирования данного поля должны
соответствовать пункту 8.6.7.2 "е";
з) "Encapsulated NotificationRequest" - назначение и требования
к функциям кодирования/декодирования данного поля должны
соответствовать пункту 8.6.7.2 "з";
и) "Encapsulated EndpointConfiguration" - назначение и формат
команды должны соответствовать пункту 8.6.4.2, за исключением поля
"EndpointId", которое заполняться не должно.
8.6.9. Освобождение соединения должно обеспечиваться командой
"DeleteConnection" в соответствии с пунктами 2.3.5 - 2.3.7 [19].
Формат команды "DeleteConnection" различается в зависимости от
устройства, по инициативе которого освобождается соединение:
- устройство управления шлюзами MGC;
- шлюз MGC.
Кроме того, формат команды "DeleteConnection" различается от ее
назначения:
- для освобождения всех соединений, относящихся к одному
соединению;
- для безусловного освобождения всех соединений на шлюзе MG.
В зависимости от устройства, по инициативе которого
освобождается соединение, команда "DeleteConnection" может
передаваться как в направлении от устройства управления шлюзами
MGC к шлюзу MG, так и в обратном направлении.
8.6.9.1. Формат команды "DeleteConnection", передаваемой
устройством управления шлюзами MGC, должен соответствовать пункту
2.3.5 [19]:
DeleteConnection(CallId,EndpointId,ConnectionId,
[Encapsulated NotificationRequest],
[Encapsulated EndpointConfiguration]).
Таблица 8.8
ПОЛЯ КОМАНДЫ "DELETECONNECTION"
----------------------T-------------------------------T----------¬
¦ Название поля ¦ Значение ¦Статус ¦
¦ ¦ ¦обязатель-¦
¦ ¦ ¦ности ¦
+---------------------+-------------------------------+----------+
¦CallId ¦Идентификатор вызова ¦ О ¦
+---------------------+-------------------------------+----------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+---------------------+-------------------------------+----------+
¦ConnectionId ¦Идентификатор соединения ¦ О ¦
+---------------------+-------------------------------+----------+
¦Encapsulated ¦Команда контроля шлюза MG ¦ Н ¦
¦NotificationRequest ¦ ¦ ¦
+---------------------+-------------------------------+----------+
¦Encapsulated ¦Команда переконфигурации шлюза ¦ Н ¦
¦EndpointConfiguration¦MG ¦ ¦
+---------------------+-------------------------------+----------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.9.2. Назначение и требования к функциям
кодирования/декодирования полей команды "DeleteConnection", формат
которой определен в пункте 8.6.9.1:
а) "CallId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "а";
б) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
в) "ConnectionId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.8.2 "в";
г) "Encapsulated NotificationRequest" - назначение и требования
к функциям кодирования/декодирования данного поля должны
соответствовать пункту 8.6.7.2 "з";
д) "Encapsulated EndpointConfiguration" - назначение и
требования к функциям кодирования/декодирования данного поля
должны соответствовать пункту 8.6.7.2 "и".
8.6.9.3. Формат команды "DeleteConnection", передаваемой шлюзом
MG, должен соответствовать пункту 2.3.6 [18]:
DeleteConnection(CallId,EndpointId,ConnectionId,Reason-code,
Connection-parameters).
Таблица 8.9
ПОЛЯ КОМАНДЫ "DELETECONNECTION"
----------------------T---------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+---------------------+---------------------------+--------------+
¦CallId ¦Идентификатор вызова ¦ О ¦
+---------------------+---------------------------+--------------+
¦EndpointId ¦Идентификатор устройства ¦ О ¦
¦ ¦управления шлюзами MGC ¦ ¦
+---------------------+---------------------------+--------------+
¦ConnectionId ¦Идентификатор соединения ¦ О ¦
+---------------------+---------------------------+--------------+
¦Reason-code ¦Код причины освобождения ¦ О ¦
+---------------------+---------------------------+--------------+
¦Connection-parameters¦Параметры соединения ¦ О ¦
+---------------------+---------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.9.4. Назначение и требования к функциям
кодирования/декодирования полей команды "DeleteConnection", формат
которой определен в пункте 8.6.9.3:
а) "CallId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "а";
б) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
в) "ConnectionId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.8.2 "в";
г) "Reason-code" - причина освобождения соединения, в
соответствии с пунктом 2.5 RFC 2705 должно принимать следующие
значения:
- 000 при штатном освобождении соединения;
- 900 при освобождении соединения из-за неисправности шлюза MG;
- 901 при освобождении соединения из-за отключения шлюза MG
средствами системы административного управления;
- 902 при освобождении соединения из-за ухудшения его
характеристик ниже допустимого уровня;
д) "Connection-parameters" - при освобождении соединения
передается статистика соединения, которая должна включать
следующую информацию:
- количество переданных пакетов RTP;
- количество переданных октетов;
- количество полученных пакетов RTP;
- количество полученных октетов;
- количество потерянных пакетов RTP;
- отклонение величины задержки получения пакетов RTP в мс;
- средняя задержка передачи пакетов RTP по сети в мс.
8.6.9.5. Формат команды "DeleteConnection", используемой для
освобождения всех соединений, относящихся к одному соединению, и
инициируемой устройством управления шлюзами MGC, должен
соответствовать пункту 2.3.6 [19]:
DeleteConnection(CallId,EndpointId).
Таблица 8.10
ПОЛЯ КОМАНДЫ "DELETECONNECTION"
----------------------T---------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+---------------------+---------------------------+--------------+
¦CallId ¦Идентификатор вызова ¦ О ¦
+---------------------+---------------------------+--------------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+---------------------+---------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.9.6. Назначение и требования к функциям
кодирования/декодирования полей команды "DeleteConnection", формат
которой определен в пункте 8.6.9.5:
а) "CallId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "а";
б) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а".
8.6.9.7. Формат команды "DeleteConnection", используемой для
безусловного освобождения всех соединений на шлюзе MG и
инициируемой устройством управления шлюзами MGC, должен
соответствовать пункту 2.3.7 [19]:
DeleteConnection(EndpointId).
Таблица 8.11
ПОЛЯ КОМАНДЫ "DELETECONNECTION"
----------------------T---------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+---------------------+---------------------------+--------------+
¦CallId ¦Идентификатор вызова ¦ О ¦
+---------------------+---------------------------+--------------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+---------------------+---------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.9.8. Назначение и требования к функциям
кодирования/декодирования полей "EndpointId" должны
соответствовать пункту 8.6.4.2 "а".
8.6.10. Контроль и диагностика против шлюза MG должны
осуществляться командой "AuditEndPoint" в соответствии с пунктом
2.3.8 [19]. Команда должна передаваться в направлении от
устройства управления шлюзами MGC к шлюзу MG.
8.6.10.1. Формат команды "AuditEndPoint" должен соответствовать
пункту 2.3.9 [19]):
AuditEndPoint(EndpointId,[RequestedInfo]).
Таблица 8.12
ПОЛЯ КОМАНДЫ "AUDITENDPOINT"
----------------------T---------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+---------------------+---------------------------+--------------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+---------------------+---------------------------+--------------+
¦RequestedInfo ¦Запрашиваемая информация ¦ Н ¦
+---------------------+---------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.10.2. Назначение и требования к функциям
кодирования/декодирования полей команды "AuditEndPoint":
а) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
б) "RequestedInfo" - должен содержать перечень характеристик
соединения, описываемых следующими параметрами: "RequestedEvents",
"DigitMap", "SignalRequests", "RequestIdentifier",
"NotifiedEntity", "ConnectionIdentifiers", "DetectEvents",
"ObservedEvents", "EventStates", "RestartReason", "RestartDelay",
"ReasonCode", "Capabilities", которые должны соответствовать
следующему:
- "RequestedEvents" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "в";
- "DigitMap" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "д";
- "SignalRequests" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "е";
- "RequestIdentifier" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "г";
- "NotifiedEntity" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "б";
- "ConnectionIdentifiers" - перечень соединений, относящихся к
одному шлюзу MG;
- "DelectEvents" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "з";
- "ObservedEvents" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.6.2 "г";
- "EventStates" - назначение и требования к функциям
кодирования/декодирования данного поля аналогичны полю
"ObservedEvents" и должны соответствовать пункту 8.6.6.2 "г";
- "RestartReason" - назначение и требования к функциям
кодирования/декодирования данного поля аналогичны полю
"ReasonCode" и должны соответствовать пункту 8.6.9.4 "г";
- "RestartDelay" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.12.2 "в";
- "ReasonCode" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.9.4 "г";
- "Capabilities" - требования к функциям
кодирования/декодирования данного поля аналогичны требованиям
кодирования/декодирования поля LocalConnectionOptions и должны
соответствовать пункту 8.6.7.2 "г".
8.6.11. Контроль и диагностика соединения должны осуществляться
командой "AuditConnection" в соответствии с пунктом 2.3.9 [19].
Команда должна передаваться в направлении от устройства управления
шлюзами MGC к шлюзу MG.
8.6.11.1. Формат команды "AuditConnection" должен
соответствовать пункту 2.3.11 [19]:
AuditConnection(EndpointId,ConnectionId,RequestedInfo).
Таблица 8.13
ПОЛЯ КОМАНДЫ "AUDITCONNECTION"
----------------------T---------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+---------------------+---------------------------+--------------+
¦EndpointId ¦Идентификатор шлюза MG ¦ О ¦
+---------------------+---------------------------+--------------+
¦ConnectionId ¦Идентификатор соединения ¦ О ¦
+---------------------+---------------------------+--------------+
¦RequestedInfo ¦Запрашиваемая информация ¦ О ¦
+---------------------+---------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.11.2. Назначение и требования к функциям
кодирования/декодирования данного поля команды "AuditEndPoint":
а) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
б) "ConnectionId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.8.2 "в";
в) "RequestedInfo" - поле должно содержать перечень
характеристик соединения, описываемых следующими параметрами:
"CallId", "NotifiedEntity", "LocalConnectionOptions", "Mode",
"RemoteConnectionDescriptor", "LocalConnectionDescriptor",
"ConnectionParameters". Данные параметры должны соответствовать
следующему:
- "CallId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "а";
- "NotifiedEntity" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.5.2 "б";
- "LocalConnectionOptions" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "г";
- "Mode" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.7.2 "д";
- "RemoteConnectionDescriptor" - назначение и требования к
функциям кодирования/декодирования данного поля должны
соответствовать пункту 8.6.7.2 "е";
- "LocalConnectionDescriptor" - описатель, задающий
характеристики соединения, которые должны быть установлены
локальным шлюзом MG;
- "ConnectionParameters" - текущее значение параметров
(характеристик) соединения в соответствии с 8.6.9.4 "д".
8.6.12. Команда "RestartInProgress" должна использоваться
шлюзом MG для уведомления устройства управления шлюзами MGC о том,
что шлюз MG находится в процессе перезагрузки. Команда
"RestartInProgress" должна передаваться в направлении от шлюза MG
к устройству управления шлюзами MGC.
8.6.12.1. Формат команды "RestartInProgress" должен
соответствовать пункту 2.3.10 [19]:
RestartInProgress(EndPointId,RestartMethod,[RestartDelay],[Reas
on-code]).
Таблица 8.14
ПОЛЯ КОМАНДЫ "RESTARTINPROGRESS"
----------------------T---------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+---------------------+---------------------------+--------------+
¦EndpointId ¦Идентификатор устройства ¦ О ¦
¦ ¦управления шлюзами MGC ¦ ¦
+---------------------+---------------------------+--------------+
¦RestartMethod ¦Метод рестарта ¦ О ¦
+---------------------+---------------------------+--------------+
¦RestartDelay ¦Пауза ¦ Н ¦
+---------------------+---------------------------+--------------+
¦Reason-code ¦Причина рестарта ¦ Н ¦
+---------------------+---------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.6.12.2. Требования к функциям кодирования/декодирования полей
команды "RestartMethod":
а) "EndpointId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
б) "RestartMethod" - определяет метод рестарта в соответствии с
таблицей 8.15:
Таблица 8.15
ЗНАЧЕНИЯ ПОЛЯ "RESTARTMETHOD"
------------------T----------------------------------------------¬
¦ Метод рестарта ¦ Описание ¦
+-----------------+----------------------------------------------+
¦"graceful" ¦При ухудшении характеристик соединения шлюз MG¦
¦ ¦должен освободить соединение и после паузы, ¦
¦ ¦значение которой определяется в поле ¦
¦ ¦"RestartDelay", переустановить это соединение ¦
+-----------------+----------------------------------------------+
¦"forced" ¦При ухудшении характеристик соединения шлюз MG¦
¦ ¦должен немедленно освободить все соединения ¦
+-----------------+----------------------------------------------+
¦"restart" ¦При ухудшении характеристик соединения шлюз MG¦
¦ ¦должен запомнить параметры существующих ¦
¦ ¦соединений и немедленно переустановить их ¦
+-----------------+----------------------------------------------+
¦"disconnected" ¦При освобождении соединения из-за аварии шлюза¦
¦ ¦MG соединение должно быть установлено заново ¦
¦ ¦через определенное время, значение которого ¦
¦ ¦определено в поле "RestartDelay" ¦
+-----------------+----------------------------------------------+
¦"cancel-graceful"¦Шлюз MG должен прервать и завершить процесс ¦
¦ ¦рестарта методом "graceful" ¦
L-----------------+-----------------------------------------------
в) "RestartDelay" - величина паузы в секундах;
г) "Reason-code" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.9.4 "г".
8.7. Требования к реализации протокола управления MEGACO
8.7.1. Реализация протокола управления MEGACO должна
соответствовать документу IETF RFC 3015 [21], который определяет
перечень команд управления шлюзами MG и их форматы.
8.7.2. Протокол MEGACO может быть реализован в следующих
устройствах:
- устройство управления шлюзами MGC;
- шлюз MG.
8.7.3. Объектами управления протокола MEGACO является
совокупность соединений, относящихся к текущему сеансу связи или
конференции.
8.7.3.1. Соединения должны идентифицироваться параметром
TerminationID.
8.7.3.2. Сеансы должны идентифицироваться параметром ContextID.
8.7.4. Протокол управления MEGACO в соответствии с [21] должен
обеспечивать:
- добавление соединения в сеанс связи;
- изменение конфигурации соединения;
- удаление соединения из сеанса связи;
- перемещение соединения в другой сеанс связи;
- контроль и диагностику соединений;
- определение возможностей шлюза MG;
- уведомление устройства управления шлюзами MGC о событиях,
произошедших на шлюзах MG;
- уведомление устройства управления шлюзами MGC об отказах
шлюзов MG.
8.7.5. Должны поддерживаться два способа кодирования полей
команд протокола MEGACO:
- в виде текстовых строк;
- в бинарном виде.
8.7.6. Добавление соединения в сеанс связи должно
осуществляться с использованием команды "Add" в соответствии с
пунктом 7.2.1 [21]. При первом вызове команды "Add" должен
создаваться сеанс связи. Добавление первого соединения в пустой
сеанс связи должно обеспечивать создание сеанса связи. Команда
"Add" должна передаваться в направлении от устройства управления
шлюзами MGC к шлюзу MG.
8.7.6.1. Формат команды "Add" должен соответствовать пункту
7.2.1 [21]:
Add(TerminationID,[MediaDescriptor],[ModemDescriptor],
[MuxDescriptor],[EventsDescriptor],[SignalsDescriptor],
[DigitMapDescriptor],[AuditDescriptor]).
Таблица 8.16
ПОЛЯ КОМАНДЫ "ADD"
-------------------T------------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+------------------+------------------------------+--------------+
¦TerminationID ¦Идентификатор соединения ¦ О ¦
+------------------+------------------------------+--------------+
¦MediaDescriptor ¦Перечень характеристик ¦ Н ¦
¦ ¦информационных потоков ¦ ¦
+------------------+------------------------------+--------------+
¦ModemDescriptor ¦Описатель типа оконечного ¦ Н ¦
¦ ¦оборудования ¦ ¦
+------------------+------------------------------+--------------+
¦MuxDescriptor ¦Описатель способа ¦ Н ¦
¦ ¦мультиплексирования соединений¦ ¦
+------------------+------------------------------+--------------+
¦EventsDescriptor ¦Перечень контролируемых ¦ Н ¦
¦ ¦событий ¦ ¦
+------------------+------------------------------+--------------+
¦SignalsDescriptor ¦Перечень контролируемых ¦ Н ¦
¦ ¦состояний ¦ ¦
+------------------+------------------------------+--------------+
¦DigitMapDescriptor¦Набор допустимых символов ¦ Н ¦
+------------------+------------------------------+--------------+
¦AuditDescriptor ¦Перечень характеристик ¦ Н ¦
¦ ¦соединения ¦ ¦
+------------------+------------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.7.6.2. Назначение и требования к функциям
кодирования/декодирования полей команды "Add":
а) "TerminationId" - идентифицирует соединение, которое должно
быть добавлено в сеанс связи. Требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.6.4.2 "а";
б) "MediaDescriptor" - устанавливает режимы соединения
(передача, прием, прием/передача, тест) и пр.;
в) "ModemDescriptor" - в случае, если оконечным оборудованием
является модем для коммутируемых линий, должен содержать
наименование протокола передачи данных (V.32, V.32bis, V.90 и
пр.);
г) "MuxDescriptor" - в случае, если окончанием соединения
(TerminationID) является функциональный элемент Н.323, реализующий
функции мультиплексирования соединений, данное поле должно
содержать наименование алгоритма мультиплексирования (Н.221, Н.223
и пр.);
д) "EventsDescriptor" - содержит перечень событий шлюза MG,
которые могут быть получены и соответствующим образом обработаны
устройством управления шлюзами MGC;
е) "SignalsDescriptor" - содержит перечень состояний шлюза MG,
которые могут быть получены и соответствующим образом обработаны
устройством управления шлюзами MGC;
ж) "DigitMapDescriptor" - набор символов, которые могут быть
обработаны устройством управления шлюзами MGC. По умолчанию, набор
должен содержать цифровые символы, строчные и заглавные буквы
английского алфавита, символы "пробел", "+", "-", "&", "!", "_",
"/", """, "?", "@", "/\", "'", "~", "*", "$", "\", "(", ")", "%",
".", ";", "[", "]", "{", "}", ":", ",", "#", "<", ">", "=";
з) "AuditDescriptor" - после завершения выполнения команды
данная структура должна содержать параметры соединения, его
статистику, а также перечень состояний и событий, связанных с
оборудованием, участвующим в обслуживании соединения.
8.7.7. Изменение конфигурации соединения должно осуществляться
с использованием команды "Modify" в соответствии с пунктом 7.2.2
[21]. Команда "Modify" должна передаваться в направлении от
устройства управления шлюзами MGC к шлюзу MG.
8.7.7.1. Формат команды "Modify", а также назначение и
требования к функциям кодирования/декодирования полей должны
соответствовать пунктам 8.7.6.1, 8.7.6.2.
8.7.8. Удаление соединения из сеанса связи должно
осуществляться с использованием команды "Subtract" в соответствии
с пунктом 7.2.3 [21]. При удалении последнего соединения должно
обеспечиваться удаление всего сеанса связи. Команда "Subtract"
должна передаваться в направлении от устройства управления шлюзами
MGC к шлюзу MG.
8.7.8.1. Формат команды "Subtract" должен соответствовать
пункту 7.2.3 [21]:
Subtract(TerminationID,[AuditDescriptor]).
Таблица 8.17
ПОЛЯ КОМАНДЫ "SUBTRACT"
----------------------T---------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+---------------------+---------------------------+--------------+
¦TerminationId ¦Идентификатор соединения ¦ О ¦
+---------------------+---------------------------+--------------+
¦AuditDescriptor ¦Перечень характеристик ¦ Н ¦
¦ ¦соединения ¦ ¦
+---------------------+---------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.7.8.2. Назначение и требования к функциям
кодирования/декодирования полей команды "Subtract":
а) "TerminationId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.7.6.2 "а";
б) "AuditDescriptor" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.7.6.2 "з".
8.7.9. Перемещение соединения в другой сеанс связи должно
осуществляться с использованием команды "Move" в соответствии с
пунктом 7.2.4 [21]. Команда "Move" должна передаваться в
направлении от устройства управления шлюзами MGC к шлюзу MG.
8.7.9.1. Формат команды "Move", а также назначение и требования
к функциям кодирования/декодирования полей должны соответствовать
пунктам 8.7.6.1, 8.7.6.2.
8.7.10. Контроль и диагностика существующего соединения должны
осуществляться с использованием команды "AuditValue" в
соответствии с пунктом 7.2.5 [21]. Команда "AuditValue" должна
передаваться в направлении от устройства управления шлюзами MGC к
шлюзу MG.
8.7.10.1. Формат команды "AuditValue", а также назначение и
требования к функциям кодирования/декодирования полей должны
соответствовать пунктам 8.7.8.1, 8.7.8.2.
8.7.11. Определение возможностей шлюзов MG должно
осуществляться с использованием команды "AuditCapabilities" в
соответствии с пунктом 7.2.6 [21]. Команда "AuditCapabilities"
должна передаваться в направлении от устройства управления шлюзами
MGC к шлюзу MG.
8.7.11.1. Формат команды "AuditCapabilities", а также
назначение и требования к функциям кодирования/декодирования полей
должны соответствовать пунктам 8.7.8.1, 8.7.8.2.
8.7.12. Уведомление устройства управления шлюзами MGC о
событиях, произошедших на шлюзах MG, должно осуществляться с
использованием команды "Notify" в соответствии с пунктом 7.2.7
[21]. Команда "Notify" должна передаваться в направлении от шлюза
MG к устройству управления шлюзами MGC.
8.7.12.1. Формат команды "Notify" должен соответствовать пункту
7.2.7 [21]:
Notify(TerminationId,ObservedEventsDescriptor).
Таблица 8.18
ПОЛЯ КОМАНДЫ "NOTIFY"
-------------------------T------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+------------------------+------------------------+--------------+
¦TerminationId ¦Идентификатор соединения¦ О ¦
+------------------------+------------------------+--------------+
¦ObservedEventsDescriptor¦Список событий ¦ О ¦
+------------------------+------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.7.12.2. Назначение и требования к функциям
кодирования/декодирования полей команды "Notify":
а) "TerminationId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.7.6.2 "а";
б) "ObservedEventsDescriptor" - должен содержать перечень
событий, произошедших в шлюзе MG, в порядке их обнаружения.
8.7.13. Уведомление устройства управления шлюзами MGC об
отказах шлюзов MG должно осуществляться с использованием команды
"ServiceChange" в соответствии с пунктом 7.2.8 [21]. Команда
должна обеспечивать выполнение двух основных функций: уведомления
об отказах и уведомления о восстановлении работоспособности.
Команда "ServiceChange" должна передаваться в направлении от шлюза
MG к устройству управления шлюзами MGC.
8.7.13.1. Формат команды "ServiceChange" должен соответствовать
пункту 7.2.8 [21]:
ServiceChange(TerminationId,ServiceChangeDescriptor).
Таблица 8.19
ПОЛЯ КОМАНДЫ "SERVICECHANGE"
------------------------T-------------------------T--------------¬
¦ Название поля ¦ Значение ¦ Статус ¦
¦ ¦ ¦обязательности¦
+-----------------------+-------------------------+--------------+
¦TerminationId ¦Идентификатор соединения ¦ О ¦
+-----------------------+-------------------------+--------------+
¦ServiceChangeDescriptor¦Причина отказа ¦ О ¦
+-----------------------+-------------------------+--------------+
¦ Примечания. 1. О - обязательно. ¦
¦ 2. Н - необязательно. ¦
L-----------------------------------------------------------------
8.7.13.2. Назначение и требования к функциям
кодирования/декодирования полей команды "ServiceChange":
а) "TerminationId" - назначение и требования к функциям
кодирования/декодирования данного поля должны соответствовать
пункту 8.7.6.2 "а";
б) "ServiceChangeDescriptor" - должен содержать информацию о
причинах отказа, методе восстановления обслуживания, временные
метки для синхронизации внутренних часов устройств,
восстанавливающих обслуживание.
8.8. Требования к реализации протокола сигнализации Н.225
8.8.1. Перечень сообщений протокола сигнализации Н.225 согласно
таблице 8.20 должен соответствовать Рекомендации МСЭ-Т Н.225.0
[22]. Сообщения протокола сигнализации Н.225 должны передаваться в
поле нагрузки пакетов протокола UDP [25].
8.8.2. Требования к функциям кодирования/декодирования
сообщений протокола сигнализации Н.225 должны соответствовать
Рекомендации МСЭ-Т Q.931 [26].
Таблица 8.20
ПЕРЕЧЕНЬ СООБЩЕНИЙ Н.225
------------------T------------------------T---------------------¬
¦ Сообщение Н.225 ¦ Передача ¦ Прием ¦
+-----------------+------------------------+---------------------+
¦ Группа сообщений установления и освобождения соединения ¦
+-----------------T------------------------T---------------------+
¦Alerting ¦ О ¦ О ¦
+-----------------+------------------------+---------------------+
¦Call Proceeding ¦ Н ¦ О.1 ¦
+-----------------+------------------------+---------------------+
¦Connect ¦ О ¦ О ¦
+-----------------+------------------------+---------------------+
¦Progress ¦ Н ¦ Н ¦
+-----------------+------------------------+---------------------+
¦Setup ¦ О ¦ О ¦
+-----------------+------------------------+---------------------+
¦Setup Acknowledge¦ Н ¦ Н ¦
+-----------------+------------------------+---------------------+
¦Release Complete ¦ О ¦ О ¦
+-----------------+------------------------+---------------------+
¦ ¦ ¦ ¦
+-----------------+------------------------+---------------------+
¦ Группа информационных сообщений ¦
+-----------------T------------------------T---------------------+
¦Information ¦ Н ¦ Н ¦
+-----------------+------------------------+---------------------+
¦Notify ¦ Н ¦ Н ¦
+-----------------+------------------------+---------------------+
¦Status ¦ О ¦ О ¦
+-----------------+------------------------+---------------------+
¦Status Inquiry ¦ Н ¦ О ¦
+-----------------+------------------------+---------------------+
¦ Примечания. 1. О - обязательный. ¦
¦ 2. Н - необязательный. ¦
¦ 3. О.1 - обязательно при условии. ¦
L-----------------------------------------------------------------
8.8.3. Структура и формат сообщений протокола сигнализации
Н.225 должны соответствовать Рекомендации МСЭ-Т Q.931 [24].
8.8.4. Оборудование должно передавать и принимать информацию о
состоянии занятости в сообщении "Alerting". Требования к функциям
кодирования/декодирования сообщения "Alerting" должны
соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.1 [22].
8.8.5. Принимающая сторона должна передавать информацию о
начале обработки вызова в сообщении "Call Proceeding". Требования
к функциям кодирования/декодирования сообщения "Call Ppoceeding"
должны соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.2 [22].
8.8.6. Принимающая сторона должна передавать информацию об
установлении соединения в сообщении "Connect". Требования к
функциям кодирования/декодирования сообщения "Connect" должны
соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.3 [22].
8.8.7. Шлюз MG должен передавать информацию о начале фазы
установления (до передачи сообщения "Connect") в сообщении
"Progress". Требования к функциям кодирования/декодирования
сообщения "Progress" должны соответствовать Рекомендации МСЭ-Т
Н.225.0, 7.3.7 [22].
8.8.8. Передающая сторона должна информировать принимающую
сторону о начале установления соединения в сообщении "Setup".
Требования к функциям кодирования/декодирования сообщения "Setup"
должны соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.10 [22].
8.8.9. Принимающая сторона должна подтверждать готовность
начать установление соединения сообщением "Setup Acknowledge".
Требования к функциям кодирования/декодирования сообщения "Setup
Acknowledge" должны соответствовать Рекомендации МСЭ-Т Н.225.0,
7.3.11 [22].
8.8.10. Шлюз MG должен информировать устройство управления
вызовами и шлюзами MGC о завершении вызова и освобождении
соединения сообщением "Release Complete". Требования к функциям
кодирования/декодирования сообщения "Release Complete" должны
соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.9 [22].
8.8.11. Передача дополнительной информации о вызове и
возможностях оконечного оборудования (терминалов) должна
осуществляться в сообщении "Information". Требования к функциям
кодирования/декодирования сообщения "Information" должны
соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.6 [22].
8.8.12. Назначение и требования к функциям
кодирования/декодирования сообщения "Notify" должны
соответствовать Рекомендации МСЭ-Т Н.225.0, 7.4.2 [22].
8.8.13. Передача информации о текущем состоянии вызова должна
осуществляться в сообщении "Status". Требования к функциям
кодирования/декодирования сообщения "Status" должны
соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.12 [22].
8.8.14. Запрос информации о текущем состоянии вызова должен
осуществляться в сообщении "Status Inquiry". Требования к функциям
кодирования/декодирования сообщения "Status Inquiry" должны
соответствовать Рекомендации МСЭ-Т Н.225.0, 7.3.13 [22].
8.8.15. Оборудование, реализующее функции протокола
сигнализации Н.225, должно обеспечивать:
- Таймер Т303, определяющий время ожидания приема сообщений
"Alerting", "Call Proceeding", "Connect", "Release Complete".
Время ожидания не должно превышать 4 секунд;
- Таймер Т301, определяющий время, по истечении которого
вызывающая сторона должна принудительно завершить вызов. Указанное
время не должно быть меньше 180 секунд.
8.9. Требования к реализации протоколов SIGTRAN
8.9.1. В соответствии с документом RFC 2719 [23] Оборудование
должно обеспечивать передачу сообщений подсистем МТР2, МТР2
одноранговой, МТР3, SCCP протокола сигнализации ОКС N 7.
8.9.2. В соответствии с документом RFC 2719 [23] Оборудование
должно обеспечивать передачу сообщений протоколов сигнализаций
Q.921, V5.2.
8.9.3. Передача сообщений подсистем ОКС N 7 и протоколов
сигнализаций Q.921, V5.2 должна осуществляться с использованием
протокола SCTP (Stream Control Transmission Protocol). Реализация
протокола SCTP должна соответствовать документу RFC 2960 [24].
8.9.4. Формат пакета SCTP должен соответствовать разделу 3
документа RFC 2960 и рисунку 8.1.
------------------------¬
¦ Заголовок ¦
+-----------------------+
¦ Команда N 1 ¦
+-----------------------+
¦ Команда N 2 ¦
+-----------------------+
¦ ... ¦
+-----------------------+
¦ Команда N n ¦
L------------------------
Рисунок 8.1. Формат пакета SCTP
8.9.5. Формат заголовка пакета SCTP и перечень поддерживаемых
полей должны соответствовать разделу 3.1 документа RFC 2960,
рисунку 8.2 и таблице 8.21.
----------------------T----------------------¬
¦Номер порта источника¦Номер порта назначения¦
+---------------------+----------------------+
¦ Метка верификации ¦
+--------------------------------------------+
¦ Контрольная сумма ¦
L---------------------------------------------
Рисунок 8.2. Формат заголовка пакета SCTP
Таблица 8.21
ПОЛЯ ЗАГОЛОВКА ПАКЕТА SCTP
-------T----------------------------------------T----------------¬
¦N поля¦ Название поля ¦Длина поля, бит ¦
+------+----------------------------------------+----------------+
¦1 ¦Номер порта источника ¦ 16 ¦
+------+----------------------------------------+----------------+
¦2 ¦Номер порта назначения ¦ 16 ¦
+------+----------------------------------------+----------------+
¦3 ¦Метка верификации ¦ 32 ¦
+------+----------------------------------------+----------------+
¦4 ¦Контрольная сумма ¦ 32 ¦
L------+----------------------------------------+-----------------
8.9.6. Функции кодирования/декодирования полей заголовка пакета
SCTP должны соответствовать следующим требованиям:
а) поле "Номер порта источника" должно содержать номер порта
SCTP отправителя;
б) поле "Номер порта назначения" должно содержать номер порта
SCTP получателя;
в) поле "Метка верификации" должно содержать числовое значение,
однозначно идентифицирующее отправителя пакета SCTP. Отправитель
пакета SCTP должен устанавливать значение этой метки, равное
значению, полученному при инициализации сеанса связи между ним и
получателем;
г) поле "Контрольная сумма" должно содержать контрольную сумму
пакета SCTP.
8.9.7. Пакет SCTP может включать в себя несколько управляющих
команд. Перечень допустимых команд приведен в таблице 8.22.
Таблица 8.22
УПРАВЛЯЮЩИЕ КОМАНДЫ ПРОТОКОЛА SCTP
--------------------------------------------------------T--------¬
¦ Команда ¦ Код ¦
¦ ¦команды ¦
+-------------------------------------------------------+--------+
¦Данные пользователя (DATA) ¦0 ¦
+-------------------------------------------------------+--------+
¦Создание сеанса связи (INIT) ¦1 ¦
+-------------------------------------------------------+--------+
¦Подтверждение создания сеанса связи (INIT ACK) ¦2 ¦
+-------------------------------------------------------+--------+
¦Выборочное подтверждение (SACK) ¦3 ¦
+-------------------------------------------------------+--------+
¦Команда опроса состояния (HEARTBEAT) ¦4 ¦
+-------------------------------------------------------+--------+
¦Подтверждение состояния (HEARTBEAT ACK) ¦5 ¦
+-------------------------------------------------------+--------+
¦Удаление сеанса связи (ABORT) ¦6 ¦
+-------------------------------------------------------+--------+
¦Завершение сеанса связи (SHUTDOWN) ¦7 ¦
+-------------------------------------------------------+--------+
¦Подтверждение завершения сеанса связи (SHUTDOWN ACK) ¦8 ¦
+-------------------------------------------------------+--------+
¦Ошибка (ERROR) ¦9 ¦
+-------------------------------------------------------+--------+
¦Завершение создания сеанса связи (COOKIE ECHO) ¦10 ¦
+-------------------------------------------------------+--------+
¦Создание сеанса связи завершено (COOKIE ACK) ¦11 ¦
+-------------------------------------------------------+--------+
¦Процедура завершения сеанса связи окончена ¦14 ¦
¦(SHUTDOWN COMPLETE) ¦ ¦
+-------------------------------------------------------+--------+
¦Зарезервировано ¦12 - 13,¦
¦ ¦15 - 255¦
L-------------------------------------------------------+---------
8.9.7.1. Пакет SCTP должен содержать в себе только одну команду
в случаях, когда должны передаваться команды INIT, INIT ACK,
SHUTDOWN COMPLETE.
8.9.8. Формат команды SCTP должен соответствовать разделу 3.2
документа RFC 2960, рисунку 8.3 и таблице 8.22.
-----------------------T----------------T------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+----------------+------------------------+
¦ Данные команды ¦
L-----------------------------------------------------------------
Рисунок 8.3. Формат порции данных
Таблица 8.22
ПОЛЯ КОМАНДЫ SCTP
-------T----------------------------------------T----------------¬
¦N поля¦ Название поля ¦Длина поля, бит ¦
+------+----------------------------------------+----------------+
¦1 ¦Код команды ¦8 ¦
+------+----------------------------------------+----------------+
¦2 ¦Флаги ¦8 ¦
+------+----------------------------------------+----------------+
¦3 ¦Длина данных команды ¦16 ¦
+------+----------------------------------------+----------------+
¦4 ¦Данные команды ¦Переменная длина¦
L------+----------------------------------------+-----------------
8.9.8.1. Функции кодирования/декодирования полей команды SCTP
должны соответствовать следующим требованиям:
а) поле "Код команды" должно принимать численное значение в
соответствии с таблицей 8.22. При этом старшие два бита данного
поля должны соответствовать следующей таблице:
-----T-----------------------------------------------------------¬
¦Биты¦ Действия получателя команды ¦
+----+-----------------------------------------------------------+
¦00 ¦Отбросить пакет SCTP, прекратив его обработку и всех ¦
¦ ¦содержащихся в нем команд ¦
+----+-----------------------------------------------------------+
¦01 ¦Отбросить пакет SCTP, прекратив его обработку и всех ¦
¦ ¦содержащихся в нем команд. Уведомить отправителя командой ¦
¦ ¦ERROR или INIT ACK с кодом ошибки "неподдерживаемый ¦
¦ ¦параметр" ¦
+----+-----------------------------------------------------------+
¦10 ¦Пропустить данную команду и продолжить обработку остальных ¦
¦ ¦в штатном режиме ¦
+----+-----------------------------------------------------------+
¦11 ¦Пропустить данную команду и продолжить обработку остальных ¦
¦ ¦в штатном режиме. Уведомить отправителя командой ERROR ¦
¦ ¦с кодом ошибки "неподдерживаемая команда" ¦
L----+------------------------------------------------------------
б) поле "Флаги" должно содержать значения, специфичные для
разных команд, при этом по умолчанию поле должно принимать
значение, равное нулю;
в) поле "Длина данных команды" должно содержать длину в байтах
поля "Данные команды";
г) поле "Данные команды" должно содержать информацию,
специфичную для разных команд SCTP.
8.9.8.2. Поле "Данные команды" должно быть кратно четырем
байтам, в противном случае необходимо дополнять данные незначащими
байтами до необходимой длины.
8.9.9. Формат команды "Данные пользователя" (DATA) должен
соответствовать разделу 3.3.1 документа RFC 2960 и рисунку 8.4.
-----------------T----------T---T-----T-----T--------------------¬
¦ Код команды ¦ Резерв ¦ U ¦ B ¦ E ¦Длина данных команды¦
+----------------+----------+---+-----+-----+--------------------+
¦ Идентификатор соответствия TSN ¦
+------------------------------T---------------------------------+
¦ Идентификатор потока TCP ¦ Порядковый номер в потоке TCP ¦
+------------------------------+---------------------------------+
¦ Идентификатор протокола верхнего уровня ¦
+----------------------------------------------------------------+
¦ Данные ¦
L-----------------------------------------------------------------
Рисунок 8.4. Формат команды "Данные пользователя"
8.9.9.1. Форматы полей команды "Данные пользователя" должны
соответствовать таблице 8.23.
Таблица 8.23
ПОЛЯ КОМАНДЫ "ДАННЫЕ ПОЛЬЗОВАТЕЛЯ"
-------T----------------------------------------T----------------¬
¦N поля¦ Название поля ¦Длина поля, бит ¦
+------+----------------------------------------+----------------+
¦1 ¦Код команды ¦8 ¦
+------+----------------------------------------+----------------+
¦2 ¦Резерв ¦5 ¦
+------+----------------------------------------+----------------+
¦3 ¦U-бит ¦1 ¦
+------+----------------------------------------+----------------+
¦4 ¦В-бит ¦1 ¦
+------+----------------------------------------+----------------+
¦5 ¦E-бит ¦1 ¦
+------+----------------------------------------+----------------+
¦6 ¦Длина данных команды ¦16 ¦
+------+----------------------------------------+----------------+
¦7 ¦Идентификатор соответствия TSN ¦32 ¦
+------+----------------------------------------+----------------+
¦8 ¦Идентификатор потока TCP ¦16 ¦
+------+----------------------------------------+----------------+
¦9 ¦Порядковый номер в потоке TCP ¦16 ¦
+------+----------------------------------------+----------------+
¦10 ¦Идентификатор протокола верхнего уровня ¦32 ¦
+------+----------------------------------------+----------------+
¦11 ¦Данные ¦Переменная длина¦
L------+----------------------------------------+-----------------
8.9.9.2. Функции кодирования/декодирования полей команды
"Данные пользователя" должны соответствовать следующим
требованиям:
а) поле "Код команды" должно принимать значение "0";
б) поле "Резерв" должно принимать значение "0";
в) поле "U-бит", установленное в "1", означает, что команды
передаются в неупорядоченном порядке и должны передаваться в
приложения верхнего уровня без обработки;
г) поле "В-бит" должно принимать значение "1" в случаях
передачи команды в нескольких фрагментах, передаваемых по
отдельности. Значение "1" должно устанавливаться только в первом
фрагменте;
д) поле "Е-бит" должно принимать значение "1" в последнем
фрагменте;
е) поле "Длина данных команды" должно содержать количество байт
данных команды от поля "Код команды" включительно до конца
команды;
ж) поле "Идентификатор соответствия TSN" должно содержать
значение, однозначно идентифицирующее пару команд "запрос-ответ";
з) поле "Идентификатор потока TCP" должно содержать значение,
однозначно идентифицирующее сессию TCP, в которой передается пакет
SCTP;
и) поле "Порядковый номер в потоке TCP" должно содержать
значение, определяющее порядок следования пакетов SCTP;
к) поле "Идентификатор протокола верхнего уровня" должно
содержать значение, определяющее тип информации, передаваемой
приложениям верхнего уровня (MTP2, MTP3, ОКС N 7 и пр.);
л) поле "Данные" содержит информацию протоколов верхнего
уровня.
8.9.10. Формат команды "Создание сеанса связи" (INIT) должен
соответствовать разделу 3.3.2 документа RFC 2960 и рисунку 8.5.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+--------------+--------------------------+
¦ Метка верификации ¦
+----------------------------------------------------------------+
¦ Размер окна приемника ¦
+--------------------------------T-------------------------------+
¦ Количество исходящих сессий ¦ Количество входящих сессий ¦
+--------------------------------+-------------------------------+
¦ Идентификатор соответствия TSN ¦
+----------------------------------------------------------------+
¦ Необязательные параметры ¦
L-----------------------------------------------------------------
8.9.10.1. Форматы полей команды "Создание сеанса связи" должны
соответствовать таблице 8.24.
Таблица 8.24
ПОЛЯ КОМАНДЫ "СОЗДАНИЕ СЕАНСА СВЯЗИ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Метка верификации ¦ О ¦32 ¦
+----+---------------------------+--------------+----------------+
¦5 ¦Размер окна приемника ¦ О ¦32 ¦
+----+---------------------------+--------------+----------------+
¦6 ¦Количество исходящих сессий¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦7 ¦Количество входящих сессий ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦8 ¦Идентификатор соответствия ¦ О ¦32 ¦
¦ ¦TSN ¦ ¦ ¦
+----+---------------------------+--------------+----------------+
¦9 ¦Необязательные параметры ¦ Н ¦Переменная длина¦
L----+---------------------------+--------------+-----------------
8.9.10.2. Функции кодирования/декодирования полей команды
"Создание сеанса связи" должны соответствовать следующим
требованиям:
а) поле "Код команды" должно принимать значение "1";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) требования к функциям кодирования/декодирования поля "Длина
данных команды" должны соответствовать пункту 8.9.9.2 "е";
г) поле "Метка верификации" должно принимать значение,
выбранное случайным образом, которое используется для однозначного
сопоставления пакетов SCTP, относящихся к одному сеансу связи
(пункт 8.9.6 "в");
д) поле "Размер окна приемника" должно содержать длину буфера
для приема и обработки пакетов SCTP;
е) поле "Количество исходящих сессий" должно содержать
количество исходящих сессий, создаваемых в течение данного сеанса
связи;
ж) поле "Количество входящих сессий" должно содержать
количество сессий, которое отправитель данной команды в состоянии
обработать;
з) поле "Идентификатор соответствия TSN" должно содержать
числовое значение, выбранное случайным образом, от которого
начнется отсчет значений, позволяющих определять пару "запрос-
ответ";
и) поле "Необязательные параметры" является необязательным и
может содержать вспомогательные или уточняющие данные.
8.9.11. Формат команды "Подтверждение создания сеанса связи"
(INIT ACK) должен соответствовать разделу 3.3.3 документа RFC 2960
и рисунку 8.6.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+--------------+--------------------------+
¦ Метка верификации ¦
+----------------------------------------------------------------+
¦ Размер окна приемника ¦
+--------------------------------T-------------------------------+
¦ Количество исходящих сессий ¦ Количество входящих сессий ¦
+--------------------------------+-------------------------------+
¦ Идентификатор соответствия TSN ¦
+----------------------------------------------------------------+
¦ Необязательные параметры ¦
L-----------------------------------------------------------------
Рисунок 8.6. Формат команды
"Подтверждение создания сеанса связи"
8.9.11.1. Форматы полей команды "Подтверждение создания сеанса
связи" должны соответствовать таблице 8.25.
Таблица 8.25
ПОЛЯ КОМАНДЫ "ПОДТВЕРЖДЕНИЕ СОЗДАНИЯ СЕАНСА СВЯЗИ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Метка верификации ¦ О ¦32 ¦
+----+---------------------------+--------------+----------------+
¦5 ¦Размер окна приемника ¦ О ¦32 ¦
+----+---------------------------+--------------+----------------+
¦6 ¦Количество исходящих сессий¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦7 ¦Количество входящих сессий ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦8 ¦Идентификатор соответствия ¦ О ¦32 ¦
¦ ¦TSN ¦ ¦ ¦
+----+---------------------------+--------------+----------------+
¦9 ¦Необязательные параметры ¦ Н ¦Переменная длина¦
L----+---------------------------+--------------+-----------------
8.9.11.2. Функции кодирования/декодирования полей команды
"Подтверждение создания сеанса связи" должны соответствовать
следующим требованиям:
а) поле "Код команды" должно принимать значение "2";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) требования к функциям кодирования/декодирования поля "Длина
данных команды" должны соответствовать пункту 8.9.9.2 "е";
г) поле "Метка верификации" должно принимать значение, равное
значению поля "Метка верификации" команды "Создание сеанса связи"
(пункт 8.9.10.2 "г");
д) требования к функциям кодирования/декодирования поля "Размер
окна приемника" должны соответствовать пункту 8.9.10.2 "д";
е) требования к функциям кодирования/декодирования поля
"Количество исходящих сессий" должны соответствовать пункту
8.9.10.2 "е";
ж) требования к функциям кодирования/декодирования поля
"Количество входящих сессий" должны соответствовать пункту
8.9.10.2 "ж";
з) требования к функциям кодирования/декодирования поля
"Идентификатор соответствия TSN" должны соответствовать пункту
8.9.10.2 "з";
и) требования к функциям кодирования/декодирования поля
"Необязательные параметры" должны соответствовать пункту 8.9.10.2
"и".
8.9.12. Команда "Выборочное подтверждение" служит для
детального информирования удаленного устройства о произошедших
сбоях в передаче пакетов SCTP. Формат команды "Выборочное
подтверждение" (SACK) должен соответствовать разделу 3.3.4
документа RFC 2960 и рисунку 8.7.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+--------------+--------------------------+
¦ Идентификатор соответствия TSN последней команды ¦
+----------------------------------------------------------------+
¦ Размер окна приемника ¦
+--------------------------------T-------------------------------+
¦ Количество блоков ¦ Количество блоков ¦
¦ пропущенных пакетов ¦ дублированных пакетов ¦
+--------------------------------+-------------------------------+
¦ Первый пропущенный пакет ¦ Последний пропущенный ¦
¦ (блок 1) ¦ пакет (блок 1) ¦
+--------------------------------+-------------------------------+
¦ ... ¦
+--------------------------------T-------------------------------+
¦ Первый пропущенный пакет ¦ Последний пропущенный ¦
¦ (блок n) ¦ пакет (блок n) ¦
+--------------------------------+-------------------------------+
¦ Дублированный пакет 1 ¦
+----------------------------------------------------------------+
¦ ... ¦
+----------------------------------------------------------------+
¦ Дублированный пакет n ¦
L-----------------------------------------------------------------
Рисунок 8.7. Формат команды "Выборочное подтверждение"
8.9.12.1. Форматы полей команды "Выборочное подтверждение"
должны соответствовать таблице 8.26.
Таблица 8.26
ПОЛЯ КОМАНДЫ "ВЫБОРОЧНОЕ ПОДТВЕРЖДЕНИЕ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦ 16 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Идентификатор соответствия ¦ О ¦ 32 ¦
¦ ¦TSN последней команды ¦ ¦ ¦
+----+---------------------------+--------------+----------------+
¦5 ¦Размер окна приемника ¦ О ¦ 32 ¦
+----+---------------------------+--------------+----------------+
¦6 ¦Количество блоков ¦ Н ¦ 16 ¦
¦ ¦пропущенных пакетов ¦ ¦ ¦
+----+---------------------------+--------------+----------------+
¦7 ¦Количество блоков ¦ Н ¦ 16 ¦
¦ ¦дублированных пакетов ¦ ¦ ¦
+----+---------------------------+--------------+----------------+
¦8 ¦Пропущенный пакет ¦ Н ¦ 16 ¦
+----+---------------------------+--------------+----------------+
¦9 ¦Дублированный пакет ¦ Н ¦ 32 ¦
L----+---------------------------+--------------+-----------------
8.9.12.2. Функции кодирования/декодирования полей команды
"Подтверждение создания сеанса связи" должны соответствовать
следующим требованиям:
а) поле "Код команды" должно принимать значение "3";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) требования к функциям кодирования/декодирования поля "Длина
данных команды" должны соответствовать пункту 8.9.9.2 "е";
г) поле "Идентификатор соответствия TSN последней команды"
должно содержать значение идентификатора соответствия TSN
последней успешно принятой и обработанной команды;
д) требования к функциям кодирования/декодирования поля "Размер
окна приемника" должны соответствовать пункту 8.9.10.2 "д";
е) поле "Количество блоков пропущенных пакетов" должно
содержать количество передаваемых в данной команде блоков с
информацией о потерянных пакетах SCTP;
ж) поле "Количество блоков дублированных пакетов" должно
содержать количество передаваемых в данной команде SCTP блоков с
информацией о пакетах с идентичными идентификаторами TSN;
з) поле "Пропущенный пакет" должно содержать идентификаторы
соответствия TSN первого и последнего потерянного пакета SCTP;
и) поле "Дублированный пакет" должно содержать номер
идентификатора соответствия TSN пакетов SCTP, ошибочно переданных
с одинаковыми идентификаторами соответствия TSN.
8.9.13. Команда "Команда опроса состояния" служит для контроля
работоспособности получателя команды. Формат команды "Команда
опроса состояния" (HEARTBEAT) должен соответствовать разделу 3.3.5
документа RFC 2960 и рисунку 8.8.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+--------------+--------------------------+
¦ Необязательные параметры ¦
L-----------------------------------------------------------------
Рисунок 8.8. Формат команды "Команда опроса состояния"
8.9.13.1. Форматы полей команды "Команда опроса состояния"
должны соответствовать таблице 8.27.
Таблица 8.27
ПОЛЯ КОМАНДЫ "КОМАНДА ОПРОСА СОСТОЯНИЯ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Необязательные параметры ¦ Н ¦Переменная длина¦
L----+---------------------------+--------------+-----------------
8.9.13.2. Функции кодирования/декодирования полей команды
"Команда опроса состояния" должны соответствовать следующим
требованиям:
а) поле "Код команды" должно принимать значение "4";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) требования к функциям кодирования/декодирования поля "Длина
данных команды" должны соответствовать пункту 8.9.9.2 "е";
г) требования к функциям кодирования/декодирования поля
"Необязательные параметры" должны соответствовать пункту 8.9.10.2
"и".
8.9.14. Команда "Подтверждение состояния" (HEARTBEAT ACK)
служит для подтверждения работоспособности получателя команды
"Команда подтверждения состояния". Требования к функциям
кодирования/декодирования команды должны соответствовать
подразделу 8.9.13.
8.9.14.1. Поле "Код команды" (пункт 8.9.13.2 "а") должно
принимать значение "5".
8.9.15. Формат команды "Удаление сеанса связи" (ABORT) должен
соответствовать разделу 3.3.7 документа RFC 2960 и рисунку 8.9.
----------------------T----------T----------T--------------------¬
¦ Код команды ¦ Резерв ¦ Т ¦Длина данных команды¦
+---------------------+----------+----------+--------------------+
¦ Код ошибки ¦
L-----------------------------------------------------------------
Рисунок 8.9. Формат команды "Удаление сеанса связи"
8.9.15.1. Форматы полей команды "Удаление сеанса связи" должны
соответствовать таблице 8.28.
Таблица 8.28
ПОЛЯ КОМАНДЫ "УДАЛЕНИЕ СЕАНСА СВЯЗИ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Резерв ¦ О ¦7 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Т-бит ¦ О ¦1 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Длина данных команды ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦5 ¦Код ошибки ¦ Н ¦Переменная длина¦
L----+---------------------------+--------------+-----------------
8.9.15.2. Функции кодирования/декодирования полей команды
"Удаление сеанса связи" должны соответствовать следующим
требованиям:
а) поле "Код команды" должно принимать значение "6";
б) требования к функциям кодирования/декодирования поля
"Резерв" должны соответствовать пункту 8.9.9.2 "б";
в) поле "Т-бит" должно принимать значение "0" в случаях, когда
отправитель уже уничтожил в оперативной памяти устройства массив
данных, связанный с сеансом связи;
г) требования к функциям кодирования/декодирования поля "Длина
данных команды" должны соответствовать пункту 8.9.9.2 "е";
д) поле "Код ошибки" должно содержать причину удаления сеанса
связи.
8.9.16. Формат команды "Завершение сеанса связи" (SHUTDOWN)
должен соответствовать разделу 3.3.8 документа RFC 2960 и рисунку
8.10.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+--------------+--------------------------+
¦ Идентификатор соответствия TSN последней команды ¦
L-----------------------------------------------------------------
Рисунок 8.10. Формат команды "Завершение сеанса связи"
8.9.16.1. Форматы полей команды "Завершение сеанса связи"
должны соответствовать таблице 8.29.
Таблица 8.29
ПОЛЯ КОМАНДЫ "ЗАВЕРШЕНИЕ СЕАНСА СВЯЗИ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦ 16 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Идентификатор соответствия ¦ О ¦ 32 ¦
¦ ¦TSN последней команды ¦ ¦ ¦
L----+---------------------------+--------------+-----------------
8.9.16.2. Функции кодирования/декодирования полей команды
"Завершение сеанса связи" должны соответствовать следующим
требованиям:
а) поле "Код команды" должно принимать значение "7";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) поле "Длина данных команды" должно принимать значение "8";
г) поле "Идентификатор соответствия TSN последней команды"
должно содержать номер последней команды в буфере приема, которая
должна быть обработана до завершения сеанса связи.
8.9.17. Формат команды "Подтверждение завершения сеанса связи"
(SHUTDOWN ACK) должен соответствовать разделу 3.3.9 документа RFC
2960 и рисунку 8.11.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
L----------------------+--------------+---------------------------
Рисунок 8.11. Формат команды
"Подтверждение завершения сеанса связи"
8.9.17.1. Форматы полей команды "Подтверждение завершения
сеанса связи" должны соответствовать таблице 8.30.
Таблица 8.30
ПОЛЯ КОМАНДЫ "ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ СЕАНСА СВЯЗИ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦ 16 ¦
L----+---------------------------+--------------+-----------------
8.9.17.2. Функции кодирования/декодирования полей команды
"Подтверждение завершения сеанса связи" должны соответствовать
следующим требованиям:
а) поле "Код команды" должно принимать значение "8";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) поле "Длина данных команды" должно принимать значение "4".
8.9.18. Формат команды "Ошибка" (ERROR) должен соответствовать
разделу 3.3.10 документа RFC 2960 и рисунку 8.12.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+--------------+--------------------------+
¦ Код ошибки ¦
L-----------------------------------------------------------------
Рисунок 8.12. Формат команды "Ошибка"
8.9.18.1. Форматы полей команды "Ошибка" должны соответствовать
таблице 8.31.
Таблица 8.31
ПОЛЯ КОМАНДЫ "ОШИБКА"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Код ошибки ¦ О ¦Переменная длина¦
L----+---------------------------+--------------+-----------------
8.9.18.2. Функции кодирования/декодирования полей команды
"Ошибка" должны соответствовать следующим требованиям:
а) поле "Код команды" должно принимать значение "9";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) требования к функциям кодирования/декодирования поля "Длина
данных команды" должны соответствовать пункту 8.9.9.2 "е";
г) поле "Код ошибки" должно указывать на одно или несколько
сообщений об ошибке в соответствии со следующей таблицей:
-----------T-----------------------------------------------------¬
¦Код ошибки¦ Ошибка ¦
+----------+-----------------------------------------------------+
¦1 ¦Неправильный номер идентификатора потока TCP ¦
+----------+-----------------------------------------------------+
¦2 ¦Отсутствует обязательный параметр ¦
+----------+-----------------------------------------------------+
¦3 ¦Запрос устаревшей информации ¦
+----------+-----------------------------------------------------+
¦4 ¦Недостаточно ресурсов ¦
+----------+-----------------------------------------------------+
¦5 ¦Неизвестный адрес ¦
+----------+-----------------------------------------------------+
¦6 ¦Нераспознанная команда ¦
+----------+-----------------------------------------------------+
¦7 ¦Неправильный обязательный параметр ¦
+----------+-----------------------------------------------------+
¦8 ¦Неизвестный параметр ¦
+----------+-----------------------------------------------------+
¦9 ¦Отсутствуют данные протокола верхнего уровня ¦
+----------+-----------------------------------------------------+
¦10 ¦Попытка запроса информации в процессе завершения ¦
¦ ¦сеанса связи ¦
L----------+------------------------------------------------------
8.9.19. Создание сеанса связи осуществляется в два этапа.
Первый этап - начальная фаза соединения, реализуемая командами
"Создание сеанса связи" и "Подтверждение создания сеанса связи".
Второй этап - завершение процедуры создания соединения,
реализуемый командами "Завершение создания сеанса связи" (COOKIE
ECHO) и "Создание сеанса связи завершено" (COOKIE ACK). Формат
команды "Завершение создания сеанса связи" должен соответствовать
разделу 3.3.11 документа RFC 2960 и рисунку 8.13.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
+----------------------+--------------+--------------------------+
¦ Идентификатор дополнительной информации ¦
L-----------------------------------------------------------------
Рисунок 8.13. Формат команды
"Завершение создания сеанса связи"
8.9.19.1. Форматы полей команды "Завершение создания сеанса
связи" должны соответствовать таблице 8.32.
Таблица 8.32
ПОЛЯ КОМАНДЫ "ЗАВЕРШЕНИЕ СОЗДАНИЯ СЕАНСА СВЯЗИ"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦16 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Идентификатор ¦ О ¦Переменная длина¦
¦ ¦дополнительной информации ¦ ¦ ¦
L----+---------------------------+--------------+-----------------
8.9.19.2. Функции кодирования/декодирования полей команды
"Завершение создания сеанса связи" должны соответствовать
следующим требованиям:
а) поле "Код команды" должно принимать значение "10";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) требования к функциям кодирования/декодирования поля "Длина
данных команды" должны соответствовать пункту 8.9.9.2 "е";
г) поле "Идентификатор дополнительной информации" должно
содержать значение, аналогичное указываемому в поле
"Необязательные параметры" команды "Подтверждение создания сеанса
связи", для однозначного сопоставления команд, относящихся к
начальной и заключительной фазам создания сеанса связи.
8.9.20. Формат команды "Создание сеанса связи завершено" должен
соответствовать разделу 3.3.12 документа RFC 2960 и рисунку 8.14.
-----------------------T--------------T--------------------------¬
¦ Код команды ¦ Флаги ¦ Длина данных команды ¦
L----------------------+--------------+---------------------------
Рисунок 8.14. Формат команды
"Создание сеанса связи завершено"
8.9.20.1. Форматы полей команды "Создание сеанса связи
завершено" должны соответствовать таблице 8.33.
Таблица 8.33
ПОЛЯ КОМАНДЫ "СОЗДАНИЕ СЕАНСА СВЯЗИ ЗАВЕРШЕНО"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Флаги ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Длина данных команды ¦ О ¦ 16 ¦
L----+---------------------------+--------------+-----------------
8.9.20.2. Функции кодирования/декодирования полей команды
"Завершение создания сеанса связи" должны соответствовать
следующим требованиям:
а) поле "Код команды" должно принимать значение "11";
б) поле "Флаги" зарезервировано для будущего применения и
должно игнорироваться;
в) поле "Длина данных команды" должно содержать значение "4".
8.9.21. Формат команды "Процедура завершения сеанса связи
окончена" (SHUTDOWN COMPLETE) должен соответствовать разделу
3.3.13 документа RFC 2960 и рисунку 8.15.
----------------------T----------T----------T--------------------¬
¦ Код команды ¦ Резерв ¦ Т ¦Длина данных команды¦
L---------------------+----------+----------+---------------------
Рисунок 8.15. Формат команды
"Процедура завершения сеанса связи окончена"
8.9.21.1. Форматы полей команды "Процедура завершения сеанса
связи окончена" должны соответствовать таблице 8.34.
Таблица 8.34
ПОЛЯ КОМАНДЫ "ПРОЦЕДУРА ЗАВЕРШЕНИЯ СЕАНСА СВЯЗИ ОКОНЧЕНА"
-----T---------------------------T--------------T----------------¬
¦ N ¦ Название поля ¦Обязательность¦Длина поля, бит ¦
¦поля¦ ¦ поля ¦ ¦
+----+---------------------------+--------------+----------------+
¦1 ¦Код команды ¦ О ¦ 8 ¦
+----+---------------------------+--------------+----------------+
¦2 ¦Резерв ¦ О ¦ 7 ¦
+----+---------------------------+--------------+----------------+
¦3 ¦Т-бит ¦ О ¦ 1 ¦
+----+---------------------------+--------------+----------------+
¦4 ¦Длина данных команды ¦ О ¦ 16 ¦
L----+---------------------------+--------------+-----------------
8.9.21.2. Функции кодирования/декодирования полей команды
"Процедура завершения сеанса связи окончена" должны
соответствовать следующим требованиям:
а) поле "Код команды" должно принимать значение "14";
б) требования к функциям кодирования/декодирования поля
"Резерв" должны соответствовать пункту 8.9.9.2 "б";
в) поле "Т-бит" должно принимать значение "0" в случаях, когда
отправитель уже уничтожил в оперативной памяти устройства массив
данных, связанный с сеансом связи;
г) поле "Длина данных команды" должно принимать значение "4".
8.10. Требования к реализации протоколов цифровой абонентской
сигнализации DSS1
Цифровая абонентская сигнализация на сетевом уровне должна
соответствовать пункту 6.9 [4].
8.11. Требования к реализации протокола сигнализации ОКС N 7
8.11.1. Оборудование должно обеспечивать реализацию следующих
подсистем протокола сигнализации ОКС N 7:
- подсистемы передачи сообщений (MTP) для национальной сети
России (MTP-2000);
- подсистемы пользователей ЦСИС (ISUP) для национальной сети
России (ISUP-R-2000).
8.11.1.1. Подсистема передачи сообщений (MTP) для национальной
сети России (MTP-2000) должна соответствовать [26].
8.11.1.2. Подсистема пользователей ЦСИС (ISUP) для национальной
сети России (ISUP-R-2000) должна соответствовать [27].
9. Общие технические требования к Оборудованию,
реализующему функции гибкого коммутатора
9.1. Требования к конструкции
9.1.1. Оборудование может размещаться в стойке, на стене, на
столе и т.д.
9.1.2. Оборудование, предназначенное для установки на станции
коммутации, должно удовлетворять следующим требованиям:
- габариты Оборудования по ширине должны быть не более 600 мм;
- конструкция Оборудования должна обеспечивать независимое
функционирование различных систем, размещенных на одной стойке, и
допускать последующую доукомплектацию стойки разными типами
аппаратуры;
- конструкция Оборудования должна обеспечивать возможность его
обслуживания и ремонта без доступа к боковым стенкам;
- панель обслуживания, если она предусмотрена, должна
размещаться на стойках на высоте, обеспечивающей удобство
эксплуатации;
- в случае размещения на стойке одновременно основного и
вспомогательного Оборудования, ремонт или замена вспомогательного
Оборудования не должны изменять работоспособность основного;
- однотипные съемные блоки Оборудования должны быть
взаимозаменяемы;
- при размещении Оборудования в стойке ввод цепей основного
источника электропитания в комплекты Оборудования, относящиеся к
разным системам, должен быть раздельным;
- ввод цепей электропитания устройства сигнализации может быть
общим для всех комплексов Оборудования, размещенных на стойке;
- в верхней части стоек должен быть предусмотрен отдельный
вывод заземления;
- лицевые панели блоков, комплектов должны иметь надежное
заземление и выполнять функции электромагнитного экрана.
9.2. Требования к электропитанию
9.2.1. Электропитание Оборудования, размещаемого на узле,
должно осуществляться от первичного источника постоянного тока с
заземленным положительным полюсом.
9.2.2. Номинальное напряжение первичного источника постоянного
тока должно составлять 60, 48 или 24 В.
9.2.3. Допустимые пределы изменения напряжения первичного
источника постоянного тока должны составлять:
- при номинальном напряжении Uн = 60 В - от 48,0 до 72,0 В;
- при номинальном напряжении Uн = 48 В - от 38,4 до 57,6 В;
- при номинальном напряжении Uн = 24 В - от 19,2 до 28,8 В.
9.2.4. Во всех остальных случаях занижения или пропадания
напряжения первичного источника постоянного тока Оборудование
после восстановления напряжения должно восстанавливать заданные в
ТТ параметры без вмешательства обслуживающего персонала.
9.2.5. Допустимые напряжения пульсаций первичного источника
постоянного тока должны соответствовать величинам, указанным в
таблице 9.1.
Таблица 9.1
ДОПУСТИМЫЕ НАПРЯЖЕНИЯ ПУЛЬСАЦИЙ ПЕРВИЧНОГО ИСТОЧНИКА
--------------------T--------------------------------------------¬
¦ Диапазон частот ¦ Эффективное напряжение пульсаций, мВ ¦
¦ +-------------------------T------------------+
¦ ¦при номинале 60 или 48 В ¦при номинале 24 В ¦
+-------------------+-------------------------+------------------+
¦До 300 Гц ¦ 250 ¦ 100 ¦
+-------------------+-------------------------+------------------+
¦От 300 Гц до 20 кГц¦ 15 ¦ 10 ¦
+-------------------+-------------------------+------------------+
¦От 20 до 150 кГц ¦ 2,5 ¦ 1,5 ¦
+-------------------+-------------------------+------------------+
¦Псофометрическое ¦ 5 ¦ 5 ¦
L-------------------+-------------------------+-------------------
9.2.6. Допустимые одиночные импульсные изменения напряжения на
вводах первичного источника постоянного тока должны
соответствовать следующим значениям:
- при длительности импульса 0,4 с - +/- 0,2Uн;
- при длительности импульса 0,05 с - +/- 0,4Uн.
Каждое из указанных воздействий не должно вызывать появления
цифровых ошибок, коррелированных с этим воздействием, или
срабатывания устройств контроля и сигнализации.
9.2.7. Напряжение помех, создаваемое Оборудованием на вводах
первичного источника электропитания, не должно превышать значений,
приведенных в 9.2.5. Псофометрическое напряжение помех,
создаваемых Оборудованием, должно быть не более 2 мВ.
9.2.8. Кратковременные изменения напряжения на вводах питания
при включении аппаратуры или коротком замыкании в ней не должны
превышать значений, приведенных в 9.2.6.
Примечание. Напряжение помех по 9.2.7 и 9.2.8 измеряется при
подключении Оборудования к первичному источнику электропитания
постоянного тока через эквивалент токораспределительной сети
(емкость С = 2000 мкФ, подключенную параллельно первичному
источнику, и индуктивность L = 100 мкГн с сопротивлением R = 0,03
Ом, включенную последовательно в цепь питания).
9.2.9. Электропитание Оборудования, размещаемого вне станции,
можно осуществлять:
- от источника постоянного тока согласно 9.2.1 - 9.2.8;
- от сети переменного тока с номинальным напряжением 220 В.
9.2.9.1. Допустимые параметры первичного источника (сети)
переменного тока должны составлять:
- напряжение - от 187 до 242 В;
- частота - от 47,5 до 50,5 Гц;
- коэффициент нелинейных искажений - не более 10%;
- кратковременное (длительностью до 3 с) изменение напряжения
относительно номинального значения - -/+ 40%;
- импульсные перенапряжения длительностью до 10 мкс - +/- 1000
В.
При питании от сети переменного тока желательно обеспечивать
возможность питания от резервированного источника постоянного
тока, продолжительность работы от которого (при коэффициенте
активного использования канала = 0,1) должна быть не менее 4 ч.
9.3. Требования по устойчивости и воздействию климатических и
механических факторов
9.3.1. Аппаратура, устанавливаемая в отапливаемых и
неотапливаемых помещениях, должна соответствовать требованиям
настоящих ТТ при температуре 40 -С и после пребывания при
температуре 50 -С.
9.3.2. Аппаратура, устанавливаемая в отапливаемых помещениях,
должна соответствовать требованиям настоящих ТТ при температуре 5
-С и после пребывания при температуре минус 50 -С.
9.3.3. Аппаратура, устанавливаемая в неотапливаемых помещениях,
должна соответствовать требованиям настоящих ТТ при температуре
минус 40 -С и после пребывания при температуре минус 50 -С.
9.3.4. Аппаратура должна сохранять свои параметры при рабочих
температурах при изменении напряжения первичного источника
электропитания в допустимых пределах.
9.3.5. Аппаратура, устанавливаемая в отапливаемых помещениях,
должна соответствовать требованиям настоящих ТТ при воздействии
повышенной влажности до 80% при температуре 25 -С.
9.3.6. Аппаратура, устанавливаемая в неотапливаемых помещениях,
должна соответствовать требованиям настоящих ТТ при воздействии
повышенной влажности до 98% при температуре 25 -С. В случае
размещения аппаратуры в герметизированном контейнере указанное
требование должно выполняться при открытой крышке контейнера.
9.3.7. Аппаратура должна соответствовать требованиям настоящих
ТТ при понижении атмосферного давления до 60 кПа (450 мм рт. ст.).
9.3.8. Аппаратура в упакованном виде должна соответствовать
требованиям настоящих ТТ после воздействия пониженного
атмосферного давления 12 кПа (90 мм рт. ст.) при температуре минус
50 -С.
9.3.9. По прочности при транспортировании в упакованном виде
комплекс аппаратуры должен удовлетворять требованиям, приведенным
в таблице 9.2.
Таблица 9.2
ТРЕБОВАНИЯ К ПРОЧНОСТИ ПРИ ТРАНСПОРТИРОВАНИИ
-----------T--------------T-----------------------T--------------¬
¦Количество¦Пиковое уско- ¦ Время воздействия ¦Частота ударов¦
¦ ударов ¦рение, в ед. g¦ударного ускорения, мс ¦ в минуту ¦
+----------+--------------+-----------------------+--------------+
¦ Вертикальная нагрузка ¦
+----------T--------------T-----------------------T--------------+
¦2000 ¦15 ¦5 - 10 ¦200 ¦
+----------+--------------+-----------------------+--------------+
¦8800 ¦10 ¦5 - 10 ¦200 ¦
+----------+--------------+-----------------------+--------------+
¦ Горизонтальная нагрузка ¦
+----------T--------------T-----------------------T--------------+
¦200 ¦12 ¦2 - 15 ¦200 ¦
+----------+--------------+-----------------------+--------------+
¦ Горизонтальная поперечная нагрузка ¦
+----------T--------------T-----------------------T--------------+
¦200 ¦12 ¦2 - 15 ¦200 ¦
L----------+--------------+-----------------------+---------------
9.3.10. Аппаратура не должна содержать узлы и конструктивные
элементы с резонансом в диапазоне частот от 5 до 25 Гц.
9.3.11. Аппаратура должна быть работоспособной и сохранять
параметры после воздействия амплитуды виброускорения 2g в течение
30 мин. на частоте 25 Гц.
9.4. Требования по надежности аппаратуры
В технических условиях должны быть указаны следующие показатели
надежности:
- среднее время наработки на отказ;
- среднее время восстановления после отказа;
- срок службы.
9.5. Требования по электромагнитной совместимости и защите от
опасных и мешающих влияний
9.5.1. В зависимости от места размещения аппаратуры напряжения
радиопомех, создаваемых аппаратурой, должны соответствовать
требованиям норм 9-93, норм 8-95, ГОСТ 30428, ГОСТ Р 51318.22-99
(СИС ПР 22-97).
9.5.2. Общее несимметричное напряжение радиопомех, создаваемых
аппаратурой на зажимах для подключения ее к сети электропитания
(на сетевых зажимах), не должно превышать значений, указанных в
таблице 9.3.
Таблица 9.3
ОБЩЕЕ НЕСИММЕТРИЧНОЕ НАПРЯЖЕНИЕ РАДИОПОМЕХ
----------------T------------------------------------------------¬
¦Полоса частот, ¦ Напряжение радиопомех, Uс, дБмкВ ¦
¦ МГц +-----------------------------T------------------+
¦ ¦ квазипиковое значение ¦ среднее значение ¦
+---------------+------------------------T----+-------------T----+
¦От 0,15 до 0,5 ¦{66 - 19,1 x lgF / 0,15}¦79* ¦{56 - 19,1 х ¦66* ¦
¦ ¦ ¦ ¦lgF / 0,15} ¦ ¦
+---------------+------------------------+----+-------------+----+
¦От 0,5 до 5 ¦56 ¦73* ¦46 ¦60* ¦
+---------------+------------------------+----+-------------+----+
¦От 5 до 30 вкл.¦60 ¦73* ¦50 ¦60* ¦
+---------------+------------------------+----+-------------+----+
¦ Примечания. 1. Все значения указаны в дБ относительно¦
¦напряжения 1 мкВ (0 дБ). ¦
¦ 2. F - частота измерений, МГц. ¦
¦ 3. Значения, отмеченные знаком "*", допустимы для аппаратуры,¦
¦устанавливаемой вне жилых домов и не подключенной к¦
¦электрическим сетям жилых домов. ¦
L-----------------------------------------------------------------
9.5.3. Общее несимметричное напряжение радиопомех Uп,
создаваемых на зажимах аппаратуры для подключения к 2- и 4-
проводным симметричным линиям связи, выходящим за границу объекта,
не должно превышать значений, указанных в таблице 9.4.
Таблица 9.4
ОБЩЕЕ НЕСИММЕТРИЧНОЕ НАПРЯЖЕНИЕ РАДИОПОМЕХ
------------T----------------------------------------------------¬
¦ Полоса ¦ Напряжение радиопомех, Uс, дБмкВ ¦
¦частот, Мгц+-------------------------T--------------------------+
¦ ¦ квазипиковое значение ¦ среднее значение ¦
+-----------+-------------------------+--------------------------+
¦От 0,15 ¦{84 - 19,1 x lgF / 0,15} ¦{56 - 19,1 x lgF / 0,15) ¦
¦до 0,5 ¦{97 - 19,1 x lgF / 0,15}*¦{84 - 18,1 x lgF / 0,15)* ¦
+-----------+-------------------------+--------------------------+
¦От 5 до ¦74 87*¦64 70*¦
¦30 вкл. ¦ ¦ ¦
+-----------+-------------------------+--------------------------+
¦ Примечания. 1. Все значения указаны в дБ относительно¦
¦напряжения 1 мкВ (0 дБ). ¦
¦ 2. F - частота измерений, МГц. ¦
¦ 3. Значения, отмеченные знаком "*", допустимы для аппаратуры,¦
¦устанавливаемой вне жилых домов и не подключенной к¦
¦электрическим сетям жилых домов. ¦
L-----------------------------------------------------------------
9.5.4. Квазипиковое значение напряженности поля радиопомех на
расстоянии 3 м от корпуса аппаратуры не должно превышать значений,
указанных в таблице 9.5.
Таблица 9.5
КВАЗИПИКОВОЕ ЗНАЧЕНИЕ НАПРЯЖЕННОСТИ ПОЛЯ РАДИОПОМЕХ
--------------------T--------------------------------------------¬
¦Полоса частот, МГц ¦ Напряжение поля радиопомех, дБмкВ/м ¦
+-------------------+--------------------------------------------+
¦От 30 до 230 ¦40 ¦
+-------------------+--------------------------------------------+
¦От 230 до 1000 ¦47 ¦
+-------------------+--------------------------------------------+
¦ Примечания. 1. Все значения указаны в дБ относительно¦
¦напряжения 1 мкВ (0 дБ). ¦
¦ 2. Для аппаратуры, устанавливаемой вне жилых домов,¦
¦напряженность поля радиопомех измеряется на расстоянии 10 м¦
¦от корпуса аппаратуры. ¦
L-----------------------------------------------------------------
9.6. Требования к маркировке аппаратуры
В соответствии с ОСТ 45.02 аппаратура должна иметь маркировку с
обозначением товарного знака, типа, децимального номера,
порядкового номера и года изготовления. На аппаратуре и в
техническом паспорте на аппаратуру должен быть нанесен знак
сертификата соответствия.
9.7. Требования к упаковке аппаратуры
Упаковка аппаратуры должна обеспечивать выполнение требований
по транспортированию и хранению в соответствии с ТТ. На
упаковочной таре должен быть нанесен знак сертификата
соответствия.
10. Требования по безопасности персонала
10.1. Предельно допустимое значение плотности потока энергии
электромагнитного поля на рабочих местах персонала в диапазоне
частот 300 МГц...300 ГГц должно быть не более 10 мкВт/кв. см в
соответствии с СанПиН 2.2.4/2.1.8.055-96.
10.2. Должна отсутствовать опасность повреждения об острые углы
и края аппаратуры; в аппаратуре не должны применяться материалы,
вредные для здоровья.
10.3. Токоведущие элементы должны быть защищены от случайного
прикосновения.
10.4. Величина сопротивления между клеммой защитного заземления
и любой металлической нетоковедущей частью аппаратуры, доступной
для прикосновения, не должна превышать 0,1 Ом.
10.5. Аппаратура должна соответствовать требованиям пожарной
безопасности в производственных помещениях по ГОСТ 12.1.004.
10.6. Должна быть исключена возможность воспламенения
аппаратуры при случайном замыкании в цепях питания и при
неправильном включении полярности электропитания.
10.7. Сопротивление изоляции для цепей первичного питания по
отношению к каркасу должно быть, МОм, не менее:
- в нормальных климатических условиях - 20;
- при повышенной температуре - 5;
- при повышенной влажности - 1.
10.8. Изоляция относительно корпуса незаземленных цепей
первичного электропитания с номинальным напряжением до 60 В должна
выдерживать испытания, Впик, постоянного тока:
- в нормальных климатических условиях, В, - 500;
- в условиях повышенной влажности, В, - 300.
10.9. Изоляция линейных цепей (относительно корпуса) и цепей
электропитания 220 В (относительно корпуса) должна выдерживать при
нормальных климатических условиях без пробоя в течение 1 мин.
напряжение постоянного тока не менее 1,5 кВ.
10.10. Напряжение на эквивалентном сопротивлении, В, не более:
- в течение 0,35 с после касания - 3;
- в течение 1 с после касания - 2;
- более 1 с после касания - 4.
10.11. На корпусах Оборудования, в которых имеется опасное
напряжение, должен быть нанесен предупредительный знак о наличии
опасного электрического напряжения.
10.12. В инструкции по монтажу, настройке и эксплуатации должны
быть указаны дополнительные организационные и технические
мероприятия, обеспечивающие безопасную эксплуатацию аппаратуры и
линейных сооружений при наличии ДП в соответствии с [28] и [29].
11. Требования по транспортированию и хранению
11.1. Аппаратура в упакованном виде должна выдерживать
транспортирование при температуре от минус 50 -С до плюс 50 -С и
относительной влажности до 100% при 25 -С.
11.2. Аппаратура в упакованном виде должна выдерживать хранение
в течение года в складских неотапливаемых помещениях при
температуре от минус 50 -С до плюс 40 -С, при среднемесячном
значении относительной влажности 80% при температуре плюс 20 -С,
допускается кратковременное повышение влажности до 98% при
температуре не более 25 -С без конденсации влаги, но суммарно не
более 1 месяца в год.
12. Требования к документации на аппаратуру
12.1. Документация должна быть достаточной для изучения
принципов работы составных частей и всего комплекса аппаратуры, ее
настройки и обслуживания.
12.2. В состав комплекта документации на русском языке должны
быть включены:
- руководство по установке и монтажу;
- руководство по эксплуатации.
13. Требования к методам контроля аппаратуры
13.1. Все испытания, если их режим не оговорен дополнительно,
проводятся при номинальном напряжении электропитания в нормальных
климатических условиях (НКУ):
- температура окружающего воздуха, -С, - 25 +/- 10;
- относительная влажность воздуха, %, - 45...80;
- атмосферное давление, кПа (мм рт. ст.), - 84...107
(630...880).
13.2. При температуре 30 -С и выше относительная влажность
воздуха не должна быть более 70%.
13.3. Проверка осуществляется по методикам, принятым на заводе-
изготовителе, а также в соответствии с методиками измерений
электрических параметров.
14. Указания по эксплуатации аппаратуры
14.1. Эксплуатация аппаратуры должна осуществляться в
соответствии с руководством по эксплуатации.
14.2. Оборудование не требует проведения профилактических работ
и постоянного присутствия эксплуатационного персонала.
15. Гарантии изготовителя
15.1. Предприятие-изготовитель должно гарантировать
соответствие качества аппаратуры требованиям технических условий.
15.2. Гарантийный срок должен быть не менее 12 месяцев с
момента ввода в действие аппаратуры, но не более 18 месяцев со дня
поставки. В контракте на поставку аппаратуры указанные сроки могут
быть изменены по обоюдному согласию.
15.3. В течение гарантийного срока предприятие-изготовитель
производит безвозмездную замену или ремонт аппаратуры. Гарантии не
распространяются на дефекты, возникающие вследствие
некомпетентного обращения, обслуживания, хранения и
транспортирования.
15.4. Состав ЗИП и условия их поставки в течение срока службы
аппаратуры должны оговариваться в контракте.
Приложение А
(справочное)
БИБЛИОГРАФИЯ
[1] Документ международного консорциума
"Эталонная архитектура, июнь 2002, версия
1.2" (International Softswitch Consortium
"Reference Architecture, June 2002,
v 1.2")
[2] РД 45.079-99 "Оборудование связи,
реализующее функции совмещенного узла
коммутации и управления услугами SSCP
платформы интеллектуальной сети связи.
Общие технические требования"
[3] РД 45.129-2000 "Телематические службы"
[4] РД 45.046-99. Аппаратура связи,
реализующая функции передачи речевой
информации по сетям передачи данных с
протоколом IP. Технические требования
[5] РД 45.176-2001. Аппаратура связи,
реализующая функции коммутации кадров в
локальной сети на уровне звена данных.
Технические требования
[6] Рекомендация Электрические характеристики
МСЭ-Т V.10 несимметричных цепей стыка, работающих
двухполюсным током на номинальных
скоростях передачи данных до 100 кбит/с.
(Electrical characteristics for
unbalanced double-current interchange
circuits operating at data signalling
rates nominally up to 100 kbit/s)
[7] Рекомендация Электрические характеристики
МСЭ-Т V.11 симметричных цепей стыка, работающих
двухполюсным током на скоростях
передачи данных до 10 Мбит/с (Electrical
characteristics for balanced
double-current interchange circuits
operating at data signalling rates up to
10 Mbit/s)
[8] Рекомендация Перечень определений цепей стыка между
МСЭ-Т V.24 оконечным оборудованием данных (ООД) и
аппаратурой окончания канала данных (АКД)
(List of definitions for interchange
circuits between data terminal equipment
(DTE) and data circuit-terminating
equipment (DCE))
[9] Рекомендация Электрические характеристики
МСЭ-Т V.28 несимметричных цепей стыка, работающих
двухполюсным током (Electrical
characteristics for unbalanced
double-current interchange circuits)
[10] Рекомендация Физические и электрические характеристики
МСЭ-Т G.703 интерфейсов цифровой иерархии
(Physical/electrical characteristics of
hierarchical digital interfaces)
[11] Рекомендация Управление джитером и отклонением в
МСЭ-Т G.825 сетях, базирующихся на синхронной
цифровой иерархии (The control of jitter
and wander within digital networks which
are based on the synchronous digital
hierarchical)
[12] Рекомендация Интерфейс между оконечным оборудованием
МСЭ-Т Х.21 данных и аппаратурой окончания канала
данных для синхронных действий в сетях
данных общего пользования (Interface
between Data Terminal equipment and Data
Circuit-terminating Equipment for
synchronous operation on public data
networks)
[13] Рекомендация Использование в сетях данных общего
МСЭ-Т Х.21bis пользования оконечного оборудования
данных, разработанного для
взаимодействия с синхронными модемами
V-серии (Use on public data networks of
Data Terminal equipment which designed
for interfacing to synchronous V-Series
modems)
[14] Общие технические требования на средства
связи для подключения к ЦСИО. Утверждены
Министерством связи Российской Федерации
28 мая 1997 г.
[15] РД 45.059-99. Аппаратура и системы
передачи синхронной цифровой иерархии.
Технические требования
[16] РД 45.080-99. Аппаратура цифровых систем
передачи абонентского доступа.
Технические требования
[17] Технические требования к аппаратуре
связи, реализующей функции маршрутизации
пакетов протокола межсетевого обмена
(аппаратура маршрутизации пакетов IP).
Редакция 1-1998 г., утверждены
Госкомсвязи России 6 августа 1998 г.
[18] Средства технические телематических
служб. Протокол SIP. Общие технические
требования. Редакция 1 - 2002, утверждены
Министерством Российской Федерации по
связи и информатизации 3 июля 2002 г.
[19] IETF RFC 2705 Протокол управления шлюзами MG (MGCP),
версия 1.0bis (Media Gateway Control
Protocol (MGCP), Version 1.0bis)
[20] IETF RFC 821 Протокол передачи простых почтовых
сообщений (Simple Mail Transfer
protocol)
[21] IETF RFC 3015 Протокол Megaco, версия 1.0 (Megaco
Protocol, Version 1.0)
[22] Рекомендация Протоколы сигнализации и разбиение
МСЭ-Т Н.225.0 данных на пакеты в системах мультимедиа
(Call signaling protocols and media
stream packetization for packet based
multimedia communication systems)
[23] IETF RFC 2719 Основные принципы архитектуры
транспортной системы передачи
информации сигнализации (Framework
Architecture for Signaling Transport)
[24] IETF RFC 2960 Протокол управления потоком при передаче
(Stream Control Transmission Protocol)
[25] IEFT RFC 768 Протокол дейтаграмм пользователя (User
Datagram Protocol)
[26] Рекомендация Цифровая абонентская сигнализация N 1
МСЭ-Т Q.931 (ЦАС 1). Спецификация уровня 3 интерфейса
пользователь-сеть в ЦСИС для управления
базовым вызовом (Digital Subscriber
Signalling System No. one (DSS1) - ISDN
user-network interface layer 3
specification for basic call control)
[27] РД 45.217-2001 "Технические спецификации
ОКС 7. Книга 1. Подсистема передачи
сообщений (МТР) для национальной сети
России (МТР-2000)"
[28] РД 45.217-2001 "Технические спецификации
ОКС 7. Книга 1. Подсистема пользователя
ЦСИС (ISUP) для национальной сети России
(ISUP-R-2000)"
[29] Правила техники безопасности при
эксплуатации электроустановок
потребителей. 4-е издание, переработанное
и дополненное (с изменениями). Москва,
1997
[30] Правила эксплуатации электроустановок
потребителей. 5-е издание, переработанное
и дополненное (с изменениями). Москва,
Госэнергонадзор, 1994
|
