МИНИСТЕРСТВО ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ И СВЯЗИ
РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРИКАЗ

от 31 мая 2007 года N 58

Об утверждении Правил применения оборудования коммутации систем
подвижной радиотелефонной связи. Часть II. Правила применения оборудования
коммутации сети подвижной радиотелефонной связи стандарта GSM 900/1800

    
    В соответствии со статьей 41 Федерального закона от 7 июля 2003 года N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст.2895; N 52 (ч.I), ст.5038; 2004, N 35, ст.3607; N 45, ст.4377; 2005, N 19, ст.1752; 2006, N 6, ст.636; N 10, ст.1069; N 31 (ч.I), ст.3431, 3452; 2007, N 1, ст.8; N 7, ст.835) и пунктом 4 Правил организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденных постановлением Правительства Российской Федерации от 13 апреля 2005 года N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст.1463),
    
приказываю:
    
    1. Утвердить прилагаемые Правила применения оборудования коммутации систем подвижной радиотелефонной связи. Часть II. Правила применения оборудования коммутации сети подвижной радиотелефонной связи стандарта GSM 900/1800.
    
    2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.
    
    3. Контроль за исполнением настоящего приказа возложить на заместителя Министра информационных технологий и связи Российской Федерации Б.Д.Антонюка.
    
    

Министр
Л.Д.Рейман

    

Зарегистрировано
в Министерстве юстиции
Российской Федерации
22 июня 2007 года,
регистрационный N 9675

    
Приложение

УТВЕРЖДЕНЫ
приказом Министерства
информационных технологий и
связи Российской Федерации
от 31 мая 2007 года N 58

    
    
ПРАВИЛА
применения оборудования коммутации систем подвижной радиотелефонной
связи. Часть II. Правила применения оконечно-транзитных узлов связи сетей
подвижной радиотелефонной связи стандарта GSM 900/1800

    
I. Общие положения

    
    1. Правила применения оборудования коммутации систем подвижной радиотелефонной связи. Часть II. Правила применения оконечно-транзитных узлов связи сетей подвижной радиотелефонной связи стандарта GSM 900/1800 (далее - Правила) разработаны в соответствии со статьей 41 Федерального закона от 7 июля 2003 года N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст.2895; N 52 (ч.I), ст.5038; 2004, N 35, ст.3607; N 45, ст.4377; 2005, N 19, ст.1752; 2006, N 6, ст.636; N 10, ст.1069; N 31 (ч.I), ст.3431, 3452; 2007, N 1, ст.8; N 7, ст.835) в целях обеспечения целостности, устойчивости функционирования и безопасности единой сети электросвязи Российской Федерации.
    
    2. Правила устанавливают обязательные требования к параметрам оконечно-транзитных узлов связи сетей подвижной радиотелефонной связи стандарта GSM 900/1800 (далее - СПРС).
    
    3. Оконечно-транзитные узлы связи идентифицируются как оборудование коммутации систем подвижной радиотелефонной связи, относятся к сложному телекоммуникационному оборудованию и согласно пункту 9 Перечня средств связи, подлежащих обязательной сертификации, утвержденного постановлением Правительства Российской Федерации от 31 декабря 2004 года N 896 (Собрание законодательства Российской Федерации, 2005, N 2, ст.155), должны пройти процедуру обязательной сертификации в порядке, установленном Правилами организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденными постановлением Правительства Российской Федерации от 13 апреля 2005 года N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст.1463).
    
    4. В состав оконечно-транзитных узлов связи СПРС входят следующие виды оборудования (далее - оборудование узлов связи):
    
    1) центр коммутации подвижной связи (далее - ЦКП) с использованием следующих технологий коммутации:
    
    коммутации каналов;
    
    коммутации пакетов информации;
    
    2) визитный регистр местонахождения (далее - ВРМ);
    
    3) опорный регистр местонахождения (далее - ОРМ);
    

    4) центр аутентификации (далее - Аут);
    
    5) регистр идентификации оборудования (далее - РИО);
    
    6) центр управления и технического обслуживания (далее - ЦУиТО);
    
    7) оборудование передачи данных;
    
    8) подсистема передачи мультимедийных сообщений на базе протоколов сети передачи данных Интернет (IMS).
    
    9) оборудование, реализующее функцию многоточечной полудуплексной связи в сети подвижной радиотелефонной связи (далее - РоС).
    
    10) ЦКП с использованием технологии с коммутацией пакетов информации состоит из следующего оборудования:
    
    а) сервер центра коммутации подвижной связи (далее - ЦКП сервер);
    
    б) медиашлюз (далее - МШ);
    
    в) шлюз сигнализации (далее - ШС).
    
    

II. Требования к оборудованию узлов связи сетей подвижной
радиотелефонной связи стандарта GSM 900/1800

    
    5. В оборудовании узлов связи обеспечивается электрическое соединение всех доступных прикосновению металлических нетоковедущих частей, которые оказываются под напряжением, с элементами заземления. Значение сопротивления между элементом заземления и каждой доступной прикосновению металлической нетоковедущей частью оборудования, которая оказывается под напряжением, не превышает 0,1 Ом.
    
    6. Электропитание оборудования узлов связи осуществляется в соответствии с требованиями к параметрам электропитания, установленными в пунктах П.9.1-П.9.4 приложения 9 к Правилам применения транзитных междугородных узлов автоматической коммутации. Часть I. Правила применения транзитных междугородных узлов связи, использующих систему сигнализации по общему каналу сигнализации N 7 (ОКС N 7), утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 16.05.2006 N 59 (зарегистрирован в Министерстве юстиции Российской Федерации 29 мая 2006 года, регистрационный N 7879), или от сети переменного тока с номинальным напряжением 220 В, частотой 50 Гц.
    
    Оборудование электропитающей установки (далее - ЭПУ) не входит в состав оконечно-транзитных узлов связи и соответствует Правилам применения оборудования электропитания средств связи, утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 03.03.2006 N 21 (зарегистрирован в Министерстве юстиции Российской Федерации 27 марта 2006 года, регистрационный N 7638).
    
    7. Оборудование узлов связи сохраняет работоспособность при отклонении напряжения электропитания от номинальных значений в допустимых пределах:
    
    при номинальном напряжении 60 В - в пределах от 48,0 до 72,0 В;
    
    при номинальном напряжении 48 В - в пределах от 40,5 до 57 В;
    
    при напряжении переменного тока 220 В - в пределах от 187 до 242 В (частота - от 47,5 до 50,5 Гц, коэффициент нелинейных искажений - не более 10%, кратковременное (длительностью до 3 с) изменение напряжения относительно номинального значения ±40 %).
    
    8. В оборудовании узлов связи предусмотрена система сигнализации для контроля неисправностей в ЭПУ.
    

    9. Для оборудования узлов связи устанавливаются следующие обязательные требования к параметрам:
    
    1) интерфейсов взаимодействия согласно приложению N 1 к Правилам;
    
    2) устойчивости к внешним электрическим и электромагнитным воздействиям и индустриальным радиопомехам согласно приложению N 2 к Правилам;
    
    3) устойчивости к внешним климатическим и механическим воздействиям согласно приложению N 3 к Правилам;
    
    4) в части нумерации и идентификации согласно приложению N 4 к Правилам;
    
    5) используемых интерфейсов и системы синхронизации согласно приложению N 5 к Правилам;
    
    6) акустических сигналов согласно приложению N 7 к Правилам;
    
    7) системы учета данных для начисления платы согласно приложению N 8 к Правилам;
    
    8) системы сигнализации по общему каналу ОКС N 7 согласно приложению N 6 к Правилам;
    
    9) протоколов передачи данных согласно приложению N 9 к Правилам;
    
    10) протокола управления медиашлюзами MEGACO/H.248 согласно приложению N 10 к Правилам;
    
    11) протокола управления медиашлюзами MGCP согласно приложению N 11 к Правилам;
    
    12) протокола управления вызовом, независимого от среды переноса, BICC согласно приложению N 12 к Правилам;
    
    13) протокола установления сеансов связи SIP согласно приложению N 13 к Правилам;
    
    14) протокола передачи информации сигнализации SIGTRAN согласно приложению N 14 к Правилам;
    
    15) транспортного протокола реального времени RTP и протокола управления транспортировкой в реальном времени RTCP согласно приложению N 15 к Правилам;
    
    16) протокола Diameter согласно приложению N 16 к Правилам;
    
    17) протокола управления передачей пользовательской информации ТВСР согласно приложению N 17 к Правилам.
    
    10. Для оборудования управления и технического обслуживания устанавливаются требования согласно приложению N 18 к Правилам.
________________
    * Приложения (1-18) в Бюллетене нормативных актов федеральных органов исполнительной власти, N 30, 23.07.2007 не приводятся. - Примечание изготовителя базы данных.
    
              
    11. Списки используемых сокращений и наименований сообщений приведены в приложениях N 19, 20* к Правилам (справочно), соответственно.
________________
    * Приложения в Бюллетене нормативных актов федеральных органов исполнительной власти, N 30, 23.07.2007 не приводятся. - Примечание изготовителя базы данных.
    
              
    

