Приказ Минкомсвязи России от 25.06.2018 № 319

«Об утверждении Правил применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE»

(Зарегистрировано в Минюсте России 31.07.2018 № 51741)

Зарегистрировано в Минюсте России 31 июля 2018 г. № 51741

ПРИКАЗ

от 25 июня 2018 г. № 319

ОБ УТВЕРЖДЕНИИ ПРАВИЛ ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ СЕТЕЙ ПОДВИЖНОЙ РАДИОТЕЛЕФОННОЙ СВЯЗИ. ЧАСТЬ VII. ПРАВИЛА ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ СТАНДАРТА LTE

В соответствии со статьей 41 и пунктом 2.1 статьи 12 Федерального закона от 7 июля 2003 г. № 126-ФЗ «О связи» (Собрание законодательства Российской Федерации, 2003, № 28, ст. 2895; № 52, ст. 5038; 2004, № 35, ст. 3607; № 45, ст. 4377; 2005, № 19, ст. 1752; 2006, № 6, ст. 636; № 10, ст. 1069; № 31, ст. 3431, ст. 3452; 2007, № 1, ст. 8; № 7, ст. 835; 2008, № 18, ст. 1941; 2009, № 29, ст. 3625; 2010, № 7, ст. 705; № 15, ст. 1737; № 27, ст. 3408; № 31, ст. 4190; 2011, № 7, ст. 901; № 9, ст. 1205; № 25, ст. 3535; № 27, ст. 3873, ст. 3880; № 29, ст. 4284, ст. 4291; № 30, ст. 4590; № 45, ст. 6333; № 49, ст. 7061; № 50, ст. 7351, ст. 7366; 2012, № 31, ст. 4322, ст. 4328; № 53, ст. 7578; 2013, № 19, ст. 2326; № 27, ст. 3450; № 30, ст. 4062; № 43, ст. 5451; № 44, ст. 5643; № 48, ст. 6162; № 49, ст. 6339, ст. 6347; № 52, ст. 6961; 2014, № 6, ст. 560; № 14, ст. 1552; № 19, ст. 2302; № 26, ст. 3366, ст. 3377; № 30, ст. 4229, ст. 4273; № 49, ст. 6928; 2015, № 29, ст. 4342, ст. 4383, ст. 4389; 2016, № 10, ст. 1316, ст. 1318; № 15, ст. 2066; № 18, ст. 2498; № 26, ст. 3873; № 27, ст. 4213, ст. 4221; № 28, ст. 4558; 2017, № 17, ст. 2457; № 24, ст. 3479; № 31, ст. 4742; № 50, ст. 7557; 2018, № 17, ст. 2419) и пунктом 4 Правил организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденных постановлением Правительства Российской Федерации от 13 апреля 2005 г. № 214 (Собрание законодательства Российской Федерации, 2005, № 16, ст. 1463; 2008, № 42, ст. 4832; 2012, № 6, ст. 687), приказываю:

1. Утвердить прилагаемые Правила применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE.

2. Признать утратившими силу:

приказ Министерства связи и массовых коммуникаций Российской Федерации от 06.06.2011 № 130 «Об утверждении Правил применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE» (зарегистрирован Министерством юстиции Российской Федерации 28 июня 2011 г., регистрационный № 21216);

пункт 3 Изменений, которые вносятся в приказы Министерства информационных технологий и связи Российской Федерации и Министерства связи и массовых коммуникаций Российской Федерации, утвержденных приказом Министерства связи и массовых коммуникаций Российской Федерации от 14.12.2015 № 543 «О внесении изменений в некоторые приказы Министерства информационных технологий и связи Российской Федерации и Министерства связи и массовых коммуникаций Российской Федерации» (зарегистрирован Министерством юстиции Российской Федерации 18 января 2016 г., регистрационный № 40606).

3. Признать не подлежащими применению:

подпункт 5 пункта 9.1 Правил применения оборудования коммутации систем подвижной радиотелефонной связи. Часть II. Правила применения оборудования коммутации сети подвижной радиотелефонной связи стандарта GSM 900/1800, утвержденных приказом Министерства информационных технологий и связи Российской Федерации от 31.05.2007 № 58 «Об утверждении Правил применения оборудования коммутации систем подвижной радиотелефонной связи. Часть II. Правила применения оборудования коммутации сети подвижной радиотелефонной связи стандарта GSM 900/1800» (зарегистрирован Министерством юстиции Российской Федерации 22 июня 2007 г., регистрационный № 9675);

подпункт 5 пункта 10.1 подпункт «в» пункта 10.3 Правил применения оборудования коммутации систем подвижной радиотелефонной связи. Часть V. Правила применения оконечно-транзитных узлов связи сетей подвижной радиотелефонной связи стандарта UMTS, утвержденных приказом Министерства информационных технологий и связи Российской Федерации от 27.08.2007 № 101 «Об утверждении Правил применения оборудования коммутации систем подвижной радиотелефонной связи. Часть V. Правила применения оконечно-транзитных узлов связи сетей подвижной радиотелефонной связи стандарта UMTS» (зарегистрирован Министерством юстиции Российской Федерации 29 августа 2007 г., регистрационный № 10066).

4. Установить, что настоящий приказ вступает в силу по истечении ста восьмидесяти дней после дня его официального опубликования, за исключением подпунктов 5 и 6 пункта 15 Правил применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденных настоящим приказом, которые вступают в силу с 1 декабря 2019 года.

5. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.

Министр К. Ю. Носков

Утверждены приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 25.06.2018 № 319

ПРАВИЛА ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ СЕТЕЙ ПОДВИЖНОЙ РАДИОТЕЛЕФОННОЙ СВЯЗИ. ЧАСТЬ VII. ПРАВИЛА ПРИМЕНЕНИЯ ОБОРУДОВАНИЯ КОММУТАЦИИ СТАНДАРТА LTE

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

1. Правила применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE (далее — Правила) разработаны в целях обеспечения целостности, устойчивости функционирования и безопасности единой сети электросвязи Российской Федерации.

2. Правила устанавливают требования к оборудованию коммутации стандартов LTE и (или) LTE-Advanced (далее — стандарт LTE), включая оборудование коммутации IMS, при оказании услуг передачи данных и телефонного соединения, в том числе требования к протоколам, обеспечивающим взаимодействие с узлами связи стандартов GSM 900/1800 и UMTS, а также к оборудованию коммутации стандарта LTE для взаимодействия с беспроводным доступом, отличным от стандартов GSM 900/1800, UMTS, LTE (далее — non-3GPP) и принадлежащим домашнему или визитному оператору сети подвижной радиотелефонной связи (далее — доверенный беспроводный доступ TWAN) или принадлежащим другой сети связи общего пользования (далее — ненадежный беспроводный доступ UTWAN).

3. Оборудование коммутации стандарта LTE идентифицируется как сложное телекоммуникационное оборудование коммутации сетей подвижной радиотелефонной связи и согласно пункту 8 Перечня средств связи, подлежащих обязательной сертификации, утвержденного постановлением Правительства Российской Федерации от 25 июня 2009 г. № 532 (Собрание законодательства Российской Федерации, 2009, № 26, ст. 3206; 2015, № 6, ст. 954), подлежит обязательной сертификации в порядке, установленном Правилами организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденными постановлением Правительства Российской Федерации от 13 апреля 2005 г. № 214 (Собрание законодательства Российской Федерации, 2005, № 16, ст. 1463; 2008, № 42, ст. 4832; 2012, № 6, ст. 687).

4. Правила распространяются на следующее оборудование стандарта LTE:

1. модуль управления мобильностью (Mobility Managemen Entity) (далее — MME);

2. обслуживающий шлюз (Serving Gateway) (далее — S-GW);

3. шлюз взаимодействия с сетями, использующими технологию с коммутацией пакетов (Packet Data Networks Gateway) (далее — PDN GW);

II. Требования к оборудованию коммутации стандарта LTE

(187 — 242) В при напряжении переменного тока 220 В (частота — (47,5 — 50,5) Гц, коэффициент нелинейных искажений — не более 10%, кратковременное (длительностью до 3 секунд) изменение напряжения относительно номинального значения \pm 40%).

8. В оборудовании коммутации стандарта LTE должна быть предусмотрена система сигнализации для контроля неисправностей в ЭПУ.

