РУКОВОДЯЩИЙ ДОКУМЕНТ ОТРАСЛИ

ОБОРУДОВАНИЕ СВЯЗИ, РЕАЛИЗУЮЩЕЕ
ФУНКЦИИ ГИБКОГО КОММУТАТОРА

(Softswitch)

Технические требования

 

РД 45.333-2002

 

 

ЦНТИ «Информсвязь»

Москва - 2003

 

РД 45.333-2002

ОБОРУДОВАНИЕ СВЯЗИ, РЕАЛИЗУЮЩЕЕ ФУНКЦИИ ГИБКОГО
КОММУТАТОРА (Softswitch).

Технические требования

 

 

Предисловие

1 РАЗРАБОТАН Федеральным государственным учреждением «Центр научных исследований и экспертизы в области связи»

ВНЕСЕН Департаментом электросвязи Министерства Российской Федерации по связи и информатизации

2 УТВЕРЖДЕН Первым заместителем Министра Российской Федерации по связи и информатизации Б.Д. Антонюком

3 ВВЕДЕН В ДЕЙСТВИЕ информационным письмом № БА-П3-4619 от 30.06.2003

4 ВВЕДЕН ВПЕРВЫЕ

 

СОДЕРЖАНИЕ

РД 45.333-2002

Оборудование связи, реализующее функции
гибкого коммутатора (Softswitch)

Дата введения 2003-30-06

1 Область применения

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

Настоящий руководящий документ устанавливает характеристики Оборудования, определяющие требования к сетевым интерфейсам и протоколам, необходимые для обеспечения совместимости оборудования различных производителей, а также общие требования, принятые на ВСС России для аппаратуры связи. При этом регламентируются только функции Оборудования, а способы их технической реализации не ограничиваются.

Не все функции, содержащиеся в данных технических требованиях (ТТ), обязательны для Оборудования данного типа, но если они выполняются, то их реализация должна соответствовать данным ТТ.

2 Нормативные ссылки

В настоящем руководящем документе использованы ссылки на следующие нормативные документы:

ГОСТ 12.1.004-91 ССБТ. Пожарная безопасность. Общие требования

ГОСТ Р 51318.22-99 Совместимость технических средств электромагнитная. Радиопомехи индустриальные от оборудования информационной техники. Нормы и методы испытаний

ГОСТ 30428-96 Совместимость технических средств электромагнитная. Радиопомехи индустриальные от аппаратуры проводной связи. Нормы и методы испытаний

OCT 45.02-97 Отраслевая система сертификации. Знак соответствия. Порядок маркирования технических средств электросвязи

Нормы 8-95 Общесоюзные нормы допускаемых индустриальных радиопомех. Электроустройства, эксплуатируемые вне жилых домов и не связанные с их электрической сетью. Предприятия (объекты) на выделенных территориях или в отдельных зданиях. Допускаемые величины. Методы испытаний

Нормы 9-93 Радиопомехи индустриальные. Аппаратура проводной связи. Нормы и методы испытаний

3 Обозначения и сокращения

АКД                Аппаратура окончания канала данных

АЛ                  Абонентская линия

ИСС                Интеллектуальная сеть связи

ОКС № 7        Общеканальная система сигнализации № 7

ПД                  Передача данных

ПЦИ               Плезиохронная цифровая иерархия

СТф                Стык телефонный

СЦИ                Синхронная цифровая иерархия

ТфОП             Телефонная сеть общего пользования

УПАТС          Учрежденческая производственная автоматическая телефонная станция

ЦСИС             Цифровая сеть с интеграцией служб

AS                   Application Server (сервер приложений)

BRI                 Basic Rate Interface (интерфейс на базовой скорости)

CDDI              Copper Distributed Data interface (проводной распределенный интерфейс передачи данных)

DSS1               Digital Subscriber Signalling System No. One (цифровая абонентская система сигнализации № 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 (узел коммутации услуг)

ТСАР              Transaction Capability Application Part (подсистема применения возможностей транзакции)

TCP                 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), реализующий функции взаимодействия устройств, входящих в состав гибкого коммутатора с сетью ОКС № 7;

- сервер приложений (AS - Application Server), реализующий функции создания управления и предоставления дополнительных видов обслуживания.

4.2 В зависимости от исполнения Оборудования, устройства, входящие в его состав, могут совмещать несколько функций из перечня, определенного в пункте 4.1. Взаимодействие отдельных устройств Оборудования осуществляться через сеть с коммутацией пакетов.