Приложение N 1
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной связи
стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам интерфейсов взаимодействия

    
    1. Интерфейс ЦКП, реализованный с использованием технологии коммутации каналов, с оборудованием ВРМ, ОРМ, РИО; интерфейсы ОРМ с ВРМ; ОРМ с Аут; ОРМ с РИО.
    
    1.1. Физический уровень.
    
    Цифровой интерфейс со скоростью передачи 2048 кбит/с (стык А).
    
    Требования к параметрам интерфейса установлены в приложении N 1 к Правилам применения транзитных междугородных узлов автоматической коммутации. Часть I. Правила применения транзитных междугородных узлов связи, использующих систему сигнализации по общему каналу сигнализации N 7 (ОКС N 7), утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 16.05.2006 N 59 (зарегистрирован в Министерстве юстиции Российской Федерации 29 мая 2006 года, регистрационный N 7879).
    
    1.2. Система сигнализации.
    
    ОКС N 7 (подсистема передачи сообщений МТР, подсистема управления соединением сигнализации SCCP, подсистема возможностей транзакций ТСАР, прикладная подсистема подвижной связи MAP).
    
    Требования к параметрам системы сигнализации ОКС N 7 установлены в приложении N 6 к Правилам.
    
    2. Интерфейс ЦКП, реализованный с использованием технологии коммутации каналов, и ШC с узлами связи сетей фиксированной телефонной связи (далее - СФТС).
    
    2.1. Физический уровень.
    
    В оборудовании реализованы один или оба из следующих интерфейсов;
    
    а) цифровой интерфейс со скоростью передачи 2048 кбит/с (стык А);
    
    б) интерфейс синхронной цифровой иерархии STM-1 со скоростью передачи 155520 кбит/с.
    
    Требования к параметрам интерфейса STM-1 установлены в приложении N 1 к Правилам применения транзитных междугородных узлов автоматической коммутации. Часть I. Правила применения транзитных междугородных узлов связи, использующих систему сигнализации по общему каналу сигнализации N 7 (ОКС N 7), утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 16.05.2006 N 59 (зарегистрирован в Министерстве юстиции Российской Федерации 29 мая 2006 года, регистрационный N 7879).
    
    2.2. Система сигнализации.
    
    ОКС N 7 (подсистемы МТР, SCCP, подсистема пользователя ISUP).
    
    3. Интерфейс ЦКП, реализованный с использованием технологии коммутации каналов, и ШС с узлами СПРС.
    
    3.1. Физический уровень.
    
    В оборудовании реализованы один или оба из следующих интерфейсов:
    
    а) цифровой интерфейс со скоростью передачи 2048 кбит/с (стык А);
    
    б) интерфейс синхронной цифровой иерархии STM-1 со скоростью передачи 155520 кбит/с.
    
    3.2. Система сигнализации.
    
    ОКС N 7 (подсистемы МТР, SCCP, TCAP, MAP, ISUP).
    
    4. Интерфейс узла текущей поддержки пакетной передачи данных SGSN (далее - УТПД) с ВРМ.
    
    4.1. Физический уровень.
    
    Цифровой интерфейс со скоростью передачи 2048 кбит/с (стык А).
    
    4.2. Система сигнализации.
    
    ОКС N 7 (подсистемы МТР, SCCP, прикладная подсистема базовых станций BSSAP).
    
    5. Интерфейс УТПД с ОРМ, РИО; шлюзового узла поддержки пакетной передачи данных GGSN (далее - УШПД) с ОРМ.
    
    5.1. Физический уровень.
    
    Цифровой интерфейс со скоростью передачи 2048 кбит/с (стык А).
    
    5.2. Система сигнализации.
    
    ОКС N 7 (подсистемы МТР, SCCP, TCAP, MAP).
    
    6. Интерфейс УТПД с УШПД или с УТПД другой СПРС.
    
    6.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов протокола сети передачи данных Интернет IP.
    
    Требования к параметрам интерфейса установлены в приложении N 5 к Правилам.
    
    6.2. Сетевой и транспортный уровни.
    
    Протокол IP, протокол передачи дейтаграмм пользователя UDP или протокол управления передачей TCP, протокол туннелирования для пакетной передачи данных GTP.
    
    Требования к параметрам протоколов IP, GTP установлены в приложении N 9 к Правилам.
    
    7. Интерфейс УТПД с оборудованием подсистемы базовых станций.
    
    7.1. Физический уровень.
    
    Цифровой интерфейс со скоростью передачи 2048 кбит/с (стык А).
    
    7.2. Система сигнализации.
    
    Протокол сетевой службы NS, протокол пакетной передачи данных для подсистемы базовых станций BSSGP, протокол сходимости подсетей SNDCP.
    
    Требования к параметрам протоколов NS, BSSGP, SNDCP установлены в приложении N 9 к Правилам.
    
    8. Интерфейс УШПД с сетями передачи данных.
    
    8.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    8.2. Сетевой и транспортный уровни.
    
    Протоколы IP, UDP или TCP.
    
    9. Интерфейс ЦКП сервера с МШ.
    
    9.1. Физический, канальный уровни.
    
    В оборудовании реализован один или оба из следующих интерфейсов:
    
    а) интерфейс, обеспечивающий транспортировку пакетов IP;
    
    б) интерфейс с асинхронным режимом переноса информации ATM с уровнем адаптации ATM типа 5 AAL5.
    
    9.2. Сетевой и транспортный уровни.
    
    В случае использования интерфейсов, указанных в подпункте а пункта 9.1, на сетевом уровне реализуется протокол IP, на транспортном уровне реализуются протоколы UDP, или TCP, или протокол передачи с управлением потоками SCTP. Требования к параметрам протокола SCTP установлены в приложении N 14 к Правилам.
    
    9.3. Прикладной уровень.
    
    Используется один из протоколов управления медиашлюзами MEGACO/H.248 или MGCP, требования к которым установлены в приложениях NN 10, 11 к Правилам, соответственно.
    
    10. Интерфейс ЦКП сервера с ЦКП сервером, с устройством управления шлюзами узла СФТС, реализованного с использованием технологии коммутации пакетов информации.
    
    10.1. Физический и канальный уровни.
    
    В оборудовании реализован один или оба из следующих интерфейсов:
    
    а) интерфейс, обеспечивающий транспортировку пакетов IP;
    
    б) интерфейс с асинхронным режимом переноса информации с уровнем адаптации AAL5.
    
    10.2. Сетевой и транспортный уровни.
    
    В случае использования интерфейсов, указанных в подпункте а пункта 10.1, на сетевом уровне реализуется протокол IP, на транспортном уровне реализуются протоколы UDP, или TCP, или SCTP.
    
    10.3. Прикладной уровень.
    
    Протокол BICC или протокол SIP, требования к которым установлены в приложениях NN 12, 13 к Правилам соответственно.
    
    11. Интерфейс ЦКП сервера с ОРМ.
    
    11.1. Физический, канальный уровень.
    
    В оборудовании реализован один или оба из следующих интерфейсов:
    
    а) интерфейс, приведенный в пункте 1;
    
    б) интерфейс, обеспечивающий транспортировку пакетов IP.
    
    11.2. Сетевой и транспортный уровни.
    
    В случае использования интерфейсов, указанных в подпункте б) пункта 11.1, на сетевом уровне реализуется протокол IP. На транспортном уровне реализуются протоколы группы SIGTRAN: SCTP и один из протоколов: протокол уровня адаптации пользователя МТР2 - M2UA или протокол уровня адаптации пользователя МТРЗ - M3UA. Требования к протоколам группы SIGTRAN установлены в приложении N 14 к Правилам.
    
    11.3. Система сигнализации.
    
    ОКС N 7 (подсистемы SCCP, TCAP, MAP).
    
    12. Интерфейс ЦКП сервера с ШС.
    
    12.1. Физический и канальный уровни.
    
    В оборудовании реализованы один или оба из следующих интерфейсов:
    
    а) интерфейс, обеспечивающий транспортировку пакетов IP;
    
    б) интерфейс с асинхронным режимом переноса информации с уровнем адаптации AAL5.
    
    12.2. Сетевой и транспортный уровни.
    
    В случае использования интерфейсов, указанных в подпункте а пункта 12.1, на сетевом уровне реализуется протокол IP, на транспортном уровне реализуются протоколы группы SIGTRAN: SCTP и один из протоколов: M2UA, M3UA; протокол уровня адаптации пользователя SCCP - SUA. Требования к протоколам группы SIGTRAN установлены в приложении N 14 к Правилам.
    
    12.3. Система сигнализации.
    
    ОКС N 7 (подсистемы SCCP, TCAP, ISUP, MAP).
    
    13. Интерфейс между медиашлюзами.
    
    13.1. Физический и канальный уровни.
    
    В оборудовании реализован один или оба из следующих интерфейсов:
    
    а) интерфейс, обеспечивающий транспортировку пакетов IP;
    
    б) интерфейс с асинхронным режимом переноса информации ATM с уровнем адаптации ATM типа 2 AAL2.
    
    13.2. Сетевой и транспортный уровни.
    
    В случае использования интерфейсов, указанных в подпункте а пункта 13.1, реализуются протоколы IP, UDP, а также протоколы RTP и RTCP, требования к которым установлены в приложении N 15 к Правилам.
    
    14. Подсистема передачи мультимедийных сообщений на базе протоколов сети передачи данных Интернет IMS.
    
    IMS состоит из следующего оборудования:
    
    а) оборудование, реализующее функции управления сеансом - CSCF;
    
    б) устройство управления шлюзом передачи мультимедийных сообщений MGCF;
    
    в) шлюз передачи мультимедийных сообщений IMS-MGW;
    
    г) оборудование, реализующее функции процессора ресурсов мультимедиа MRFP;
    
    д) оборудование, реализующее функции контроллера ресурсов мультимедиа MRFC;
    
    е) сервер баз данных, содержащий информацию о пользователях подсистемы IMS, HSS;
    
    ж) сервер баз данных, содержащий адреса HSS, используется при наличие на сети более одного HSS;
    
    з) оборудование, реализующее функции управления шлюзом взаимодействия с внешней сетью с коммутацией каналов BGCF;
    
    и) шлюз сигнализации.
    
    14.1. Интерфейсы оборудования подсистемы IMS.
    
    14.1.1. Интерфейс CSCF с CSCF, с оконечным оборудованием пользователя, с оборудованием MGCF, с BGCF, с MRFC, с сетью передачи данных; MGCF с BGCF;BGCF c BGCF.
    
    14.1.1.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    14.1.1.2. Сетевой, транспортный уровни.
    
    Протокол IP, протоколы UDP, или TCP, или SCTP.
    
    14.1.1.3. Прикладной уровень.
    
    Протокол SIP.
    
    14.1.2. Интерфейс оборудования MGCF с IMS -MGW; MRFP с MRFC.
    
    14.1.2.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    14.1.2.2. Сетевой, транспортный уровни.
    
    Протокол IP, протоколы UDP, или TCP, или SCTP.
    
    14.1.2.3. Прикладной уровень.
    
    Протоколы управления медиашлюзами MEGACO/ H.248 или MGCP.
    
    14.1.3. Интерфейс УШПД с оборудованием CSCF, MRF, IMS - MGW.
    
    14.1.3.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IР.
    
    14.1.3.2. Сетевой, транспортный уровни.
    
    Протокол IP, протоколы UDP, или TCP, или SCTP.
    
    14.1.4. Интерфейс оборудования IMS-MGW с MRFP, MRFP с сетью передачи данных.
    
    14.1.4.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    14.1.4.2. Сетевой, транспортный уровни.
    
    Протокол IP, протокол UDP.
    
    14.1.4.3. Прикладной уровень.
    
    Протоколы RTP и RTCP.
    
    14.1.5. Интерфейсы оборудования CSCF с HSS, с SLF.
    
    14.1.5.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    14.1.5.2. Сетевой, транспортный уровни.
    
    Протокол IP, протоколы UDP, или TCP, или SCTP.
    
    14.1.5.3. Прикладной уровень.
    
    Протокол Diameter. Требования к параметрам протокола Diameter установлены в приложении N 16 к Правилам.
    
    14.1.6. Интерфейс оборудования HSS с ВРМ, с ЦКП сервером, с УТПД, с УШПД аналогичен приведенному в пункте 11.
    
    14.1.7. Интерфейс ШС с MGCF.
    
    14.1.7.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    14.1.7.2. Сетевой и транспортный уровни.
    
    Протокол IP, протоколы группы SIGTRAN: SCTP и один из протоколов: M2UA, M3UA, SUA.
    
    14.1.7.3. Система сигнализации.
    
    ОКС N 7 (подсистемы SCCP, TCAP, ISUP, MAP).
    
    15. Оборудование, реализующее функцию многоточечной полудуплексной связи в сети подвижной радиотелефонной связи - РоС:
    
    а) сервер РоС.
    
    б) сервер управления группами/списками участников РоС-сессий.
    
    в) коллективно используемый сервер управления группами/списками.
    
    г) сервер сбора информации для учета стоимости многоточечной полудуплексной связи в сети подвижной радиотелефонной связи.
    
    д) сервер присутствия.
    
    15.1. Интерфейс сервера РоС с оборудованием CSCF.
    
    15.1.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    15.1.2. Сетевой, транспортный уровни.
    
    Протокол IP, протоколы UDP, или TCP, или SCTP.
    
    15.1.3. Прикладной уровень.
    
    Протокол SIP.
    
    15.2. Интерфейсы сервера РоС с оборудованием IMS-MGW, с сервером РоС.
    
    15.2.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    15.2.2. Сетевой, транспортный уровни.
    
    Протокол IP, протокол UDP.
    
    15.2.3. Прикладной уровень.
    
    Протоколы RTP и RTCP. Протокол управления передачей пользовательской информации ТВСР. Требования к параметрам протокола ТВСР установлены в приложении N 17 к Правилам.
    
    15.3. Интерфейс сервера управления группами/списками участников РоС-сессий, коллективно используемого сервера управления группами/списками, сервера присутствия с оборудованием CSCF.
    
    15.3.1. Физический и канальный уровни.
    
    Интерфейс, обеспечивающий транспортировку пакетов IP.
    
    15.3.2. Сетевой, транспортный уровни.
    
    Протокол IP, протоколы UDP, или TCP, или SCTP.
    
    15.3.3. Прикладной уровень.
    
    Протокол SIP.
    
    

Приложение N 2
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам устойчивости к внешним электрическим и электромагнитным
воздействиям и индустриальным радиопомехам

    
    
    1. Несимметричное напряжение радиопомех U на зажимах для подключения к сети электропитания (далее - сетевые зажимы) оборудования узла связи СПРС не превышает значений, приведенных в таблице N 1.
    

Таблица N 1

Нормы напряжения радиопомех на сетевых зажимах

    
    
    2. Общее несимметричное напряжение радиопомех U на зажимах для подключения к симметричным линиям связи (далее - линейные зажимы) оборудования узла связи СПРС не превышает значений, приведенных в таблице N 2.
    

Таблица N 2

Нормы напряжения радиопомех на линейных зажимах

    
    
    3. В таблице N 2 в полосе частот от 0,15 до 0,50 МГц допустимые значения напряжения радиопомех U в децибелах относительно 1 мкВ вычисляют по формулам:
    

    