9. Требования к параметрам устойчивости к внешним климатическим и механическим воздействиям для оборудования коммутации стандарта LTE приведены в приложении № 3 к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи. Часть II. Правила применения оборудования коммутации сети подвижной радиотелефонной связи стандарта GSM 900/1800, утвержденным Приказом Министерства информационных технологий и связи Российской Федерации от 31.05.2007 № 58 (зарегистрирован Министерством юстиции Российской Федерации 22 июня 2007 г., регистрационный № 9675), с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 01.02.2012 № 29 (зарегистрирован Министерством юстиции Российской Федерации 22 февраля 2012 г., регистрационный № 23312), от 23.04.2013 № 93 (зарегистрирован Министерством юстиции Российской Федерации 14 июня 2013 г., регистрационный № 2878822) и от 14.12.2015 № 543 (зарегистрирован Министерством юстиции Российской Федерации 18 января 2016 г., регистрационный № 40606) (далее — Правила № 58-07).

10. Требования к системе нумерации и идентификации для оборудования коммутации стандарта LTE приведены в приложении № 1 к Правилам.

11. Для оборудования, выполняющего функции MME, устанавливаются следующие требования к:

1. перечню хранящихся в MME данных об абонентских радиостанциях, поддерживающих стандарт LTE и находящихся в состояниях ECM-IDLE, ECM-CONNECTED или EMM-DEREGISTERED в зонах слежения (TA), обслуживаемых MME (приложение № 2 к Правилам);

2. перечню сообщений протокола S1-AP (S1 Application Part) при взаимодействии оборудования систем базовых станций стандарта LTE (eNodeB) с MME (приложение № 3 к Правилам);

л) осуществление генерации и распределения ключей протокола GRE для инкапсуляции пакетов данных для каждого соединения передачи данных по восходящей линии от S-GW при реализации интерфейсов S2a/S2b протоколом PMIPv6;

м) реализация функций взаимодействия протокола PMIPv6 в направлении P-GW и в направлении функций MAG, реализованных в TWAN (интерфейсы S8 и S2a) либо в ePDG (интерфейсы S8 и S2b). При этом S-GW реализует функции MAG по отношению к P-GW;

н) реализация функций соединения PMIPv6 в направлении P-GW и в направлении функций MAG, реализованных в TWAN либо в ePDG, для пользовательского уровня;

8. протоколу MIPv4 при взаимодействии S-GW с TWAN (интерфейс S2a) при реализации в оборудовании коммутации стандарта LTE (приложение № 17 к Правилам);

9. перечню данных, хранящихся в S-GW при реализации non-3GPP доступа (Приложение № 22 к Правилам).

13. Для оборудования, выполняющего функции P-GW, устанавливаются следующие требования к:

1. перечню данных об обслуживаемых в P-GW абонентских радиостанциях, поддерживающих стандарты LTE, GSM 900/1800, UMTS (приложение № 12 к Правилам);

г) осуществление генерации и распределения ключей протокола GRE, используемых для инкапсуляции пользовательских данных, передаваемых по восходящей линии при реализации интерфейсов S5 и S8 или S2a, или S2b протоколом PMIPv6;

д) реализация функции домашнего агента при реализации интерфейса S2a протоколом MIPv4 (при регистрации должно осуществляться назначение UE временного IP-адреса с помощью протокола MIPv4 при этом временный IP-адрес должен являться адресом агента визитной сети (далее — FACoA);

е) реализация протокола GTP для уровня управления (GTPv2-C) и уровня пользователя (GTPv1-U) для обеспечения соединения PDN с UE (при реализации интерфейсов S2a или S2b протоколом GTP должен использоваться non-3GPP доступ);

12. протоколу IKEv2 при взаимодействии P-GW с UE (интерфейс S2c) при реализации в оборудовании коммутации стандарта LTE (приложение № 19 к Правилам);
13. протоколу IPSec при взаимодействии P-GW с UE (интерфейс S2c) (приложение № 20 к Правилам);
14. перечню сообщений протокола Diameter при реализации интерфейса S6b (приложение № 21 к Правилам);
15. перечню данных, хранящихся в P-GW, при реализации non-3GPP доступа (приложение № 22 к Правилам).

14. Для оборудования, выполняющего функции EIR, устанавливаются следующие требования к:

1. данным об абонентской радиостанции, хранящимся в EIR (приложение № 14 к Правилам);

2) перечню сообщений протокола Diameter при реализации интерфейса взаимодействия MME с EIR (интерфейс S13) (приложение № 5 к Правилам);

3) интерфейсам взаимодействия (приложение № 9 к Правилам);

4) протоколу SCTP при реализации в оборудовании коммутации стандарта LTE (пункт 2 приложения № 14 к Правилам № 58-07).

15. Для оборудования, выполняющего функции HSS/AuC, устанавливаются следующие требования к:

1. перечню хранящихся в HSS данных об абонентских радиостанциях, поддерживающих стандарт LTE (приложение № 13 к Правилам);

2. перечню сообщений протокола Diameter при реализации интерфейса взаимодействия HSS с MME (интерфейс S6a) (приложение № 5 к Правилам);

6. протоколу взаимодействия сервера абонентских данных HSS и/или центра аутентификации AuC с отдельным аппаратным модулем безопасности HSM, выполняющим криптографические функции аутентификации и идентификации абонентов (приложение № 24 к Правилам);

7. функциям HSS при реализации non-3GPP доступа при взаимодействии с 3GPP AAA сервером по протоколу Diameter (интерфейс SWx);

21. Для оборудования, выполняющего функции ePDG, устанавливаются следующие требования к:

1. функциям ePDG:

а) выделение UE временного удаленного IP адреса (далее — CoA), являющегося локальным для ePDG, при реализации интерфейса S2c;

б) регистрация локального IP адреса UE;

в) обеспечение возможности транспортировки удаленного IP-адреса, выделенного в качестве IP-адреса PDN, при реализации интерфейса S2b;

г) маршрутизация пакетов данных от (к) P-GW (от (к) S-GW при выполнении S-GW функции LA в сети VPLMN к (от) UE, если реализуется интерфейс S2b протоколом GTP;

д) маршрутизация пакетов данных к UE через интерфейс SWu, связанный соединением с PDN;

7. протоколу IPSec, идентификационному заголовку протокола IPSec (AH), протоколу ESP) (приложение № 20 к Правилам);

8. перечню сообщений протокола Diameter при реализации интерфейса взаимодействия ePDG и 3GPP AAA сервер/прокси (интерфейс SWm) (приложение № 21 к Правилам);

9. перечню данных, хранящихся в ePDG, при реализации non-3GPP доступа (приложение № 22 к Правилам);

ж) удаление данных о подключении из HLR/HSS при отмене регистрации пользователя в 3GPP AAA сервере;

з) сохранение информации о состоянии подключения UE к WLAN;

и) формирование и передача данных для тарификации системе тарификации в HPLMN при доступе UE через UTWAN;

к) хранение данных о качестве обслуживания для TWAN;

л) взаимодействие с TWAN (интерфейс STa), с HLR/HSS (интерфейс SWx), с UTWAN (интерфейс SWa), с 3GPP AAA прокси-сервером (интерфейс SWd) по протоколу Diameter;

м) передача к P-GW информации для авторизации;

н) предоставление P-GW временного удаленного IP адреса UE, полученного от HSS при использовании статического удаленного IP адреса;

о) предоставление 3GPP AAA прокси-серверу информации о правилах обслуживания пользователя;

2. протоколу PMIPv6 при реализации в оборудовании коммутации стандарта LTE (приложение № 8 к Правилам);

1. Идентификация AC должна осуществляться в соответствии с требованиями приказа Министерства связи и массовых коммуникаций Российской Федерации от 25 апреля 2017 г. № 205 «Об утверждении и введении в действие российской системы и плана нумерации» (зарегистрирован Министерством юстиции Российской Федерации 13 июля 2017 г., регистрационный № 47401).

2. Оборудование коммутации стандарта LTE должно осуществлять маршрутизацию данных, используя адресацию сети Интернет в формате, определенном протоколами IP четвертой и шестой версий (далее — IPv4, IPv6).