4.3 Устройства, входящие в состав Оборудования, могут быть реализованы как специализированное оборудование или на базе специализированного компьютера (например, сервер в промышленном исполнении), оснащенного соответствующими аппаратными или программными средствами.

Рисунок 4.1 - Структурная схема гибкого коммутатора

4.4 Оборудование имеет два вида интерфейсов:

- внутренние интерфейсы, предназначенные для взаимодействия устройств, входящих в его состав (интерфейсы 1 - 8);

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

4.5 К оборудованию могут подключаться следующие типы терминалов:

- аналоговый телефонный аппарат;

- персональный компьютер, оснащенный соответствующими средствами;

- специализированный абонентский терминал (IP-телефон).

4.6 К телефонной сети оборудование может подключаться по следующим интерфейсам и протоколам:

- по абонентским аналоговым интерфейсам;

- по абонентским цифровым интерфейсам ISDN PRI и ISDN BRI;

- по межсетевому интерфейсу ОКС № 7 с применением межсетевого экрана (firewall), входящего в состав ТфОП.

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

Таблица 4.1 - Интерфейсы и протоколы оборудования

4.9 Устройства, входящие в состав Оборудования, могут устанавливаться на объектах связи ВСС России.

5 Применение оборудования, реализующего функции гибкого коммутатора

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

- распределенный телефонный концентратор;

- транзитная станция коммутации и распределенный SSP;

- распределенная УПАТС;

- распределенный узел телематических служб.

5.2 Схема организации распределенного телефонного концентратора на базе оборудования, реализующего функции гибкого коммутатора показана на рисунке 5.1. Распределенный телефонный концентратор может применяться на участках абонентского доступа, построенных с использованием технологий кабельного телевидения, xDSL и прочих, предполагающих передачу речевой информации по протоколу IP.

Рисунок 5.1 - Схема организации распределенного телефонного концентратора

5.2.1 Устройства, применяемые для организации распределенного телефонного концентратора, должны обеспечивать качество обслуживания, соответствующее качественным показателям на ТфОП.

5.2.2 Распределенный телефонный концентратор состоит из шлюзов MG, взаимодействующих через сеть ПД. Устройство MGC обеспечивает управление вышеуказанными устройствами, которые располагаются в месте окончания участка абонентского доступа. Взаимодействие с ТфОП осуществляется на правах абонентской установки по интерфейсам до ISDN PRI включительно. Подключение распределенного телефонного концентратора к ТфОП осуществляется в одной точке. Для реализации дополнительных видов обслуживания и расширения возможностей распределенного телефонного концентратора могут использоваться сервера приложений AS и конвертеры SIP.

5.3 Схема организации транзитной станции коммутации на базе оборудования, реализующего функции гибкого коммутатора показана на рисунке 5.2.

5.3.1 Транзитный коммутатор обеспечивает взаимодействие различных телефонных сетей через мультипротокольную транспортную сеть. В состав транзитной станции коммутации входят шлюзы MG, обеспечивающие преобразование речевой информации в цифровую форму, шлюзы сигнализации SG, обеспечивающие взаимодействие телефонных сетей по протоколу сигнализации ОКС № 7, и устройство MGC, обеспечивающее управление перечисленными устройствами. Шлюз сигнализации SG должен подключаться к ТфОП с использованием межсетевого экрана (firewall), входящего в состав ТфОП.

Рисунок 5.2 - Схема организации транзитной станции коммутации

5.3.2 На базе транзитной станции коммутации возможно создание SSP (рисунок 5.3).

Требования к реализации функций SSF в устройстве MGC должны соответствовать [2].

Взаимодействие с SCP должно осуществляться по протоколу INAP системы сигнализации ОКС № 7. Подключение устройства MGC к сети ОКС № 7 должно осуществляться с использованием шлюза сигнализации SG.

Платформы ИСС подключаются к устройству управления шлюзами MGC по интерфейсу ОКС № 7 с использованием шлюза сигнализации SG. Передача сообщений ОКС № 7 должна осуществляться с использованием межсетевого экрана, входящего в состав ТфОП. Дополнительно, функции управления услугами ИСС могут быть реализованы на серверах приложений AS.

Рисунок 5.3 - Схема организации распределенного SSP

5.4 Схема организации распределенной УПАТС на базе оборудования, реализующего функции гибкого коммутатора, показана на рисунке 5.4.

5.4.1 В состав распределенной УПАТС входят устройство SIP-Proxy, шлюзы MG и серверы приложений AS, взаимодействующие через корпоративную сеть ПД. Устройство MGC обеспечивает управление указанными выше устройствами. Взаимодействие с ТфОП осуществляется на правах абонентской установки по интерфейсам до ISDN PRI включительно. Подключение к ТфОП должно осуществляться в одной точке.