где f - частота измерений, МГц.
    
    4. Квазипиковое значение напряженности поля радиопомех от оборудования узла связи СПРС, измеренное на расстоянии 10 м, не превышает значений, приведенных в таблице N 3.
    

Таблица N 3

Нормы квазипикового значения напряженности поля радиопомех

    
    
    5. Напряжение радиопомех, создаваемых оборудованием узла связи СПРС на зажимах при подключении к коаксиальным и волоконно-оптическим линиям связи, не нормируется.
    
    6. Оборудование узла связи СПРС устойчиво к воздействию электростатических разрядов, параметры которых приведены в таблице N 4, и отвечает критериям качества функционирования, приведенным в пункте 10.
    

Таблица N 4

Параметры электростатических разрядов и критерии
функционирования

    
    
    7. Оборудование узла связи СПРС устойчиво к воздействию электромагнитных полей в диапазоне от 80 до 1000 МГц, параметры которых приведены в таблице N 5, и отвечает критериям качества функционирования, приведенным в пункте 10.
    

Таблица N 5

    
Параметры напряженности электромагнитного поля
и критерии функционирования

    
    
    7.1. Приведенные ниже классы условий электромагнитной обстановки соответствуют степеням жесткости испытаний, установленным в таблице N 5:
    
    а) класс 2 - обстановка, характеризуемая средним уровнем электромагнитных излучений. Соответствует случаю применения переносных абонентских радиостанций (далее - АС) мощностью менее 1 Вт при ограничении их работы в непосредственной близости к техническому средству;
    
    б) класс 3 - обстановка, характеризуемая высоким уровнем электромагнитных излучений. Соответствует случаю применения переносных АС мощностью более 1 Вт в непосредственной близости к техническому средству (но не менее 1 м), а также соответствует близкому расположению мощных радиовещательных и телевизионных установок.
    
    8. Оборудование узла связи СПРС устойчиво к воздействию наносекундных импульсных помех (длительность фронта импульса 5 не и длительность импульса 50 нс) в цепях электропитания постоянного и переменного тока, в линейных цепях и цепях сигнализации и управления, параметры которых приведены в таблице N 6, и отвечает критериям качества функционирования, приведенным в пункте 10.
    

Таблица N 6

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

    
    
    9. Оборудование узла связи СПРС устойчиво к воздействию микросекундных импульсных помех большой энергии с длительностью фронта импульса 1 мкс и длительностью импульса 50 мкс в цепях электропитания переменного тока и симметричных линейных цепях, а также длительностью фронта импульса 6,5 мкс и длительностью импульса 700 мкс в симметричных линейных цепях (испытания в режиме холостого хода), параметры которых приведены в таблице N 7, и отвечает критериям качества функционирования, приведенным в пункте 10.
    

Таблица N 7  

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

    
    
    10. Для оборудования узла связи СПРС определены следующие критерии качества функционирования:
    
    а) критерий А - нормальное функционирование оборудования в соответствии с требованиями, установленными в технической документации;
    
    б) критерий В - временное ухудшение качества функционирования или прекращение выполнения установленной функции с последующим автоматическим восстановлением нормального функционирования.
    
    

Приложение N 3
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам устойчивости к внешним климатическим
и механическим воздействиям

    
    
    1. Оборудование узла связи СПРС сохраняет работоспособность при климатических и механических воздействиях, параметры которых приведены в таблицах NN 1, 2.
    

Таблица N 1

    
Параметры климатических воздействий

    
    
Таблица N 2

    
Параметры механических воздействий

    
    
Приложение N 4
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам оборудования узла коммутации в части
системы нумерации и идентификации

    
    
    1. Оборудование узла коммутации поддерживает Российскую систему и план нумерации, принятые в Российской Федерации.
    
    2. Оборудование узла коммутации обеспечивает прием и передачу до 18 знаков телефонного номера.
    
    3. Формат номера, поступающего на узел коммутации.
    
    3.1. При исходящей международной связи:
    
    Пмн. Кс Nнац;
    
    Пмн. Кс Nгл;
    
    Пмн. Кс Ки Na;
    
    Пмн. Кс Киг Na;
    
    Пмн. 800 GSN,
    
где: Пмн - международный префикс;
    
    Кс - код страны или группы стран в сводном плане нумерации, код страны для Глобальной службы, код страны для Сети;
    
    Nнац - национальный (значащий) номер абонента;
    
    Nгл - номер абонента Глобальной службы;
    
    Ки - код идентификации Сети;
    
    Киг - код идентификации Группы стран;
    
    Na - номер абонента;
    
    GSN - глобальный номер абонента услуги бесплатного международного телефона.
    
    3.2. При исходящей междугородной связи:
    
    Пн. ABC x х х х х х x;
    
    Пн. DEF x х х х х х x,
    
где: Пн. - национальный префикс;
    
    ABC - код географически определяемой зоны нумерации;
    
    DEF - код географически не определяемой зоны нумерации;
    
    x х х х х х x - зоновый номер.
    
    3.3. При исходящей связи к пользователям телефонных сетей фиксированной и подвижной связи Российской Федерации:
    
    Пн. ABC x х х х х х x,
    Пн. DEF x х х х х х x.
    
    3.4. При оказании услуг связи с использованием кодов доступа к услугам элсектросвязи (КДУ), в том числе к услугам связи по передаче данных и к телематическим услугам связи:
    
    Пн.КДУ X Х Х Х … X,
    
    где: Пн. - национальный префикс;
    
    КДУ - код доступа к услуге электросвязи;
    
    X Х Х - индекс, закрепляемый за оператором связи, предоставляющим услуги связи с использованием кодов доступа к услугам электросвязи;
    
    Х … X - номер услуги связи.
    
    4. Для доступа абонентов и пользователей к экстренным оперативным службам местных сетей фиксированной телефонной связи используется сокращенный номер: "112", в соответствии с принятой на телефонной сети связи общего пользования нумерацией.
    
    4.1. В случае вызова абонентом сети подвижной связи экстренных оперативных служб оборудование узла связи обеспечивает передачу номера этого абонента в формате национального номера.
    
    5. Для идентификации оконечных элементов сети подвижной связи используется комбинация цифровых обозначений:
    
    код страны подвижной связи (МСС) - до 3 десятичных знаков (Российская Федерация, МСС = 250);
    
    код сети подвижной связи (MNC) - до 2 десятичных знаков (для идентификации сети подвижной связи в пределах страны);
    
    опознавательный номер абонентской станции (MSIN) - 10 десятичных знаков (для идентификации абонентской станции в пределах сети подвижной связи, к которой она подключена).
    
    6. Последовательное обозначение кода страны подвижной связи, кода сети подвижной связи, опознавательного номера абонентской станции образует международный номер абонентской станции (IMSI), используемый для идентификации абонентской станции подвижной связи в глобальных сетях подвижной связи. Максимальное число десятичных знаков в международном номере равно 15.
    
    

Приложение N 5
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам используемых интерфейсов и системы синхронизации

    
    
    1. Требования к параметрам интерфейсов, обеспечивающих транспортировку пакетов IP, используемых оборудованием узла связи, установлены в приложении N 25 к Правилам применения оборудования проводных и оптических систем передачи абонентского доступа, утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 24.08.2006 N 112 (зарегистрирован в Министерстве юстиции Российской Федерации 4 сентября 2006 года, регистрационный N 8194).
    
    2. Параметры системы синхронизации.
    
    2.1. Генератор блока сетевой синхронизации управляется сигналом тактовой сетевой синхронизации, выделяемым из каналов первичных групп 2048 кбит/с (стык А), или поступающим со стыка Y - 2048 кГц.
    
    2.2. Для приема сигналов тактовой сетевой синхронизации предусматриваются не менее двух входов 2048 кбит/с и не менее двух входов 2048 кГц.
    
    2.3. В оборудование тактовой синхронизации оборудования узла связи входят два блока синхронизации, работающие синхронно.
    
    2.4. В нормальных условиях для синхронизации используется основной синхросигнал. В случае его отказа, блок синхронизации оборудования узла связи автоматически переключается на следующий по приоритету синхросигнал.
    
    В оборудовании узла связи предусмотрена возможность выбора сигналов синхронизации с терминала технического обслуживания и эксплуатации.
    
    2.5. Оборудование узла связи переходит в автономный режим работы с запоминанием частоты синхросигнала в случае пропадания всех входящих синхросигналов.
    
    2.6. При любых переключениях в блоке тактовой синхронизации скачок фазы на выходе оборудования узла связи не более 61 нс.
    
    2.7. Блок синхронизации оборудования узла связи имеет систему автоматизированного контроля и соответствующую сигнализацию.
    
    

Приложение N 6
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам системы сигнализации ОКС N 7

    
    
    1. В оборудовании узла связи реализуются следующие подсистемы системы сигнализации ОКС N 7:
    
    а) подсистема передачи сообщений МТР;
    
    б) подсистема управления соединением сигнализации SCCP;
    
    в) подсистема пользователя цифровой сети с интеграцией служб ISUP;
    
    г) подсистема возможностей транзакций ТСАР;
    
    д) прикладная подсистема подвижной связи MAP.
    
    2. Реализация подсистем МТР, SCCP, ISUP, ТСАР системы сигнализации ОКС N 7 в оборудовании узла связи осуществляется в соответствии с требованиями к параметрам технических и программных средств, используемых для обеспечения систем сигнализации, установленными в приложении N 3 к Правилам применения транзитных междугородных узлов автоматической коммутации. Часть I. Правила применения транзитных междугородных узлов связи, использующих систему сигнализации по общему каналу сигнализации N 7 (ОКС N 7), утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 16.05.2006 N 59 (зарегистрирован в Министерстве юстиции Российской Федерации 29 мая 2006 года, регистрационный N 7879), за исключением:
    
    а) пунктов П.3.2.3.15 - П.3.2.3.17;
    
    б) сообщений в пункте П.3.2.4.1 и таблице П.3.1: "Отбой вызывающего абонента" (CCL - Clear calling line), "Вызов" RNG (Ring), "Последующее адресное сообщение" (SAM - Subsequent Address Message);
    
    в) сообщений в пункте П.3.2.4.1 и таблице П.3.2: "Запрос идентификации" (IDR - Identification Request), "Ответ на запрос идентификации" (IRS -Identification Response);
    
    г) подпункта 2) пункта П.3.2.4.6;
    
    д) пунктов П.3.2.4.9, П.3.2.4.10.
    
    3. Требования к параметрам подсистемы MAP.
    
    3.1. Перечень сообщений подсистемы MAP, реализованных в оборудовании узла связи, приведен в таблицах NN 1-19.
    

Таблица N 1

    
Общие сообщения

    
    
Таблица N 2

    
Сообщения управления местонахождением

    
    
Таблица N 3

    
Пейджинг и поиск

    
    
Таблица N 4

    
Сообщения управления доступом

    
    
Таблица N 5

    
Сообщения для реализации хэндовера

Таблица N 6

Сообщения управления аутентификацией

Таблица N 7

Сообщения управления безопасностью

Таблица N 8

Сообщения идентификации оборудования

Таблица N 9

Сообщения управления абонентскими данными

Таблица N 10

Сообщения управления идентичности

Таблица N 11

Сообщения восстановления ошибки

Таблица N 12

Сообщения запроса абонентской информации

Таблица N 13

Сообщения отслеживания абонента

Таблица N 14

Сообщения для реализации функций эксплуатации
и технического обслуживания

Таблица N 15

Сообщения обработки вызова

Таблица N 16

Сообщения, связанные с дополнительными видами обслуживания

Таблица N 17

Сообщения для сервиса коротких сообщений

Таблица N 18

Сообщения сетевого запроса активации пакетной передачи данных

Таблица N 19

Сообщения управления службой определения местонахождения

    
    
    4. Оборудование узла связи обеспечивает работу по системе одностороннего отбоя.
    
    