3. Для идентификации AC в информационно-телекоммуникационной сети «Интернет» на время взаимодействия AC с информационно-телекоммуникационной сетью «Интернет» ей должен присваиваться адрес сети в формате протокола IPv4 и (или) IPv6.

4. Для аутентификации UE при доступе через TWAN должны использоваться идентификаторы:

1) доступа к сети (далее — NAI), имеющий структуру:

«1»@wlan.mnc.mcc.3gppnetwork.org — для аутентификации EAP-AKA;

«0»@wlan.mnc.mcc.3gppnetwork.org — для аутентификации EAP-SIM;

2. сети доступа (далее — ANID), принимающий при доступе non-3GPP следующие значения:

Правила применения оборудования коммутации стандарта LTE, утвержденным приказом Министерства

радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденным приказом Министерства цифрового развития, связи и массовых коммуникаций

Таблица № 1. Сообщения протокола Diameter на интерфейсах S6a/S6d между MME/SGSN и HSS, определение идентификатором приложения (далее — Auth-Application-Id), равным «16777251»

Таблица № 2. Сообщения протокола Diameter на интерфейсах S13/S13' между MME/SGSN и EIR, определенные Auth-Application-Id, равным «16777252»

Таблица № 3. Сообщения протокола Diameter на интерфейсе Gx между PCRF и PDN GW, определенные Auth-Application-Id, равным «16777224», и на интерфейсе S9 между V-PCRF и H-PCRF, определенные Auth-Application-Id, равным «16777267»

Таблица № 4. Сообщения протокола Diameter на интерфейсе Rx между PCRF и функциями приложений (далее — AF), определенные Auth-Application-Id, равным «16777236»

Таблица № 5. Сообщения протокола Diameter на интерфейсе Gxc между H-PCRF (V-PCRF) и S-GW, определенные Auth-Application-Id, равным «16777266»

Таблица № 1. Сообщения протокола NAS подсистемы управления мобильностью (EMM), передаваемые между AC и MME через интерфейс S1-MME

Таблица № 2. Сообщения протокола NAS подсистемы управления сессией (ESM), передаваемые между AC и MME на интерфейсе S1-MME

1. Протокол GTP (далее — GTPv2-C) должен реализовывать в S-GW, P-GW, SGSN, MME интерфейсы взаимодействия S5/S8 (если не используется PMIPv6), Sv, S11, S4, S3, S10, S16 и соответствовать следующим требованиям:

1.1. общий формат заголовка сообщений протокола GTPv2-C приведен на рисунке 1.

3. бит 4 (флаг T) должен определять наличие поля идентификатора конечной точки туннеля TEID в заголовке:

поле TEID не должно присутствовать при флаге T равном «0»;

поле TEID должно следовать в октетах 5 — 8 за полем «Длина сообщения» и занимать четыре октета;

4. биты 3 — 1 (резервные) должен быть равен «0», а получатель не должен анализировать;

второй октет должен определять тип сообщения;

октеты 3 — 4 должны содержать поле «Длина сообщения», содержащее информацию о длине сообщения в октетах, начиная с пятого октета;

октеты 9 — 11 (в случае присутствия TEID) или 5 — 7 (в случае отсутствия TEID) должны содержать поле «Номер последовательности» GTPv2-C. Следующий октет должен использоваться как резерв;

2. Протокол GTP (GTPv1-U) должен реализовывать в оборудовании S-GW, P-GW, SGSN интерфейсы взаимодействия S1-U, S5/S8 (если не используется PMIPv6), S4, S12 и соответствовать следующим требованиям:

2.1. формат заголовка сообщений протокола GTPv1-U приведены на рисунке 2.

Примечание:

в первом октете:

1. биты 6 — 8 должны определять версию протокола GTPv1-U и быть равны десятичному числу «1»;

2. бит 5 (флаг PT) должен определять тип протокола и быть равны десятичному числу «1»;

3. бит 4 (резервный) должен быть равен «0» и не должен анализироваться получателем;

4. бит 3 (флаг E) должен определять наличие поля «Дополнительный заголовок»:

поле «Дополнительный заголовок» должно присутствовать при флаге E равном «1»;

поле «Дополнительный заголовок» должно отсутствовать или не обрабатываться при флаге E равном «0»;

5. бит 2 (флаг S) должен определять наличие поля «Номер последовательности»:

поле «Номер последовательности» должно присутствовать при флаге S равном «1»;

поле «Номер последовательности» должно отсутствовать или не обрабатываться при флаге S равном «0»;

6. бит 1 (флаг PN) должен определять наличие поля «Номер блока данных»:

поле «Номер блока данных» должно присутствовать в заголовке сообщения при флаге PN равном «1»;

поле «Номер блока данных» должно отсутствовать при флаге PN равном «0»;

второй октет должен определять тип сообщения;

октеты 3 — 4 должны содержать поле «Длина сообщения», указывающего длину сообщения в октетах, начиная с девятого октета;

поле TEID должно занимать четыре октета с пятого по восьмой;

октеты 9 — 10 должны содержать поле «Номер последовательности»;

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

2.2. информационные элементы или пакеты пользовательских данных должны следовать за заголовком сообщений протокола GTPv1-U.

2.3. сообщения протокола GTPv1-U приведены в таблице № 2.

Таблица № 2.

1. Требования к протоколу PMIPv6:

1.1. формат заголовка Mobility Header и перечень поддерживаемых полей приведены в таблице № 1.

Примечание:

поле Payload Proto должно идентифицировать тип заголовка, следующего за заголовком Mobility Header и должно использовать значения, аналогичные используемым в заголовке «Следующий заголовок» протокола IPv6 описанное в подпункте 1.2.5 пункта 1 Приложения № 8 Правил;

поле Header Len должно указывать длину заголовка (за исключением первых 8 октетов) в единицах, равных 8 октетам, и должно быть равно «0», если сообщение не имеет параметров;

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

поле Резерв должно быть равно «0»;

поле Checksum должно содержать контрольную сумму заголовка Mobility Header, начиная с поля Payload Proto;

поле Message Data должно быть полем переменной длины и должно содержать данные сообщения. Тип сообщения должен указываться в поле MH Type;

1.2. поле «Дополнение до границы заголовка» должно использоваться для выравнивания границы заголовка по длине, кратной 8 октетам. (свободные позиции должны заполняться нулями);

1.3. сообщения для интерфейсов S5, S8, S2a, S2b:

«Обновление регистрации прокси» (PBU — Proxy Binding Update);

«Подтверждение обновления регистрации» (PBA — Proxy Binding Acknowledgement);

«Индикация аннулирования регистрации» (BRI — Binding Revocation Indication);

«Подтверждение аннулирования регистрации» (BRA — Binding Revocation Acknowledgement);

1.4. формат заголовка Type 2 Routing Header и перечень поддерживаемых полей приведены в таблице № 2.

Примечание:

поле Next Header должно идентифицировать тип заголовка, следующего за заголовком Type 2 Routing Header и использовать значения, аналогичные используемым в заголовке «Следующий заголовок» протокола IPv6;

поле Hdr Ext Len должно указывать длину заголовка (за исключением первых 8 октетов) в единицах, равных 8 октетам и быть равно двум единицам;

поле Routing Type должно указывать тип маршрутизации и быть равно «2»;

поле Segments Left должно быть равно «1»;

поле Резерв быть равно «0»;

поле Home Address (16 октетов) должно содержать домашний адрес узла назначения.

Приложение № 9 к Правилам применения оборудования

радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденным приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 25.06.2018 № 319

ТРЕБОВАНИЯ К ИНТЕРФЕЙСАМ ВЗАИМОДЕЙСТВИЯ

1. Оборудование MME должно взаимодействовать с оборудованием UE по интерфейсу S1-MME с использованием протокола NAS, с оборудованием сети радиодоступа стандартов LTE/LTE-Advanced (далее — E-UTRAN) по интерфейсу S1-MME с использованием протокола S1-AP, с оборудованием MSC сервера/VLR по интерфейсу SGs с использованием протокола SGsAP, с оборудованием HSS/LTE по интерфейсу S6a с использованием протокола Diameter, с оборудованием SGSN по интерфейсу S3 с использованием протокола GTP уровня управления версии 2 (далее — GTPv2-C), с оборудованием EIR по интерфейсу S13 с использованием протокола Diameter.