Оконечное оборудование (персональные компьютеры и IP-телефоны) образуют локальные сети, которые управляются устройством MGC по протоколу SIP или Н.225. Аналоговые телефонные аппараты подключаются к распределенной УПАТС с использованием шлюзов MG, при этом шлюз MG может устанавливаться как непосредственно в помещении пользователей, так и в помещении оператора, организующего распределенную УПАТС.

Предоставление служащим организации дополнительных видов обслуживания (ДВО) осуществляется с использованием сервера приложений AS.

Рисунок 5.4 - Схема организации распределенного телефонного коммутатора

5.5 Схема организации распределенного узла телематических служб на базе оборудования, реализующего функции гибкого коммутатора показана на рисунке 5.5.

5.5.1 Распределенный узел телематических служб, организованный с использованием гибкого коммутатора, базируется на одном или более сервере приложений AS и шлюзах MG. Управление указанными устройствами осуществляется с использованием устройства MGC. Функции авторизации и аутентификации выполняет дополнительный сервер AAA. Возможен доступ к телематическим службам со стороны пользователей Интернет.

Распределенный узел телематических служб подключается к ТфОП в соответствии с требованиями [3].

Рисунок 5.5 - Схема организации распределенного узла телематических служб

5.6 Особенности сетевого применения Оборудования и реализация вышеуказанных способов должны регулироваться отдельными нормативными документами, утвержденными Минсвязи России

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 Base SX), реализованные в оборудовании, должны соответствовать подразделу 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 (Х.21 [12], X.21bis [13]).

7.5 Требования к электрическим параметрам телефонного канала

Электрические параметры телефонного канала должны соответствовать пункту 6.6 [4].

7.6 Требования к интерфейсам ISDN BRI/PRI

Интерфейс ISDN BRI/PRI, реализованный в аппаратуре, должен соответствовать разделу 4 [14].

7.7 Требования к интерфейсам СЦИ и ПЦИ

Интерфейсы СЦИ (STM-N) и интерфейсы ПЦИ (E1, E3), реализованные в оборудовании, должны соответствовать подразделу 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 Требования к реализации протокола управления H.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.2 [19]. Дополнительно, команда обеспечивает инициализацию шлюза MG. Команда «EndpointConfiguration» должна передаваться в направлении от устройства управления шлюзами MGC к шлюзу MG.

8.6.4.1 Формат команды «EndpointConfiguration» должен соответствовать пункту 2.3.2 [19]:

EndpointConfiguration(EndpointId, BearerInformation)

Таблица 8.2 - Поля команды «EndpointConfiguration»

8.6.4.2 Назначение и требования к функциям кодирования/декодирования полей команды EndpointConfiguration:

)            поле «EndpointId» должно идентифицировать шлюз MG, а также его отдельные элементы (интерфейсную плату, порт и пр.). Поле представляет собой текстовую строку, состоящую из мнемонического имени шлюза MG в формате адреса электронной почты (должен соответствовать RFC 821 [20]) и наименования отдельных элементов. Наименования отдельных элементов должны отделяться от имени шлюза символом «/». Допускается иерархическое перечисление отдельных элементов, также разделяемых символом «/» (например, «mg@gateway.com/module1/port1»). Для обозначения произвольного элемента должен использоваться символ «*». Для обозначения произвольного символа в элементе должен использоваться символ «$» (пункт 2.1.2 [19]);

)            поле «BearerInformation» должно содержать вид модуляции сигнала (A-law или m-law) в формате текстовой строки.

8.6.5 Распознавание вида передаваемой информации, тонов DTMF, определение состояний оконечного оборудования должно осуществляться с использованием команды «NotificationRequest» в соответствии с пунктом 2.3.3 [19]. Команда «NotificationRequest» должна передаваться в направлении от устройства управления шлюзами MGC к шлюзу MG.

8.6.5.1 Формат команды «NotificationRequest» должен соответствовать пункту 2.3.3 [19]:

NotificationRequest(EndpointId, [NotifiedEntity], [RequestedEvents], RequestIdentifier, [DigitMap], [SignalRequests], [QuarantineHandling], [DetectEvents], [encapsulated EndpointConfiguration])

Таблица 8.3 - Поля команды «NotificationRequest»

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.4 [19]:

Notify (EndpointId, [NotifiedEntity], RequestIdentifier, ObservedEvents)

Таблица 8.4 - Поля команды «Notify»