Приложение N 7
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам акустических сигналов

    
    
    1. Для информирования вызывающего и вызываемого абонентов о состоянии соединения используются информационные акустические сигналы, формируемые генераторами сигналов тональной частоты, и фразы автоинформатора.
    
    1.1. Оборудование узла связи передает следующие основные акустические сигналы:
    
    а) "Контроль посылки вызова" (далее - КПВ) - информирует вызывающего абонента о посылке вызывного сигнала вызываемому абоненту;
    
    б) "Занято" - информирует абонента о занятости вызываемого абонента после набора номера или об отбое другого абонента после разговора;
    
    в) "Занято при перегрузке" - информирует вызывающего абонента об отказе в обслуживании из-за отсутствия свободных соединительных линий или станционных приборов;
    
    г) "Указательный сигнал" - информирует абонента о невозможности установления соединения из-за устойчивой причины;
    
    д) "Сигнал уведомления" - информирует абонента, занятого в разговоре, о поступлении к нему нового вызова;
    
    е) "Контроль посылки сигнала уведомления (Ожидание)" - информирует вызывающего абонента о посылке вызываемому абоненту сигнала уведомления.
    
    Параметры информационных акустических сигналов приведены в таблице N 1.
    

Таблица N 1

    
Параметры информационных акустических сигналов

    
    
    1.2. Частоты сигналов, указанные в таблице N 1, имеют синусоидальную форму с коэффициентом нелинейных искажений не более 5%.
    
    1.3. Нестабильность частот, указанных в таблице N 1, не более 0,5%.
    
    1.4. Сигнал КПВ и "Сигнал уведомления" начинаются с посылки.
    
    1.5. Последовательность подачи трех частот сигнала "Указательный сигнал": низкая, средняя, высокая. Допускается пауза между частотами внутри посылок длительностью до 0,03.
    
    2. Оборудование узла связи передает абонентам фразы автоинформатора при предоставлении абоненту основных и дополнительных видов обслуживания.
    
    2.1. Основные фразы автоинформатора передаются при условиях, приведенных в таблице N 2.
    

Таблица N 2

    
Основные фразы автоинформатора

    
    
Приложение N 8
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам системы учета данных для начисления платы

    
    
    1. Система учета данных для начисления платы (далее - СУД) выполняет следующие функции:
    
    а) сбор и хранение учетных данных с целью последующего определения стоимости, для следующих видов учетного трафика:
    
    исходящие и входящие соединения между абонентами СПРС;
    
    исходящие и входящие соединения с абонентами сетей подвижной радиотелефонной связи других стандартов;
    
    исходящие и входящие соединения с абонентами СФТС;
    
    исходящие и входящие междугородные, международные соединения;
    
    исходящие соединения к экстренным оперативным службам;
    
    соединения с использованием услуг дополнительных видов обслуживания;
    
    соединения для абонента, находящегося в роуминге;
    
    соединения с использованием услуги передачи.
    
    б) обеспечение вывода учетной информации на промежуточное электронное запоминающее устройство или по каналу передачи данных в автоматизированную систему расчетов (далее - АСР);
    
    в) контроль функционирования системы учета.
    
    2. Формирование учетных данных в СУД осуществляется при предоставлении всех видов учетного трафика.
    
    3. Формирование учетных данных начинается с момента индикации ответа вызываемого абонента (службы) и прекращается при отбое любого из абонентов.
    
    4. Для обеспечения функций учета СУД создает запись, регистрирующую следующие основные данные:
    
    а) категория и номер вызывающего абонента или адресная информация вызывающей стороны;
    
    б) номер вызываемого абонента (службы) или адресная информация вызываемой стороны;
    
    в) дата (день, месяц, год) и время начала соединения (час, минута, секунда);
    
    г) продолжительность соединения или время окончания соединения (час, минута, секунда);
    
    д) используемые в соединении услуги;
    
    е) объем передаваемой информации, в случае установления соединений для передачи данных.
    
    5. В учетной записи фиксируются дополнительные данные, необходимые для определения стоимости разговоров, такие как:
    
    а) роуминговый номер подвижного абонента СПРС, местоположение абонентской радиостанции при ее передвижении;
    
    б) индикатор записи (одиночная, промежуточная запись).
    
    6. Для каждого соединения в СУД создается либо обычная одиночная запись, либо несколько промежуточных записей. Промежуточная запись создается для соединений большой длительности.
    
    7. В СУД поступают данные текущего времени (год, месяц, день, часы, минуты, секунды) от оборудования узла связи.
    
    8. Погрешность при измерении продолжительности соединения не превышает 1 с.
    
    9. Погрешность при измерении количества (объема) передаваемой информации при передаче данных не превышает следующих значений:
    
    
    
где: К - количество (объем) передаваемой информации в байтах; К - погрешность при измерении количества передаваемой информации в байтах.
    
    10. Вероятность неправильной работы систем измерений длительности соединений или систем измерений количества (объема) передаваемой информации, выражающейся в превышении допустимой погрешности измерений длительности соединения или количества (объема) передаваемой информации или недостоверном определении номеров абонентов, не превышает 10.
    
    11. СУД обеспечивает хранение учетных данных.
    
    12. Передача информации в АСР осуществляется в виде файлов с использованием стандартных сетевых протоколов и открытых интерфейсов или с использованием промежуточных электронных запоминающих устройств.
    
    13. Для бесперебойной работы СУД обеспечиваются дублирование и резервирование устройств. В случае возникновения отказов или неисправностей в оборудовании СУД, а также в процессе передачи информации в АСР, в систему управления и технического обслуживания посылаются соответствующие сигналы, одновременно осуществляется запись сведений о неисправностях.
    
    14. В СУД предусмотрена система защиты от несанкционированного доступа к информации.
    
    15. В СУД обеспечена возможность установки обслуживающим персоналом параметров, регистрируемых в записях о соединениях, и типов записей.
    
    16. В СУД обеспечивается функция немедленного вывода на устройство технического обслуживания учетной информации для оперативной обработки данных.
    
    

Приложение N 9
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам протоколов передачи данных

    
    
    1. В СПРС передача данных осуществляется с использованием службы пакетной передачи данных через радиоинтерфейс GPRS, которая состоит из следующего оборудования:
    
    - узел текущей поддержки пакетной передачи данных SGSN (далее - УТПД);
    
    - шлюзовый узел поддержки пакетной передачи данных GGSN (далее - УШПД).
    
    2. Требования к параметрам протокола сетевой службы NS.
    
    2.1. Формат блока данных протокола (PDU) NS приведен в таблице N 1.
    

Таблица N 1

    
Формат блока данных NS

    
    
    2.2. Типы блоков данных протокола NS:
    
    а) Работоспособное состояние.
    
    б) Работоспособное состояние - Подтверждение.
    
    в) Блокировка.
    
    г) Блокировка - Подтверждение.
    
    д) Сброс.
    
    е) Сброс - Подтверждение.
    
    ж) Статус.
    
    з) Разблокировка.
    
    и) Разблокировка - Подтверждение.
    
    к) Данные без соединения.
    
    2.3. Структура информационного элемента протокола NS приведена в таблице N 2.
    

Таблица N 2

    
Структура информационного элемента протокола NS

    
    
    2.3.1. Идентификатор информационного элемента определяет тип информационного элемента.
    
    2.3.2. Индикатор длины - поле размером 1 или 2 байта. Поле содержит бит расширения (бит N 8), размер информационного поля, следующего за полем индикатора длины. Если бит расширения имеет значение 1, поле индикатора длины состоит из одного байта.
    
    2.4. Информационные элементы протокола NS:
    
    2.4.1. Идентификатор виртуальных соединений протокола BSSGP для подсистемы базовых станций (далее - БС).
    
    2.4.2. Причина.
    
    2.4.3. Блок данных протокола.
    
    2.4.4. Сервисный блок данных.
    
    2.4.5. Идентификатор виртуальных соединений.
    
    2.4.6. Идентификатор объекта сетевой службы.
    
    2.4.7. Резервный байт.
    
    3. Требования к параметрам протокола пакетной передачи данных для подсистемы базовых станций - BSSGP.
    
    3.1. Формат блока данных протокола BSSGP приведен в таблице N 3.
    

Таблица N 3

    
Формат блока данных протокола BSSGP

    
    
    3.2. Типы блоков данных протокола BSSGP:
    
    3.2.1. Передача данных без соединения по линии "вниз".
    
    3.2.2. Передача данных без соединения по линии "вверх".
    
    3.2.3. Возможность радиодоступа.
    
    3.2.4. Режим пейджинговой связи с коммутацией пакетов.
    
    3.2.5. Режим пейджинговой связи с коммутацией каналов.
    
    3.2.6. Обновление возможности радиодоступа.
    
    3.2.7. Подтверждение обновления возможности радиодоступа.
    
    3.2.8. Радио статус.
    
    3.2.9. Приостановление.
    
    3.2.10. Подтверждение приостановления.
    
    3.2.11. Отрицательное подтверждение приостановления.
    
    3.2.12. Продолжение.
    
    3.2.13. Подтверждение продолжения.
    
    3.2.14. Отрицательное подтверждение продолжения.
    
    3.2.15. Сброс логического соединения.
    
    3.2.16. Подтверждение сброса логического соединения.
    
    3.2.17. Отказ от управления логическим соединением.
    
    3.2.18. Управление потоком в виртуальном соединении протокола BSSGP в подсистеме БС.
    
    3.2.19. Подтверждение управления потоком в виртуальном соединении протокола BSSGP в подсистеме БС.
    
    3.2.20. Управление потоком для АС.
    
    3.2.21. Подтверждение управления потоком для АС.
    
    3.2.22. Блокирование виртуального соединения протокола BSSGP в подсистеме БС.
    
    3.2.23. Подтверждение блокирования виртуального соединения протокола BSSGP в подсистеме БС.
    
    3.2.24. Разблокирование виртуального соединения протокола BSSGP в подсистеме БС.
    
    3.2.25. Подтверждение разблокирования виртуального соединения протокола BSSGP в подсистеме БС.
    
    3.2.26. Восстановление (перезапуск) виртуального соединения протокола BSSGP в подсистеме БС.
    
    3.2.27. Подтверждение восстановления виртуального соединения протокола BSSGP в подсистеме БС.
    
    3.2.28. Статус.
    
    3.2.29. Вызов трейса узлом текущей поддержки.
    
    3.3. Структура информационного элемента протокола BSSGP приведена в таблице N 4.
    

Таблица N 4

    
Структура информационного элемента протокола BSSGP

    
    
    3.4. Информационные элементы протокола BSSGP:
    
    3.4.1. Размер блока виртуального соединения для АС, устанавливаемый по умолчанию.
    
    3.4.2. Индикатор зоны обслуживания подсистемы БС.
    
    3.4.3. Скорость передачи пакетов.
    
    3.4.4. Максимальный размер блока виртуального соединения.
    
    3.4.5. Идентификатор виртуального соединения.
    
    3.4.6. Среднее значение задержки из-за пребывания пакета блока виртуального соединения в очереди.
    
    3.4.7. Причина.
    
    3.4.8. Идентификатор соты.
    
    3.4.9. Необходимость в канале.
    
    3.4.10. Параметры прерывистого приема.
    
    3.4.11. Приоритет услуги расширенного многоуровневого приоритета и прерывания обслуживания.
    
    3.4.12. Количество блоков данных протокола управления логическим соединением удаленных и переданных по команде от УТПД.
    
    3.4.13. Международный номер АС.
    
    3.4.14. Блок данных протокола управления логическим соединением.
    
    3.4.15. Количество аннулированных в подсистеме БС кадров управления логическим соединением.
    
    3.4.16. Идентификатор области местонахождения.
    
    3.4.17. Идентификаторы АС.
    
    3.4.18. Размер блока виртуальных соединений, передаваемый АС.
    
    3.4.19. Возможности АС по осуществлению радиодоступа.
    
    3.4.20. Идентификатор ЦУиТО.
    
    3.4.21. Ошибка входящего пакета.
    
    3.4.22. Время пребывания блока данных протокола в пределах подсистемы БС.
    
    3.4.23. Приоритет блока данных протокола.
    
    3.4.24. Качество обслуживания при передаче пакетов данного типа.
    
    3.4.25. Причины неуспешного разъединения соединения в радиоканале.
    
    3.4.26. Индикатор выполнения/невыполнения запроса обновление возможности радиодоступа.
    
    3.4.27. Идентификатор зоны маршрутизации данных.
    
    3.4.28. Величина скорости передачи АС, применяемая по умолчанию.
    
    3.4.29. Эталонная последовательность информационного элемента.
    
    3.4.30. Маркер, используемый для связи блоков данных запроса и ответа.
    
    3.4.31. Временный идентификатор логического канала.
    
    3.4.32. Временный номер абонента.
    
    3.4.33. Эталонная последовательность, используемая для трассировки.
    
    3.4.34. Тип трассировки.
    
    3.4.35. Идентификатор транзакции.
    
    3.4.36. Идентификатор инициатора трассировки.
    
    3.4.37. Количество переданных или удаленных подсистемой БС октетов для данной АС.
    
    4. Требования к параметрам протокола сходимости подсетей SNDCP.
    
    4.1. Формат блока данных протокола SNDCP для передачи данных с подтверждением приема (SN-DATA) приведен в таблице N 5.
    