Взаимодействие MME с SGSN должно осуществляться по интерфейсу Gn с использованием протокола GTP, если обеспечивающий взаимодействие с MME SGSN не реализует интерфейс S3.

2. Оборудование S-GW должно взаимодействовать с оборудованием E-UTRAN по интерфейсу S1-U с использованием протокола GTP уровня пользователя версии 1 (далее — GTPv1-U), с оборудованием SGSN по интерфейсу S4, с оборудованием P-GW своей сети по интерфейсу S5, другой сети по интерфейсу S8 с использованием протоколов GTPv2-C и GTPv1-U или PMIPv6, с оборудованием MME по интерфейсу S11 с использованием протокола GTPv2-C, с оборудованием UTRAN по интерфейсу S12 с использованием протокола GTP.

3. Оборудование P-GW должно взаимодействовать с оборудованием S-GW своей сети по интерфейсу S5, другой сети по интерфейсу S8 с использованием протоколов GTPv2-C и GTPv1-U или PMIPv6, с оборудованием PCRF по интерфейсу Gx с использованием протокола Diameter. Взаимодействие SGSN с P-GW должно осуществляться по интерфейсам Gn или Gp с использованием протокола GTP, если SGSN не реализует интерфейс S4. Оборудование P-GW должно взаимодействовать с оборудованием внешней сети передачи данных по интерфейсу SGi.

4. Оборудование HSS должно взаимодействовать с оборудованием MME по интерфейсу S6a с использованием протокола Diameter.

5. Оборудование PCRF должно взаимодействовать с оборудованием P-GW по интерфейсу Gx, с оборудованием PCRF другой сети по интерфейсу S9 и с обслуживающей сетью IP по интерфейсу Rx с использованием протокола Diameter.

6. Оборудование EIR должно взаимодействовать с оборудованием MME по интерфейсу S13 с использованием протокола Diameter.

7. Оборудование SGSN должно взаимодействовать с оборудованием MME по интерфейсу S3 с использованием протокола GTPv2-C, по интерфейсу Gn с использованием протокола GTP, если обеспечивающий взаимодействие с MME SGSN не реализует интерфейс S3, с оборудованием S-GW по интерфейсу S4 с использованием протоколов GTPv2-C и GTPv1-U, с P-GW по интерфейсам Gn или Gp с использованием протокола GTP, если SGSN не реализует интерфейс S4.

8. В оборудовании коммутации стандарта LTE должны использоваться интерфейсы к сети передачи данных с использованием контроля несущей и обнаружением коллизий. Требования к параметрам согласно приложению 25 к Правилам применения оборудования проводных и оптических систем передачи абонентского доступа, утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 24.08.2006 № 112 (зарегистрирован в Министерстве юстиции Российской Федерации 4 сентября 2006 г., регистрационный № 8194), с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 23.04.2013 № 93 (зарегистрирован в Министерстве юстиции Российской Федерации 14 июня 2013 г., регистрационный № 28788) и от 17.03.2014 № 45 (зарегистрирован в Министерстве юстиции Российской Федерации 16 апреля 2014 г., регистрационный № 31998);

9. Для обслуживания non-3GPP доступа должны реализовываться следующие интерфейсы взаимодействия:

S2a (взаимодействие TWAN (TWAG) и S-GW либо P-GW в зависимости от архитектуры сети, обеспечение передачи данных пользователя и сигнализации, реализация протоколов управления мобильностью PMIPv6, MIPv4 (с адресацией FACoA) или GTP уровня управления и уровня пользователя);

S2b (взаимодействие ePDG и S-GW либо P-GW в зависимости от архитектуры сети, обеспечение передачи данных пользователя и сигнализации, реализация протоколов управления мобильностью PMIPv6 или GTP);

S5 (взаимодействие S-GW и P-GW, обеспечение передачи данных пользователя и сигнализации с использованием туннелей, реализация протоколов GTP либо PMIPv6);

S8 (взаимодействие S-GW в VPLMN и P-GW в HPLMN, использование пользовательского трафика через HPLMN при роуминге и в случае маршрутизации, реализация протокола GTP либо PMIPv6);

S6a (взаимодействие MME и HSS, использование для аутентификации и авторизации, реализация протокола Diameter);

S6b (взаимодействие P-GW и 3GPP AAA сервера либо 3GPP AAA прокси-сервера (при роуминге в случае маршрутизации трафика через визитную сеть) с использованием Diameter);

Gx (обеспечение передачи сообщений управления качеством передачи данных QoS и правил тарификации от PCRF к P-GW с использованием протокола Diameter);

Gxa (обеспечение передачи сообщений протокола Diameter для управления качеством передачи данных QoS от PCRF к TWAN);

Gxb (взаимодействие ePDG и VPCRF, обеспечение передачи сообщений протокола Diameter для управления качеством передачи данных QoS от VPCRF к ePDG);

Gxc (обеспечение передачи сообщений протокола Diameter для управления качеством передачи данных QoS между S-GW и PCRF);

S9 (обеспечение передачи сообщений протокола Diameter для управления качеством передачи данных QoS в условиях роуминга между HPCRF и VPCRF). По интерфейсу S9 должны передаваться данные о правилах тарификации в случае маршрутизации пользовательского трафика в PDN из визитной сети;

SGi (взаимодействие P-GW и PDN);