8.6.6.2 Назначение и требования к функциям кодирования/декодирования полей команды «Notify»:

)            «EndpointId» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 8.6.4.2-а.

)            «NotifiedEntity» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать полю «NotifiedEntity» команды «NotificationRequest», описанному в пункте 8.6.4.2-б.

)            «RequestIdentifier» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать полю «RequestIdentifier» описанному в пункте 8.6.4.2-г.

)            «ObservedEvents» - должен содержать перечень событий, обнаруженных шлюзом MG в порядке их обнаружения.

8.6.7 Установление соединения между двумя шлюзами MG осуществляется с использованием сообщения «CreateConnection» в соответствии с пунктом 2.3.5 [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»

8.6.7.2 Назначение и требования к функциям кодирования/декодирования полей команды «CreateConnection»:

)            «CallId» - идентификатор вызова.

)            «EndpointId» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 8.6.4.2-а.

)            «NotifiedEntity» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать полю «NotifiedEntity» команды «NotificationRequest», описанному в пункте 8.6.4.2-б.

)            «LocalConnectionOptions» - перечень параметров, используемый устройством управления шлюзами MGC при создании соединения. Поле «LocalConnectionOptions» должно содержать следующие параметры:

- наименование алгоритма кодирования речевой информации;

- период передачи пакетов с речевой информацией в миллисекундах;

- пропускную способность соединения в кбайт/с;

- класс обслуживания в соответствии с полем ToS заголовка пакета IP;

- использование режима эхоподавления;

- использование режимов определения и подавления пауз;

- использование режимов адаптации уровня сигнала и подавления шума.

)            «Mode» - определяет режим соединения и представляет собой текстовую строку, которая должна содержать одно из значений, в соответствии с таблицей 8.10:

Таблица 8.6 - Режимы соединений

)            «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.6 [19]:

ModifyConnection(CallId, EndpointId, ConnectionId, [NotifiedEntity], [LocalConnectionOptions], [Mode], [RemoteConnectionDescriptor], [Encapsulated NotificationRequest], [Encapsulated EndpointConfiguration])

Таблица 8.7 - Поля команды «ModifyConnection»

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.7, 2.3.8, 2.3.9 [19]. Формат команды «DeleteConnection» различается в зависимости от устройства, по инициативе которого освобождается соединение:

- устройство управления шлюзами MGC;

- шлюз MGC.

Кроме того, формат команды «DeleteConnection» различается от ее назначения:

- для освобождения всех соединений, относящихся к одному соединению;

- для безусловного освобождения всех соединений на шлюзе MG.

В зависимости от устройства, по инициативе которого освобождается соединение, команда «DeleteConnection» может передаваться как в направлении от устройства управления шлюзами MGC к шлюзу MG, так и в обратном направлении.

8.6.9.1 Формат команды «DeleteConnection», передаваемой устройством управления шлюзами MGC должен соответствовать пункту 2.3.7 [19]:

DeleteConnection(CallId, EndpointId, ConnectionId, [Encapsulated NotificationRequest], [Encapsulated EndpointConfiguration])

Таблица 8.8 - Поля команды «DeleteConnection»

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.8 [18]:

DeleteConnection(CallId, EndpointId, ConnectionId, Reason-code, Connection-parameters)

Таблица 8.9 - Поля команды «DeleteConnection»

8.6.9.4 Назначение и требования к функциям кодирования/декодирования полей команды «DeleteConnection», формат которой определен в пункте 8.6.9.3:

)            «CallId» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 8.6.7.2-а.

)            «EndpointId» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 8.6.4.2-а.

)            «Connectionld» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 8.6.8.2-в.

)            «Reason-code» - причина освобождения соединения, в соответствии с пунктом 2.5 RFC 2705 bis должно принимать следующие значения:

- 000 при штатном освобождении соединения;

- 900 при освобождении соединения из-за неисправности шлюза MG;

- 901 при освобождении соединения из-за отключения шлюза MG средствами системы административного управления;

- 902 при освобождении соединения из-за ухудшения его характеристик ниже допустимого уровня.

)            «Connection-parameters» - при освобождении соединения передается статистика соединения, которая должна включать следующую информацию:

- количество переданных пакетов RTP;

- количество переданных октетов;

- количество полученных пакетов RTP;

- количество полученных октетов;

- количество потерянных пакетов RTP;

- отклонение величины задержки получения пакетов RTP в мс;

- средняя задержка передачи пакетов RTP по сети в мс.

8.6.9.5 Формат команды «DeleteConnection», используемой для освобождения всех соединений относящихся к одному соединению, и инициируемой устройством управления шлюзами MGC должен соответствовать пункту 2.3.9 [19]:

DeleteConnection(CallId, EndpointId)

Таблица 8.10 - Поля команды «DeleteConnection»

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.9 [19]:

DeleteConnection(EndpointId)

Таблица 8.11 - Поля команды «DeleteConnection»

8.6.9.8 Назначение и требования к функциям кодирования/декодирования поля «EndpointId» должны соответствовать пункту 8.6.4.2-а.

8.6.10 Контроль и диагностика портов шлюза MG должны осуществляться командой «AuditEndPoint» в соответствии с пунктом 2.3.10 [19]. Команда должна передаваться в направлении от устройства управления шлюзами MGC к шлюзу MG.

8.6.10.1 Формат команды «AuditEndPoint» должен соответствовать пункту 2.3.10 [19]:

AuditEndPoint(EndpointId, [RequestedInfo])

Таблица 8.12 - Поля команды «AuditEndPoint»

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;

- «DetectEvents» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 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.11 [19]. Команда должна передаваться в направлении от устройства управления шлюзами MGC к шлюзу MG.

8.6.11.1 Формат команды «AuditConnection» должен соответствовать пункту 2.3.11 [19]:

AuditConnection (EndpointId, ConnectionId, RequestedInfo)

Таблица 8.13 - Поля команды «AuditConnection»

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.12 [19]:

RestartInProgress (EndPointId, RestartMethod, [RestartDelay], [Reason-code])

Таблица 8.14 - Поля команды «RestartInProgress»

8.6.12.2 Требования к функциям кодирования/декодирования полей команды «RestartMethod»:

)            «EndpointId» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 8.6.4.2-а.

)            «RestartMethod» - определяет метод рестарта в соответствии с таблицей 8.19:

Таблица 8.15 - Значения поля «RestartMethod»

)            «RestartDelay» - величина паузы в секундах.

)            «Reason-code» - назначение и требования к функциям кодирования/декодирования данного поля должны соответствовать пункту 8.6.9.4-г.

8.7 Требования к реализации протокола управления MEGAСО

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»

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»

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»

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»

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

8.8.3 Структура и формат сообщений протокола сигнализации Н.225 должны соответствовать Рекомендации МСЭ-Т Q.931 [24].

8.8.4 Оборудование должно передавать и принимать информацию о состоянии занятости в сообщении «Alerting». Требования к функциям кодирования/декодирования сообщения «Alerting» должны соответствовать Рекомендации МСЭ-Т H.225.0, 7.3.1 [22].

8.8.5 Принимающая сторона должна передавать информацию о начале обработки вызова в сообщении «Call Proceeding». Требования к функциям кодирования/декодирования сообщения «Call Proceeding» должны соответствовать Рекомендации МСЭ-Т H.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 одноранговой, МТРЗ, SCCP протокола сигнализации ОКС № 7.

8.9.2 В соответствии с документом RFC 2719 [23] Оборудование должно обеспечивать передачу сообщений протоколов сигнализаций Q.921, V5.

8.9.3 Передача сообщений подсистем ОКС № 7 и протоколов сигнализаций Q.921, V5 должна осуществляться с использованием протокола SCTP (Stream Control Transmission Protocol). Реализация протокола SCTP должна соответствовать документу RFC 2960 [25].

8.9.4 Формат пакета SCTP должен соответствовать разделу 3 документа RFC 2960 и рисунку 8.1.

Рисунок 8.1 - Формат пакета SCTP

8.9.5 Формат заголовка пакета SCTP и перечень поддерживаемых полей должны соответствовать разделу 3.1 документа RFC 2960, рисунку 8.2 и таблице 8.21.

Рисунок 8.2 - Формат заголовка пакета SCTP

Таблица 8.21 - Поля заголовка пакета SCTP

8.9.6 Функции кодирования/декодирования полей заголовка пакета SCTP должны соответствовать следующим требованиям:

)            поле «Номер порта источника» должно содержать номер порта SCTP отправителя;

)            поле «Номер порта назначения» должно содержать номер порта SCTP получателя;

)            поле «Метка верификации» должно содержать числовое значение, однозначно идентифицирующее отправителя пакета SCTP. Отправитель пакета SCTP должен устанавливать значение этой метки равное значению, полученному при инициализации сеанса связи между ним и получателем;

)            поле «Контрольная сумма» должно содержать контрольную сумму пакета SCTP.

8.9.7 Пакет SCTP может включать в себя несколько управляющих команд. Перечень допустимых команд приведен в таблице 8.22.

Таблица 8.22 - Управляющие команды протокола SCTP