Таблица N 5

    
Формат блока данных протокола SNDCP для передачи
данных с подтверждением приема

    
    
    4.2. Формат блока данных протокола SNDCP для передачи данных без подтверждения приема (SN-UNITDATA) приведен в таблице N 6.
    

Таблица N 6

    
Формат блока данных протокола SNDCP для передачи
данных без подтверждения приема

    
    
    4.3. Значения полей блока данных протокола SNDCP:
    
    4.3.1. Идентификатор точки доступа к сетевому сервису принимает следующие значения:
    
    а) 0 - механизм отмены;
    
    б) 1 - передача в режиме "точка-многоточие";
    
    в) 2-4 - резерв;
    
    г) 5-15 - динамически выделяемое значение.
    
    4.3.2. Флаг наличия дополнительных сегментов принимает следующие значения:
    
    а) 0 - последний сегмент N-PDU;
    
    б) 1 - данный сегмент N-PDU не является последним.
    
    4.3.3. Идентификатор типа пакета принимает следующие значения:
    
    а) 0 - пакет SN-DATA;
    
    б) 1 - пакет SN-UNITDATA.
    
    4.3.4. Индикатор компрессии принимает следующие значения:
    
    а) 0 - поля компрессии DCOMP и РСОМР не включены в пакет;
    
    б) 1 - наличие полей компрессии DCOMP и РСОМР в пакете.
    
    4.3.5. Резервное поле принимает значение 0.
    
    4.3.6. Идентификатор компрессии управляющей информации протокола принимает следующие значения:
    
    а) 0 - компрессия не используется;
    
    б) 1-14 - указывает на динамически согласуемые идентификаторы компрессии данных;
    
    в) 15 - зарезервировано.
    
    4.3.7. Идентификатор компрессии данных принимает следующие значения:
    
    а) 0 - компрессия не используется;
    
    б) 1-14 - указывает на динамически согласуемые идентификаторы компрессии данных;
    
    в) 15 - зарезервировано.
    
    4.3.8. Номер N-PDU принимает следующие значения:
    
    а) 0-2047 - при нулевом значении бита расширения;
    
    б) 2048-524287 - в тех случаях, когда бит расширения равен 1.
    
    4.3.9. Бит расширения принимает следующие значения:
    
    а) 0 - следующий байт содержит данные;
    
    б) 1 - следующий байт содержит расширение N-PDU.
    
    5. Требования к параметрам протокола туннелирования для пакетной передачи данных GTP.
    
    5.1. Формат пакета управления протокола GTP приведен в таблице N 7.
    

Таблица N 7

    
Формат пакета управления протокола GTP

    
    
    5.2. Сообщения протокола GTP.
    
    5.2.1. Сообщения управления каналом между узлами поддержки GPRS (GSN).
    
    5.2.1.1. Запрос "эхо".
    
    5.2.1.2. Ответ "эхо".
    
    5.2.2. Сообщения управления "туннелем".
    
    5.2.2.1. Запрос создания контекста протокола пакетной передачи данных (PDP).
    
    5.2.2.2. Ответ создания контекста PDP.
    
    5.2.2.3. Запрос обновления контекста PDP.
    
    5.2.2.4. Ответ обновление контекста PDP.
    
    5.2.2.5. Запрос удаления контекста PDP.
    
    5.2.2.6. Ответ удаления контекста PDP.
    
    5.2.2.7. Запрос создания контекста PDP при анонимном доступе.
    
    5.2.2.8. Ответ создания контекста PDP при анонимном доступе.
    
    5.2.2.9. Запрос удаления контекста PDP при анонимном доступе.
    
    5.2.2.10. Ответ удаления контекста PDP при анонимном доступе.
    
    5.2.2.11. Ошибочная индикация.
    
    5.2.2.12. Запрос уведомления.
    
    5.2.2.13. Ответ уведомления.
    
    5.2.2.14. Запрос отказа в уведомлении.
    
    5.2.2.15. Ответ отказа в уведомлении.
    
    5.2.3. Сообщения, используемые для определения местонахождения АС при запросе активации контекста протокола пакетной передачи данных со стороны сети и отсутствии интерфейса УШПД с ОРМ.
    
    5.2.3.1. Запрос передачи информации маршрутизации для GPRS.
    
    5.2.3.2. Ответ передачи информации маршрутизации для GPRS.
    
    5.2.3.3. Запрос уведомления об ошибке.
    
    5.2.3.4. Ответ уведомления об ошибке.
    
    5.2.3.5. Запрос: АС отмечена для GPRS.
    
    5.2.3.6. Ответ: АС отмечена для GPRS.
    
    5.2.4. Сообщения управления мобильностью.
    
    5.2.4.1. Запрос идентификации.
    
    5.2.4.2. Ответ идентификации.
    
    5.2.4.3. Запрос контекста УТПД.
    
    5.2.4.4. Ответ контекста УТПД.
    
    5.2.4.5. Подтверждение контекста УТПД.
    
    5.3. Информационные элементы сообщений протокола GTP.
    
    5.3.1. Причина.
    
    5.3.2. Международный идентификатор АС.
    
    5.3.3. Идентификатор зоны маршрутизации.
    
    5.3.4. Временный идентификатор АС.
    
    5.3.5. Временный идентификатор АС для режима пакетной передачи данных.
    
    5.3.6. Профиль качества обслуживания.
    
    5.3.7. Требование переупорядочения.
    
    5.3.8. Триплет аутентификации.
    
    5.3.9. Причина MAP.
    
    5.3.10. Подпись идентификатора АС для режима пакетной передачи данных.
    
    5.3.11. Подтверждение АС.
    
    5.3.12. Восстановление.
    
    5.3.13. Режим выбора.
    
    5.3.14. Метка потока данных N I.
    
    5.3.15. Метка потока сигнализации.
    
    5.3.16. Метка потока данных N II.
    
    5.3.17. Заряженный идентификатор.
    
    5.3.18. Конечный адрес пользователя.
    
    5.3.19. Контекст управления мобильностью.
    
    5.3.20. Контекст пакета данных протокола.
    
    5.3.21. Имя точки доступа.
    
    5.3.22. Конфигурация опций протокола.
    
    5.3.23. Адрес узлов поддержки.
    
    5.3.24. Международный номер АС.
    
    5.3.25. Частное расширение.
    
    6. Требования к параметрам по реализации протокола IP.
    
    6.1. Формат заголовка пакета IP версии 4 (далее - IPv4) и перечень поддерживаемых полей приведен в таблице N 8.
    
    6.1.1. Минимальная длина заголовка пакета составляет 20 байт, а максимальная длина - 60 байт при максимальной длине пакета в 65535 байт.
    
    6.1.2. Поле "Версия" содержит номер версии протокола IP.
    
    6.1.3. Поле "Длина заголовка" содержит значение длины заголовка пакета в словах.
    

Таблица N 8

    
Формат заголовка пакета IPv4

    
    
    6.1.4. Поле "Тип обслуживания" содержит код набора параметров качества обслуживания:
    
    а) приоритетность;
    
    б) задержка;
    
    в) пропускная способность;
    
    г) надежность.
    
    6.1.5. Кодирование поля "Тип обслуживания" приведено в таблице N 9.
    

Таблица N 9

    
Кодирование поля "Тип обслуживания"

    
    
    Значения разрядов 0-2 игнорируются, если оборудование не поддерживает управление приоритетом при передаче пакетов.
    
    6.1.6. Поле "Длина пакета IP" содержит значение длины пакета IP в байтах, включая заголовок и данные. Возможность обрабатывать пакеты длиной менее 576 байт является обязательным требованием. В отдельных случаях допускается длина пакета до 65535 байт.
    
    6.1.7. Поле "Идентификатор пакета IP" используется процедурой фрагментации при сборке или разборке пакета для определения последовательности передаваемых фрагментов.
    
    6.1.8. Поле "Флаги" используется процедурой фрагментации для управления последовательностью сборки фрагментов пакета. Кодирование разрядов поля "Флаги" приведено в таблице N 10.
    

Таблица N 10

    
Кодирование разрядов поля "Флаги"

    
    
    6.1.9. Поле "Смещение фрагмента" используется для указания смещения данного фрагмента относительно первого фрагмента в блоках фрагментации (8 байт). Для первого фрагмента смещение устанавливается в "0".
    
    6.1.10. Поле "Счетчик допустимого времени пребывания пакета в сети" содержит текущее значение счетчика максимально допустимого времени пребывания пакета в сети в секундах. Если в поле находится значение "0", пакет удаляется.
    
    6.1.11. Поле "Тип протокола следующего уровня" содержит стандартизированный код протокола следующего уровня.
    
    6.1.12. Поле "Контрольная последовательность заголовка" (далее - КПЗ) содержит контрольную последовательность заголовка. При любом изменении содержания заголовка КПЗ пересчитывается.
    
    6.1.13. В поле "Адрес источника пакета" указывается IP-адрес источника пакета.
    
    6.1.14. В поле "Адрес получателя пакета" указывается IP-адрес получателя пакета.
    
    6.1.15. Поддерживаются два способа кодирования поля "Режим обработки пакета":
    
    а) поле длиной 1 байт,
    
    б) комбинация трех подполей: тип режима (1 байт), счетчик длины поля режима (1 байт), данные режима (переменная длина).
    
    Подполе типа режима включает: флаг (1 бит), класс режима (2 бита), номер режима (5 бит).
    
    При установке бита флага в значение "1" оборудование копирует данное поле при фрагментации во все фрагменты, в значение "0" - не копирует.
    
    6.1.16. Для выравнивания границы заголовка по длине, кратной 32 битам, используется "Поле дополнения до границы заголовка". Свободные позиции заполняются нулевыми битами.
    
    6.2. Формат заголовка пакета IP версии 6 (далее - IPv6) и перечень поддерживаемых полей приведен в таблице N 11. Минимальная длина заголовка пакета составляет 40 байт, длина пакета составляет до 1280 байт или выше (до 1500 байт) без фрагментации.
    

Таблица N 11

    
Формат заголовка пакета IPv6

    
    
    6.2.1. Поле "Версия" содержит номер версии протокола IP.
    
    6.2.2. Поле "Класс трафика" эквивалентно по назначению полю "Тип обслуживания" протокола IPv4 и используется для назначения и различия разных классов или приоритетов передачи пакетов.
    
    6.2.3. Поле "Метка потока" используется для выделения последовательностей пакетов, для которых запрашивается специальная обработка пакетов IP, например предоставление качества обслуживания, отличающегося от принятого, или обслуживание в реальном времени. Оборудование, не поддерживающее функции поля "Метка потока", устанавливает значение данного поля в ноль при отправке пакета, передает дальше данное поле без изменений при пересылке пакета и игнорирует данное поле при получении пакета.
    
    6.2.4. Поле "Длина полезной нагрузки" содержит значение длины полезной нагрузки пакета IPv6 в байтах.
    
    6.2.5. Поле "Следующий заголовок" определяет тип заголовка, следующего непосредственно за основным, и использует те же значения разрядов, что и поле "Тип протокола следующего уровня" протокола IPv4.
    
    6.2.6. В протоколе IPv6 информация уровня Интернет сети передачи данных кодируется в отдельных дополнительных заголовках, которые размещаются между заголовком IPv6 и заголовком следующего уровня в пакете.
    
    6.2.7. Каждый дополнительный заголовок является целым числом и имеет длину, кратную 8 байтам.
    
    6.2.8. В рамках протокола IPv6 определены следующие шесть дополнительных заголовков:
    
    - "Специальные параметры обработки пакетов";
    
    - "Маршрутизация";
    
    - "Фрагментация";
    
    - "Дополнительные параметры для пункта назначения";
    
    - "Аутентификация";
    
    - "Информация для обеспечения конфиденциальности данных путем шифрования".
    
    6.2.9. Значение поля "Лимит переходов" основного заголовка IPv6 уменьшается на 1 в каждом пункте, который участвует в пересылке пакета. Пакет удаляется, если значение этого поля уменьшается до нуля.
    
    6.2.10. В поле "Адрес отправителя" основного заголовка IPv6 указывается IP-адрес отправителя пакета.
    
    