SWa (взаимодействие UTWAN с 3GPP AAA сервером (прокси-сервером) по протоколу Diameter для безопасной передачи информации аутентификации, авторизации и учета (тарификации);

STa (взаимодействие TWAN с 3GPP AAA сервером (прокси-сервером) по протоколу Diameter для безопасной передачи информации аутентификации, авторизации и учета (тарификации) с поддержкой протокола EAP-AKA, EAP-AKA');

SWd (взаимодействие 3GPP AAA прокси-сервера и 3GPP AAA сервера по протоколу Diameter с поддержкой протокола EAP-AKA, EAP-AKA');

SWm (взаимодействие 3GPP AAA сервера (прокси-сервера) и ePDG для передачи данных сигнализации AAA и передачи данных аутентификации и авторизации протоколов управления мобильности PMIPv6 (MAG-AAA) и MIPv6 (MIPv6 NAS-AAA) с поддержкой протокола EAP-AKA);

SWu (взаимодействие мобильного терминала и шлюза ePDG, обеспечение безопасной передачи данных в туннеле IPSec). Обмен ключами при формировании туннеля IPSec должен выполняться при помощи протокола IKEv2;

SWx (взаимодействие 3GPP AAA сервера и базы данных HSS, обеспечение обмена данными для аутентификации и авторизации UE).

Интерфейсы S5, S8, S2a, S2b должны реализовывать один и тот же протокол — либо PMIPv6, либо GTP.

к Правилам применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденным приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 25.06.2018 № 319

ПЕРЕЧЕНЬ ДАННЫХ ОБ ОБСЛУЖИВАЕМЫХ В S-GW АБОНЕНТСКИХ РАДИОСТАНЦИЯХ, ПОДДЕРЖИВАЮЩИХ СТАНДАРТЫ LTE, GSM 900/1800, UMTS

1. Система учета данных для начисления платы (далее — СУД) должна выполнять сбор и хранение учетных данных для последующего определения стоимости для всех видов учетного трафика.

2. СУД должна обеспечивать передачу учетных данных в автоматизированную систему расчетов (далее — АСР).

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

4. СУД должна создавать запись для обеспечения функций учета, регистрирующую следующие данные:

1. категорию и номер вызывающего абонента или адресную информацию вызывающей стороны;

2. номер вызываемого абонента (службы) или адресную информацию вызываемой стороны;

3. дату (день, месяц, год) и время начала соединения (час, минута, секунда);

4. продолжительность соединения или время окончания соединения (час, минута, секунда);

5. используемые в соединении услуги;

6. объем передаваемой/принимаемой информации с указанием качества предоставления услуги, в случае установления соединений для передачи данных;

7. индикаторы записи;

8. идентификаторы операторов;

9. идентификаторы оборудования EPC, обеспечивающего сбор данных для учета стоимости.

5. СУД должна обеспечивать хранение учетных данных.

6. Передача информации в АСР должна осуществляться с использованием стандартных сетевых протоколов и открытых интерфейсов.

7. Для бесперебойной работы СУД должны обеспечиваться дублирование и резервирование устройств. Системе управления и технического обслуживания должны посылаться сообщения об отказе или неисправности оборудования СУД при возникновении отказов или неисправности оборудования СУД, а также в процессе передачи информации в АСР, и одновременно осуществляться запись сведений о неисправностях.

8. В СУД должна быть предусмотрена система защиты от несанкционированного доступа к информации.

9. В СУД обеспечена возможность установки обслуживаемым персоналом параметров, регистрируемых в записях о соединениях, и типов записей.

10. В СУД должна обеспечиваться функция немедленного вывода на устройство технического обслуживания учетной информации для оперативной обработки данных.

Приложение № 12

коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденным приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 25.06.2018 № 319

ПЕРЕЧЕНЬ ДАННЫХ ОБ ОБСЛУЖИВАЕМЫХ В P-GW АБОНЕНТСКИХ РАДИОСТАНЦИЯХ, ПОДДЕРЖИВАЮЩИХ СТАНДАРТЫ LTE, GSM 900/1800, UMTS

утвержденным приказом Министерства цифрового развития, связи

3. Формат IMEISV:

код типа (TAC) должен содержать 8 десятичных знаков;

серийный номер (SNR) должен содержать 6 десятичных знаков (индивидуальный серийный номер, однозначно идентифицирующий оборудование АС в пределах TAC);

номер версии программного обеспечения оборудования АС (SVN), идентифицирующий номер версии программного обеспечения мобильного оборудования. Длина поля должна составлять 2 десятичных знака.

Число десятичных знаков в IMEISV должно быть равно 16.

4. Международные идентификаторы оборудования АС, содержащиеся в EIR, должны разделяться на три списка:

белый список, содержащий IMEI допущенного для работы в сети оборудования;

черный список, содержащий IMEI не допущенного для работы в сети оборудования;

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

5. Оборудование коммутации стандарта LTE должно осуществлять проверку IMEI при каждой попытке доступа АС в EPC и останавливать любую попытку доступа при получении из регистра EIR одного из следующих ответов: «оборудование находится в черном списке» или «оборудование не содержится в белом списке».

Российской Федерации от 25.06.2018 № 319

1. В Центр Управления и Технического Обслуживания (ЦУ и ТО) должна направляться информация о состоянии оборудования коммутации стандарта LTE. Для управления и технического обслуживания оборудования коммутации стандарта LTE должен использоваться централизованный метод.

2. ЦУ и ТО должен использоваться для управления оборудованием коммутации стандарта LTE, контроля работоспособности оборудования коммутации стандарта LTE, сбора и вывода информации о функционировании оборудования коммутации стандарта LTE обслуживающему персоналу.

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

4. ЦУ и ТО должен выполнять следующие функции:

административное управление;

контроль функционирования оборудования коммутации стандарта LTE;

управление восстановлением работоспособности оборудования коммутации стандарта LTE;

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

5. Функция административного управления оборудованием коммутации стандарта LTE должна включать:

1. управление конфигурацией оборудования коммутации стандарта LTE, обеспечивающее:

ввод, изменение и удаление данных конфигурации;

активацию или деактивацию загрузки программного обеспечения (далее — ПО) в оборудование узла связи и его работоспособность;

2. управление командами системы, обеспечивающее следующие функции:

5. управление защитой информации, обеспечивающее следующие функции:

наличие не менее двух категорий пользователей (администратор и пользователь), имеющих различные пароли и различные права доступа к ЦУ и ТО;

6. управление системными часами реального времени, обеспечивающее контроль и возможность установки системных часов реального времени.

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

7. Контроль функционирования оборудования коммутации стандарта LTE должен осуществляется постоянно или периодически (по расписанию или по команде технического персонала с терминала технического обслуживания).

8. Автоматический контроль должен осуществляться распределенно (модули самостоятельно должны обнаруживать повреждения и ошибки).

9. Аварийные сообщения должны быть разделены на категории по срочности восстановления неисправностей:

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

2. главные аварии (серьезные неисправности, требующие вмешательства в течение дня);

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

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

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

12. Перезапуск ПО должен производиться с сохранением статистических и тарификационных данных и, в основном, с сохранением установленных соединений.

13. Перезагрузка ПО оборудования коммутации стандарта LTE должна производиться с сохранением данных учета стоимости соединений и статистических данных.

14. Управление тестированием и диагностикой должно осуществлять обнаружение и локализацию неисправного оборудования с помощью диагностических программ.

15. ЦУ и ТО должен обеспечивать автоматический ежемесячный статистический учет ситуаций в оборудовании коммутации стандарта LTE и программном обеспечении.

16. ЦУ и ТО должен обеспечивать возможность сбора и отображения статистических данных.

UE должно выбирать P-CSCF из списка, хранящегося в идентификационном модуле абонента для работы в IMS (далее — ISIM);

UE должно выбирать P-CSCF из списка объектов управления IMS.

Первоначально активация канала передачи данных в EPS должна осуществляться в рамках процедуры подключения UE к EPS, инициируемой UE с помощью сообщения протокола NAS «Запрос подключения». В «Запросе подключения» в параметре настройки пользовательского оборудования, определяющем оборудование коммутации, через которое будет осуществляться телефонное соединение, в третьем октете второй и третий биты должны иметь одно из трех значений:

«01» — голос только через IMS;

«10» — в первую очередь голос следует передавать через домен CS, во вторую — через IMS;

«11» — в первую очередь голос следует передавать через IMS, во вторую — через домен CS.

Третий бит при установлении соединения для передачи голоса должен быть равен «0», для передачи данных — «1».

Активация канала передачи данных EPS должна осуществляться с помощью сообщений «Запрос соединения с сетью передачи данных» протокола NAS и «Запрос активации канала передачи данных» протокола GTPv2-C. В параметре «Запроса соединения с сетью передачи данных», определяющем опции конфигурации протокола, должны быть установлены:

запрос адреса P-CSCF (если используется второй способ выделения адреса P-CSCF);

флаг сигнализации IMS.

В параметре сообщения протокола NAS «Подключение принято», определяющем поддерживаемые сетью функции, первый бит третьего октета должен быть равен «1», что указывает на поддержку IMS голоса через домен коммутации пакетов на интерфейсе S1.

Передача UE IP-адреса (в параметре «Адрес сети передачи данных») и IP-адреса P-CSCF (в параметре «Протокол параметров конфигурации») должна осуществляться в ответе на «Запрос активации канала передачи данных» протокола GTPv2-C и в одном из сообщений «Запрос активации контекста EPS по умолчанию», «Запрос активации контекста выбранной EPS» протокола NAS.

UE должен присваиваться новый IP-адрес при перемещения UE в зону обслуживания другого P-GW.

UE должно осуществлять процедуру регистрации или перерегистрации в IMS после назначения или изменения IP-адреса UE или IP-адреса P-CSCF.

Освобождение динамического IP-адреса UE должно осуществляться при разрыве соединения с оборудованием коммутации IMS с помощью сообщения «Запрос разъединения с сетью передачи данных» протокола NAS или при окончании времени регистрации.

коммутации стандарта LTE, утвержденным приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 25.06.2018 № 319

ТРЕБОВАНИЯ К ПРОТОКОЛУ MIPV4

1. Требования к дополнениям и расширениям протоколов, необходимых для поддержки мобильности пользователя в сети, использующей IPv4:

1.1. Требования к дополнительным сообщениям «Запрос регистрации» (Registration Request), «Результат регистрации» (Registration Reply), поддерживающие управление мобильностью пользователя и отправляемые с порта UDP/TCP 434:

а) формат сообщения «Запрос регистрации» приведен на рисунке 1.

Примечание:

поле «Тип» (1 байт) должно быть равно «1»;

поле «S» (1 бит) должно быть равно «1», если мобильный узел запрашивает сохранение нескольких предыдущих адресов привязки;

поле «B» (1 бит) должно быть равно «1», если мобильный узел запрашивает у домашнего агента доставку широковещательных дейтаграмм;

поле «D» (1 бит) должно быть равно «1», если мобильный узел декапсулирует дейтаграммы, направленные по адресу CoA;

поле «M» (1 бит) должно быть равно «1», если мобильный узел запрашивает у домашнего агента режим минимальной инкапсуляции данных;

поле «G» (1 бит) должно быть равно «1», если мобильный узел запрашивает у домашнего агента режим инкапсуляции GRE;

поля «r» и «X» (по 1 биту) должно быть равны «0» и должны игнорироваться при приеме;

поле «Адрес домашнего агента» (4 байта) должно указывать IP-адрес домашнего агента;

поле «CoA» (4 байта) должно указывать временный IP-адрес мобильного узла в визитной сети;

поле «Идентификация» должно содержать сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса регистрации и ответа;

Рисунок 2

поле «Домашний адрес» (4 байта) должно указывать IP-адрес мобильного узла в домашней сети;

поле «Адрес домашнего агента» (4 байта) должно указывать IP-адрес домашнего агента;

поле «Идентификатор» должно содержать сгенерированное мобильным узлом 64-битовое число, используемое для сопоставления запроса регистрации и ответа;

Рисунок 3.

1.2. требования к сообщениям протокола ICMPv4 «Объявление маршрутизатора» (Router Advertisement), «Запрос доступности маршрутизатора» (Router Solicitation), поддерживающим управление мобильностью пользователя:

а) значения расширений, используемых для сообщений протокола ICMPv4 «Объявление маршрутизатора» (Router Advertisement), «Запрос доступности маршрутизатора» (Router Solicitation):

«0» — один байт заполнения, последнее расширение сообщения ICMP должно использоваться для дополнения длины сообщения до четного количества байт;

Примечание:

поле «Тип расширения» (1 байт) должно быть равно «16»;

поле «Порядковый номер» (2 байта) должно содержать номер сообщения с расширением Agent Advertisement;

поле «Длительность регистрации» (2 байта) должно содержать информацию о длительности регистрации в секундах (при значении «0» — запрос отмены регистрации, при значении «0xffff» — бесконечность);

поле «R» (1 бит) должно содержать информацию, что требуется регистрация в визитном агенте (FA) при наличии у мобильного узла адреса CoA;

поле «B» (1 бит) должно содержать информацию, что FA не осуществляет регистрацию мобильных узлов;

поле «H» (1 бит) (домашний агент, HA) должно содержать информацию, что агент предлагает услугу домашнего агента;

поле «F» (1 бит) (визитный агент) должно содержать информацию, что агент предлагает услугу визитного агента;

поле «M» (1 бит) (минимальная инкапсуляция) должно содержать информацию, что агент реализует прием дейтаграмм, использующих минимальную инкапсуляцию;

поле «G» (1 бит) (GRE инкапсуляция) должно содержать информацию, что агент реализует прием дейтаграмм, которые используют GRE инкапсуляцию;

поле «r» (1 бит) должно быть резервным и равно «0»;

поле «T» (1 бит) должно содержать информацию, что FA поддерживает обратную инкапсуляцию;

поле «Резерв» (8 бит) должно быть равно «0»;

поле «Адрес(а) CoA» должно содержать один или более адресов CoA при установлении бита F (количество адресов, присутствующих в поле, должно определяться указателем длины);

в) формат расширения «Длина префикса» (19) приведен на рисунке 5.