8.9.7.1 Пакет SCTP должен содержать в себе только одну команду, в случаях, когда должны передаваться команды INIT, INIT ACK, SHUTDOWN COMPLETE.

8.9.8 Формат команды SCTP должен соответствовать разделу 3.2 документа RFC 2960, рисунку 8.3 и таблице 8.23.

Рисунок 8.3 - Формат порции данных

Таблица 8.22 - Поля команды SCTP

8.9.8.1 Функции кодирования/декодирования полей команды SCTP должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать численное значение в соответствии с таблицей 8.22. При этом старшие два бита данного поля должны соответствовать следующей таблице:

)            поле «Флаги» должно содержать значения, специфичные для разных команд, при этом по умолчанию поле должно принимать значение, равное нулю;

)            поле «Длина данных команды» должна содержать длину в байтах поля «Данные команды»;

)            поле «Данные команды» должно содержать информацию, специфичную для разных команд SCTP.

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

8.9.9 Формат команды «Данные пользователя» (DATA) должен соответствовать разделу 3.3.1 документа RFC 2960 и рисунку 8.4.

Рисунок 8.4 - Формат команды «Данные пользователя»

8.9.9.1 Форматы полей команды «Данные пользователя» должны соответствовать таблице 8.23.

Таблица 8.23 - Поля команды «Данные пользователя»

8.9.9.2 Функции кодирования/декодирования полей команды «Данные пользователя» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «0»;

)            поле «Резерв» должно принимать значение «0»;

)            поле «U-бит», установленное в «1», означает, что команды передаются в неупорядоченном порядке и должны передаваться в приложения верхнего уровня без обработки;

)            поле «В-бит» должно принимать значение «1» в случаях передачи команды в нескольких фрагментах, передаваемых по отдельности. Значение «1» должно устанавливаться только в первом фрагменте;

)            поле «Е-бит» должно принимать значение «1» в последнем фрагменте;

)            поле «Длина данных команды» должно содержать количество байт данных команды от поля «Код команды» включительно, до конца команды;

)            поле «Идентификатор соответствия TSN» должен содержать значение, однозначно идентифицирующее пару команд «запрос-ответ»;

)            поле «Идентификатор потока TCP» должно содержать значение, однозначно идентифицирующее сессию TCP, в которой передается пакет SCTP;

)            поле «Порядковый номер в потоке TCP» должно содержать значение, определяющее порядок следования пакетов SCTP;

)            поле «Идентификатор протокола верхнего уровня» должен содержать значение, определяющее тип информации, передаваемой приложениям верхнего уровня (МТР2, МТР3, ОКС № 7 и пр.);

)            поле «Данные» содержит информацию протоколов верхнего уровня.

8.9.10 Формат команды «Создание сеанса связи» (INIT) должен соответствовать разделу 3.3.2 документа RFC 2960 и рисунку 8.5.

8.9.10.1 Форматы полей команды «Создание сеанса связи» должны соответствовать таблице 8.24.

Таблица 8.24 - Поля команды «Создание сеанса связи»

8.9.10.2 Функции кодирования/декодирования полей команды «Создание сеанса связи» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «1»;

)            поле «Флаги» зарезервировано для будущего применения и должно игнорироваться;

)            требования к функциям кодирования/декодирования поля «Длина данных команды» должно соответствовать пункту 8.9.9.2-е;

)            поле «Метка верификации» должно принимать значение, выбранное случайным образом, которое используется для однозначного сопоставления пакетов SCTP, относящихся к одному сеансу связи (пункт 8.9.6-в);

)            поле «Размер окна приемника» должно содержать длину буфера для приема и обработки пакетов SCTP;

)            поле «Количество исходящих сессий» должно содержать количество исходящих сессий, создаваемых в течение данного сеанса связи;

)            поле «Количество входящих сессий» должно содержать количество сессий, которое отправитель данной команды в состоянии обработать;

)            поле «Идентификатор соответствия TSN» должен содержать числовое значение, выбранное случайным образом, от которого начнется отсчет значений, позволяющих определять пару «запрос-ответ»;

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

8.9.11 Формат команды «Подтверждение создания сеанса связи» (INIT АСК) должен соответствовать разделу 3.3.3 документа RFC 2960 и рисунку 8.6.

Рисунок 8.6 - Формат команды «Подтверждение создания сеанса связи»

8.9.11.1 Форматы полей команды «Подтверждение создания сеанса связи» должны соответствовать таблице 8.25.

Таблица 8.25 - Поля команды «Подтверждение создания сеанса связи»

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.