Приложение N 10
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам протокола MEGACO/H.248

    
    
    1. Протокол MEGACO/H.248 обеспечивает:
    
    а) добавление соединения в сеанс связи;
    
    б) изменение конфигурации соединения;
    
    в) удаление соединения из сеанса связи;
    
    г) перемещение соединения в другой сеанс связи;
    
    д) контроль и диагностику соединений;
    
    е) определение возможностей МШ;
    
    ж) уведомление о событиях, произошедших в медиашлюзах;
    
    з) уведомление оборудования узла связи (далее - сервера), осуществляющего управление МШ, об отказах на входе/выходе (далее - портов) медиашлюзов.
    
    2. Поддерживается два способа кодирования полей команд протокола MEGACO/H.248:
    
    а) в виде текстовых строк;
    
    б) в бинарном виде.
    
    3. Команды протокола MEGACO/H.248.
    
    3.1. Добавление соединения в сеанс связи осуществляется с использованием команды "Добавить". При первом получении от сервера команды "Добавить" создается сеанс связи. Добавление первого соединения в пустой сеанс связи обеспечивает создание сеанса связи.
    
    Команда "Добавить" передается в направлении от сервера к МШ.
    
    3.2. Изменение конфигурации соединения осуществляется с использованием команды "Изменить". Команда передается в направлении от сервера к МШ.
    
    3.3. Удаление соединения из сеанса связи осуществляется с использованием команды "Отключить". При удалении последнего соединения обеспечивается удаление всего сеанса связи. Команда передается в направлении от сервера к МШ.
    
    3.4. Перемещение соединения в другой сеанс связи осуществляется с использованием команды "Перевести". Команда передается в направлении от сервера к МШ.
    
    3.5. Контроль и диагностика существующего соединения осуществляется с использованием команды "Проверить порт". Команда передается в направлении от сервера к МШ.
    
    3.6. Запрос о возможностях порта медиашлюза, о событиях, которые обнаружены портом, список сигналов, которые порт передает в канал, осуществляется с использованием команды "Проверить возможности порта". Команда передается в направлении от сервера к МШ.
    
    3.7. Уведомление сервера о событиях, произошедших на портах медиашлюзов, осуществляется с использованием команды "Уведомить". Команда передается в направлении от МШ к серверу.
    
    3.8. Команда "Рестарт" обеспечивает выполнение функций уведомления об отказах порта или группы портов медиашлюза и уведомление о восстановлении их работоспособности. В этом случае команда "Рестарт" передается в направлении от МШ к серверу. Когда сервер предписывает МШ вывести из обслуживания порт или группу портов или вернуть их в обслуживание, команда "Рестарт" передается от- сервера к МШ.
    
    

Приложение N 11
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам протокола MGCP

    
    
    1. Протокол MGCP обеспечивает:
    
    а) согласование вида кодирования (модуляции) сигнала между двумя МШ;
    
    б) распознавание вида передаваемой информации (например, голосовая информация, факсимильные сообщения, данные), определение состояния оконечного оборудования;
    
    в) установление соединения;
    
    г) освобождение соединения;
    
    д) освобождение соединения конфигурации "точка-несколько точек";
    
    е) контроль и диагностика портов медиашлюзов;
    
    ж) контроль и диагностика соединений;
    
    з) уведомление сервера об освобождении ресурсов медиашлюзов.
    
    2. Команды протокола MGCP.
    
    2.1. Согласование типа модуляции сигнала между двумя МШ осуществляется с использованием команды "Конфигурация порта". Дополнительно команда обеспечивает инициализацию МШ. Команда передается в направлении от сервера к МШ.
    
    2.2. Распознавание вида передаваемой информации, определение состояний оконечного оборудования осуществляется с использованием команды "Запрос уведомления". Команда передается в направлении от сервера к МШ.
    
    2.3. Команда "Уведомить" передается в направлении от МШ к серверу при обнаружении событий, описанных в поле "Запрос событий" команды "Запрос уведомления".
    
    2.4. Установление соединения между двумя МШ осуществляется с использованием сообщения "Создать соединение". Команда передается в направлении от сервера к МШ.
    
    2.5. Изменение конфигурации соединения осуществляется с использованием команды "Модифицировать соединение". Команда передается в направлении от сервера к МШ.
    
    2.6. Освобождение соединения обеспечивается командой "Завершить соединение". Формат команды различается в зависимости от устройства, по инициативе которого освобождается соединение: сервер или МШ, а также от назначения команды: для освобождения всех соединений, относящихся к одному соединению или для безусловного освобождения всех соединений на МШ.
    
    2.6.1. Параметр "Причина освобождения соединения" при передаче команды "Завершить соединение" от МШ к серверу принимает следующие значения:
    
    а) 000 при штатном освобождении соединения;
    
    б) 900 при освобождении соединения из-за неисправности МШ;
    
    в) 901 при освобождении соединения из-за отключения МШ;
    
    г) 902 при освобождении соединения из-за ухудшения его характеристик ниже допустимого уровня.
    
    При освобождении соединения передается следующая информация:
    
    а) количество переданных пакетов RTP;
    
    б) количество переданных октетов RTP;
    
    в) количество полученных пакетов RTP;
    
    г) количество полученных октетов RTP;
    
    д) количество потерянных пакетов RTP;
    
    е) отклонения величины задержки получения пакетов RTP в мс;
    
    ж) средняя задержка передачи пакетов RTP по сети в мс.
    
    2.7. Контроль и диагностика портов МШ осуществляются командой "Проверить порт". Команда передается в направлении от сервера к МШ.
    
    2.8. Контроль и диагностика соединения осуществляются командой "Проверить соединение". Команда передается в направлении от сервера к МШ.
    
    2.9. Команда "Идет рестарт" используется МШ для уведомления сервера о том, что МШ находится в процессе перезагрузки (возвращение порта или группы портов в рабочее состояние или вывод порта или группы портов из рабочего состояния). Команда передается в направлении от МШ к серверу.
    
    

Приложение N 12
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам протокола BICC

    
    
    1. Сообщение протокола BICC состоит из целого числа октетов и содержит следующие поля:
    
    а) код вызова;
    
    б) код типа сообщения;
    
    в) обязательная часть параметров постоянной длины;
    
    г) обязательная часть параметров переменной длины;
    
    д) необязательная часть параметров постоянной длины;
    
    е) необязательная часть параметров переменной длины.
    
    На рисунке приведен формат сообщения протокола BICC.
    

    
Рисунок. Формат сообщения протокола BICC

    
    
    2. Названия сообщений и их коды приведены в таблице.
    

Таблица

Сообщения и коды протокола BICC

    
    
Приложение N 13
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам протокола SIP

    
    
    1. Команды SIP передаются на порт с номером 5060 по умолчанию. Команды передаются на другой порт узла связи, если номер этого порта заранее известен отправителю.
    
    2. Оборудование узла связи реализует функции следующих элементов сети SIP: агент абонента, прокси-сервер, сервер регистрации и сервер перенаправления.
    
    3. Протокол SIP использует принцип адресации, где в качестве адресов используются унифицированные указатели ресурсов SIP URL: имя@домен, имя@хост, имя@IР-адрес, номер телефона@шлюз.
    
    4. Сообщения SIP разделяются на запросы обслуживаемой стороны (далее - клиента) к обслуживающей стороне (далее - серверу) и ответы сервера к клиенту.
    
    Оба типа сообщений состоят из начальной (стартовой) строки, одной или более строк заголовка, пустой строки, указывающей на конец заголовка, и необязательной части сообщения - тела. Стартовая строка, каждая строка поля заголовка и пустая строка завершаются символом "возврат каретки".
    
    5. Запрос включает начальную строку, содержащую тип запроса, текущий узел, которому этот запрос адресован и номер версии протокола, разделенных пробелами, и заканчивается символом "возврат каретки".
    
    В сервере реализуется обработка сообщений, являющихся запросами: "Приглашение", "Подтверждение", "Завершение", "Отмена", "Регистрация", "Запрос", "Информация", "Подтверждение предварительного ответа", "Обновление параметров", "Запрос подписки", "Информация о текущем состоянии", "Предписание", "Сообщение", "Определение абонента в сети".
    
    5.1. Запрос "Приглашение" инициирует сеанс связи и содержит описание сеанса связи, вид принимаемой информации и параметры, необходимые для приема информации. Запрос может содержать вид информации, которую вызывающая сторона передает, и данные, необходимые для аутентификации абонента. При необходимости изменения характеристик подготовленных или уже используемых каналов, передается запрос "Приглашение" с новым описанием сеанса связи. Запрос "Приглашение" также используется для приглашения нового участника к уже установленному соединению.
    
    5.2. Запросом "Подтверждение" оборудование вызывающего пользователя подтверждает, что на свой запрос "Приглашение" оно получило ответ с содержанием окончательных параметров описания сеанса связи. На запрос "Подтверждение" не должен генерироваться ответ.
    
    5.3. Запрос "Завершение" используется для завершения соединения. Сторона, получившая запрос "Завершение", прекращает передачу голосовой (мультимедийной) информации и подтверждает это ответом 200.
    
    5.4. Запрос "Отмена" передается для отмены обработки ранее переданных запросов, но не влияет на те запросы, обработка которых уже завершена.
    
    5.5. При помощи запроса "Регистрация" абоненты сообщают свое текущее местоположение. В этом запросе содержатся заголовки "Логический адресат запроса", "Адрес отправителя запроса", "Текущий адрес абонента" с новым адресом абонента, по которому должны передаваться все дальнейшие запросы "Приглашение" (если в запросе "Регистрация" заголовок "Текущий адрес абонента" отсутствует, регистрация остается неизменной, а в случае отмены регистрации размещается символ "*"), и заголовок "Время жизни сообщения", в котором указывается время в секундах, по истечении которого регистрация заканчивается (если этот заголовок отсутствует, то по умолчанию назначается время - 1 час). Регистрация отменяется передачей сообщения "Регистрация" с заголовком "Время жизни сообщения", которому присвоено значение ноль, и с соответствующим заголовком "Текущий адрес абонента".
    
    5.6. Сообщением "Запрос" вызывающий абонент запрашивает информацию о возможностях терминального оборудования вызываемого абонента.
    
    5.7. Запрос "Информация" используется для переноса сообщений сигнализации ОКС N 7 в течение сеанса связи, для переноса тональных сигналов, созданных в ходе сеанса, для переноса информации об остатке на счете (информации о стоимости), для переноса между участниками сеанса связи изображений и другой информации.
    
    5.8. Запрос "Подтверждение предварительного ответа" используется для подтверждения предварительных ответов, при его получении требуется передача ответа. В запросе "Подтверждение предварительного ответа" указывается номер подтверждаемого предварительного ответа.
    
    5.9. Запрос "Обновление параметров" используется для изменения параметров сеанса до прихода окончательного ответа на запрос "Приглашение". При этом в поле заголовка "Поддерживаемые типы запросов" запроса "Приглашение" указывается тип запроса "Обновление параметров".
    
    5.10. Сообщение "Запрос подписки" используется для запроса информации о текущем состоянии и об обновлениях состояния удаленного ресурса. "Запрос подписки" подтверждается окончательным ответом.
    
    5.11. Запрос "Информация о текущем состоянии" передается после получения "Запроса подписки", а также после изменения состояния, на уведомление о котором была открыта подписка. Запрос "Информация о текущем состоянии" подтверждается окончательным ответом.
    
    5.12. Запрос "Предписание" информирует получателя связаться с третьей стороной, используя контактную информацию, которая содержится в запросе.
    
    5.13. Запрос "Сообщение" предназначен для передачи мгновенных текстовых сообщений, которые помещаются в тело запроса "Сообщение". При доставке сообщения получателю формируется ответ с кодом 200.
    
    6. Ответ на запрос включает начальную строку с полями, где указываются номер версии протокола, тип ответа и короткая расшифровка ответа. Все эти поля разделяются пробелом, а заканчивается строка символом "возврат каретки".
    
    Поле тип ответа состоит из трех цифр (код статуса), определяющих результат выполнения запроса.
    
    Протокол SIP определяет две группы ответов на запрос инициирующий соединение: предварительные и окончательные. Окончательные ответы несут результат обработки запроса и передаются с подтверждением. Предварительные ответы несут информацию о текущей стадии обработки запроса и передаются без подтверждения.
    
    6.1. Сервер SIP поддерживает классы ответов, приведенные в таблице N 1. Первая цифра поля кода статуса определяет класс ответа.
    