Примечание:

поле «Payload Proto» должно идентифицировать тип заголовка, следующего сразу за Mobility Header, использовать значения, соответствующие заголовку «Следующий заголовок» протокола IPv6.

поле «Header Len» должно указывать длину заголовка (за исключением первых 8 октетов) в единицах, равных 8 октетам. Значение Header Len должно устанавливаться равным «0», если сообщение не имеет параметров.

поле «Checksum» должно содержать контрольную сумму заголовка «Mobility Header», начиная с поля «Payload Proto».

поле «Message Data» должно быть полем переменной длины и должно содержать данные сообщения. Тип сообщения должен указываться в поле «MH Type».

поле «Дополнение до границы заголовка» должно использоваться для выравнивания границы заголовка по длине, кратной 8 октетам. Свободные позиции должны заполняться нулями.

1.2. сообщения, передаваемые при использовании заголовка «Mobility Header»:

а) «Запрос обновления привязки UE» (сообщение BRR (Binding Refresh Request) должно включать следующие поля (поле «MH Type» для сообщения BRR должно быть равно «0»):

«Резерв» (16 бит) (должно быть резервным, равно «0» и должно игнорироваться получателем);

«Опции мобильности» (Mobility Options) (должно быть переменной длины (длина полного заголовка мобильности должна быть кратна 8 октетам) и должно содержать одну или несколько опций мобильности, закодированных в формате TLV, или не должно содержать таких опций, а получатель должен игнорировать и пропускать любые опции);

б) «Инициирование проверки домашнего адреса» (сообщение HoTI (Home Test Init) должно включать следующие поля (поле «MH Type» для сообщения HoTI должно быть равно «1»):

«Резерв» (16 бит) (должно быть резервным, равно «0» и должно игнорироваться получателем);

в) «Инициирование проверки временного адреса» (сообщение Care-of Test Init) должно включать следующие поля (поле «MH Type» для сообщения «Care-of Test Init» должно быть равно «2»):

«Идентифицирующая цепочка временного адреса» (Care-of Init Cookie) (должно быть 64-битовым полем, содержащим значение вновь сгенерированного случайного числа, которое возвращается в UE в сообщении «Care-of Test»);

«Опции мобильности» (Mobility Options) (должно быть полем переменной длины (длина полного заголовка мобильности должна быть кратна 8 октетам), содержать одну или несколько опций мобильности, закодированных в формате TLV, или не должно содержать таких опций, а получатель должен игнорировать и пропускать любые опции).

«Идентифицирующая цепочка домашнего адреса» (Home Init Cookie) (должно быть 64-битовым полем и приниматься в сообщении «Home Test Init»);

«Маркер Home Keygen Token» (должно содержать 64 бита маркера, используемого в процедуре обратной маршрутизации);

«Опции мобильности» (Mobility Options) (должно быть полем переменной длины (длина полного заголовка мобильности должна быть кратна 8 октетам), содержать одну или несколько опций мобильности, закодированных в формате TLV, или не должно содержать таких опций, а получатель должен игнорировать и пропускать любые опции);

д) «Care-of Test», используемое для возврата UE идентифицирующей цепочки, посылаемой узлу-корреспонденту в сообщении «Care-of Test Init» должно включать следующие поля (поле «MH Type» для сообщения «Care-of Test» должно быть равно «4»):

«Одноразовый индекс временного номера» (Care-of Nonce Index) (должно быть 16-битовым полем, возвращаемым обратно узлу-корреспонденту мобильным узлом в сообщении «Binding Update»);

«Идентифицирующая цепочка временного адреса» (Care-of Init Cookie) (должно быть 64-битовым полем, содержащим принятое в сообщении «Care-of Test Init» значение);

«Маркер Care-of Keygen Token» (должно содержать 64 бита маркера, используемого в процедуре обратной маршрутизации);

«Опции мобильности» (Mobility Options) (должно быть полем переменной длины (длина полного заголовка мобильности должна быть кратна 8 октетам), содержать одну или несколько опций мобильности, закодированных в формате TLV, или не должно содержать таких опций, а получатель должен игнорировать и пропускать любые опции);