Рисунок 8.8 - Формат команды «Выборочное подтверждение»

8.9.12.1 Форматы полей команды «Выборочное подтверждение» должны соответствовать таблице 8.26.

Таблица 8.26 - Поля команды «Выборочное подтверждение»

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.

Рисунок 8.8 - Формат команды «Команда опроса состояния»

8.9.13.1 Форматы полей команды «Команда опроса состояния» должны соответствовать таблице 8.27.

Таблица 8.27 - Поля команды «Команда опроса состояния»

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.

Рисунок 8.9 - Формат команды «Удаление сеанса связи»

8.9.15.1 Форматы полей команды «Удаление сеанса связи» должны соответствовать таблице 8.28.

Таблица 8.28 - Поля команды «Удаление сеанса связи»

8.9.15.2 Функции кодирования/декодирования полей команды «Удаление сеанса связи» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «6»;

)            требования к функциям кодирования/декодирования поля «Резерв» должно соответствовать пункту 8.9.9.2-б;

)            поле «Т-бит» должно принимать значение «О» в случаях, когда отправитель уже уничтожил в оперативной памяти устройства массив данных, связанный с сеансом связи;

)            требования к функциям кодирования/декодирования поля «Длина данных команды» должно соответствовать пункту 8.9.9.2-е;

)            поле «Код ошибки» должно содержать причину удаления сеанса связи.

8.9.16 Формат команды «Завершение сеанса связи» (SHUTDOWN) должен соответствовать разделу 3.3.8 документа RFC 2960 и рисунку 8.10.

Рисунок 8.10 - Формат команды «Завершение сеанса связи»

8.9.16.1 Форматы полей команды «Завершение сеанса связи» должны соответствовать таблице 8.29.

Таблица 8.29 - Поля команды «Завершение сеанса связи»

8.9.16.2 Функции кодирования/декодирования полей команды «Завершение сеанса связи» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «7»;

)            поле «Флаги» зарезервировано для будущего применения и должно игнорироваться;

)            поле «Длина данных команды» должно принимать значение «8»;

)            поле «Идентификатор соответствия TSN последней команды» должно содержать номер последней команды в буфере приема, которая должна быть обработана до завершения сеанса связи.

8.9.17 Формат команды «Подтверждение завершения сеанса связи» (SHUTDOWN ACK) должен соответствовать разделу 3.3.9 документа RFC 2960 и рисунку 8.11.

Рисунок 8.11 - Формат команды «Подтверждение завершения сеанса связи»

8.9.17.1 Форматы полей команды «Подтверждение завершения сеанса связи» должны соответствовать таблице 8.30.

Таблица 8.30 - Поля команды «Подтверждение завершения сеанса связи»

8.9.17.2 Функции кодирования/декодирования полей команды «Подтверждение завершения сеанса связи» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «8»;

)            поле «Флаги» зарезервировано для будущего применения и должно игнорироваться;

)            поле «Длина данных команды» должно принимать значение «4».

8.9.18 Формат команды «Ошибка» (ERROR) должен соответствовать разделу 3.3.10 документа RFC 2960 и рисунку 8.12.

Рисунок 8.12 - Формат команды «Ошибка»

8.9.18.1 Форматы полей команды «Ошибка» должны соответствовать таблице 8.31.

Таблица 8.31 - Поля команды «Ошибка»

8.9.18.2 Функции кодирования/декодирования полей команды «Ошибка» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «9»;

)            поле «Флаги» зарезервировано для будущего применения и должно игнорироваться;

)            требования к функциям кодирования/декодирования поля «Длина данных команды» должно соответствовать пункту 8.9.9.2-е;

)            поле «Код ошибки» должно указывать на одно или несколько сообщений об ошибке в соответствии со следующей таблицей:

8.9.19 Создание сеанса связи осуществляется в два этапа. Первый этап - начальная фаза соединения, реализуемая командами «Создание сеанса связи» и «Подтверждение создания сеанса связи». Второй этап - завершение процедуры создания соединения, реализуемый командами «Завершение создания сеанса связи» (COOKIE ECHO) и «Создание сеанса связи завершено» (COOKIE ACK). Формат команды «Завершение создания сеанса связи» должен соответствовать разделу 3.3.11 документа RFC 2960 и рисунку 8.13.

Рисунок 8.13 - Формат команды «Завершение создания сеанса связи»

8.9.19.1 Форматы полей команды «Завершение создания сеанса связи» должны соответствовать таблице 8.32.

Таблица 8.32 - Поля команды «Завершение создания сеанса связи»