Таблица N 1

    
Классы ответов SIP

    
    
    Реализации SIP различают класс ответа (первую цифру кода). От реализаций SIP не требуется различать значения всех указанных кодов статуса. Нераспознанный ответ любого класса обрабатывается как код х00 данного класса.
    
    6.2. Ответы 1хх.
    
    100 - предназначен для обнуления таймеров.
    
    180 - вызываемому абоненту передается информация о вызове.
    
    181 - указывается в теле сообщения, к какому абоненту переправляется вызов.
    
    182 - используется в приложениях, которые позволяют ставить текущий вызов в очередь до тех пор, пока не будут обслужены вызовы, находящиеся перед ним.
    
    183 - используется для того, чтобы заранее получить описание сеанса информационного обмена от шлюзов на пути к вызываемому абоненту таким образом, чтобы мог быть проключен голосовой тракт в предответном состоянии до того, как вызывающий абонент получит сигнал КПВ.
    
    189 - используется для предоставления текущей информации о состоянии соединения, переключаемого на другой номер в фазе разговора. При этом ожидается получить либо ответ об успешной обработке, либо ответ об отказе вызываемой стороны.
    
    6.3. Ответы 2хх.
    
    200 - успешное выполнение запроса.
    
    202 - запрос принят для обработки, но обработка не завершена.
    
    6.4. Ответы 3хх.
    
    300 - указывает несколько SIP-адресов, по которым можно найти вызываемого абонента.
    
    301 - означает, что вызываемый абонент больше не находится по адресу, указанному в запросе, и направлять запросы нужно на адрес, указанный в поле заголовка "Текущий адрес абонента".
    
    302 - означает, что абонент временно (промежуток времени может быть указан в поле заголовка "Время жизни сообщения") находится по другому адресу, указанному в поле "Текущий адрес абонента".
    
    305 - означает, что вызываемый абонент не доступен непосредственно, входящий вызов должен пройти через прокси-сервер. Вызывающей стороне рекомендуется повторить запрос через прокси-сервер, адрес которого указан в поле заголовка "Текущий адрес абонента".
    
    380 - запрошенная услуга недоступна, но доступны альтернативные услуги, которые описаны в теле сообщения.
    
    6.5. Ответы 4хх.
    
    400 - означает, что запрос не понят из-за синтаксических ошибок в нем.
    
    401 - означает, что запрос требует проведения процедуры аутентификации абонента.
    
    403 - означает, что сервер понял запрос, но отказался его обслуживать. Повторный запрос не посылается.
    
    404 - сервер не обнаружил вызываемого абонента.
    
    405 - не разрешается передавать запрос этого типа на адрес, указанный в заголовке.
    
    406 - вызываемая сторона будет формировать ответы, которые не будут поняты вызывающей стороной.
    
    407 - перед вызовом требуется провести аутентификацию в прокси-сервере.
    
    408 - сервер не может передать ответ в течение времени, указанного вызывающим абонентом в заголовке "Время жизни сообщения" запроса.
    
    410 - сервер не имеет доступа к запрашиваемому ресурсу и не знает куда переадресовать запрос.
    
    413 - размер запроса слишком велик для обработки на сервере.
    
    414 - у сервера возникли трудности с интерпретацией адреса получателя из-за его длины.
    
    415 - сервер не может принять запрос, так как формат содержимого тела сообщения не поддерживается сервером для запроса данного типа.
    
    416 - сервер не может обработать запрос из-за того, что схема адреса получателя ему непонятна.
    
    420 - сервер не понимает расширение протокола SIP.
    
    421 - в заголовке запроса не указано, какое расширение сервер должен применить для его обработки.
    
    423 - сервер отклоняет запрос, так как время действия ресурса короткое.
    
    480 - соединение с оконечной системой установлено успешно, но абонент в данный момент недоступен.
    
    481 - сервер получил запрос не относящийся к текущему диалогу или транзакции. Запрос отбрасывается.
    
    482 - обнаружен замкнутый маршрут передачи запроса.
    
    483 - запрос на своем пути прошел через большее число прокси-серверов, чем разрешено.
    
    484 - принят запрос с неполным адресом.
    
    485 - означает, что адрес вызываемого абонента не однозначен.
    
    486 - означает, что вызываемый абонент в настоящий момент занят и не желает (не может) принять входящий вызов.
    
    487 - запрос был отменен сообщением "Завершение" или "Отмена".
    
    488 - соединение было установлено, но отдельные параметры описания сеанса связи недопустимы.
    
    489 - сервер не понял тип события, на которое осуществляется подписка или о котором передается уведомление.
    
    491 - запрос поступил в то время, когда сервер еще не закончил обработку другого запроса, относящегося к тому же диалогу.
    
    493 - сервер не в состоянии подобрать ключ дешифрования для тела сообщения.
    
    494 - ответ содержит используемые сервером механизмы обеспечения безопасности.
    
    6.6. Ответы 5хх.
    
    500 - означает, что сервер не имеет возможности обслужить запрос из-за внутренней ошибки. Клиент может попытаться повторно послать запрос через некоторое время.
    
    501 - означает, что в сервере не реализованы какие-либо функции, необходимые для обслуживания запроса. Ответ передается в том случае, когда сервер не может распознать тип запроса, полученного им от любого из абонентов.
    
    502 - информирует о том, что сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос.
    
    503 - указывает, что сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.
    
    504 - сервер не получил ответа в течение установленного промежутка времени от сервера, к которому он обратился для завершения вызова.
    
    505 - сервер не поддерживает или отказывается поддерживать версию протокола SIP, используемую в запросе.
    
    513 - сервер не в состоянии обработать запрос из-за большой длины сообщения.
    
    580 - сервер не принимает параметры, предлагаемые в описании сеанса, в ответе указывается причина отказа.
    
    6.7. Ответы 6хх.
    
    600 - вызываемый абонент занят и не желает принимать вызов в данный момент. Ответ может содержать указание на время, подходящее для нового вызова. Если с абонентом можно связаться по другому адресу или оставить сообщение, то используется ответ 486.
    
    603 - означает, что вызываемый абонент не желает принимать входящие вызовы, не указывая причину отказа.
    
    604 - означает, что вызываемого абонента не существует.
    
    606 - соединение с сервером было установлено, но отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания, вид адресации, не допустимы.
    
    7. Для предотвращения зацикливания прокси-сервер должен проверять наличие своего адреса в поле общего заголовка "Список элементов сети, через которые прошел запрос" при получении входящего запроса. Поля общего заголовка "Логический адресат запроса", "Адрес отправителя запроса", "Идентификатор сеанса связи" и "Текущий адрес абонента" должны быть скопированы из исходных полей.
    
    8. Поля заголовка команды SIP включают поля общего заголовка, заголовка запроса, заголовка ответа и заголовка содержания. Поля заголовка могут занимать несколько строк. Поле заголовка состоит из имени поля, символа "двоеточие" и значения поля.
    
    Порядок полей в заголовке не имеет значения. Прокси-сервер не изменяет порядок полей в перенаправляемом сообщении, а также не вносит изменения в заголовки, передаваемые от одного до другого оконечного устройства. Прокси-сервер может вносить изменения в заголовки, формируемые на промежуточных стадиях передачи сообщения.
    
    8.1. Заголовок содержания включает поля: кодирование тела сообщения, размер тела сообщения, тип содержимого.
    
    8.2. Поля общего заголовка используются и в запросах и в ответах и применяются к сообщению в целом, а не к передаваемому содержанию.
    
    8.3. Поля заголовка запроса передают информацию о запросе и о самом клиенте и передаются только в запросах.
    
    8.4. Поля заголовка ответа передаются только в ответах.
    
    В таблице N 2 приведены названия заголовков сообщений SIP и место их использования.
    

Таблица N 2

    
Названия заголовков сообщений SIP и место их использования

    
    
    9. Тело сообщения.
    
    Для запросов "Подтверждение", "Приглашение" и "Запрос" тело сообщения всегда содержит описание сессии. Запрос "Завершение" не содержит тела сообщения.
    
    Все ответы могут содержать тело сообщения. Ответы с кодом 1хх содержат консультативную информацию о состоянии выполняющегося запроса, ответы с кодом 2хх на запрос "Приглашение" содержат параметры описания сессии, в ответах с кодом 3хх может содержаться информация об альтернативных действиях или службах.
    
    10. Для переноса сообщений сигнализации ОКС N 7 по сети с коммутацией пакетов информации в ЦКП-сервере реализуется расширенная версия протокола SIP - протокол SIP-T. SIP-T использует процедуры, запросы и ответы протокола SIP.
    
    В SIP-T сообщения ОКС N 7 инкапсулируются в тело запроса SIP, а часть информации сообщения, необходимая для правильной маршрутизации, транслируется в заголовок запроса SIP.
    
    Преобразования сообщений протоколов ОКС N 7 в SIP и обратно осуществляются в ЦКП-сервере.
    
    

Приложение N 14
к Правилам применения
оборудования коммутации систем
подвижной радиотелефонной связи.
Часть II. Правила применения
оконечно-транзитных узлов связи
сетей подвижной радиотелефонной
связи стандарта GSM 900/1800

    
    
ТРЕБОВАНИЯ
к параметрам протоколов SIGTRAN

    
    
    1. В оборудовании узла связи реализованы следующие протоколы группы SIGTRAN:
    
    а) протокол SCTP;
    
    б) протокол M2UA;
    
    в) протокол M3UA;
    
    г) протокол SUA.
    
    2. Требования к параметрам протокола SCTP.
    
    2.1. Посредством протокола SCTP реализуются следующие функции:
    
    а) последовательная передача данных в потоке;
    
    б) фрагментация данных;
    
    в) идентификация передаваемых данных и процедура управления перегрузками;
    
    г) пакетирование сообщений пакета SCTP;
    
    д) подтверждение пакетов;
    
    е) управление путями.
    
    Формат пакета SCTP приведен на рисунке 1.
    

    
    
Рисунок 1. Формат пакета SCTP

    
    2.2. Формат заголовка пакета SCTP и перечень поддерживаемых полей приведены на рисунке 2 и в таблице N 1, соответственно.
    

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

    
    
Таблица N 1

    
Перечень полей

    
    
    2.3. Поля заголовка пакета SCTP содержат следующую информацию:
    
    а) поле "Номер порта источника" содержит номер порта SCTP отправителя;
    
    б) поле "Номер порта назначения" содержит номер порта SCTP получателя;
    
    в) поле "Метка верификации" содержит числовое значение, однозначно идентифицирующее отправителя пакета SCTP. Отправитель пакета SCTP устанавливает значение этой метки равное значению, полученному при инициализации сеанса связи между ним и получателем.
    
    г) поле "Контрольная сумма" содержит контрольную сумму пакета SCTP.
    
    2.4. Пакет SCTP включает в себя управляющие команды. Перечень допустимых команд приведен в таблице N 2.
    