е) «Информирование об обновлении привязки» (сообщение BU (Binding Update) должно использоваться мобильным узлом для уведомления других узлов о своем новом временном адресе и включать следующие поля (поле «MH Type» для сообщения «Binding Update» должно быть равно «5»):

«Порядковый номер» (Sequence) (должно быть 16-битовым полем, используемым для нумерации сообщений «Binding Update» для сопоставления сообщения «Binding Acknowledgement» с сообщением «Binding Update»);

бит «Подтверждение» (A) (Acknowledge) (должен устанавливаться посылающим мобильным узлом и содержать информацию об ожидании сообщения «Подтверждение привязки»);

бит «Регистрация в домашнем агенте» (H) (Home Registration) (должен устанавливаться посылающим мобильным узлом, чтобы принимающий узел домашней сети служил ему домашним агентом);

бит «Соответствие линка и локального адреса» (L) (Link-Local Address Compatibility) (должен устанавливаться при одинаковом идентификаторе интерфейса домашнего адреса, переданного мобильным узлом, и линка);

бит «Возможность мобильного управления ключами» (Key Management Mobility Capability) (K) (должен быть равен «0», когда используемый для установления контекстов безопасности между мобильным узлом и домашним агентом протокол IPsec не переносит информацию о перемещении, должен использоваться только в сообщениях «Binding Update», посылаемых домашнему агенту, и должен быть равен «0» в других сообщениях «Binding Update», а узлы-корреспонденты должны игнорировать указанный бит);

«Зарезервировано» (Reserved) (12 бит) (должно быть равно «0» и должно игнорироваться получателем);

«Время жизни» (Lifetime) (16 бит) (должно указывать на количество единиц времени, оставшихся до того момента, когда привязка UE считается просроченной (при значении «0» указывает на необходимость удаления информации о привязке мобильного узла при этом указанный временный адрес должен устанавливаться равным домашнему адресу). За единицу времени должны быть приняты 4 секунды);

«Опции мобильности» (Mobility Options) (должно быть полем переменной длины (длина полного заголовка мобильности должна быть кратна 8 октетам), содержать одну или несколько опций мобильности, закодированных в формате TLV, или не должно содержать таких опций, получатель должен игнорировать и пропускать любые опции).

В сообщении «Binding Update» должны быть допустимы следующие опции мобильности:

опция «Данные авторизации привязки» (Binding Authorization Data) (должна быть обязательной в сообщениях «Binding Update», посылаемых узлу-корреспонденту);

Таблица № 2.

Примечание:

поле «Next Header» должно идентифицировать тип заголовка, следующего за заголовком «Type 2 Routing Header» и использовать для идентификации заголовков те же значения, что и в заголовке «Следующий заголовок» протокола IPv6;

поле «Hdr Ext Len» должно содержать информацию о длине заголовка (за исключением первых 8 октетов) в единицах, равных 8 октетам и быть равно «2»;

поле «Home Address» должно быть полем длиной 16 октетов и содержать домашний адрес узла назначения.

1.4. дополнительные сообщения ICMP IPv6:

Протоколом Mobile IPv6 вводится четыре новых типа сообщений для протокола ICMP.

Для определения адреса домашнего агента должны использоваться новые сообщения ICMP:

«Запрос определения адреса домашнего агента» (Home Agent Address Discovery Request) (должно использоваться мобильным терминалом для инициации механизма динамического определения адреса домашнего агента);

«Ответ определения адреса домашнего агента» (Home Agent Address Discovery Reply) (должно использоваться домашним агентом для ответа мобильному узлу, использующему механизм динамического определения адреса домашнего агента).

Для перенумерования сетей и конфигурирования адресов на мобильном узле должны использоваться новые сообщения ICMP:

«Запрос мобильного префикса» (Mobile Prefix Solicitation);

«Объявление мобильного префикса» (Mobile Prefix Advertisement).

а) формат сообщения «Запрос определения адреса домашнего агента» (Home Agent Address Discovery Request) приведен на рисунке 1.

Рисунок 1

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

поле «Резерв» должно быть равно «0» и должно игнорироваться получателем;

б) формат сообщения «Ответ определения адреса домашнего агента» (Home Agent Address Discovery Reply) приведен на рисунке 2.

поле «Адреса домашнего агента» должно содержать список адресов домашних агентов мобильного узла в домашней сети;

в) формат сообщения «Запрос мобильного префикса» (Mobile Prefix Solicitation) приведен на рисунке 3.

Рисунок 3

Примечание:

поле «Тип» (1 байт) должно быть равно «146»;

поле «Код» (1 байт) должно быть равно «0»;

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

поле «Резерв» должно должно быть равно «0» и должно игнорироваться получателем.

Поля пакета протокола IPv6 должны заполняться следующим образом: в поле «Адрес источника» (Source Address) должен указываться временный адрес мобильного узла, а в поле «Адрес места назначения» (Destination Address) — адрес домашнего агента мобильного узла;

г) формат сообщения «Объявление мобильного префикса» (Mobile Prefix Advertisement) приведен на рисунке 4.

Рисунок 4

поле «Код» (1 байт) должно быть равно «0»;

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

поле «M» (1 бит) (флаг управляемого конфигурирования адресов) должно указывать на доступность адреса через DHCPv6 при значении поля «M» равном «1»;

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

поле «Резерв» должно быть равно «0» и должно игнорироваться получателем;

поле «Опции» (сообщение должно содержать одну или несколько опций «Prefix Information») должно передавать префикс, который мобильный узел использует для конфигурирования своего домашнего адреса (домашних адресов).

Поля пакета протокола IPv6 должны заполняться следующим образом: в поле «Адрес источника» (Source Address) должен указываться адрес домашнего агента, а в поле «Адрес места назначения» (Destination Address) — значение поля «Source Address» из сообщения «Запрос мобильного префикса».

2. Требования к формату сообщений протокола обнаружения соседних узлов (далее — NDP):

2.1. формат сообщения «Объявление маршрутизатора» (Router Advertisement) приведен на рисунке 5.

Рисунок 5

Примечание:

поле «Тип» (1 байт) должно быть равно «134»;

поле «Код» (1 байт) должно быть равно «0»;

поле «Текущий предел шагов» должно содержать значение по умолчанию и его следует поместить в поле числа шагов IP-заголовка для исходящих пакетов;

поле «M» (1 бит) (флаг управляемого конфигурирования адресов) должно содержать информацию о доступности адреса через DHCPv6 при значении поля «M» равном «1»;

поле «O» (1 бит) (флаг другой конфигурации) должно содержать информацию о существовании другой информации о конфигурации, доступной через DHCPv6, при значении поля «O» равном «1»;

поле «H» (1 бит) (флаг домашнего агента) содержать информацию о функционировании маршрутизатора в качестве домашнего агента при значении поля «H» равном «1»;

поле «Резерв» должно быть равно «0» и должно игнорироваться получателем;

поле «Время жизни маршрутизатора» должно содержать информацию о времени функционирования устройства в качестве маршрутизатора, измеряемое в секундах;

поле «Время достижимости» (4 байта) должно содержать информацию о времени доступности соседнего маршрутизатора после получения подтверждения доступности, измеряемое в миллисекундах;

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

3. Требования к протоколу DSMIPv6:

3.1. на мобильном терминале должно устанавливаться программное обеспечение (далее — ПО) клиента DSMIPv6, на P-GW — ПО домашнего агента DSMIPv6 для функционирования протокола DSMIPv6 на интерфейсе S2c;

3.2. расширения для сообщений протокола MIPv6:

а) Для сообщения «Binding Update», передаваемого от UE к домашнему агенту или точке привязки мобильности (Mobility Anchor Point (далее — MAP):

опция «IPv4 Home Address Option» (должна указывать домашний адрес мобильного узла формата IPv4);

опция «IPv4 Care-of Address Option» (должна указывать временный адрес мобильного узла формата IPv4 при нахождении его в сети, поддерживающей только протокол IPv4);

флаг (F) (должен указывать при его установке на необходимость инкапсуляции с помощью протокола UDP);

б) для сообщения «Binding Acknowledgement», передаваемого от домашнего агента или MAP к UE:

опция «IPv4 Acknowledgement Option» (должна указывать на осуществление обновления адреса привязки для мобильного узла адресом формата IPv4 и адрес мобильного узла формата IPv4);