8.9.19.2 Функции кодирования/декодирования полей команды «Завершение создания сеанса связи» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «10»;

)            поле «Флаги» зарезервировано для будущего применения и должно игнорироваться;

)            требования к функциям кодирования/декодирования поля «Длина данных команды» должно соответствовать пункту 8.9.9.2-е;

)            поле «Идентификатор дополнительной информации» должно содержать значение, аналогичное указываемому в поле «Необязательные параметры» команды «Подтверждение создания сеанса связи» для однозначного сопоставления команд, относящихся к начальной и заключительной фазам создания сеанса связи.

8.9.20 Формат команды «Создание сеанса связи завершено» должен соответствовать разделу 3.3.12 документа RFC 2960 и рисунку 8.14.

Рисунок 8.14 - Формат команды «Создание сеанса связи завершено»

8.9.20.1 Форматы полей команды «Создание сеанса связи завершено» должны соответствовать таблице 8.33.

Таблица 8.33 - Поля команды «Создание сеанса связи завершено»

8.9.20.2 Функции кодирования/декодирования полей команды «Завершение создания сеанса связи» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «11»;

)            поле «Флаги» зарезервировано для будущего применения и должно игнорироваться;

)            поле «Длина данных команды» должно содержать значение «4».

8.9.21 Формат команды «Процедура завершения сеанса связи окончена» (SHUTDOWN COMPLETE) должен соответствовать разделу 3.3.13 документа RFC 2960 и рисунку 8.15.

Рисунок 8.15 - Формат команды «Процедура завершения сеанса связи окончена»

8.9.21.1 Форматы полей команды «Процедура завершения сеанса связи окончена» должны соответствовать таблице 8.34.

Таблица 8.34 - Поля команды «Процедура завершения сеанса связи окончена»

8.9.21.2 Функции кодирования/декодирования полей команды «Процедура завершения сеанса связи окончена» должны соответствовать следующим требованиям:

)            поле «Код команды» должно принимать значение «14»;

)            требования к функциям кодирования/декодирования поля «Резерв» должны соответствовать пункту 8.9.9.2-б;

)            поле «Т-бит» должно принимать значение «О» в случаях, когда отправитель уже уничтожил в оперативной памяти устройства массив данных, связанный с сеансом связи;

)            поле «Длина данных команды» должно принимать значение «4».

8.10 Требования к реализации протоколов цифровой абонентской сигнализации DSS1

Цифровая абонентская сигнализация на сетевом уровне должна соответствовать пункту 6.9 [4].

8.11 Требования к реализации протокола сигнализации ОКС № 7

8.11.1 Оборудование должно обеспечивать реализацию следующих подсистем протокола сигнализации ОКС № 7;

- подсистемы передачи сообщений (МТР) для национальной сети России (МТР-2000);

- подсистемы пользователей ЦСИС (ISUP) для национальной сети России (ISUP-R-2000).

8.11.1.1 Подсистема передачи сообщений (МТР) для национальной сети России (МТР-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 - Допустимые напряжения пульсаций первичного источника

9.2.6 Допустимые одиночные импульсные изменения напряжения на вводах первичного источника постоянного тока должны соответствовать следующим значениям:

- при длительности импульса 0,4 с ± 0,2 U_н;

- при длительности импульса 0,005 с ± 0,4 U_н.

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

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 - Требования к прочности при транспортировании

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 - Общее несимметричное напряжение радиопомех

9.5.3 Общее несимметричное напряжение радиопомех Uп, создаваемых на зажимах аппаратуры для подключения к 2-х и 4-х проводным симметричным линиям связи, выходящим за границу объекта, не должно превышать значений, указанных в таблице 9.4.

Таблица 9.4 - Общее несимметричное напряжение радиопомех

9.5.4 Квазипиковое значение напряженности поля радиопомех на расстоянии 3 м от корпуса аппаратуры не должно превышать значений, указанных в таблице 9.5.

Таблица 9.5 - Квазипиковое значение напряженности поля радиопомех

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 ... 800).

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 signaling 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] Рекомендация МСЭ-Т Х.21 bis	Использование в сетях данных общего пользования оконечного оборудования данных, разработанного для взаимодействия с синхронными модемами 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, утверждены Министерством Российской Федерации по связи и информатизации 03 июля 2002 г.
[19] IETF RFC 2705bis	Протокол управления шлюзами MG (MGCP), версия 1.0 bis (Media Gateway Control Protocol (MGCP), Version 1.0 bis)
[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] Рекомендация MCЭ-T Q.931	Цифровая абонентская сигнализация № 1 (ЦАС 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.