Таблица N 2

    
Управляющие команды

    
    
    2.4.1. Пакет SCTP содержит в себе только одну команду, в случаях, когда передаются команды "Создание сеанса связи", "Подтверждение создания сеанса связи", "Процедура завершения сеанса связи окончена".
    
    2.5. Формат команды SCTP приведен на рисунке 3 и в таблице N 3 соответственно.
    

    
Рисунок 3. Формат команды SCTP

    
Таблица N 3

    
Формат команды SCTP

    
    
    2.5.1. Поля команды SCTP содержат следующую информацию;
    
    а) поле "Код команды" принимает численное значение в соответствии с таблицей N 3 и заполняется так, что первые два бита старшего разряда определяют действие, которое выполняется, в случае, если получателем не распознан код команды;
    
    б) поле "Флаги" содержат значения, специфичные для разных команд, при этом по умолчанию поле принимает значение, равное нулю;
    
    в) поле "Длина данных команды" содержит длину команды в байтах, включая поля: "Код команды", "Флаги", "Длина данных команды" и "Данные команды";
    
    г) поле "Данные команды" содержит информацию, специфичную для разных команд SCTP.
    
    2.5.2. Общая длина команды, входящей в SCTP-пакет, равна 4 байтам. Если ее длина не равна 4 байтам, то команда дополняется нулями до требуемой длины.
    
    2.5.3. Команда не дополняется более чем 3 байтами.
    
    2.6. Передача полезной нагрузки осуществляется только тогда, когда установлено соединение между принимающей и посылающей сторонами.
    
    2.6.1. При пакетировании информации абонента в порции пакета SCTP узел отправитель разбивает эту информацию на множество частей, размеры каждой из которых не превосходят по величине максимально допустимый размер.
    
    2.6.2. Узел-получатель собирает фрагментированные сообщения в единую информацию.
    
    2.6.3. Сообщения управления находятся в пакете перед данными абонента.
    
    2.6.4. Передача данных абонента адресату осуществляется, если размер окна приемника узла получателя не равно нулю. В противном случае данные не отсылаются в пункт назначения.
    
    2.6.5. Все пакеты, адресованные определенному узлу, устанавливаются в очередь и передаются в строгой последовательности.
    
    2.6.6. Узел-получатель формирует команду "Выборочное подтверждение" и передает ее совместно с исходящими данными противоположному узлу.
    
    2.6.7. Узел-отправитель не передает какую-либо полезную информацию, если не получено подтверждение на последнюю посланную команду.
    
    3. Требования к параметрам протокола M2UA.
    
    3.1. Значение номера порта SCTP для M2UA равно 2904. Идентификатор полезной нагрузки протокола SCTP для M2UA равен 2.
    
    3.2. Протокол M2UA при передаче сообщений сигнализации сети с коммутацией каналов выполняет следующие функции;
    
    а) поддержка границы интерфейсов МТР2/МТР3;
    
    б) поддержка взаимодействия между модулями уровня управления;
    
    в) поддержка управления активными соединениями SCTP.
    
    3.3. Протокол M2UA реализует следующие функции:
    
    а) отображение идентификатора интерфейса на физический интерфейс ШС, соединение SCTP и соответствующий поток трафика внутри соединения;
    
    б) управление соединением SCTP;
    
    в) поддержание состояния сервера приложений;
    
    г) управление потоком SCTP;
    
    д) управление потоком (перегрузками);
    
    е) проверка состояния канала ОКС N 7.
    
    3.4. Общий заголовок сообщения для M2UA имеет следующую структуру: версия, класс сообщения, тип сообщения, длина сообщения. Заголовок сообщения является общим для всех уровней адаптации протокола сигнализации и приведен на рисунке 4.
    

    
Рисунок 4. Формат общего заголовка

    
    
    Значения полей заголовка:
    
    а) в поле "Версия" содержится версия M2UA;
    
    б) значение поля "Резерв" установлено отправителем равным нулю и не учитывается получателем;
    
    в) в поле "Класс сообщения" содержатся следующие значения:
    
    0 - сообщения управления M2UA;
    
    1 - зарезервировано;
    
    2 - зарезервировано;
    
    3 - сообщения поддержания состояния процесса сервера приложений;
    
    4 - сообщения поддержания трафика процесса сервера приложений;
    
    5 - зарезервировано;
    
    6 - сообщения M2UA;
    
    7 - зарезервировано;
    
    8 - зарезервировано;
    
    9 - зарезервировано;
    
    10 - сообщения управления идентификатором интерфейса;
    
    11-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    г) в поле "Тип сообщения" содержатся следующие типы сообщений для соответствующих классов сообщений:
    
    Сообщения M2UA:
    
    0 - зарезервировано;
    
    1 - данные;
    
    2 - запрос на установление соединения;
    
    3 - подтверждение установления соединения;
    
    4 - запрос на разъединение соединения;
    
    5 - подтверждение разъединения соединения;
    
    6 - указатель на разъединение соединения;
    
    7 - запрос отчета о состоянии;
    
    8 - подтверждение состояния;
    
    9 - индикация состояния;
    
    10 - запрос на поиск данных;
    
    11 - подтверждение поиска данных;
    
    12 - индикация поиска данных;
    
    13 - полная индикация поиска данных;
    
    14 - указание перегрузка;
    
    15 - подтверждение получения данных;
    
    16-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    Сообщения поддержания состояния процесса сервера приложений:
    
    0 - зарезервировано;
    
    1 - инициация процесса сервера приложений;
    
    2 - завершение процесса сервера приложений;
    
    3 - команда опроса состояния;
    
    4 - подтверждение инициации процесса сервера приложений;
    
    5 - подтверждение завершения процесса сервера приложений;
    
    6 - подтверждение команды опроса состояния;
    
    7-127 - зарезервировано;
    
    127-255- зарезервировано.
    
    Сообщения поддержания трафика процесса сервера приложений:
    
    0 - зарезервировано;
    
    1 - активный процесс сервера приложений;
    
    2 - неактивный процесс сервера приложений;
    
    3 - подтверждение активного процесса сервера приложений;
    
    4 - подтверждение неактивного процесса сервера приложений;
    
    5-127 - зарезервировано;
    
    127-255 - зарезервировано.
    
    Сообщения управления M2UA:
    
    0 - ошибка;
    
    1 - уведомление;
    
    2-127 - зарезервировано;
    
    127-255 - зарезервировано.
    
    Сообщения управления идентификаторами интерфейса:
    
    0 - зарезервировано;
    
    1 - запрос на регистрацию;
    
    2 - ответ на запрос на регистрацию;
    
    3 - запрос на дерегистрацию;
    
    4 - ответ на запрос на дерегистрацию;
    
    5-127 - зарезервировано;
    
    127-255 - зарезервировано.
    
    д) в поле "Длина сообщения" включен параметр добавочных байтов, если такие имеются.
    
    3.5. В сообщении после общего заголовка содержатся параметры переменной длины, определяемые типом сообщения.
    
    Параметры переменной длины, содержащиеся в сообщении, приведены на рисунке 5.
    

    
Рисунок 5. Формат параметра переменной длины

    
    Поле "Тэг параметра" определяет тип параметра, принимающий значение от 0 до 65535.
    
    3.6. Помимо общего заголовка в сообщении M2UA содержится специальный заголовок. В специальном заголовке содержится параметр "Идентификатор интерфейса", формат которого либо целочисленный, либо текстовый. Формат специального заголовка приведен на рисунках 6 и 7, соответственно.
    

    
    Рисунок 6. Формат специального заголовка (целочисленный)
    

    
    Рисунок 7. Формат специального заголовка (текстовый)
    
    3.7. Сообщения протокола M2UA, используемые в СПРС, приведены в таблице N 4. Сообщения включают в себя общий и специальный заголовки.
    

Таблица N 4

    
Сообщения протокола M2UA

    
    
    4. Требования к параметрам протокола M3UA.
    
    4.1. Значение номера порта SCTP для M3UA равно 2905. Идентификатор полезной нагрузки протокола SCTP для M3UA равен 3.
    
    4.2. Протокол M3UA осуществляет:
    
    а) передачу сообщений пользователя МТР3 посредством установления соединения SCTP;
    
    б) обнаружение ошибок в сообщениях протокола M3UA и уведомление о них;
    
    в) управление установлением соединениями SCTP;
    
    г) управление установлением соединения с несколькими ШС.
    
    4.3. Протокол M3UA реализует следующие функции:
    
    а) предоставление кода пункта сигнализации;
    
    б) определение контекстов маршрутизации и соответствующих ключей маршрутизации для передачи сообщений ОКС N 7;
    
    в) осуществление взаимодействия между подсистемами КС N 7 и M3UA;
    
    г) использование моделей резервирования;
    
    д) резервирование сервера приложений;
    
    е) управление потоком;
    
    ж) управление перегрузками;
    
    з) отображение потоков SCTP;
    
    и) использование модели Клиент/Сервер.
    
    4.4. Общий заголовок сообщения для M3UA имеет следующую структуру: версия, класс сообщения, тип сообщения, длина сообщения. Заголовок сообщения является общим для всех уровней адаптации протокола сигнализации. Формат общего заголовка приведен на рисунке 8.
    

    
Рисунок 8. Формат общего заголовка

    
    
    4.5. Значения полей заголовка:
    
    а) в поле "Версия" содержится версия M3UA;
    
    б) значение поля "Резерв" установлено отправителем равным нулю и не учитывается получателем;
    
    в) в поле "Класс сообщения" содержатся следующие значения:
    
    0 - сообщения управления M3UA;
    
    1 - сообщения передачи;
    
    2 - сообщения управления сетью сигнализации;
    
    3 - сообщения поддержания состояния процесса сервера приложений;
    
    4 - сообщения поддержания трафика процесса сервера приложений;
    
    5 - зарезервировано;
    
    6 - зарезервировано;
    
    7 - зарезервировано;
    
    8 - зарезервировано;
    
    9 - сообщения управления ключами маршрутизации;
    
    10-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    г) в поле "Тип сообщения" содержатся следующие типы сообщений для соответствующих классов сообщений:
    
    Сообщения управления M3UA:
    
    0 - ошибка;
    
    1 - уведомление;
    
    2-27 - зарезервировано;
    
    128-255 - зарезервировано.
    
    Сообщения передачи:
    
    0 - зарезервировано;
    
    1 - данные полезной нагрузки;
    
    2-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    Сообщения управления сигнализацией:
    
    0 - зарезервировано;
    
    1 - пункт назначения недоступен;
    
    2 - пункт назначения доступен;
    
    3 - проверка состояния пункта назначения;
    
    4 - перегрузка сигнализации;
    
    5 - подсистема ОКС N 7 в пункте назначения недоступна;
    
    6 - доступ к пункту назначения запрещен;
    
    7-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    Сообщения поддержания состояния процесса сервера приложений:
    
    0 - зарезервировано;
    
    1 - инициализация;
    
    2 - завершение;
    
    3 - команда опроса состояния;
    
    4 - подтверждение инициализации;
    
    5 - подтверждение завершения;
    
    6 - подтверждение команды опроса состояния;
    
    1-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    Сообщения поддержания трафика процесса сервера приложений:
    
    0 - зарезервировано;
    
    1 - активный сервер приложений;
    
    2 - неактивный сервер приложений;
    
    3 - подтверждение активного сервера приложений;
    
    4 - подтверждение неактивного сервера приложений;
    
    5-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    Сообщения управления ключами маршрутизации:
    
    0 - зарезервировано;
    
    1 - запрос на регистрацию;
    
    2 - ответ на запрос на регистрацию;
    
    3 - запрос на дерегистрацию;
    
    4 - ответ на запрос на дерегистрацию;
    
    5-127 - зарезервировано;
    
    128-255 - зарезервировано.
    
    д) в поле "Длина сообщения" включен параметр добавочных байтов, если таковые имеются.
    
    4.6. В сообщении после общего заголовка содержатся параметры переменной длины, определяемые типом сообщения.
    
    Параметры переменной длины, содержащиеся в сообщении, приведены на рисунке 9.
    

    
Рисунок 9. Формат параметра переменной длины

    
    
    Сообщения протокола M3UA приведены в таблице N 5.
    

Таблица N 5

    
Сообщения протокола M3UA