опция «NAT Detection Option» (должна указывать UE на наличие трансляции сетевого адреса (Network Address Translation, далее — NAT) при помощи домашнего агента, включать счетчик повторной передачи обновления и флага «F», указывающего при его установке на необходимость инкапсуляции с помощью протокола UDP.

1. Протокол обмена ключами в Интернет (Internet Key Exchange) версия 2 (далее — IKEv2) должен пользоваться услугами протокола UDP через порты 500 и 4500. В дейтаграмме UDP должна осуществляться передача одного сообщения IKEv2. Адреса IP и номера портов UDP в заголовках должны сохраняться и использоваться для передачи ответных пакетов. Сообщение IKEv2 должно начинаться непосредственно после заголовка UDP при передаче через порт UDP 500, а при передаче через порт UDP 4500 перед сообщением IKEv2 должны помещаться четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKEv2 и не должны учитываться в размерах и контрольных суммах IKEv2.

2. Требования к заголовкам протокола IKEv2:

2.1. сообщение протокола IKEv2 должно начинаться с заголовка. После заголовка должен следовать один или несколько элементов данных IKEv2, идентифицируемых значением поля «Next Payload» предыдущего элемента данных. Элементы данных должны обрабатываться в порядке их следования в сообщении IKEv2 путем вызова соответствующей процедуры, определяемой значением поля «Next Payload» в заголовке IKEv2, затем значением поля «Next Payload» в первом элементе данных IKEv2 и далее, пока в поле «Next Payload» не будет обнаружено нулевое значение, указывающее на отсутствие следующего элемента данных. Элемент данных типа Encrypted при приеме должен быть дешифрован, а результат расшифровки необходимо разбирать как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете. В зашифрованные элементы недопустимо включать другие элементы типа Encrypted;

поле «Initiator's SPI» (8 октетов) должно содержать значение, выбранное инициатором для уникальной идентификации параметров безопасности (Security Parameter Index, далее — SPI) IKEv2 и не должно быть равно «0»;

поле «Responder's SPI» (8 октетов) должно содержать значение, выбранное ответчиком для уникальной идентификации защищенной связи IKE и должно быть равно «0» в первом сообщении начального обмена IKEv2 (включая повторы этого сообщения, содержащие cookie), для всех остальных сообщений не должно быть равно «0»;

поле «Next Payload» (1 октет) должно содержать информацию о типе элемента данных, расположенного сразу после заголовка.

«Mj Ver» (4 бита) должен задавать старшую часть номера версии используемого протокола IKE. Реализации на основе IKEv2 должны устанавливать значение Major Version равное «2». Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим «2»;

«Mn Ver» (4 бита) должен задавать младшую часть номера версии IKE. Реализации на основе IKEv2 должны устанавливать значение Minor Version равное «0» и игнорировать младшую часть номера в принимаемых сообщениях;

«Exchange Type» (1 октет) должен указывать тип используемого обмена, ограничивающий набор элементов данных в каждом сообщении и порядок сообщений в обмене.

Типы обмена приведены в таблице № 1.

Таблица № 1.

«Flags» (1 октет) должен указывать на наличие специфических опций в сообщении при установлении соответствующего бита флага в «1»;

«Message ID» (4 октета) должен содержать идентификатор сообщения и использоваться для управления повторной передачей потерянных пакетов и связывания запросов с откликами;

«Length» (4 октета) должен содержать размер всего сообщения (заголовок и элементы данных) в октетах;

2.3. структура базового заголовка элемента данных (payload) IKEv2 приведена на рисунке 2.

Примечание:

поле «Идентификатор следующего элемента» (Next Payload) (1 октет) должно указывать тип следующего элемента данных в сообщении, должно быть равно «0», если текущий элемент является последним, и не должно использоваться для элемента типа Encrypted (всегда должен быть последним в сообщении). Указанный элемент должен содержать структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле «Next Payload» должно устанавливаться в соответствии с типом первого вложенного элемента (вместо «0»).

Примечание:

поле «C» (1 бит) должно быть равно «0» для обеспечения заявленной отправителем возможности по пропуску получателем элемента данных, когда получатель не идентифицирует код в поле «Next Payload» предыдущего элемента. Получатель должен игнорировать этот флаг при идентификации типа элемента. Флаг «C» должен относиться к текущему элементу данных;

поле «Резерв» (7 битов) должно быть равно «0» при передаче и игнорироваться на приеме;

поле «Размер текущего элемента» (Payload Length) (2 октета) должно содержать размер текущего элемента данных в октетах с учетом базового заголовка;

2.4. структура элемента данных «Предложения» (SA) приведена на рисунке 3.

Рисунок 4

Примечание:

первый октет должен должен содержать информацию о том, является ли преобразование последним в предложении. Преобразование должно быть последним при значении первого октета равном «0» и не должно являться последним при значении равном «3»;

поле «Резерв» (1 октет) должно быть равно «0» при передаче и игнорироваться на приеме;

поле «Длина преобразования» (2 октета) должно содержать информацию о размере поля «Структура преобразования» (в октетах) с учетом заголовка и атрибутов;

поле «Тип преобразования» (1 октет) должно содержать тип преобразования, задаваемого этим элементом. Преобразование не должно включаться в предложение, если оно является необязательным и инициатор предлагает его пропустить. Инициатор должен включать субструктуру преобразования с идентификатором Transform ID равном «0» в качестве одной из опций при передаче вопроса об использовании необязательного преобразования ответчику.

Примечание:

поле «Идентификатор преобразования» (2 октета) должно содержать идентификатор конкретного преобразования указанного типа.

Число и тип преобразований в элементах данных SA должны зависеть от типа протокола в самой SA.

Обязательные и опциональные типы преобразований приведены в таблице № 4.

Таблица № 4.

Примечание:

Значение атрибута должно иметь фиксированную (2 октета) или переменную длину. Для представления атрибута переменной длины должен использоваться формат «тип-размер-значение».

Формат поля «Атрибута преобразования» приведен на рисунке 5.

Примечание:

поле «Тип сертификата» (1 октет) должно содержать информацию о способе кодирования сертификата;

поле «Данные сертификата» должно иметь переменный размер.

Элемент данных Сертификат должен обеспечивать способ передачи сертификатов или другой, связанной с идентификацией информации через IKE. Элемент данных Сертификат следует включать в обмен, если сертификат доступен отправителю до указания партнером возможности получения идентификационной информации иным путем с использованием элемента Уведомление типа HTTP_CERT_LOOKUP_SUPPORTED. Требования к

Значения поля «Тип сертификата» приведены в таблице № 6.

Таблица № 6.

Рисунок 9

Примечание:

поле «Тип сертификата» (1 октет) должно содержать информацию о способе кодирования сертификата;

поле «Удостоверяющий центр» должно иметь переменный размер.

2.9. элемент данных Идентификация должен содержать данные, используемые для идентификации.

Формат элемента данных Идентификация приведен на рисунке 10.

2.10. элемент данных Случайное число должно иметь одно поле переменного размера, содержащее созданное передающей стороной случайное значение, размер элемента должен находиться в диапазоне (16 — 256) октетов включительно, повторное использование значения Случайного числа не допускается;

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

Формат элемента данных Уведомление приведен на рисунке 11.

Примечание:

поле «Идентификатор протокола» (1 октет) должно показывать тип SA, если уведомление относится к существующей SA, должно быть равно «1» для уведомлений IKE_SA, «2» для протокола AH или «3» для протокола ESP для уведомлений, касающихся IPsec, и «0» при передаче и игнорироваться на приеме для уведомлений, не относящихся к существующим SA. Все остальные значения должны быть зарезервированы IANA для использования в будущем.

поле «Размер SPI» (Security Parameter Index) (1 октет) должно указывать размер SPI в октетах;

поле «Тип уведомления» (2 октета) должен задавать тип уведомления;

поле «SPI» должно иметь переменный размер и содержать идентификатор параметров защиты;

поле «Данные уведомления» должно иметь переменный размер и содержать дополнительную информацию к типу уведомления;

3.1. формат элемента данных Удаление приведен на рисунке 12.

Элемент данных Удаление должен содержать определяемый протоколом идентификатор защищенной связи.

поле «Следующий заголовок» (1 октет) должно показывать тип информации, расположенной после идентификационного заголовка AH. Значения этого поля должны выбираться из списка номеров протоколов, предоставленного Администрацией адресного пространства Интернет IANA;

поле «Длина заголовка» (1 октет) должно содержать информацию о размере заголовка AH в 32-битовых словах (4-байтовых блоках) минус 2;

поле «Резерв» (2 октета) должно быть резервным, равно «0» и игнорируется получателем. Значение этого поля должно учитываться при вычислении ICV, но игнорироваться получателем;

Таблица № 1. Сообщения протокола Diameter на интерфейсе S6b, определенные идентификатором приложения (далее — Auth-Application-Id), равным «16777272»

Таблица № 2. Сообщения протокола Diameter на интерфейсе SWx, определенные Auth-Application-Id, равным «16777265»

Таблица № 3. Сообщения протокола Diameter на интерфейсе SWm, определенные Auth-Application-Id, равным «16777264»

Таблица № 4. Сообщения протокола Diameter на интерфейсе STa, определенные Auth-Application-Id, равным «16777250»

Таблица № 5. Сообщения протокола Diameter на интерфейсе SWa, определенные Auth-Application-Id, равным «16777250»

радиотелефонной связи. Часть VII.