Продукты и услуги Информационно-правовое обеспечение ПРАЙМ Документы ленты ПРАЙМ Проект Приказа Министерства связи и массовых коммуникаций РФ "Об утверждении Правил применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE" (подготовлен Минкомсвязью России 22.02.2018)

Проект Приказа Министерства связи и массовых коммуникаций РФ "Об утверждении Правил применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE" (подготовлен Минкомсвязью России 22.02.2018)

7 марта 2018

Досье на проект

В соответствии со статьей 41 Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст. 2895; N 52, ст. 5038; 2004, N 35, ст. 3607; N 45, ст. 4377; 2005, N 19, ст. 1752; 2006, N 6, ст. 636; N 10, ст. 1069; N 31, ст. 3431, ст. 3452; 2007, N 1, ст. 8; N 7, ст. 835; 2008, N 18, ст. 1941; 2009, N 29, ст. 3625; 2010, N 7, ст. 705; N 15, ст. 1737; N 27, ст. 3408; N 31, ст. 4190; 2011, N 7, ст. 901; N 9, ст. 1205; N 25, ст. 3535; N 27, ст. 3873, ст. 3880; N 29, ст. 4284, ст. 4291; N 30, ст. 4590; N 45, ст. 6333; N 49, ст. 7061; N 50, ст. 7351, ст. 7366; 2012, N 31, ст. 4322, ст. 4328; N 53, ст. 7578; 2013, N 19, ст. 2326; N 27, ст. 3450; N 30, ст. 4062; N 43, ст. 5451; N 44, ст. 5643; N 48, ст. 6162; N 49, ст. 6339, ст. 6347; N 52, ст. 6961; 2014, N 6, ст. 560; N 14, ст. 1552; N 19, ст. 2302;N 26, ст. 3366, ст. 3377; N 30, ст. 4229, ст. 4273; N 49, ст. 6928; 2015, N 29, ст. 4342, ст. 4383, ст. 4389; 2016, N 10, ст. 1316, ст. 1318; N 15, ст. 2066; N 18, ст. 2498; N 26, ст. 3873; N 27, ст. 4213, ст. 4221; N 28, ст. 4558; 2017, N 17, ст. 2457; N 24, ст. 3479; N 31, ст. 4742; N 50, ст. 7557), пунктом 4 Правил организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденных постановлением Правительства Российской Федерации от 13 апреля 2005 г. N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст. 1463; 2008, N 42, ст. 4832; 2012, N 6, ст. 687) и пунктом 5.2.2 Положения о Министерстве связи и массовых коммуникаций Российской Федерации, утвержденного постановлением Правительства Российской Федерации от 2 июня 2008 г. N 418 (Собрание законодательства Российской Федерации, 2008, N 23, ст. 2708; N 42, ст. 4825; N 46, ст. 5337; 2009, N 3, ст. 378; N 6, ст. 738; N 33, ст. 4088; 2010, N 13, ст. 1502; N 26, ст. 3350; N 30, ст. 4099; N 31, ст. 4251; 2011, N 2, ст. 338; N 3, ст. 542; N 6, ст. 888; N 14, ст. 1935; N 21, ст. 2965; N 44, ст. 6272; N 49, ст. 7283; 2012, N 20, ст. 2540; N 37, ст. 5001; N 39, ст. 5270; N 46, ст. 6347; 2013, N 13, ст. 1568, ст. 1569; N 33, ст. 4386; N 45, ст. 5822; 2014, N 30, ст. 4305; N 31, ст. 4414; N 47, ст. 6554; 2015, N 2, ст. 491; N 24, ст. 3486; 2016, N 2, ст. 325; N 18, ст. 2637; N 28, ст. 4741; 2017, N15, ст. 2202; N 41, ст. 5956),

приказываю:

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

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

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

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

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

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

Министр

Н.А. Никифоров

УТВЕРЖДЕНЫ
приказом Министерства связи и массовых коммуникаций Российской Федерации
от ____________________ N______

Правила применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть 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 г. N 532 (Собрание законодательства Российской Федерации, 2009, N 26, ст. 3206; 2015, N 6, ст. 954), подлежит обязательной сертификации в порядке, установленном Правилами организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденными постановлением Правительства Российской Федерации от 13 апреля 2005 г. N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст. 1463; 2008, N 42, ст. 4832; 2012, N 6, ст. 687).

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

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

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

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

4) регистр идентификации оборудования (Equipment Identity Register) (далее - EIR);

5) сервер абонентских данных и/или центр аутентификации (Home Subscriber Server / Authentication Center) (далее - HSS/AuC);

6) обслуживающий узел поддержки GPRS (Serving GPRS Support Node) (далее - SGSN);

7) оборудование, реализующее функции реализации правил политики и тарификации (The Policy and Charging Rules Function) (далее - PCRF);

8) центр управления и технического обслуживания (далее - ЦУ и ТО);

9) оборудование коммутации IMS, выполняющее функции:

а) управления сеансом (далее - CSCF), при использовании прокси сервера CSCF (далее - P-CSCF), обслуживающего CSCF (далее - S-CSCF), и запрашивающего CSCF (далее - I-CSCF);

б) сервера абонентских данных пользователей IMS (далее - HSS/IMS);

в) определения местонахождения подписки (далее - SLF);

г) управления медиашлюзами (далее - MGCF);

д) управления ресурсами мультимедиа (далее - MRFC);

е) процессора ресурсов мультимедиа (далее - MRFP);

ж) управления выбором сети (далее - BGCF);

з) управления пограничным взаимодействием (далее - IBCF);

и) учета данных для начисления платы (далее - CCF);

й) медиашлюза (далее - IMS-MGW);

к) переходного шлюза (далее - TrGw);

л) шлюза сигнализации (далее - SGF);

м) шлюза абонентского доступа (далее - IMS-AGW);

10) оборудование, реализующее функцию агента протокола Diameter (Diameter Agent) (далее - DA), для определения местонахождения пользователя, в случае наличия на сети оператора нескольких HSS.

11) оборудование 3GPP AAA сервер/прокси;

12) оборудование, реализующее функции доступа к оборудованию коммутации стандарта LTE из сети Интернет при использовании доступа UTWAN (далее ? ePDG).

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

При использовании оборудования IMS с территориально распределенной структурой с предоставлением услуг связи в различных территориально-административных образованиях интерфейсы IMS должны обеспечивать проведение оперативно-розыскных мероприятий независимо в каждом территориально-административном образовании в полном объеме.

5. Процедуру обязательной сертификации проходит как оборудование коммутации сетей подвижной радиотелефонной связи в составе входящего в него оборудования коммутации стандарта LTE, так и оборудование, приведенное в подпунктах 1 - 7, 9, 10 пункта 4 Правил, в качестве самостоятельных средств связи, включая оборудование средств связи, в том числе программное обеспечение, обеспечивающее выполнение установленных действий при проведении оперативно-розыскных мероприятий.

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

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

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

6. Электропитание оборудования коммутации стандарта LTE должно осуществляться в соответствии с требованиями к параметрам электропитания, установленными пунктами П. 9.1 - П. 9.4 приложения 9 к Правилам применения транзитных междугородных узлов автоматической коммутации. Часть I. Правила применения транзитных междугородных узлов связи, использующих систему сигнализации по общему каналу сигнализации N 7 (ОКС N 7), утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 16.05.2006 N 59 (зарегистрирован Министерством юстиции Российской Федерации 29 мая 2006 г., регистрационный N 7879), с изменениями внесенными приказом Министерства связи и массовых коммуникаций Российской Федерации от 23.04.2013 N 93 (зарегистрирован Министерством юстиции Российской Федерации 14 июня 2013 г., регистрационный N 28788), (далее - Правила N 59-06), или от сети переменного тока с номинальным напряжением 220 В, частотой 50 Гц.

Оборудование электропитающей установки (далее - ЭПУ) не входит в состав оборудования коммутации стандарта LTE и должно соответствовать Правилам применения оборудования электропитания средств связи, утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 03.03.2006 N 21 (зарегистрирован Министерством юстиции Российской Федерации 27 марта 2006 г., регистрационный N 7638),с изменениями внесенными приказом Министерства связи и массовых коммуникаций Российской Федерации от 23.04.2013 N 93 (зарегистрирован Министерством юстиции Российской Федерации 14 июня 2013 г., регистрационный N 28788).

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

при номинальном напряжении 60 В - в пределах от (48,0 - 72,0) В;

при номинальном напряжении 48 В - в пределах от (40,5 - 57,0) В;

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

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

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

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

11. Обязательные требования к оборудованию, выполняющему функции MME, приведены:

1) к данным MME (приложение N 2 к Правилам);

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

3) к параметрам протокола SGsAP (SGs Application Part), используемого при взаимодействии MME с сервером центра мобильной коммутации (MSC сервер/VLR) (приложение N 4 к Правилам);

4) к параметрам протокола Diameter, используемого при взаимодействии MME с DA или HSS (интерфейс S6a), MME с DA или EIR (интерфейс S13) (приложение N 5 к Правилам);

5) к параметрам протокола NAS (приложение N 6 к Правилам);

6) к параметрам протокола GTP (приложение N 7 к Правилам);

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

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

9) к параметрам протокола GTP (интерфейс Gn) при использовании протокола GTP (интерфейс Gn) для взаимодействия MME с SGSN, если SGSN при взаимодействии с MME не реализует протокол GTPv2-C (интерфейс S3) (приложение N 4 к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи. Часть V. Правила применения оконечно-транзитных узлов связи сетей подвижной радиотелефонной связи стандарта UMTS, утвержденным приказом Министерства информационных технологий и связи Российской Федерации от 27.08.2007 N 101 (зарегистрирован Министерством юстиции Российской Федерации 29 августа 2007 г., регистрационный N 10066), с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 01.02.2012 N 31 (зарегистрирован Министерством юстиции Российской Федерации 24 февраля 2012 г., регистрационный N 23324), от 23.04.2013 N 93 (зарегистрирован Министерством юстиции Российской Федерации 14 июня 2013 г., регистрационный N 28788), от 14.12.2015 N 543 (зарегистрирован Министерством юстиции Российской Федерации 18 января 2016 г., регистрационный N 40606) (далее - Правила N 101-07);

10) к функциям MME при реализации non-3GPP доступа (пересылка ключа протокола GRE к S-GW по интерфейсам S10/S11 для передачи данных по восходящей линии связи в случае перемещения UE из узла CN);

11) к данным MME при реализации non-3GPP доступа (приложение N 21 к Правилам).

12. Обязательные требования к оборудованию, выполняющему функции S-GW, приведены:

1) к данным S-GW (приложение N 10 к Правилам);

2) к параметрам протокола GTP (приложение N 7 к Правилам);

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

4) к параметрам систем учета данных для начисления платы (приложение N 11 к Правилам);

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

6) к параметрам протокола Diameter при взаимодействии S-GW с H-PCRF (V-PCRF) (интерфейс Gxc) при реализации PMIPv6 на интерфейсах S5, S8 (приложении N 5 к Правилам);

7) к функциям S-GW при реализации non-3GPP доступа:

а) реализация функций локального узла управления мобильностью (далее - LMA) визитной (гостевой) сети подвижной радиотелефонной связи (далее ? VPLMN) с TWAN при взаимодействии с TWAN с использованием протокола PMIPv6 на интерфейсе S2a, когда UE находится в роуминге;

б) информирование PCRF о происходящих изменениях при переходе UE на новую технологию радиодоступа;

в) осуществление контроля трафика от UE;

г) реализация функций MAG при взаимодействии с P-GW с использованием протокола PMIPv6на интерфейсах S5 и S8;

д) принятие решения о маршрутизации пакетов по восходящей линии к P-GW, по нисходящей линии к UE или определение пакетов, предназначенных для S-GW;

е) реализация функций агента протокола DHCPv4 либо DHCPv6 в случае использования протокола PMIPv6 на интерфейсах S5 или S8;

ж) осуществление обмена сообщениями "Запрос доступности маршрутизатора" (Router Solicitation) (далее ? RS) и "Ответ маршрутизатора" (Router Advertisement) (далее ? RA) протокола NDP в случае использования протокола PMIPv6 на интерфейсах S5 и S8;

з) осуществление обмена сообщениями "Запрос доступных соседей" (Neighbour Solicitation) и "Ответ соседа" (Neighbor Advertisement) протокола NDP в случае использования протокола PMIPv6 на интерфейсах S5 и S8;

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

й) реализация функций LMA в отношении функций MAG протокола PMIPv6, реализованных в TWAN либо в ePDG;

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

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

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

8) к параметрам протокола MIPv4, используемого при взаимодействии S-GW с TWAN (интерфейс S2а) при реализации в оборудовании коммутации стандарта LTE (приложение N 16 к Правилам);

9) к данным S-GW при реализации non-3GPP доступа (приложение N 21 к Правилам).

13. Обязательные требования к оборудованию, выполняющему функции P-GW, приведены:

1) к данным P-GW (приложение N 12 к Правилам);

2) к параметрам протокола GTP (приложение N 7 к Правилам);

3) к параметрам протокола Diameter при взаимодействии P-GW с PCRF (интерфейс Gx) при реализации на интерфейсах S5, S8 протокола GTP (приложение N 5 к Правилам);

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

5) к параметрам системы учета данных для начисления платы (приложение N 11 к Правилам);

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

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

8) к параметрам протокола GTP (интерфейсы Gn или Gp) при использовании протокола GTP (интерфейсы Gn или Gp) для взаимодействия P-GW с SGSN, если SGSN при взаимодействии с P-GW не реализует протокол GTPv2-C (интерфейс S3) (приложении N 4 к Правилам N 101-07);

9) к функциям P-GW при реализации non-3GPP доступа:

а) реализация функций точки взаимодействия уровня пользователя при передвижении пользователя между сетями доступа стандартов GSM 900/1800, UMTS, LTE и non-3GPP;

б) реализация функции узла LMA при использовании протокола PMIPv6 на интерфейсах S5 и S8, или на S2a, или на S2b;

в) реализация функции домашнего агента (далее ? HA) протокола DSMIPv6 при использовании интерфейса S2c между P-GW и UE. DSMIPv6 на интерфейсе S2c должен создавать туннель между UE и P-GW для пересылки пользовательского и сигнального трафика между UE и P-GW. P-GW должен обеспечивать назначение IP-адресов для создания туннеля;

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

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

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

ж) взаимодействие с 3GPP ААА сервером внешней сети передачи данных по интерфейсу SGi при использовании протоколов RADIUS или Diameter;

з) взаимодействие с 3GPP ААА сервер/прокси при использовании интерфейса S6b по протоколу Diameter;

10) к параметрам протокола MIPv4, используемого при заимодействии P-GW с TWAN (интерфейс S2a) при реализации в оборудовании коммутации стандарта LTE (16 к Правилам);

11) к параметрам протокола DSMIPv6, используемого при взаимодействии P-GW с UE (интерфейс S2c) при реализации в оборудовании коммутации стандарта LTE (приложение N 17 к Правилам);

12) к параметрам протокола IKEv2, используемого при взаимодействии P-GW с UE (интерфейс S2c) при реализации в оборудовании коммутации стандарта LTE (приложение N 18 к Правилам);

13) к параметрам протокола IPSec, используемого при взаимодействии P-GW с UE (интерфейс S2c) (приложение N 19 к Правилам);

14) к параметрам протокола Diameter на интерфейсе S6b (приложение N 20 к Правилам);

15) к данным P-GW при реализации non-3GPP доступа (приложение N 21 к Правилам).

14. Обязательные требования к оборудованию, выполняющему функции EIR, приведены:

1) к данным, хранящимся в EIR (приложение N 14 к Правилам);

2) к параметрам протокола Diameter, используемого при взаимодействии MME с EIR (интерфейс S13) (приложение N 5 к Правилам);

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

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

15. Обязательные требования к оборудованию, выполняющему функции HSS/AuC, приведены:

1) к данным HSS для абонентских радиостанций (далее - АС), поддерживающих радиодоступ стандарта LTE (приложение N 13 к Правилам);

2) к параметрам протокола Diameter, используемого при взаимодействии HSS с MME (интерфейс S6a) (приложение N 5 к Правилам);

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

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

5) к реализации криптографических функций аутентификации абонентов услуг подвижной радиотелефонной связи в оборудовании коммутации сетей подвижной радиотелефонной связи, удостоверенной сертификатом соответствия фактически используемых для такой реализации средств криптографической защиты информации требованиям федерального органа исполнительной власти в области обеспечения безопасности к шифровальным (криптографическим) средствам класса КА;

6) к параметрам протокола, используемого в случае реализации криптографических алгоритмов аутентификации в аппаратном модуле безопасности (Hardware Security Module - HSM) (приложение N 23 к Правилам).

16. Обязательные требования к оборудованию, выполняющему функции SGSN, приведены:

1) к параметрам протокола GTP (приложении N 7 к Правилам);

2) к параметрам протоколов IP, UDP, TCP при реализации в оборудовании коммутации стандарта LTE (приложении N 8 к Правилам);

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

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

5) к параметрам протокола Diameter на интерфейсе SWx (приложение N 20 к Правилам);

6) к данным HSS при реализации non-3GPP доступа (приложение N 21 к Правилам).

17. Обязательные требования к оборудованию, выполняющему функции PCRF, приведены:

1) к параметрам протокола Diameter, используемого при взаимодействии PCRF с P-GW (интерфейс Gx) при реализации на интерфейсах S5, S8 протокола GTP, PCRF визитной сети (далее - V-PCRF) с PCRF домашней сети (далее - H-PCRF), H-PCRF (V-PCRF) с S-GW (интерфейс Gxc) при реализации на интерфейсах S5, S8 протокола PMIPv6, PCRF с функциями приложений (интерфейс Rx), (приложении N 5 к Правилам);

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

3) к параметрам используемых интерфейсов (приложение N 9 к Правилам);

4) к функциям PCRF при реализации non-3GPP доступа должны быть устанавлены:

а) к PCRF домашней сети (далее - H-PCRF):

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

взаимодействие с TWAN по интерфейсу Gxa, с S-GW по интерфейсу Gxc, с ePDG по интерфейсу Gxb для передачи сообщений управления качеством передачи данных QoS и тарификации с использованием протокола Diameter;

взаимодействие с PCRF визитной сети (далее - V-PCRF) по интерфейсу S9 с использованием протокола Diameter;

б) к PCRF визитной сети:

взаимодействие с H-PCRF по интерфейсу S9 с использованием протокола Diameter.

17.1. Обязательные требования для оборудования коммутации LTE к параметрам, обеспечивающим пользователям стандартов LTE/LTE-Advanced оказание услуг передачи данных и телефонного соединения через оборудование коммутации IMS, приведены в приложении N 15.1 к Правилам.

18. Требования к оборудованию Центра Управления и Технического Обслуживания (ЦУ и ТО) приведены в приложении N 15 к Правилам.

18.1. Обязательные требования к оборудованию, выполняющему функции DA переключения (далее - DRLA), прокси сервер (далее - DPXA), перенаправления (далее - DRDA), обеспечивающего определение местонахождения подписки пользователя, в случае наличия на сети оператора нескольких HSS, приведены:

1) к параметрам протокола Diameter, используемого при взаимодействии MME с DA (интерфейс S6a) (приложении N 5 к Правилам);

2) к параметрам протоколов IP, TCP при реализации в оборудовании коммутации стандарта LTE (приложении N 8 к Правилам);

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

4) к интерфейсам взаимодействия и их параметрам (приложении N 9 к Правилам).

19. Обязательные требования к оборудованию, выполняющему функции ePDG приведены:

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

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

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

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

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

6) к инкапсуляции и деинкапсуляции пакетов данных для туннелей IPSec, для GTP или PMIPv6 при осуществлении поддержки мобильности на базе интерфейса S2b;

7) к реализации функций MAG, если на S2b используется PMIPv6;

8) к формированию безопасных туннелей IPSec при помощи протокола IKEv2 для передачи данных аутентификации и авторизации;

9) к обеспечению функций LMA в случае реализации расширения протокола IKEv2;

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

11) к организации взаимодействия правил тарификации различных операторов;

12) к реализации функций пограничного взаимодействия;

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

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

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

16) к параметрам протокола GTP (приложение N 7 к Правилам);

17) к параметрам протокола IKEv2 (приложение N 18 к Правилам);

18) к параметрам протокола IPSec, идентификационному заголовку протокола IPSec (AH), параметрам протокола ESP) (приложение N 19 к Правилам);

19) к параметрам протокола Diameter на интерфейсе SWm между ePDG и 3GPP AAA сервер/прокси (приложение N 20 к Правилам);

20) к данным ePDG при реализации non-3GPP доступа (приложение N 21 к Правилам);

21) к параметрам протокола EAP-AKA, EAP-AKA′ (приложение N 22 к Правилам).

20. Обязательные требования к оборудованию, выполняющему функции 3GPP AAA, приведены:

1) к выполнению функции сервера для метода EAP-AKA, используемого при аутентификации UE;

2) к получению от HLR/HSS информации о профилях UE для аутентификации;

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

4) к обновлению информации для доступа TWAN по запросу HLR/HSS;

5) к передаче информации авторизации пользователя к WLAN через 3GPP ААА прокси сервер, если пользователь находится в визитной сети;

6) к регистрации своего адреса в HLR/HSS при каждой аутентификации пользователя;

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

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

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

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

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

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

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

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

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

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

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

18) к параметрам протокола IKEv2 (приложение N 18 к Правилам);

19) к параметрам протокола IPSec (идентификационный заголовок протокола IPSec (AH), параметры протокола ESP) (приложение N 19 к Правилам);

20) к параметрам протокола Diameter на интерфейсах STa, SWx, SWa, SWd (приложение N 20 к Правилам);

21) к данным 3GPP AAA сервера при реализации non-3GPP доступа (приложение N 21 к Правилам);

22) к параметрам протокола EAP-AKA, EAP-AKA′ (приложение N 22 к Правилам).

21. Обязательные требования к оборудованию, выполняющему функции 3GPP AAA прокси, приведены:

1) к трансляции информации для аутентификации между WLAN и 3GPP AAA сервером;

2) к предоставлению информации об ограничениях, полученной из домашней сети при использовании доступа WLAN;

3) к формированию и передаче данных для тарификации к системе тарификации VPLMN;

4) к прекращению обслуживания;

5) к обеспечению взаимодействия интерфейсов SWa, STa и SWd при использовании на них различных протоколов;

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

9) к параметрам протокола IKEv2 (приложение N 18 к Правилам);

10) к параметрам протокола IPSec (идентификационный заголовок протокола IPSec (AH), параметры протокола ESP) (приложение N 19 к Правилам);

11) к параметрам протокола Diameter на интерфейсах STa, SWa, SWd (приложение N 20 к Правилам);

12) к данным 3GPP AAA прокси сервера при реализации non-3GPP доступа (приложение N 21 к Правилам);

13) к параметрам протокола EAP-AKA, EAP-AKA′ (приложение N 22 к Правилам).

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

Требования к параметрам системы нумерации и идентификации

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

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

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

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

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

"1"<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org ? для аутентификации EAP-AKA;

"0"<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org ? для аутентификации EAP-SIM;

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

"WIMAX" - сеть доступа WiMAX;

"WLAN" ? сеть доступа WLAN;

"ETHERNET" ? сеть фиксированного доступа с коммутацией пакетов.

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

Требования к данным MME

Требования к данным MME должны устанавливаться для AC стандарта LTE (для состояний АС ECM-IDLE, ECM-CONNECTED или EMM-DEREGISTERED), находящихся в зонах слежения (далее - ТА), обслуживаемых указанной MME, и приведены в таблице.

Таблица

Данные	Комментарии
Международный номер AC (IMSI)
Индикатор неподтверждения подлинности IMSI (IMSI unauthenticated-indicator)
Международный номер AC в сети ISDN (MSISDN)	при наличии в HSS
Состояние управления мобильностью (ECM-IDLE, ECM-CONNECTED, EMM-DEREGISTERED) (MM State)
Глобальный уникальный временный идентификатор (GUTI)
Международный идентификатор оборудования AC и версия программного обеспечения (IMEI/IMEISV) (ME Identity)
Список зон слежения (Tracking Area List)
Идентификатор зоны слежения, в которой произошло последнее обновление зоны слежения (TAI of last TAU)
Глобальный идентификатор соты в сети радиодоступа стандарта LTE (E-UTRAN Cell Global Identity)
Время, прошедшее с момента последнего определения Глобального идентификатора соты стандарта LTE и/или LTE-Advanced (E-UTRAN Cell Identity Age)
Идентификатор закрытой группы пользователей (CSG ID)
Членство в закрытой группе пользователей (CSG membership)
Режим доступа (Access mode)
Параметры аутентификации: произвольный номер (RAND), ожидаемый ответ (XRES), ключ (KASME), символ аутентификации (AUTN) (Authentication Vector)
Возможности радиодоступа AC (UE Radio Access Capability)
Марка класса 2 для оборудования AC (поддержка передачи обслуживания к сети радиодоступа стандарта GSM 900/1800 или UMTS) (MS Classmark 2)
Марка класса 3 для оборудования AC (поддержка передачи обслуживания к сети радиодоступа стандарта GSM 900/1800) (MS Classmark 3)
Поддерживаемые кодеки (Supported Codecs)
Сетевые возможности AC (UE Network Capability)
Сетевые возможности AC стандарта GSM 900/1800 или UMTS (MS Network Capability)
Параметры DRX (UE Specific DRX Parameters)
Выбранный алгоритм безопасности слоя без доступа (Selected NAS Algorithm)
Идентификатор установки ключа (eKSI)
Ключ KASME (KASME)
Ключи слоя без доступа и параметры счета (NAS Keys and COUNT)
Идентификатор выбранного оператора сети (Selected CN operator id)
Восстановление данных HSS (Recovery)
Ограничение доступа (Access Restriction)
Ограничения оператора для услуг передачи данных (ODB for PS parameters)
Замена APN-OI (APN-OI Replacement)
IP адрес MME для интерфейса S11 с S-GW (MME IP address for S11)
Идентификатор конечной точки туннеля MME для интерфейса S11 (MME TEID for S11)
IP адрес S-GW для интерфейсов S11/S4 (S-GW IP address for S11/S4)
Идентификатор конечной точки туннеля S-GW для интерфейсов S11/S4 (S-GW TEID for S11/S4)
IP адрес SGSN для интерфейса S3 (SGSN IP address for S3)
Идентификатор конечной точки туннеля SGSN для интерфейса S3 (SGSN TEID for S3)
IP адрес используемого узла радиодоступа eNodeB для интерфейса S1-MME (eNodeB Address in Use for S1-MME)
Уникальный идентификатор AC для eNodeB (eNB UE S1AP ID)
Уникальный идентификатор AC для MME (MME UE S1АР ID)
Подписка AC - Общая максимальная скорость передачи (Subscribed-UE-AMBR))
Общая максимальная скорость передачи (UE-AMBR)
Характеристики для учета стоимости AC в соответствии с подпиской в сети (EPS Subscribed Charging Characteristics)
Индекс приоритетности выбора Технологии радиодоступа/Частоты (Subscribed RFSP Index)
Используемый Индекс приоритетности выбора Технологии радиодоступа/Частоты (RFSP Index in Use)
Подробное описание трейса (Trace reference)
Тип трейса (Trace Type)
Идентификатор триггера (Trigger id)
Идентификатор центра управления и обслуживания, куда будут передаваться отчеты по трейсам (OMC Identity)
Параметр запроса доступности AC для MME (URRP-MME)
Данные подписки закрытой группы пользователей (CSG Subscription Data)
Разрешение местного IP доступа (LIPA Allowed) <*>
Подписка на периодическое обновление зоны маршрутизации/слежения по таймеру (Subscribed Periodic RAU/TAU Timer) <*>
Подписка на приоритетное обслуживание в домене CS (MPS CS priority) <*>
Подписка на приоритетное обслуживание в EPS (MPS EPS priority) <*>
Данные для каждого активного соединения сети передачи данных
Используемая точка доступа (APN in Use)
Ограничение точки доступа (APN Restriction)
Подписка на APN (APN Subscribed)
Тип сети передачи данных (IPv4, IPv6, IPv4v6) (PDN Type)
IP адрес (адреса) сети передачи данных (IP Address(es))
Характеристики учета стоимости абонентской станции в соответствии с подпиской в сети передачи данных EPS (EPS PDN Subscribed Charging Characteristics)
Замещение точки доступа (APN-OI Replacement)
Разрешения возможности распределения трафика IP (SIPTO permissions) <*>
Разрешения LIPA (LIPA permissions) <*>	LIPA-разрешено, только LIPA, LIPA-при условии
Возможность использовать для APN AC P-GW домашней или визитной сети (VPLMN Address Allowed)
IP адрес используемого P-GW (для плоскости управления) (P-GW Address in Use (control plane))
Идентификатор конечной точки туннеля P-GW для интерфейса S5/S8 (для плоскости управления) (P-GW TEID for S5/S8 (control plane))
Сообщение об изменении информации AC (MS Info Change Reporting Action)
Сообщение об изменении информации закрытой группы пользователей (CSG Information Reporting Action)
Профиль качества обслуживания в соответствии с подпиской в EPS (QCI и ARP) (EPS subscribed QoS profile) <*>
Подписка Точка доступа - Общая максимальная скорость передачи (Subscribed-APN-AMBR)
Точка доступа - Общая максимальная скорость передачи (APN-AMBR)
Ключ GRE, выделенный P-GW для передачи пользовательских данных "вверх" (только для PMIPv6 на S5/S8) (P-GW GRE Key for uplink traffic (user plane))
Идентификатор EPS по умолчанию (Default bearer)
Низкий приоритет доступа (low access priority) <*>
Данные для каждого канала соединения сети передачи данных
Идентификатор канала передачи данных EPS (EPS Bearer ID)
Идентификатор транзакции (TI)
IP адрес S-GW для S1-u интерфейса (S-GW IP address for S1-u)
Идентификатор конечной точки туннеля S-GW для интерфейсов S1-u (S-GW TEID for S1-u)
Идентификатор конечной точки туннеля P-GW для интерфейса S5/S8 (для плоскости пользователя) (P-GW TEID for S5/S8 (user plane))
IP адрес P-GW для интерфейса S5/S8 (для плоскости пользователя) (P-GW IP address for S5/S8 (user plane))
Качество обслуживания в канале передачи данных EPS (QCI и ARP) (EPS bearer QoS)
Шаблон потока трафика (только для PMIPv6 на S5/S8) (TFT)
Данные для экстренного обслуживания AC
Наименование точки доступа при экстренном обслуживании (Emergency Access Point Name (em APN))
Профиль QoS при экстренном обслуживании EPS (QCI и ARP) (Emergency QoS profile)
Точка доступа при экстренном обслуживании - Общая максимальная скорость передачи (Emergency APN-AMBR)
Идентификатор P-GW при экстренном обслуживании (Emergency P-GW identity)
Примечание: <*> "Данные" обязательны только для стандарта LTE-Advanced.

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

Требования к параметрам протокола S1-AP, используемого при взаимодействии eNodeB с MME

Таблица.

Сообщение	Направление передачи
Запрос установки E-RAB (E-RAB SETUP REQUEST)	от MME к eNodeB
Ответ на запрос установки E-RAB (E-RAB SETUP RESPONSE)	от eNodeB к MME
Запрос изменения E-RAB (E-RAB MODIFY REQUEST)	от MME к eNodeB
Ответ на запрос изменения E-RAB (E-RAB MODIFY RESPONSE)	от eNodeB к MME
Команда освобождения E-RAB (E-RAB RELEASE COMMAND)	от MME к eNodeB
Ответ на команду освобождения E-RAB (E-RAB RELEASE RESPONSE)	от eNodeB к MME
Освобождение E-RAB (E-RAB RELEASE INDICATION)	от eNodeB к MME
Запрос установки инициализации контекста (INITIAL CONTEXT SETUP REQUEST)	от MME к eNodeB
Ответ на запрос установки инициализации контекста (INITIAL CONTEXT SETUP RESPONSE)	от eNodeB к MME
Ошибка установки инициализации контекста (INITIAL CONTEXT SETUP FAILURE)	от eNodeB к MME
Запрос освобождения контекста АС (UE CONTEXT RELEASE REQUEST)	от eNodeB к MME
Команда освобождения контекста АС (UE CONTEXT RELEASE COMMAND)	от MME к eNodeB
Освобождение контекста АС выполнено (UE CONTEXT RELEASE COMPLETE)	от eNodeB к MME
Запрос изменения контекста АС (UE CONTEXT MODIFICATION REQUEST)	от MME к eNodeB
Ответ на запрос изменения контекста АС (UE CONTEXT MODIFICATION RESPONSE)	от eNodeB к MME
Ошибка изменения контекста (UE CONTEXT MODIFICATION FAILURE)	от eNodeB к MME
Требуется хендовер (HANDOVER REQUIRED)	от eNodeB к MME
Команда на выполнение хендовера (HANDOVER COMMAND)	от MME к eNodeB
Хендовер не возможен (HANDOVER PREPARATION FAILURE)	от MME к eNodeB
Запрос хендовера (HANDOVER REQUEST)	от MME к eNodeB
Подтверждение запроса хендовера (HANDOVER REQUEST ACKNOWLEDGE)	от eNodeB к MME
Отсутствие ресурсов для хендовера (HANDOVER FAILURE)	от eNodeB к MME
Подтверждение хендовера (HANDOVER NOTIFY)	от eNodeB к MME
Запрос коммутации конечной точки туннеля (PATH SWITCH REQUEST)	от eNodeB к MME
Подтверждение коммутации конечной точки туннеля (PATH SWITCH REQUEST ACKNOWLEDGE)	от MME к eNodeB
Ошибка при коммутации конечной точки туннеля (PATH SWITCH REQUEST FAILURE)	от MME к eNodeB
Отмена хендовера (HANDOVER CANCEL)	от eNodeB к MME
Подтверждение отмены хендовера (HANDOVER CANCEL ACKNOWLEDGE)	от MME к eNodeB
Передача статуса eNodeB (eNB STATUS TRANSFER)	от eNodeB к MME
Передача статуса MME (MME STATUS TRANSFER)	от MME к eNodeB
Поиск (PAGING)	от MME к eNodeB
Инициализация сообщений АС INITIAL UE MESSAGE	от eNodeB к MME
Транспортировка сообщений NAS "вниз" (DOWNLINK NAS TRANSPORT)	от MME к eNodeB
Транспортировка сообщений NAS "вверх" (UPLINK NAS TRANSPORT)	от eNodeB к MME
Недоставка сообщений NAS "вниз" (NAS NON DELIVERY INDICATION)	от eNodeB к MME
Сброс (RESET)	от eNodeB к MME и от MME к eNodeB
Подтверждение сброса (RESET ACKNOWLEDGE)	от eNodeB к MME и от MME к eNodeB
Индикация ошибки (ERROR INDICATION)	от eNodeB к MME и от MME к eNodeB
Запрос установки S1 (S1 SETUP REQUEST)	от eNodeB к MME
Ответ на запрос установки S1 (S1 SETUP RESPONSE)	от MME к eNodeB
Ошибка установки S1 (S1 SETUP FAILURE)	от MME к eNodeB
Обновление конфигурации eNodeB (ENB CONFIGURATION UPDATE)	от eNodeB к MME
Подтверждение обновления конфигурации eNodeB (ENB CONFIGURATION UPDATE ACKNOWLEDGE)	от MME к eNodeB
Ошибка при обновления конфигурации eNodeB (ENB CONFIGURATION UPDATE FAILURE)	от MME к eNodeB
Обновление конфигурации MME (MME CONFIGURATION UPDATE)	от MME к eNodeB
Подтверждение обновления конфигурации MME (MME CONFIGURATION UPDATE ACKNOWLEDGE)	от eNodeB к MME
Ошибка при обновления конфигурации MME (MME CONFIGURATION UPDATE FAILURE)	от eNodeB к MME
Начало перегрузки (OVERLOAD START)	от MME к eNodeB
Окончание перегрузки (OVERLOAD STOP)	от MME к eNodeB
Индикация возможностей АС (UE CAPABILITY INFO INDICATION)	от eNodeB к MME
Начало записи трейса (TRACE START)	от MME к eNodeB
Индикация ошибки записи трейса (TRACE FAILURE INDICATION)	от eNodeB к MME
Завершение трейса (DEACTIVATE TRACE)	от MME к eNodeB
Запрос информации о местоположении (LOCATION REPORTING CONTROL)	от MME к eNodeB
Ошибка при отчете о местоположении (LOCATION REPORT FAILURE INDICATION)	от eNodeB к MME
Отчет о местоположении (LOCATION REPORT)	от eNodeB к MME
Запрос начала или возобновления предупреждающих сообщений (WRITE-REPLACE WARNING REQUEST)	от MME к eNodeB
Ответ на запрос предупреждающих сообщений (WRITE-REPLACE WARNING RESPONSE)	от eNodeB к MME
Запрос удаления предупреждающих сообщений (KILL REQUEST)	от MME к eNodeB
Ответ на запрос удаления предупреждающих сообщений (KILL RESPONSE)	от eNodeB к MME
Передача информации eNodeB (eNB DIRECT INFORMATION TRANSFER)	от eNodeB к MME
Передача информации MME (MME DIRECT INFORMATION TRANSFER)	от MME к eNodeB
Передача конфигурации сети радиодоступа (eNB CONFIGURATION TRANSFER)	от eNodeB к MME
Передача конфигурации сети радиодоступа (MME CONFIGURATION TRANSFER)	от MME к eNodeB
Передача информации о пути в соте (CELL TRAFFIC TRACE)	от eNodeB к MME

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

Требования к параметрам протокола SGsAP, используемого при взаимодействии MME с MSC сервером/VLR

1. Установление входящей и исходящей радиотелефонной связи должно осуществляться к АС, имеющей регистрацию в MME сети стандарта LTE и в визитном регистре местоположения (VLR) сетей стандартов GSM 900/1800 или UMTS.

2. Сообщения SGsAP, передаваемые между MME и MSC сервером/VLR (интерфейс SGs), для установления радиотелефонной связи приведены в таблице.

Таблица.

Сообщение	Направление передачи
Подтверждение на запрос активности АС (ALERT-ACK)	от MME к VLR
Отказ на запрос активности АС (ALERT-REJECT)	от MME к VLR
Запрос активности АС (ALERT-REQUEST)	от VLR к MME
Данные "вниз" (от VLR к АС) (DOWNLINK-UNITDATA)	от VLR к MME
Подтверждение на индикацию отключения EPS (EPS-DETACH-ACK)	от VLR к MME
Индикация отключения EPS (EPS-DETACH-INDICATION)	от MME к VLR
Подтверждение на индикацию отключения IMSI (IMSI-DETACH-ACK)	от VLR к MME
Индикация отключения IMSI (IMSI-DETACH-INDICATION)	от MME к VLR
Обновление местоположения выполнено (LOCATION-UPDATE-ACCEPT)	от VLR к MME
Обновление местоположения отклонено (LOCATION-UPDATE-REJECT)	от VLR к MME
Запрос обновления местоположения (LOCATION-UPDATE-REQUEST)	от MME к VLR
Запрос специфической абонентской информации (MM-INFORMATION-REQUEST)	от VLR к MME
Индикация статуса (STATUS)	от VLR к MME или от MME к VLR
Запрос обслуживания (SERVICE-REQUEST)	от MME к VLR
Индикация активности АС (MS-ACTIVITY-INDICATION)	от MME к VLR
АС недоступна (MS-UNREACHABLE)	от MME к VLR
Данные "вверх" (от АС к VLR) (UPLINK-UNITDATA)	от MME к VLR
Отказ в поиске (PAGING-REJECT)	от MME к VLR
Запрос поиска АС (PAGING-REQUEST)	от VLR к MME
Подтверждение выполнения сброса (RESET-ACK)	от VLR к MME или от MME к VLR
Индикация сброса (RESET-INDICATION)	от VLR к MME или от MME к VLR
Переназначение TMSI выполнено (TMSI-REALLOCATION-COMPLETE)	от MME к VLR
Запрос освобождения (RELEASE-REQUEST)	от VLR к MME

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

Требования к параметрам протокола DIAMETER, используемого при взаимодействии MME с HSS (интерфейс S6A), SGSN с HSS (интерфейс S6D), MME с EIR (интерфейс S13), SGSN с EIR (интерфейс S13′), PCRF с P-GW (интерфейс GX), H-PCRF(V-PCRF) с S-GW (интерфейс GXC), V-PCRF с H-PCRF (интерфейс S9), PCRF с функциями приложений (интерфейс RX)

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

Сообщение	Код сообщения	Направление передачи
Обновление данных о местонахождении подвижного абонента. Запрос (Update-Location-Request (ULR))	316, бит R в поле команды "Флаг" установлен в "1"	от MME или SGSN к HSS
Обновление данных о местонахождении подвижного абонента. Ответ (Update-Location-Answer (ULA))	316, бит R в поле команды "Флаг" очищен	от HSS к MME или SGSN
Информация аутентификации. Запрос (Authentication-Information-Request (AIR))	318, бит R в поле команды "Флаг" установлен в "1"	от MME или SGSN к HSS
Информация аутентификации. Ответ (Authentication-Information-Answer (AIA))	318, бит R в поле команды "Флаг" очищен	от HSS к MME или SGSN
Отмена информации о местонахождении АС. Запрос (Cancel-Location-Request (CLR))	317, бит R в поле команды "Флаг" установлен в "1"	от HSS к MME или SGSN
Отмена информации о местонахождении АС. Ответ (Cancel-Location-Answer (CLA))	317, бит R в поле команды "Флаг" очищен	от MME или SGSN к HSS
Регистрация абонентских данных. Запрос (Insert-Subscriber-Data-Request (IDR))	319, бит R в поле команды "Флаг" установлен в "1"	от HSS к MME или SGSN
Регистрация абонентских данных. Ответ (Insert-Subscriber-Data-Answer (IDA))	319, бит R в поле команды "Флаг" очищен	от MME или SGSN к HSS
Удаление абонентских данных. Запрос (Delete-Subscriber-Data-Request (DSR))	320, бит R в поле команды "Флаг" установлен в "1"	от HSS к MME или SGSN
Удаление абонентских данных. Ответ (Delete-Subscriber-Data-Answer (DSA))	320, бит R в поле команды "Флаг" очищен	от MME или SGSN к HSS
Уведомление о стирании данных абонента. Запрос (Purge-UE-Request (PUR))	321, бит R в поле команды "Флаг" установлен в "1"	от MME или SGSN к HSS
Уведомление о стирании данных абонента. Ответ (Purge-UE-Answer (PUA))	321, бит R в поле команды "Флаг" очищен	от HSS к MME или SGSN
Сброс. Запрос (Reset-Request (RSR))	322, бит R в поле команды "Флаг" установлен в "1"	от HSS к MME или SGSN
Сброс. Ответ (Reset-Answer (RSA))	322, бит R в поле команды "Флаг" очищен	от MME или SGSN к HSS
Уведомление. Запрос (Notify-Request (NOR))	323, бит R в поле команды "Флаг" установлен в "1"	от MME или SGSN к HSS
Уведомление. Ответ (Notify-Answer (NOA))	323, бит R в поле команды "Флаг" очищен	от HSS к MME или SGSN

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

Сообщение	Код сообщения	Направление передачи
Проверка международного идентификатора оборудования АС. Запрос (ME-Identity-Check-Request (ECR))	324, бит R в поле команды "Флаг" установлен в "1"	от MME или SGSN к EIR
Проверка международного идентификатора оборудования АС. Ответ (ME-Identity-Check-Answer (ECA))	324, бит R в поле команды "Флаг" очищен	от EIR к MME или SGSN

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

Сообщение	Код сообщения	Направление передачи
Правила политики управления и тарификации (РСС). Запрос (CC-Request (CCR))	272, бит R в поле команды "Флаг" установлен в "1"	от PDN GW к PCRF, от V-PCRF к H-PCRF
Правила политики управления и тарификации. Ответ (CC-Answer (CCA))	272, бит R в поле команды "Флаг" очищен	от PCRF к PDN GW от H-PCRF к V-PCRF
Незапрашиваемые правила РСС. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от PCRF к PDN GW от H-PCRF к V-PCRF
Незапрашиваемые правила РСС. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от PDN GW к PCRF от V-PCRF к H-PCRF

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

Сообщение	Код сообщения	Направление передачи
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от AF к PCRF
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от PCRF к AF
Незапрашиваемые правила РСС. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от PCRF к AF
Незапрашиваемые правила РСС. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от AF к PCRF
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от AF к PCRF
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от PCRF к AF
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от PCRF к AF
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от AF к PCRF

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

Сообщение	Код сообщения	Направление передачи
Правила политики управления и тарификации (РСС). Запрос. (CC-Request (CCR))	272, бит R в поле команды "Флаг" установлен в "1"	от S-GW к H-PCRF (V-PCRF)
Правила политики управления и тарификации. Ответ. (CC-Answer (CCA))	272, бит R в поле команды "Флаг" очищен	от H-PCRF (V-PCRF) к S-GW
Незапрашиваемые правила РСС. Запрос. (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от H-PCRF (V-PCRF) к S-GW
Незапрашиваемые правила РСС. Ответ. (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от S-GW к H-PCRF (V-PCRF)

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

Требования к параметрам протокола NAS

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

Сообщение	Направление передачи
Подключение принято (Attach accept)	от MME к АС
Подключение выполнено (Attach complete)	от АС к MME
Подключение отклонено (Attach reject)	от MME к АС
Запрос подключения (Attach request)	от АС к MME
Неуспешная аутентификация (Authentication failure)	от АС к MME
Отклонение аутентификации (Authentication reject)	от MME к АС
Запрос аутентификации (Authentication request)	от MME к АС
Ответ аутентификации (Authentication response)	от АС к MME
Уведомление об обслуживании в CS (CS service notification)	от MME к АС
Отключение завершено (инициатор отключения АС) (Detach accept)	от MME к АС
Отключение завершено (инициатор отключения сеть) (Detach accept)	от АС к MME
Запрос отключения (инициатор отключения АС) (Detach request)	от АС к MME
Запрос отключения (инициатор отключения сеть) (Detach request)	от MME к АС
Транспортировка сообщений NAS "вниз" (доставка коротких сообщений) (Downlink NAS Transport)	от MME к АС
Информация сети об управлении мобильностью (EMM information)	от MME к АС
Состояние процесса управления мобильностью (EMM status)	от MME к АС или от АС к MME
Запрос расширенного обслуживания (Extended service request)	от АС к MME
Команда назначения глобального уникального временного идентификатора (GUTI (Globally Unique Temporary Identifier) reallocation command)	от MME к АС
Подтверждение назначения глобального уникального временного идентификатора (GUTI reallocation complete)	от АС к MME
Запрос идентичности (Identity request)	от MME к АС
Ответ на запрос идентичности (Identity response)	от АС к MME
Команда режима безопасности (Security mode command)	от MME к АС
Выполнение режима безопасности (Security mode complete)	от АС к MME
Отклонение режима безопасности (Security mode reject)	от АС к MME
Отклонение запроса обслуживания (Service reject)	от MME к АС
Запрос обслуживания (Service request)	от АС к MME
Принятие запроса обновления зоны слежения (Tracking area update accept)	от MME к АС
Выполнение обновления зоны слежения (Tracking area update complete)	от АС к MME
Отказ обновления зоны слежения (Tracking area update reject)	от MME к АС
Запрос обновления зоны слежения (Tracking area update request)	от АС к MME
Транспортировка сообщений NAS "вверх" (доставка коротких сообщений) (Uplink NAS Transport)	от АС к MME
Основная транспортировка сообщений NAS "вниз" (Downlink generic NAS transport)	от MME к АС
Основная транспортировка сообщений NAS "вверх" (Uplink generic NAS transport)	от АС к MME

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

Сообщение	Направление передачи
Запрос активации контекста выбранной EPS принят (Activate dedicated EPS bearer context accept)	от АС к MME
Запрос активации контекста выбранной EPS отклонен (Activate dedicated EPS bearer context reject)	от АС к MME
Запрос активации контекста выбранной EPS (Activate dedicated EPS bearer context request)	от MME к АС
Запрос активации контекста EPS по умолчанию принят (Activate default EPS bearer context accept)	от АС к MME
Запрос активации контекста EPS по умолчанию отклонен (Activate default EPS bearer context reject)	от АС к MME
Запрос активации контекста EPS по умолчанию (Activate default EPS bearer context request)	от MME к АС
Отклонение выделения ресурса (Bearer resource allocation reject)	от MME к АС
Запрос выделения ресурса (Bearer resource allocation request)	от АС к MME
Отклонение модификации ресурса (Bearer resource modification reject)	от MME к АС
Запрос модификации ресурса (Bearer resource modification request)	от АС к MME
Запрос удаления контекста выбранной EPS принят (Deactivate EPS bearer context accept)	от АС к MME
Запрос удаления контекста выбранной EPS (Deactivate EPS bearer context request)	от MME к АС
Запрос информации управления сессией (ESM information request)	от MME к АС
Информация управления сессией (ESM information response)	от АС к MME
Состояние процесса управления сессией (ESM status)	от MME к АС или от АС к MME
Запрос модификации контекста EPS принят (Modify EPS bearer context accept)	от АС к MME
Запрос модификации контекста EPS отклонен (Modify EPS bearer context reject)	от АС к MME
Запрос модификации контекста EPS (Modify EPS bearer context request)	от MME к АС
Отклонение возможности соединения с сетью передачи данных (PDN connectivity reject)	от MME к АС
Запрос соединения с сетью передачи данных (PDN connectivity request)	от АС к MME
Отклонение запроса разъединения с сетью передачи данных (PDN disconnect reject)	от MME к АС

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

Требования к параметрам протокола GTP

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

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

Версия	P	T	0	0	0
Тип сообщения
Длина сообщения
TEID
Номер последовательности
Резерв

Рисунок 1.

1.1.1. В первом октете:

1) биты 6 - 8 должны определять версию протокола GTPv2-C и устанавливаться равными десятичному числу "2";

2) бит 5 (флаг P) должен определять наличие прикрепленных сообщений. Если флаг P установлен равным "0", то нет прикрепленных сообщений; если флаг P установлен равным "1", то другое сообщение GTPv2-C с собственным заголовком и телом присутствует в конце текущего сообщения;

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

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

если флаг T = 1, поле TEID должно следовать в октетах 5 - 8 за полем "Длина сообщения". Поле TEID должно занимать четыре октета;

4) биты 3 - 1 должны являться резервными, отправитель должен устанавливать их в "0", а получатель не должен анализировать.

1.1.2. Второй октет должен определять тип сообщения.

1.1.3. Октеты 3 - 4 должны содержать поле "Длина сообщения". Поле "Длина сообщения" должно указывать длину сообщения в октетах, начиная с пятого октета.

1.1.4. Октеты 9 - 11, в случае присутствия TEID, или 5 - 7, в случае отсутствия TEID, должны содержать поле "Номер последовательности" GTPv2-C. Следующий октет должен использоваться как резерв.

1.2. Информационные элементы сообщения GTPv2-C дожны следовать за заголовком сообщения протокола GTPv2-C, имеющего формат, приведенный в подпункте 1.1 настоящего пункта.

1.3. Сообщения протокола GTPv2-C приведены в таблице N 1.

Таблица N 1.

Тип сообщения	Сообщение
1	Запрос "эхо" (Echo Reques)
2	Ответ "эхо" (Echo Response)
3	Версия не поддерживается (Version Not Supported Indication)
От SGSN/MME к MSC серверу (Sv) при хэндовере
25	Запрос отдельной непрерывности голосового вызова на радио интерфейсе (далее - SRVCC) при переходе от сети с коммутацией пакетов к сети с коммутацией каналов (SRVCC PS to CS Request)
26	Ответ на запрос SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов (SRVCC PS to CS Response)
27	Уведомление о выполнении SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов (SRVCC PS to CS Complete Notification)
28	Подтверждение выполнения SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов (SRVCC PS to CS Complete Acknowledge)
29	Уведомление о завершении SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов (SRVCC PS to CS Cancel Notification)
30	Подтверждение завершения SRVCC при переходе от сети с коммутацией пакетов к сети с коммутацией каналов (SRVCC PS to CS Cancel Acknowledge)
От SGSN/MME к P-GW (S4/S11, S5/S8)
32	Запрос создания сеанса (Create Session Request)
33	Ответ на запрос создания сеанса (Create Session Response)
34	Запрос изменения носителя (Modify Bearer Request)
35	Ответ на запрос изменения канала передачи данных (Modify Bearer Response)
36	Запрос удаления сеанса (Delete Session Request)
37	Ответ на запрос удаления сеанса (Delete Session Response)
38	Запрос уведомления об изменении (Change Notification Request)
39	Ответ на запрос уведомления об изменении (Change Notification Response)
164	Уведомление о возобновлении связи (Resume Notification)
165	Подтверждение возобновления связи (Resume Acknowledge)
Сообщения без явного ответа (Messages without explicit response)
64	Команда изменения канала передачи данных (Modify Bearer Command) (MME/SGSN к P-GW - S11/S4, S5/S8)
65	Индикация неудачного изменения канала передачи данных (Modify Bearer Failure Indication) (P-GW к MME/SGSN - S5/S8, S11/S4)
66	Команда освобождения канала передачи данных (Delete Bearer Command) (MME/SGSN к P-GW - S11/S4, S5/S8)
67	Индикация неудачного освобождения канала передачи данных (Delete Bearer Failure Indication) (P-GW к MME/SGSN - S5/S8, S11/S4))
68	Команда распределения ресурсов канала передачи данных (Bearer Resource Command) (MME/SGSN к P-GW - S11/S4, S5/S8)
69	Индикация неудачного распределения ресурсов канала передачи данных (Bearer Resource Failure Indication) (P-GW к MME/SGSN - S5/S8, S11/S4)
70	Индикация неудачного уведомления о передаче данных "вниз" (Downlink Data Notification Failure Indication) (SGSN/MME к S-GW - S4/S11)
71	Активация сеанса трассировки (Trace Session Activation) (MME/SGSN к P-GW - S11/S4, S5/S8)
72	Деактивация сеанса трассировки (Trace Session Deactivation) (MME/SGSN к P-GW - S11/S4, S5/S8)
73	Индикация остановки поиска (Stop Paging Indication) (S-GW к MME/SGSN - S11/S4)
От P-GW к SGSN/MME (S5/S8, S4/S11)
95	Запрос активации канала передачи данных (Create Bearer Request)
96	Ответ на запрос активации канала передачи данных (Create Bearer Response)
97	Запрос обновления канала передачи данных (Update Bearer Request)
98	Ответ на запрос обновления канала передачи данных (Update Bearer Response)
99	Запрос освобождения канала передачи данных (Delete Bearer Request)
100	Ответ на запрос освобождения канала передачи данных (Delete Bearer Response)
От P-GW к MME, от MME к P-GW, от S-GW к P-GW, от SGW к MME (S5/S8, S11)
101	Запрос удаления соединения (Delete PDN Connection Set Request)
102	Ответ на запрос удаления соединения (Delete PDN Connection Set Response)
От MME к MME, от SGSN к MME, от MME к SGSN, от SGSN к SGSN (S3/S10/S16)
128	Запрос идентификации (Identification Request)
129	Ответ на запрос идентификации (Identification Response)
130	Запрос контекста (Context Request)
131	Ответ на запрос контекста (Context Response)
132	Подтверждение ответа на запрос контекста (Context Acknowledge)
133	Запрос передачи при перемещении AC (Forward Relocation Request)
134	Ответ на запрос передачи при перемещении AC (Forward Relocation Response)
135	Уведомление выполнения передачи при перемещении AC (Forward Relocation Complete Notification)
136	Подтверждение выполнения передачи при перемещении AC (Forward Relocation Complete Acknowledge)
137	Уведомление о передаче контекста (Forward Access Context Notification)
138	Подтверждение передачи контекста (Forward Access Context Acknowledge)
139	Запрос отмены перемещения (Relocation Cancel Request)
140	Ответ на запрос отмены перемещения (Relocation Cancel Response)
141	Конфигурация туннеля передачи (Configuration Transfer Tunnel)
152	Передача информации сети радиодоступа (RAN Information Relay)
От SGSN к MME, от MME к SGSN (S3)
149	Уведомление об отключении (Detach Notification)
150	Подтверждение отключения (Detach Acknowledge)
151	Индикация поиска в сети с коммутацией каналов (CS Paging Indication)
153	Уведомление MME (Alert MME Notification)
154	Подтверждение на уведомление MME (Alert MME Acknowledge)
155	Уведомление активации AC (UE Activity Notification)
156	Подтверждение активации AC (UE Activity Acknowledge)
От SGSN/MME к S-GW, от SGSN к MME (S4/S11/S3), от SGSN к SGSN (S16), от S-GW к P-GW (S5/S8)
162	Уведомление о прерывании связи (Suspend Notification)
163	Подтверждение прерывания связи (Suspend Acknowledge)
От SGSN/MME к S-GW (S4/S11)
160	Запрос создания туннеля передачи (Create Forwarding Tunnel Request)
161	Ответ на запрос создания туннеля передачи (Create Forwarding Tunnel Response)
166	Запрос создания туннеля передачи косвенных данных (Create Indirect Data Forwarding Tunnel Request)
167	Ответ на запрос создания туннеля передачи косвенных данных (Create Indirect Data Forwarding Tunnel Response)
168	Запрос удаления туннеля передачи косвенных данных (Delete Indirect Data Forwarding Tunnel Request)
169	Ответ на запрос удаления туннеля передачи косвенных данных (Delete Indirect Data Forwarding Tunnel Response)
170	Запрос освобождения доступа к каналу передачи данных (Release Access Bearers Request)
171	Ответ на запрос освобождения доступа к каналу передачи данных (Release Access Bearers Response)
От S-GW к SGSN/MME (S4/S11)
176	Уведомление о передаче данных "вниз" (Downlink Data Notification)
177	Подтверждение уведомления о передаче данных "вниз" (Downlink Data Notification Acknowledge)
179	Уведомление о рестарте P-GW (P-GW Restart Notification)
180	Подтверждение на уведомление о рестарте PGW (P-GW Restart Notification Acknowledge)
От S-GW к P-GW, от P-GW к S-GW (S5/S8)
200	Запрос обновления соединения (Update PDN Connection Set Request)
201	Ответ на запрос удаления соединения (Update PDN Connection Set Response)
От MME к S-GW (S11)
211	Запрос изменения канала доступа (Modify Access Bearers Request)
212	Ответ на запрос изменения канала доступа (Modify Access Bearers Response)

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

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

Версия	PT	(*)	E	S	PN
Тип сообщения
Длина сообщения
TEID
Номер последовательности
Номер блока данных
Дополнительный заголовок

Рисунок 2.

2.1.1. В первом октете:

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", .

2.1.2. Второй октет должен определять тип сообщения.

2.1.3. Октеты 3 - 4 должны содержать поле "Длина сообщения", указывающего длину сообщения в октетах, начиная с девятого октета.

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

2.1.5. Октеты 9 - 10 должны содержать поле "Номер последовательности".

2.1.6. Поля "Номер блока данных" и "Дополнительный заголовок" занимают по одному октету.

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

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

Таблица N 2.

Тип сообщения	Сообщение
1	Запрос "эхо" (Echo Request)
2	Ответ "эхо" (Echo Response)
26	Ошибочная индикация (Error Indication)
31	Уведомление о поддержке расширенных заголовков (Supported Extension Headers Notification)
254	Меркер конца обмена информацией по туннелю (End Marker)
255	Блок данных протокола GTP (G-PDU)

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

Требования к параметрам протокола PMIPv6

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

1.1. Требования к дополнительному заголовку протокола IPv6 Mobility Header, обеспечивающему мобильность пользователя.

1.1.1. Требования к формату заголовка Mobility Header и перечню поддерживаемых полей приведены в таблице N 1.

Таблица N 1.

N поля	Поля заголовка	Длина поля (бит)
1	Payload Proto	8
2	Header Len	8
3	MH Type	8
4	Резерв	8
5	Checksum	16
6	Message Data	0 - n

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

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

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

1.1.5. Значение поля Резерв должно устанавливаться равным "0".

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

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

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

1.3. В рамках протокола PMIPv6 для интерфейсов S5, S8, S2a, S2b должны быть определены следующие сообщения:

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

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

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

"Подтверждение аннулирования регистрации" (BRA - Binding Revocation Acknowledgement).

1.4. Требования к дополнительному заголовку протокола IPv6 Type 2 Routing Header, обеспечивающему дополнительные данные для маршрутизации.

1.4.1. Требования к формату заголовка Type 2 Routing Header и перечню поддерживаемых полей приведены в таблице N 2.

Таблица N 2.

N поля	Поля заголовка	Длина поля (бит)
1	Next Header	8
2	Hdr Ext Len	8
3	Routing Type	8
4	Segments Left	8
5	Резерв	32
6	Home Address	16

1.4.2. Поле Next Header должно идентифицировать тип заголовка, следующего за заголовком Type 2 Routing Header и должно использовать значения, аналогичные используемым в заголовке "Следующий заголовок" протокола IPv6, описанное в подпункте 1.2.5 пункта 1 Приложения N 8 Правил.

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

1.4.4. Поле Routing Type должно указывать тип маршрутизации. Значение поля Routing Type должно устанавливаться равным двум.

1.4.5. Значение поля Segments Left должно устанавливаться равным "1".

1.4.6. Значение поля Резерв должно устанавливаться равным "0".

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

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

Требования к интерфейсам взаимодействия и их параметрам

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, если обеспечивающий взаимодействие с MMЕ SGSN не реализует интерфейс S3.

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

3. Оборудование P-GW должно взаимодействовать с оборудованием S-GW своей сети по интерфейсу S5, другой сети по интерфейсу S8 с использованием протоколов GTPv2-C и GTPvl-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 N 112 (зарегистрирован в Министерстве юстиции Российской Федерации 4 сентября 2006 г., регистрационный N 8194), с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 23.04.2013 N 93 (зарегистрирован в Министерстве юстиции Российской Федерации 14 июня 2013 г., регистрационный N 28788) и от 17.03.2014 N 45 (зарегистрирован в Министерстве юстиции Российской Федерации 16 апреля 2014 г., регистрационный N 31998);

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

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

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

S2c (интерфейс взаимодействия UE с P-GW, обеспечивающий передачу данных пользователя и сигнализации и поддерживающий протоколы управления мобильностью DSMIPv6 и IPSec). Формирование безопасных туннелей IPSec должно выполняться при помощи протокола IKEv2;

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 c использованием протокола Diameter);

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

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

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

S9 (интерфейс, обеспечивающий передачу сообщений протокола Diameter для управления качеством передачи данных QoS в условиях роуминга между НPCRF и 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.

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

Требования к данным S-GW

Данные EPS для обслуживаемых в S-GW AC стандартов LTE, GSM900/1800, UMTS приведены в таблице.

Таблица.

Данные	LTE и/или LTE-Advanced	GSM 900/1800, UMTS
Международный номер AC (IMSI)	присутствует	присутствует
Индикатор неподтверждения подлинности IMSI (IMSI unauthenticated-indicator)	присутствует	присутствует
Международный идентификатор оборудования AC и версия программного обеспечения (IMEI/IMEISV) (ME Identity)	присутствует	присутствует
Международный номер AC в сети ISDN (MSISDN)	присутствует	присутствует
Идентификатор выбранного оператора сети (Selected CN operator id)	присутствует	присутствует
Идентификатор конечной точки туннеля MME для интерфейса S11 (MME TEID for S11)	присутствует
IP адрес MME для интерфейса S11 (MME IP address for S11)	присутствует
Идентификатор конечной точки туннеля S-GW для интерфейсов S11/S4 (для плоскости управления) (S-GW TEID for S11/S4 (control plane))	присутствует	присутствует
IP адрес S-GW для интерфейса S11/S4 (для плоскости управления) (S-GW IP address for S11/S4 (control plane))	присутствует	присутствует
IP адрес SGSN для интерфейса S4 (для плоскости управления) (SGSN IP address for S4 (control plane))		присутствует
Идентификатор конечной точки туннеля SGSN для интерфейса S4 (для плоскости управления) (SGSN TEID for S4 (control plane))		присутствует
Подробное описание трейса (Trace reference)	присутствует	присутствует
Тип трейса (Trace Type)	присутствует	присутствует
Идентификатор триггера (Trigger id)	присутствует	присутствует
Идентификатор центра управления и обслуживания, куда будут передаваться отчеты по трейсам (ОМС Identity)	присутствует	присутствует
Последний известный идентификатор соты местонахождения AC (Last known Cell Id)	присутствует	присутствует
Время последнего обновления идентификатора соты местонахождения AC (Last known Cell Id age)	присутствует	присутствует
Данные для каждого соединения с сетью передачи данных
Используемая точка доступа (APN in Use)	присутствует	присутствует
Характеристики учета стоимости для AC в сети передачи данных EPS (EPS PDN Charging Characteristics)	присутствует	присутствует
IP адрес используемого P-GW (для плоскости управления) (P-GW Address in Use (control plane))	присутствует	присутствует
Идентификатор конечной точки туннеля P-GW для интерфейсов S5/S8 (для плоскости управления) (только для GTP на S5/S8) (P-GW TEID for S5/S8 (control plane))	присутствует	присутствует
IP адрес используемого P-GW (для плоскости пользователя) (P-GW Address in Use (user plane))	присутствует	присутствует
Ключ GRE, выделенный P-GW для передачи пользовательских данных "вверх" (только для PMIPv6 на S5/S8) (P-GW GRE Key for uplink traffic (user plane))	присутствует	присутствует
IP адрес S-GW для интерфейса S5/S8 (для плоскости управления) (S-GW IP address for S5/S8 (control plane))	присутствует	присутствует
Идентификатор конечной точки туннеля S-GW для интерфейсов S5/S8 (для плоскости управления) (только для GTP на S5/S8) (S-GW TEID for S5/S8 (control plane))	присутствует	присутствует
IP адрес используемого S-GW (для плоскости пользователя) (S-GW Address in Use (user plane))	присутствует	присутствует
Ключ GRE, выделенный S-GW для передачи пользовательских данных "вниз" (только для PMIPv6 на S5/S8) (S-GW GRE Key for downlink traffic (user plane))	присутствует	присутствует
Канал передачи данных по умолчанию (только для PMIPv6 на S5/S8) (Default Bearer)	присутствует	присутствует
Данные о каждом канале передачи данных EPS в соединении сети передачи данных
Идентификатор канала передачи данных EPS (EPS Bearer ID)	присутствует	присутствует
Шаблон потока трафика (TFT)	присутствует	присутствует
IP адрес используемого P-GW (для плоскости пользователя) (только для GTP на S5/S8) (P-GW Address in Use (user plane))	присутствует	присутствует
Идентификатор конечной точки туннеля P-GW для интерфейса S5/S8 (для плоскости пользователя) (только для GTP на S5/S8) (P-GW TEID for S5/S8 (user plane))	присутствует	присутствует
IP адрес S-GW для интерфейса S5/S8 (для плоскости пользователя) (S-GW IP address for S5/S8 ((user plane))	присутствует	присутствует
Идентификатор конечной точки туннеля S-GW для интерфейсов S5/S8 (для плоскости пользователя) (только для GTP на S5/S8) (S-GW TEID for S5/S8 (user plane))	присутствует	присутствует
IP адрес S-GW для интерфейсов S1-u, S12 и S4 (для плоскости пользователя) (S-GW IP address for S1-u, S12 and S4 (user plane))	присутствует	присутствует
Идентификатор конечной точки туннеля S-GW для интерфейсов S1-u, S12 и S4 (для плоскости пользователя) (S-GW TEID for S1-u, S12 and S4 (user plane))	присутствует	присутствует
IP адрес узла радиодоступа eNodeB для интерфейса S1-u (eNodeB Address for S1-u)	присутствует
Идентификатор конечной точки туннеля узла радиодоступа eNodeB для интерфейса S1-u (eNodeB TEID for S1-u)	присутствует
IP адрес контроллера сети радиодоступа UMTS для интерфейса S12 (RNC IP address for SI2)		присутствует
Идентификатор конечной точки туннеля контроллера сети радиодоступа UMTS для интерфейса S12 (RNC TEID for S12)		присутствует
IP адрес SGSN для интерфейса S4 (для плоскости пользователя) (SGSN IP address for S4(user plane))		присутствует
Идентификатор конечной точки туннеля SGSN для интерфейса S4 (для плоскости пользователя) (SGSN TEID for S4 (user plane))		присутствует
Качество обслуживания в канале передачи данных EPS (ARP, GBR, MBR, QIC) (EPS Bearer QoS)	присутствует	присутствует
Идентификатор данных учета стоимости, генерируемых S-GW и P-GW (Charging Id)	присутствует	присутствует

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

Требования к параметрам системы учета данных для начисления платы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к данным P-GW

Данные EPS для каждой обслуживаемой в P-GW AC стандартов LTE, GSM 900/1800, UMTS приведены в таблице.

Таблица.

Данные	LTE и/или LTE-Advanced	GSM 900/1800, UMTS
Международный номер AC (IMSI)	присутствует	присутствует
Индикатор неподтверждения подлинности IMSI (IMSI unauthenticated-indicator)	присутствует	присутствует
Международный идентификатор оборудования AC и версия программного обеспечения (IMEI/IMEISV) (ME Identity)	присутствует	присутствует
Международный номер AC в сети ISDN (MSISDN)	присутствует	присутствует
Идентификатор выбранного оператора сети (Selected CN operator id)	присутствует	присутствует
Тип технологии радиодоступа (RAT (Radio Access Technology) type)	присутствует	присутствует
Подробное описание трейса (Trace reference)	присутствует	присутствует
Тип трейса (Trace Type)	присутствует	Присутствует
Идентификатор триггера (Trigger id)	присутствует	присутствует
Идентификатор центра управления и обслуживания, куда будут передаваться отчеты по трейсам (ОМС Identity)	присутствует	присутствует
Данные для каждой используемой точки доступа
Используемая точка доступа (APN in Use)	присутствует	присутствует
Точка доступа - Общая максимальная скорость передачи (APN-AMBR)	присутствует	присутствует
Данные о соединении сети передачи данных для каждой точки доступа
IР-адрес(а) (IP Address(es))	присутствует	присутствует
Тип сети передачи данных (PDN type)	присутствует	присутствует
IP-адрес используемого S-GW (для уровня управления) (S-GW Address in Use (control plane))	присутствует	присутствует
Идентификатор конечной точки туннеля S-GW для интерфейсов S5/S8 (для уровня управления) (только для GTP на S5/S8) (S-GW TEID for S5/S8 (control plane))	присутствует	присутствует
IP адрес используемого S-GW (для уровня пользователя) (только для PMIP на S5/S8) (S-GW Address in Use (user plane))	присутствует	присутствует
Ключ GRE, выделенный S-GW для передачи пользовательских данных "вниз" (только для PMIP на S5/S8) (S-GW GRE Key for downlink traffic (user plane))	присутствует	присутствует
IP адрес P-GW для интерфейса S5/S8 (для уровня управления) (P-GW IP address for S5/S8 (control plane))	присутствует	присутствует
Идентификатор конечной точки туннеля P-GW для интерфейсов S5/S8 (для уровня управления) (только для GTP на S5/S8) (P-GW TEID for S5/S8 (control plane))	присутствует	присутствует
IP адрес используемого P-GW (для уровня пользователя) (только для PMIP на S5/S8) (P-GW Address in Use (user plane)	присутствует	присутствует
Ключ GRE, выделенный P-GW для передачи пользовательских данных "вверх" (только для PMIP на S5/S8) (P-GW GRE Key for uplink traffic (user plane))	присутствует	присутствует
Возможность передачи сообщений об изменении информации об AC (MS Info Change Reporting support indication)		присутствует
Необходимость передачи сообщений об изменении информации об AC (MS Info Change Reporting Action)	присутствует	присутствует
Необходимость передачи сообщений об изменении информации о закрытой группе пользователей (CSG Information Reporting Action)	присутствует	присутствует
Согласованный режим управления каналом (BCM)		присутствует
Идентификатор канала передачи данных по умолчанию (Default bearer)	присутствует	присутствует
Характеристики учета стоимости абонентской станции в сети передачи данных EPS (EPS PDN Charging Characteristics)	присутствует	присутствует
Данные о каждом канале передачи данных в соединении сети передачи данных (только для GTP на S5/S8)
Идентификатор канала передачи данных EPS (EPS Bearer ID)	присутствует	присутствует
Шаблон потока трафика (TFT)	присутствует	присутствует
IP адрес используемого S-GW (для уровня пользователя) (S-GW Address in Use (user plane))	присутствует	присутствует
Идентификатор конечной точки туннеля S-GW для интерфейсов S5/S8 (для уровня пользователя) (S-GW TEID for S5/S8 (user plane))	присутствует	присутствует
IP адрес используемого P-GW (для уровня пользователя) (P-GW Address in Use (user plane))	присутствует	присутствует
Идентификатор конечной точки туннеля P-GW для интерфейса S5/S8 (для уровня пользователя) (P-GW TEID for S5/S8 (user plane))	присутствует	присутствует
Качество обслуживания в канале передачи данных EPS (ARP, GBR, MBR, QCI) (EPS Bearer QoS)	присутствует	присутствует
Идентификатор данных учета стоимости, генерируемых S-GW и P-GW (Charging Id)	присутствует	присутствует

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

Требования к данным HSS для AC, поддерживающих радиодоступ стандарта LTE

Таблица.

Данные	Комментарии
Международный номер AC (IMSI)
Международный номер AC в сети ISDN (MSISDN)	опциональный
Международный идентификатор оборудования AC и версия программного обеспечения (IMEI/IMEISV)
Параметры аутентификации: произвольный номер (RAND), ожидаемый ответ (XRES), ключ (KASME), символ аутентификации (AUTN) (Authentication Vector)
Идентификатор MME, обслуживающего AC в данный момент (MME Identity)
Возможности данного MME (MME Capabilities)
EMM и ESM контекст для AC удалены из MME (MS PS Purged from EPS)
Ограничения обслуживающего оператора (ODB parameters)
Ограничения доступа в соответствии с подпиской (Access Restriction)
Характеристика для учета стоимости AC в соответствии с подпиской в сети (EPS Subscribed Charging Characteristic)
Подробное описание трейса (Trace Reference)
Тип трейса (Trace Type)
Идентификатор центра управления и обслуживания, куда будут передаваться отчеты по трейсам (OMC Identity)
Подписка AC - Общая максимальная скорость передачи (Subscribed-UE-AMBR)
Замена точки доступа (APN-OI replacement)
Индекс приоритетности выбора технологии радиодоступа/Частоты (RFSP Index)
Параметр запроса доступности AC указывающий, что подтверждение активности AC от MME зарегистрировано в HSS (URRP-MME)
Данные подписки закрытой группы пользователей (CSG Subscription Data)
Разрешение использования в VPLMN локального IP доступа (VPLMN LIPA Allowed) <*>
Подписка на периодическое обновление зоны маршрутизации/слежения по таймеру (Subscribed Periodic RAU/TAU Timer) <*>
Подписка на приоритетное обслуживание в домене CS (MPS CS priority) <*>
Возможность поддержки для AC непрерывности голосового вызова на радиоинтерфейсе (UE-SRVCC-Capability)
Подписка на приоритетное обслуживание в EPS (MPS EPS priority) <*>
Один или несколько контекстов сети передачи данных
Идентификатор контекста (Context Identifier)
Адрес сети передачи данных (PDN Address)
Тип сети передачи данных (IPv4, IPv6, IPv4v6) (PDN Type)
Замещение точки доступа (APN-OI Replacement)	опциональный
Наименование точки доступа (Access Point Name (APN))
Разрешения возможности распределения трафика IP для APN (SIPTO permissions) <*>
Разрешения LIPA (LIPA permissions) <*>	LIPA-разрешено, только LIPA, LIPA-при условии
Профиль качества обслуживания в соответствии с подпиской в EPS (QCI и ARP) (EPS subscribed QoS profile)
Подписка Точка доступа - Общая максимальная скорость передачи (Subscribed-APN-AMBR)
Характеристики учета стоимости AC в соответствии с подпиской в сети передачи данных EPS (EPS PDN Subscribed Charging Characteristics)
Возможность использовать для APN AC P-GW домашней или визитной сети (VPLMN Address Allowed)
Идентификатор P-GW (P-GW identity)
Тип выбора P-GW (статический, динамический) (P-GW Allocation Type)
Сеть радиотелефонной связи, в которой находится динамически выбранный P-GW (PLMN of P-GW)
Однородная поддержка голосового вызова IMS
в зонах слежения обслуживающего MME (Homogenous Support of IMS Over PS Sessions for MME)
Перечень соотношений: Наименование точки доступа - Идентификатор P-GW
Номер соотношения APN - P-GW (APN - P-GW relation #n)
Примечание: <*> - "данные" обязательные только для стандарта LTE-Advanced.

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

Требования к данным, хранящимся в EIR

1. В EIR должны храниться международный идентификатор оборудования АС (IMEI) или международный идентификатор оборудования и версия программного обеспечения оборудования АС (IMEISV).

2. Требования к формату IMEI:

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

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

резерв - 1 десятичный знак, принимающий значение равное "0" при передаче IMEI от АС.

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

3. Требования к формату IMEISV:

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

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

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

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

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

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

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

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

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

Требования к ЦУ и ТО

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

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

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

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

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

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

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

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

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

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

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

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

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

вывод всех кодов команд, реализованных в системе;

возможность изменения существующих и введение новых команд;

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

создание, изменение, удаление, считывание абонентских данных;

блокировка или разблокировка абонентов;

просмотр, изменение и вывод данных учета стоимости;

4) управление маршрутизацией;

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

защита доступа к ЦУ и ТО посредством паролей;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования к параметрам, обеспечивающим пользователям стандартов LTE/LTE-ADVANCED оказание услуг передачи данных и телефонного соединения через оборудование коммутации IMS

1. Для подключения к оборудованию IMS UE должно инициировать:

процедуру подключения UE к сети радиодоступа (далее - EPS);

процедуру активации канала передачи данных в EPS;

выделение IP-адреса P-CSCF;

процедуру регистрации в IMS.

2. При оказании услуг передачи данных и телефонного соединения через оборудование коммутации IMS временно (на время взаимодействия UE с оборудованием коммутации IMS) в рамках процедур подключения UE к EPS и соединения с сетью передачи данных EPS должно обеспечиваться назначение UE IP-адреса в формате, определенном протоколами IP четвертой или шестой версий (далее - IPv4, IPv6), принадлежащем одной из сетей IMS, взаимодействующей с P-GW:

IP-адреса сети IMS домашнего оператора;

IP-адреса сети IMS визитного оператора;

IP-адреса сети взаимодействующей с IMS домашнего оператора.

Выделение UE IP-адреса P-CSCF должно осуществляться одним из следующих способов:

с помощью протокола динамической конфигурации (далее - DHCP) и сервера имен доменов (далее - DNS);

с помощью процедуры активации канала передачи данных в EPS;

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 или при окончании времени регистрации.

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

Требования к параметрам протокола MIPv4

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

1.1. Дополнительные сообщения, поддерживающие управление мобильностью пользователя и отправляемые с порта UDP/TCP 434:

"Запрос регистрации" (Registration Request);

"Результат регистрации" (Registration Reply).

1.1.1. Требования к формату сообщения "Запрос регистрации" приведены на рисунке 1.

Тип	S	B	D	M	G	r	T	X	Длительность регистрации
Домашний адрес
Адрес домашнего агента
СoA
Идентификация
Расширения

Рисунок 1

Поле "Тип" (1 байт) должно устанавливаться в "1".

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

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

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

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

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

Поля "r" и "Х" (по 1 биту) должны устанавливаться в "0" и должны игнорироваться при приеме.

Поле "T" (1 бит ) должно указывать на запрос обратного туннелирования.

Поле "Длительность регистрации" (2 байта) должно указывать длительность регистрации в секундах. Значение "0" должно указыват на запрос отмены регистрации. Значение "0xffff" должно указывать бесконечность.

Поле "Домашний адрес" (4 байта) должно указывать IP адрес мобильного узла в домашней сети.

Поле "Адрес домашнего агента" (4 байта) должно указывать IP адрес домашнего агента.

Поле "СoA" (4 байта) должно указывать временный IP адрес мобильного узла в визитной сети.

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

1.1.2. Требования к формату сообщения "Результат регистрации" приведены на рисунке 2.

Тип	Код	Длительность регистрации
Домашний адрес
Адрес домашнего агента
Идентификатор
Расширения

Рисунок 2

Поле "Тип" (1 байт) должно устанавливаться в 3.

Поле "Код" (1 байт) должно указывать результат регистрации.

Поле "Длительность регистрации" (2 байта) должно указывать длительность регистрации в секундах. Значение "0" должно указывать на отмену регистрации. Значение "0xffff" должно указывать бесконечность.

Поле "Домашний адрес" (4 байта) должно указывать IP адрес мобильного узла в домашней сети.

Поле "Адрес домашнего агента" (4 байта) должно указывать IP адрес домашнего агента.

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

1.1.3. Требования к расширениям для сообщений "Запрос регистрации", "Результат регистрации".

В сообщениях регистрации должно присутствовать одно из следующих расширений: "Аутентификация в домашней сети (Mobile-Home Authentication), тип расширения - 32", "Аутентификация в визитной сети (Mobile-Foreign Authentication), тип расширения - 33", "Аутентификация между домашней и визитной сетями (Foreign-Home Authentication), тип расширения - 34".

Требования к формату расширений приведены на рисунке 3.

Тип расширения	Длина	SPI
SPI		Аутентификатор

Рисунок 3.

Поле "Длина" должно указывать длину аутентификатора плюс 4 байта.

Поле "SPI" (Security Parameter Index) должно указывать идентификатор параметров защиты, используемый для вычисления аутентификатора. Алгоритм аутентификации, используемый по умолчанию, должен быть HMAC-MD5.

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

сообщения регистрации, поступившие с порта 434 UDP;

все присутствующие в этих сообщениях расширения;

поля "Тип", "Длина" и "SPI" расширения.

1.2. Сообщения протокола ICMPv4, поддерживающие управление мобильностью пользователя:

"Объявление маршрутизатора" (Router Advertisement),

"Запрос доступности маршрутизатора" (Router Solicitation).

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

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

"16" ? "Объявление мобильного агента" (Mobility Agent Advertisement);

"19" ? длина префикса.

1.3. Требования к форматам расширений для сообщения "Объявление маршрутизатора".

1.3.1. Требования к формату расширения "Объявление мобильного агента" приведены на рисунке 4.

Тип расширения	Длина	Порядковый номер
Длительность регистрации	R	B	H	F	M	G	r	T	Резерв
Адрес (а) CoA

Рисунок 4.

Полю "Тип расширения" (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. Количество адресов, присутствующих в поле, должно определяться указателем длины.

1.3.2. Требования к формату расширения "Длина префикса" (19) приведены на рисунке 5.

Расширение "Длина префикса" может следовать за расширением "Объявление мобильного агента" и должно указывать количество бит префикса сети, применяемого к каждому адресу маршрутизатора, указанному в сообщении ICMP Router Advertisement.

Тип расширения	Длина	Длина префикса

Рисунок 5.

Полю "Тип расширения" (1 байт) должно присваиваться значение "19".

Поле "Длина префикса" (8 бит) должно определять число начальных битов, определяющих номер сети в адресе маршрутизатора, указанного в сообщении ICMP Router Advertisement. Для каждого адреса должна указываться своя длина префикса.

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

Требования к параметрам протоколов MIPv6, DSMIPv6

1. Требования к дополнительному заголовку мобильности протокола IPv6, обеспечивающему мобильность пользователя ? Mobility Header (MH).

1.1. Заголовок "Mobility Header" должен обозначаться в поле "Next Header" (Следующий заголовок) значением "135" и включать поля, приведенные в таблице N 1.

Таблица N 1.

Поля заголовка
N поля	Название	Длина поля (бит)
1	Payload Proto	8
2	Header Len	8
3	MH Type	8
4	Резерв	8
5	Checksum	16
6	Message Data	0-n

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

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

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

Поле "Резерв" должно устанавливаться равным "0".

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

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

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

1.2. При использовании заголовка "Mobility Header" должны передаваться следующие сообщения:

1.2.1. "Запрос обновления привязки UE" (Binding Refresh Request (BRR)). Полю "MH Type" для сообщения BRR должно присваиваться значение равное "0".

Cообщение BRR включает следующие поля:

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

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

1.2.2. "Инициирование проверки домашнего адреса" (Home Test Init (HoTI)). Полю "MH Type" для сообщения HoTI должно присваиваться значение равное "1".

Сообщение HoTI должно включать следующие поля:

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

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

Мобильный узел должен использовать сообщение "Home Test Init" для инициализации процедуры обратной маршрутизации и запроса маркера "Home keygen token" от узла-корреспондента, туннелируемое через домашнего агента, когда мобильный узел находится в визитной сети.

1.2.3. "Инициирование проверки временного адреса" (Care-of Test Init). Полю "MH Type" для сообщения "Care-of Test Init" должно присваивается значение равное "2".

Сообщение "Care-of Test Init" должно включать следующие поля:

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

Мобильный узел должен использовать сообщение "Care-of Test Init" (CoTI) для инициализации процедуры обратной маршрутизации и запроса маркера "Care-of Keygen Token" от узла-корреспондента.

1.2.4. "Проверка домашнего адреса" (Home Test), используемое для осуществления возврата UE идентифицирующей цепочки, посылаемой узлу-корреспонденту в сообщении "Home Test Init". Полю "MH Type" для сообщения "Home Test" должно присваиваться значение равное "3".

Сообщение "Home Test" должно включать следующие поля:

"Одноразовый индекс домашнего номера" (Home Nonce Index) (должно быть 16-битовым полем и должно возвращаться узлу-корреспонденту мобильным узлом в сообщении "Binding Update").

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

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

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

Сообщение "Care-of Test" должно включать следующие поля:

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

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

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

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

Сообщение "Binding Update" должно включать следующие поля:

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

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

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

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

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

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

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

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

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

опция "Индексы одноразовых номеров" (Nonce Indices);

опция "Альтернативный (запасной) временный адрес" (Alternate Care-of Address).

Поле заголовка "Mobility Header Header Len" должно быть установлено в "1" при отсутствии опций в сообщении, а так же следует использовать 4 октета заполнителя.

1.2.7. "Подтверждение приема сообщения об обновлении привязки" (Binding Acknowledgement (BA)). "MH Type" для сообщения BA присваивается значение равное "6".

1.2.8. "Сообщение об ошибке, связанной с мобильностью" (Binding Error (BE)). "MH Type" для сообщения BE присваивается значение равное "7".

1.3. Требования к дополнительному заголовку протокола IPv6, обеспечивающему дополнительные данные для маршрутизации "Type 2 Routing Header".

1.3.1. Заголовок "Type 2 Routing Header" должен включать поля, приведенные в таблице N 2.

Таблица N 2.

Поля заголовка
N поля	Название	Длина поля (бит)
1	Next Header	8
2	Hdr Ext Len	8
3	Routing Type	8
4	Segments Left	8
5	Резерв	32
6	Home Address	16

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

Поле "Hdr Ext Len" должно указывать длину заголовка (за исключением первых 8 октетов) в единицах, равных 8 октетам. Значение "Hdr Ext Len" должно устанавливаться равным "2".

Поле "Routing Type" должно указывать тип маршрутизации и устанавливаться равным "2".

Поле "Segments Left" должно устанавливаться равным "1".

Поле "Резерв" должно устанавливаться равным "0".

Поле "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).

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

Тип	Код	Контрольная сумма
Идентификатор		Резерв

Рисунок 1

Поле "Тип" (1 байт) должно устанавливаться в "144".

Поле "Код" (1 байт) должно устанавливаться в "0".

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

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

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

Тип	Код	Контрольная сумма
Идентификатор		Резерв
Адрес домашнего агента

Рисунок 2

Поле "Тип" (1 байт) должно устанавливаться в "145".

Поле "Код" (1 байт) должно устанавливаться в "0".

В поле "Идентификатор" (2 байта) должно помещаться число из сообщения "Home Agent Address Discovery Request".

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

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

Тип	Код	Контрольная сумма
Идентификатор		Резерв

Рисунок 3

Поле "Тип" (1 байт) должно устанавливаться в "146".

Поле "Код" (1 байт) должно устанавливаться в "0".

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

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

Тип	Код	Контрольная сумма
Идентификатор	М	О	Резерв
Опции

Рисунок 4

Поле "Тип" (1 байт) должно устанавливаться в "147".

Поле "Код" (1 байт) должно устанавливаться в "0".

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

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

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

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

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

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

Тип	Код
Текущий предел шагов	М	О	H	Резерв	Время жизни маршрутизатора
Время достижимости
Время повторной передачи
Опции

Рисунок 5

Поле "Тип" (1 байт) должно устанавливаться в "134".

Поле "Код" (1 байт) должно устанавливаться в "0".

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

Поле "H" (1 бит) (флаг домашнего агента) должно указывать на функционирование маршрутизатора в качестве домашнего агента при значеннии поля "Н" равном "1".

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

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

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

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

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

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

3.2.1. Для сообщения "Binding Update", передаваемого от UE к домашнему агенту или точке привязки мобильности (Mobility Anchor Point (далее ? MAP)), должны использоваться следующие расширения:

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

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

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

3.2.2. Для сообщения "Binding Acknowledgement", передаваемого от домашнего агента или MAP к UE, должны использоваться следующие расширения:

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

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

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

Требования к параметрам протокола IKEv2

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

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

2.1. Требования к формату заголовка IKEv2 приведены на рисунке 1.

Initiator′s SPI
Responder′s SPI
Next Payload	MjVer	MnVer	ExchType	Flags	Message ID
Length

Рисунок 1.

Поле "Initiator′s SPI" (8 октетов) должно содержать значение, выбранное инициатором для уникальной идентификации параметров безопасности (Security Parameter Index, далее -SPI) IKEv2. Нулевое значение поля "Initiator′s SPI" недопустимо.

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

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

Требования к формату и значениям типа элемента данных:

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

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

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

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

Таблица N 1.

Тип обмена	Значение
IKE_SA_INIT	34
IKE_AUTH	35
CREATE_CHILD_SA	36
INFORMATIONAL	37
Резерв IANA	38 - 239
Резерв для частного использования	240 - 255

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

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

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

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

Идентификатор следующего элемента	С	Резерв	Размер текущего элемента
Элементы данных

Рисунок 2

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

Таблица N 2.

Идентификатор следующего элемента	Обозначения	Значение
Отсутствует следующий элемент		0
Резерв		1 - 32
Контекст безопасности	SA	33
Обмен ключами	KE	34
Идентификатор инициатора	IDi	35
Идентификатор отвечающего	IDr	36
Сертификат	CERT	37
Запрос сертификата	CERTREQ	38
Идентификация	AUTH	39
Случайное число	Ni, Nr	40
Уведомление	N	41
Удаление	D	42
Идентификатор реализации	V	43
Селектор трафика - Инициатор	TSi	44
Селектор трафика - Ответчик	TSr	45
Кодирование	E	46
Конфигурация	CP	47
Расширяемая идентификация	EAP	48
Резерв IANA		49-127
Для частного применения		128-255

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

Поле "Резерв" (7 битов) должно иметь значение "0" при передаче и игнорироваться на приеме.

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

2.3. Требования к элементам данных SA ("Предложения").

Данные контекста безопасности (Security Association Payload, далее ? SA) должны использоваться для согласования атрибутов защищенной связи. Элемент SA может включать несколько предложений, упорядоченых в порядке снижения приоритета. Каждое предложение может включать несколько протоколов IPsec (IKEv2, ESP, AH), каждый протокол может включать множество преобразований, а каждое преобразование может включать несколько атрибутов.

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

0 или 2	Резерв	Длина предложения
Номер предложения	Идентификатор протокола	Значение SPI	Число преобразований
SPI передающей стороны
Структура преобразования

Рисунок 3

Первый октет должен показывать является ли предложение последним в субструктуре предложений элемента SA. Предложение должно быть последним при значении первого октета равном "0" и не должно являться последним при значении равном "2".

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

Поле "Номер предложения" (1 октет) должно указывать номер предложения. Первое предложение в элементе SA должно иметь номер "1", а номера последующих предложений должны совпадать с номером предшественника (И ? пересечение двух предложений) или быть на 1 больше (ИЛИ ? объединение двух предложений). Все номера предложений в элементе SA должны совпадать при приеме и соответствовать номеру переданного предложения, которое было принято.

Поле "Идентификатор протокола" (1 октет) должно задавать идентификатор протокола IPsec для текущего согласования.

Поле "Значение SPI" (1 октет) должно использоваться для начального согласования IKE_SA и должно иметь значение равное "0". Значение SPI следует получать из внешнего заголовка и при последующих согласованиях поле "Значение SPI"должно показывать размер SPI (в октетах) для соответствующего протокола (8 для IKEv2, 4 для ESP и AH).

Поле "Число преобразований" (1 октет) должно показывать число преобразований в предложении.

Поле "SPI передающей стороны" должно иметь переменный размер.

Поле "Структура преобразования" должно иметь переменный размер.

2.3.1. Требования к формату поля "Структура преобразования" приведены на рисунке 4.

0 или 3	Резерв	Длина преобразования
Тип преобразования	Резерв	Идентификатор преобразования
Атрибуты преобразования

Рисунок 4

Первый октет должен показывать является ли преобразование последним в предложении. Преобразование должно быть последним при значении первого октета равном "0" и не должно являться последним при значении равном "3".

Поле "Резерв" (1 октет) должно устанавливаться в "0" при передаче и игнорироваться на приеме.

Поле "Длина преобразования" (2 октета) должно указывать размер "Структуры преобразования" (в октетах) с учетом заголовка и атрибутов.

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

Таблица N 3.

Название преобразования	Тип преобразования	Используемый протокол
Резерв	0
Encryption Algorithm (ENCR) ? алгоритм шифрования	1	IKE и ESP
Pseudo-random Function (PRF) ? псевдослучайная функция	2	IKE
Integrity Algorithm (INTEG) ? алгоритм защиты целостности	3	IKE, AH, опционально в ESP
Diffie-Hellman Group (D-H) ? группа Diffie-Hellman	4	IKE, опционально в AH и ESP
Extended Sequence Numbers (ESN) ? расширенные порядковые номера	5	AH и ESP
Резерв IANA	6-240
Частное применение	241-255

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

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

Таблица N 4.

Протокол	Обязательные типы	Опциональные типы
IKE	ENCR, PRF, INTEG, D-H
ESP	ENCR, ESN	INTEG, D-H
AH	INTEG, ESN	D-H

Поле "Атрибуты преобразования" должно содержать атрибуты, представляющие собой пары "тип-значение" для каждого преобразования элемента данных SA, приведенные в таблице N 5.

Таблица N 5.

Тип атрибута	Значение атрибута	Формат атрибута
Резерв	0 - 13
Размер ключа шифрования переменного размера (Key Length) (в битах)	14	тип/значение
Резерв	15 - 17
Резерв IANA	18 - 16383
Для частного применения	16384 - 32767

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

Тип атрибута	Длина атрибута (значение)
Значение атрибута

Рисунок.5

Поле "Тип атрибута" (2 октета) должно содержать идентификатор атрибута. Для атрибута должен использоваться полный формат атрибута (тип/размер/значение) при установлении старшего бита поля "Тип атрибута" -флага формата атрибута (AF), равного "0" или сокращенный формат атрибута (тип/значение) при AF равном "1".

Поле "Длина атрибута (значение)" (2 октета) должно указывать размер атрибута, содержащийся в поле "Значение атрибута" (переменная длина), при AF равном "0" или содержать значение атрибута при AF равном "1".

2.4. Требования к элементу данных Обмен ключами (Key Exchange, далее ? KE).

Элемент данных KE должен использоваться для обмена открытыми номерами протокола Димффи-Хемллмана (Diffie-Hellman, далее ? DH) при обмене ключами DH.

Элемент данных KE должен создаваться путем копирования открытого значения DH в поле "Данные обмена ключами". Размер открытого значения DH должен быть равен размеру первичного модуля, для которого выполняется возведение в степень, дополненного при необходимости нулями в начале.

Поле "Номер группы DH" (2 байта) должен идентифицировать группу DH, в которой было рассчитано значение поля "Данные обмена ключами". Сообщение должно быть отвергнуто с возвратом элемента "Уведомление типа INVALID_KE_PAYLOAD" при выборе предложения, использующего другую группу DH.

Требования к формату элемента данных Обмен ключами приведены на рисунке 6.

Номер группы DH	Резерв
Данные обмена ключами

Рисунок 6

2.5. Требования к элементам данных Идентификатор инициатора (IDi) и Идентификатор отвечающего (IDr).

Требования к формату элементов данных IDi и IDr приведены на рисунке 7.

Тип идентификации	Резерв
Данные идентификатора

Рисунок 7

Поле "Тип идентификации" (1 байт) должен задавать тип используемых идентификаторов.

Поле "Данные идентификатора" (переменной длины) должно содержать идентификатор, тип которого указан в предыдущем поле.

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

Тип сертификата	Данные сертификата

Рисунок 8

Элемент данных Сертификат должен иметь следующие поля.

Поле "Тип сертификата" (1 октет) должно указывать способ кодирования сертификата.

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

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

Таблица N 6.

Способ кодирования сертификата	Значение Формат атрибута
Резерв	0
Сертификат X.509 с PKCS (Public Key CryptographyStandard ? криптографический стандарт открытого ключа)) N7	1
Сертификат PGP (Pretty Good Privacy)	2
Подписанный ключ DNS (Domain Name System)	3
Сертификат X.509? подпись	4
Маркер Kerberos	6
Список отозванных сертификатов CRL (Certificate Revocation List)	7
ARL	8
Сертификат простой инфраструктуры открытых ключей SPKI (Simple Public Key Infrastructure)I	9
Сертификат X.509 ? атрибут	10
Неразобранный ключ криптографического алгоритма с открытым ключом RSA	11
Хеш и URL сертификата X.509	12
Хеш и URL связки (bundle) X.509	13
Резерв IANA	14-200
Для частного применения	201-255

2.7. Требования к элементу данных Запрос сертификата.

Требования к Формату элемента данных Запрос сертификата приведены на рисунке 9.

Тип сертификата	Удостоверяющий центр

Рисунок 9

Элемент данных Запрос сертификата должен иметь следующие поля.

Поле "Тип сертификата" (1 октет) должно указывать способ кодирования сертификата.

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

2.8. Требования к элементу данных Идентификация.

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

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

Метод идентификации	Резерв
Идентификационные данные

Рисунок 10

Элемент данных Идентификация должен иметь следующие поля.

Поле "Метод идентификации" (1 октет) должен указывать используемый метод идентификации и принимать значения:

RSA цифровая подпись (1) (должно рассчитываться с использованием приватного ключа RSA и хэш-значения PKCSN1 с заполнением);

Shared Key Message Integrity Code (2) (должно рассчитываться с использованием разделяемого ключа, связанного с объектом из элемента Тип идентификации и согласованной функции prf);

DSS (Digital Signature Standard) цифровая подпись (3) (должно рассчитываться с использованием закрытого ключа DSS и хэш-значения алгоритма криптографического хеширования SHA-1 (Secure Hash Algorithm).

Значение 0 и 4 - 200 должны быть зарезервированы IANA, 201-255 должны быть выделены для частных приложений.

Поле "Идентификационные данные" должно иметь переменный размер.

2.9. Требования к элементу данных Случайное число.

Элемент данных Случайное число должен иметь одно поле переменного размера, содержащее созданное передающей стороной случайное значение.

Размер элемента должен находиться в диапазоне (16 - 256) октетов включительно. Повторное использование значения Случайного числа не допускается.

2.10. Требования элементу данных Уведомление.

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

Идентификатор протокола	Размер SPI	Тип уведомления
SPI
Данные уведомления

Рисунок 11

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

Поле "Размер SPI" (Security Parameter Index) (1 октет) должно указывать размер SPI в октетах.

Поле "Тип уведомления" (2 октета) должен задавать тип уведомления.

Поле "SPI" должно иметь переменный размер и содержать идентификатор параметров защиты.

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

2.11. Требования к элементу данных Удаление.

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

Идентификатор протокола	Размер SPI	Количество SPI
Индекс параметров безопасности (SPI)

Рисунок 12

Поле "Идентификатор протокола" (1 октет) должно иметь значение равное "1" для IKE_SA, з "2" - для AH, "3" - для ESP.

Поле "Размер SPI" (1 октет) должно содержать размер SPI указанного протокола (в октетах).

Поле "Количество SPI" (2 октета) должно содержать количество SPI в элементе данных Удаление.

Поле "Индекс параметров безопасности" (SPI) должно иметь переменный размер) и идентифицировать удаляемое защищенное соединение.

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

2.13. Элементы данных Селектор трафика - Инициатор, Селектор трафика - Ответчик.

Требования к формату элемента Селектор трафика приведены на рисунке 13.

Количество селекторов трафика	Резерв
Селектор(ы) трафика

Рисунок 13

Поле "Количество селекторов трафика" должно иметь размер равный 1 октет.

Поле "Резерв" (3 октета) должно иметь значение равное "0" при передаче и игнорироваться на приеме.

Поле "Селектор трафика" должно иметь переменный размер и содержать один или множество индивидуальных селекторов трафика.

2.14. Требования к элементу данных Кодирование (Encrypted).

Элемент данных Кодирование (Encrypted - далее E), должен содержать другие элементы в зашифрованном виде. При наличии в сообщении элемента Кодирование он должен быть последним в сообщении. Требования к формату элемента данных Кодирование приведены на рисунке 14.

Initialization Vector
Данные IKE
Padding (0 - 255) октетов	Pad Length
Integrity Checksum Data

Рисунок 14

Элемент Кодирование должен включать базовый заголовок IKE (см. рисунок 2) и следующие поля.

Поле "Initialization Vecto" должно содержать случайное значение, совпадающее с размером блока используемого алгоритма шифрования. Получатели должны воспринимать любые значения этого поля, а отправителям следует генерировать псевдослучайное значение независимо для каждого сообщения или использовать для выбора значений шифрованный блок предыдущего сообщения.

Поле "Данные IKE" должно быть переменной длины, содержать шифрованные элементы IKE и шифроваться с использованием согласованного алгоритма.

Поле "Padding" может содержать любое значение, выбранное отправителем, должно иметь размер, который делает суммарный размер шифрованных элементов, поля "Padding" и поля "Pad Length" кратным размеру блока шифрования "Initialization Vecto" и шифроваться с использованием согласованного алгоритма.

Поле "Pad Length" (1 октет) должно указывать размер поля Padding и шифроваться с использованием согласованного алгоритма. Отправителю следует устанавливать в поле "Pad Length" минимальное значение, которое делает размер полей шифрованных элементов "Padding" и "Pad Length" кратными размеру блока шифрования. Получатель должен принимать любые значения, обеспечивающие требуемое выравнивание. Это поле шифруется с использованием согласованного алгоритма.

Поле "Integrity Checksum Data" должно содержать криптографическую контрольную сумму всего сообщения, начиная с фиксированного заголовка IKE и заканчивая полем "Pad Length". Контрольная сумма должна рассчитываться для зашифрованного сообщения. Размер поля должен определяться согласованным алгоритмом защиты целостности.

2.15. Требования к элемент данных Конфигурация (CP).

Элемент данных Конфигурация (CP) должен использоваться для обмена конфигурационными параметрами между партнерами IKE. Требования к формату элемента данных Конфигурация приведены на рисунке 15.

Тип обмена	Резерв
Атрибуты конфигурации

Рисунок 15

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

Поле "Тип обмена" (1 октет) должно указывать тип обмена данными Конфигурации (REQUEST-1, REPLY-2, SET-3, ACK-4).

Поле "Резерв" (3 октета) должно устанавливаться в "0" при передаче и игнорироваться на приеме.

Поле "Атрибуты конфигурации" должно иметь переменный размер и содержать атрибуты конфигурации в формате "тип-размер-значение". Элемент данных Конфигурация может содержать несколько атрибутов или не содержит атрибуты.

2.16. Требования к элементу данных Расширяемая идентификация (EAP).

Элемент данных Расширяемая идентификация (EAP) должен позволять выполнять идентификацию IKE_SA с использованием протокола EAP. Требования к формату элемента данных EAP приведены на рисунке 16.

Код	Идентификатор	Длина
Тип	Данные

Рисунок 16

Поле "Код" (1 октет) должно показывать тип сообщение и содержит значение равное "1" при запросе (Request), "2" при отклике (Response), "3" при успешном завершением (Success) или "4" при отказе (Failure).

Поле "Идентификатор" (1 октет) должно использоваться в протоколе PPP, чтобы отличить повторное использование сообщений от повторной передачи. В откликах поле "Идентификатор" должно устанавливаться равным значению идентификатора в соответствующем запросе,а в остальных сообщениях может принимать любое значение.

Поле "Длина" (2 октета) должно показывать размер сообщения EAP и должно иметь значение в 4 раза меньше значения поля "Размер текущего элемента (Payload Lenqth) базового заголовка" (см. рисунок 2).

Поле "Тип" (1 октет) должно присутствовать только в сообщениях с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должен составлять четыре октета, а поля "Тип" и "Данные" должны отсутствовать. В запросах (1) поле "Тип" должно указывать запрашиваемые данные, а в откликах (2) поле "Тип" должно быть пустым или соответствовать типу запрошенных данных. Значения поля "Тип":

1 ? тождественность;

2 ? уведомление;

3 ? только отклики;

4?MD5 - вызов;

5 ? однократный пароль;

6 ? маркерная карта базового типа.

Поле "Данные" должно быть переменной размер и должно зависеть от типа запроса и связанного с ним отклика.

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

Требования к параметрам протокола IPSec

1. Требования к идентификационному заголовку AH.

1.1. Идентификационный заголовок протокола IPSec (AH) должен использоваться для обеспечения целостности дейтаграмм IP и идентификации источника данных без организации специальных соединений и защиты против повторного использования пакетов. AH может использоваться в комбинации с ESP или путем вложения. Услуги по защите могут обеспечиваться между парой взаимодействующих элементов сети IP.

1.2. Требования к формату заголовка идентификации AH приведены на рисунке 1.

Следующий заголовок	Длина заголовка	Резерв
Идентификатор параметров защиты (SPI)
Порядковый номер
Аутентификационные данные (Значение контрольной суммы (ICV)) (перемен.)

Рисунок 1

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

Поле "Длина заголовка" (1 октет) должно указывать размер заголовка AH в 32-битовых словах (4-байтовых блоках) минус 2.

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

Поле "Идентификатор параметров защиты" (SPI) должен быть произвольным 32-битовым значением, используемым получателем для идентификации SA, с которой связан входящий пакет. Для индивидуальных SA значение SPI может идентифицировать SA или использоваться в комбинации с типом протокола IPsec (в данном случае AH). Поле SPI должно быть обязательным и механизм отображения входящего трафика на индивидуальные SA должен поддерживаться всеми реализациями AH.

Поле "Порядковый номер" (4 октета) должно содержать значение счетчика пакетов, увеличиваемое на "1" для каждого переданного пакета (счетчик пакетов для SA). Это поле должно быть обязательным и присутствовать даже в случае, когда получатель не пользуется услугами по предотвращению повторного использования пакетов для конкретной SA. Отправитель должен передавать указанное поле, но получатель не обязан принимать его во внимание. Счетчики на стороне отправителя и получателя должны инициализироваться при значении поля "Порядковый номер" равном "0" при создании SA (первый пакет, переданный с использованием данной SA, будет иметь порядковый номер ? "1"). Если предотвращение повторного использования пакетов включено (используется по умолчанию), передаваемые порядковые номера никогда не должны повторяться. Расширенный порядковый номер должен позволять использовать для SA 64-битовые порядковые номера. В заголовке AH каждого пакета должны передаваться только младшие 32 бита расширенного порядкового номера, а старшие 32 бита должны учитываться как часть порядкового номера отправителем и получателем и включаться в расчет ICV, но не должны передаваться.

Поле "Аутентификационные данные" должно содержать значение контрольной суммы ICV для данного пакета. Размер поля должен быть кратным 32 битам как для IPv4, так и для IPv6. Указанное поле может включать заполнение для обеспечения кратности размера заголовка AH в целом 32 (IPv4) или 64 (IPv6) битам. Заполнение должны поддерживать все реализации и размер заполнения должен быть минимально достаточным для выравнивания заголовков в соответствии с требованиями IPv4/IPv6.

1.3. Требования к местонахождению заголовка AH.

AH должно обеспечивать работу в двух режимах: транспортном и туннельном.

1.3.1. В транспортном режиме AH должен помещаться между заголовком протокола IP и заголовком протокола транспортного уровня или перед другими заголовками IPsec при наличии. Требования к местонахождению заголовка AH в транспортном режиме приведены на рисунке 2.

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

Заголовок исходного IP пакета	Заголовок AH	Заголовок TCP (UDP)	Данные

Рисунок 2

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

Заголовок внешнего IP пакета	Заголовок AH	Заголовок исходного IP пакета	Заголовок TCP (UDP)	Данные

Рисунок 3

2. Требования к протоколу ESP.

2.1. Протокол ESP (IP Encapsulating Security Payload) должен использоваться для обеспечения целостности и конфиденциальности данных путем их шифрования. В зависимости от пользовательских требований к безопасности этот механизм следует применять для шифрования пакетов транспортного уровня (например, TCP, UDP, ICMP, IGMP) или дейтаграмм IP полностью. В протоколе ESP должно быть обеспечено одновременное или раздельное использование функций аутентификации и криптографической защиты вместе.

2.2. Требования к заголовку ESP.

Должна обеспечиваться возможность содержания ESP в любом месте между заголовком IP и конечным протоколом транспортного уровня. Для протокола ESP должен использоваться идентификатор IANA 50. Заголовок, расположенный непосредственно перед заголовком ESP, должен всегда содержать значение равное "50" в поле "Следующий заголовок" для IPv6 или "Протокол" для IPv4. ESP должен состоять из нешифрованного заголовка, за которым должны следовать зашифрованные данные. Шифруемые данные должны включать в себя защищенные поля заголовка ESP и защищаемые пользовательские данные: дейтаграмму IP или пакет протокола вышележащего уровня. Требования к формату заголовка ESP приведены на рисунке 4.

Идентификатор параметров защиты (SPI)
Порядковый номер
Данные (перемен.)
Данные (перемен.)		Заполнитель
Заполнитель	Длина заполнителя	Следующий заголовок
Аутентификационные данные (перемен.)

Рисунок 4

2.3. Требования к местонахождению заголовка ESP.

Должна обеспепечиваться возможность работы ESP в транспортном и туннельном режимах.

2.3.1. В транспортном режиме зашифрованные данные должны транспортироваться между хостами, заголовок исходного IP-пакета должен оставаться внешним, а Заголовок ESP должен помещаться в передаваемый пакет между заголовками протоколов третьего и четвертого уровней.

Шифрованию должны подвергаться только данные исходного IP-пакета и заключительная часть ESP заголовка. В этом режиме ESP не должен шифровать заголовок IP-пакета, поля "SPI" и "Порядковый номер".

2.3.2. Функции туннельного режима должны реализовываться в шлюзах безопасности.

В туннельном режиме в качестве внешнего заголовка должен создаваться новый заголовок IP, ESP заголовок должен помещаться перед заголовком исходного IP-пакета, а весь исходный IP-пакет и заключительная часть заголовка ESP должны шифроваться. Заголовок внешнего IP-пакета протоколом ESP не должен защищаться.

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

Требования к параметрам протокола Diameter на интерфейсах S6b, SWx, SWm, STa, SWd, SWa

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

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от P-GW к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к P-GW
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от P-GW к 3GPP AAA серверу
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к P-GW
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от P-GW к 3GPP AAA серверу или от 3GPP AAA сервера к P-GW
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к P-GW или от P-GW к 3GPP AAA серверу
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера к P-GW
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от P-GW к 3GPP AAA серверу
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к P-GW
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от P-GW к 3GPP AAA серверу/прокси

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

Сообщение	Код сообщения	Направление передачи
Аутентификация при мультимедийной сессии. Запрос. (Multimedia-Authentication-Request (MAR))	303, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера к HSS
Аутентификация при мультимедийной сессии. Ответ (Multimedia-Authentication-Answer (MAA))	303, бит R в поле команды "Флаг" очищен	от HSS к 3GPP AAA серверу
Обновление профилей. Запрос.( Push-Profile-Request (PPR))	305, бит R в поле команды "Флаг" установлен в "1"	от HSS к 3GPP AAA серверу
Обновление профилей. Ответ.( Push-Profile-Answer (PPA))	305, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к HSS
Регистрация сервера сервера. Запрос.(Server-Assignment-Request (SAR))	301, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера к HSS
Регистрация сервера. Ответ. (Server-Assignment-Answer (SAA))	301, бит R в поле команды "Флаг" очищен	от HSS к 3GPP AAA серверу
Окончание регистрации. Запрос. (Registration-Termination-Request (RTR)_	304, бит R в поле команды "Флаг" установлен в "1"	от HSS к 3GPP AAA серверу или от 3GPP AAA сервера к HSS
Окончание регистрации. Ответ (Registration-Termination-Answer (RTA))	304, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к HSS или от HSS к 3GPP AAA серверу

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

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от ePDG к 3GPP AAA серверу/прокси
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к ePDG
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от ePDG к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к ePDG
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от ePDG к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к ePDG
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к ePDG
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от ePDG к 3GPP AAA серверу/прокси
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к ePDG
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от ePDG к 3GPP AAA серверу/прокси

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

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к TWAN
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к TWAN
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от TWAN к 3GPP AAA серверу/прокси
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к TWAN
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к TWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от TWAN к 3GPP AAA серверу/прокси
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от TWAN к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к TWAN

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

Сообщение	Код сообщения	Направление передачи
Diameter-EAP-Request (DER)	268, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу
Diameter-EAP-Answer (DEA)	268, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера к UTWAN
Аварийное прекращение сессии. Запрос (Abort-Session-Request (ASR))	274, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к UTWAN
Аварийное прекращение сессии. Ответ (Abort-Session-Answer (ASA))	274, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси
Окончание сессии. Запрос (Session-Termination-Request (STR))	275, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу/прокси
Окончание сессии. Ответ (Session-Termination-Answer (STA))	275, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Запрос (Re-Auth-Request (RAR))	258, бит R в поле команды "Флаг" установлен в "1"	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси
Информация о сессии. Запрос (AA-Request (AAR))	265, бит R в поле команды "Флаг" установлен в "1"	от UTWAN к 3GPP AAA серверу/прокси
Информация о сессии. Ответ (AA-Answer (AAA))	265, бит R в поле команды "Флаг" очищен	от 3GPP AAA сервера/прокси к UTWAN
Обновление данных авторизации. Ответ (Re-Auth-Answer (RAA))	258, бит R в поле команды "Флаг" очищен	от UTWAN к 3GPP AAA серверу/прокси

На интерфейсе SWd должны транслироваться сообщения протокола Diameter с интерфейсов S6b, SWm, STa, приведенные в таблицах NN 1, 3, 4 соответственно.

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

Требования к данным, хранящимся в HSS, MME, S-GW, P-GW, ePDG, 3GPP AAA сервере, 3GPP AAA прокси сервере, необходимым при реализации non-3GPP доступа

Таблица.

Параметр	HSS	MME	S-GW	P-GW	ePDG	3GPP AAA сервер	Тип пар.
Международный идентификатор MS (IMSI)	О	У	У	У	У		П
Международный номер MS в сети ISDN (MSISDN)	У	У	У	У	У	У	П
Параметры для аутентификации в сети UMTS (RAND, XRES, CK, IK, AUTN)	О					О	В
Параметры для аутентификации в сети LTE (RAND, XRES, KASME, AUTN)	О					О	В
Режим доступа к сети (Network Access Mode)	У					У	В
Подробное описание трейса 2 (Trace Reference 2)	У			У		У	П
Уровень глубины трейса (Trace depth)	У			У		У	П
Список сетевых элементов, в которых проводится сбор трейсов (List of NE types to trace)	У					У	П
Параметры, указываемые в трейсах (Triggering events)	У			У		У	П
Перечень интерфейсов сетевых элементов для которых формируются трейсы (List of interfaces to trace)	У			У		У	П
IP адреса для которых формируются трейсы (IP address of Trace Collection Entity)	У			У		У	П
Профили имен точек доступа (APN-Configuration-Profile)	О			У	У	У	В
Указанная в подписке общая максимальная скорость передачи для точки доступа (Subscribed APN-AMBR)	О			У	У	У	П
Используемая максимальная скорость передачи для точки доступа (Used APN-AMBR)				У			В
Адрес сети передачи данных (PDN Address)	У		У	У	У	У	П/В
Разрешенный адрес визитной сети радиотелефонной связи (VPLMN Address Allowed)	О	У			У	У	П
Идентификатор PDN GW (PDN GW identity)	О	У			У	У	П
Используемая точка доступа (APN in Use)				У	У		В
Идентификатор EPS (EPS Bearer ID)				У	У		В
Качество обслуживания EPS (EPS Bearer QoS)				У	У		В
Характеристики учета стоимости соединения EPS PDN (EPS PDN Connection Charging Characteristics)	У			У	У	У	П
Тип технологии радиодоступа (RAT type)	У		У	У	У	У	В
Постоянный идентификатор пользователя (Permanent user identity)	О		О	О	О	О	П
Возможности мобильности при доступе не 3GPP (Mobility Capabilities)				O	У	У	В
IP адрес шлюза MAG (MAG IP address)						У	В
Идентификатор визитной сети (Visited Network Identifier)	У			У	У	У	В
Данные для аутентификации EAP (EAP payload)						У	В
Данные об используемом протоколе мобильности (MIP Subscriber profile)	О			О			П
Ключ GRE для восходящего направления интерфейса S5 (Uplink S5 GRE Key)		У	У	У			В
Ключ GRE для нисходящего направления интерфейса S5 (Downlink S5 GRE Key)			У	У			В
Ключ GRE для восходящего направления интерфейса S8 (Uplink S8 GRE Key)		У	У	У			В
Ключ GRE для нисходящего направления интерфейса S8 (Downlink S8 GRE Key)			У	У			В
Ключи GRE интерфейса S2a (S2a GRE Keys)			У	У	У		В
Ключи GRE интерфейса S2b (S2b GRE Keys)			У	У	У		В
Идентификатор мобильного узла (Mobile Node Identifier)			У	У			В
Адрес маршрутизатора по умолчанию формата IPv4 (IPv4 Default Router Address)			У	У			В
Локальный адрес линка (Link-local address)			У	У			В
Данные пользователя не 3GPP (Non 3GPP User Data)	У				У	У	В
Идентификатор 3GPP AAA Сервера (3GPP AAA Server Identity)	У			У	У		В
Выбор режима поддержки мобильности (Selected IP mobility mode)				У	У	У	В
Идентификатор сервера Diameter для HSS (Diameter Server Identity of HSS)		У				У	В
Неаутентифицированный IMSI (Unauthenticated IMSI)			У	У			В
Идентификатор соединения PDN (PDN Connection ID)			У	У	У		В
Идентификатор конечной точки туннеля ePDG F для S2b(плоскость управления) (ePDG F-TEID for S2b (control plane))				У	У		В
Идентификатор конечной точки туннеля ePDG F для S2b(плоскость пользователя) ePDG F-TEID for S2b (user plane)				У	У		В
Идентификатор конечной точки туннеля PGW F для S2b(плоскость управления) (PGW F-TEID for S2b (control plane))				У	У		В
Идентификатор конечной точки туннеля PGW F для S2b(плоскость пользователя) (PGW F-TEID for S2b (user plane))				У	У		В
Параметры тарификации пользователя (Subscribed Charging Characteristics)	О				У	У	П
Мастер ключ сессии) (Master session Key				У	У	У	В
Примечание: В ? временные данные, О ? обязательные данные, У ? данные по условию, П ? постоянные данные.

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

Требования к протоколам EAP-AKA, EAP-AKA′

1. Протокол EAP-AKA должен быть расширяемым протоколом аутентификации для аутентификации и согласования ключей пользователей UMTS при помощи универсального модуля идентификации абонента (USIM).

Протокол EAP-AKA′ должен применяться для доступа к оборудованию коммутации стандартов GSM 900/1800, UMTS, LTE с использованием TWAN или UTWAN доступа.

Протоколы EAP-AKA и EAP-AKA′ должны пользоваться услугами протоколов канального уровня.

2. Требования к протоколу EAP-AKA:

2.1. Требования к формату пакетов EAP приведены на рисунке 1.

Код	Идентификатор	Длина
Данные

Рисунок 1

Поле "Код" (1 октет) должен указывать тип пакета EAP и принимать значения:

1 - запрос (Request);

2 - ответ (Response);

3 - подтверждение (Success);

4 - отказ (Failure).

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

Поле "Идентификатор" (1 октет) должно обеспечивать соответствие вопросов и ответов на них.

Поле "Длина" (2 октета) должно содержать размер (в октетах) пакета EAP с учетом полей "Код", "Идентификатор", "Длина" и "Данные". Октеты, выходящие за пределы указанного размера, следует считать заполнением канального уровня, на приеме такие данные следует игнорировать. Сообщения со значением поля "Длина", превышающем размер полученного пакета, должны отбрасываться без уведомления.

Поле "Данные" должно иметь размер 0 или более октетов. Формат поля должен зависеть от типа пакета (значения поля "Код").

2.2. Требования к формату пакетов EAP Request и Response, используемых для аутентификации и согласования ключей с помощью USIM (далее - AKA), приведены на рисунке 2.

Код	Идентификатор	Длина
Тип (23)	Подтип	Резерв
Тип атрибута	Длина атрибута	Значение (2 и более байтов)

Рисунок 2

Для пакетов Request и Response поле "Данные" должно начинаться с поля "Тип" (1 октет) и содержать тип запрашиваемой информации. Пакеты Request должны передаваться, пока не будет получен корректный отклик, не завершится отсчет числа попыток или нижележащий уровень не сообщит об отказе. Поле "Идентификатор" должно сохранять значение для повторных запросов, чтобы их можно было отличить от новых запросов. Содержимое поля "Данные" должно зависеть от "Типа" запроса. Пакеты Response должны передаваться в ответ на корректный запрос.

Значение поля "Тип" для пакетов EAP-AKA должно устанавливаться равным "23".

Поле "Данные" должно включать поле "Подтип" (1 октет) и поле "Резерв" (2 октета). Поле "Подтип" должно указывать тип запроса/ответа для EAP-AKA.

Поле "Атрибуты" следует в поле "Данные" за полем "Резерв" и должно использовать формат: тип-длина-значение.

2.3. Требования к содержанию пакетов EAP-Request/AKA-Identity (подтип-5) (запрос идентификационной информации).

Идентификационной информацией для пользователя сети стандартов GSM900/1800, UMTS, LTE и Интернет должны быть IMSI (TMSI) и NAI (имя пользователя@оператор).

Запрос должен содержать один из трех атрибутов, указывающих тип запрашиваемого идентификатора:

AT_PERMANENT_ID_REQ;

AT_FULLAUTH_ID_REQ;

AT_ANY_ID_REQ.

2.4. Требования к содержанию пакетов EAP-Response/AKA-Identity (ответ, содержащий запрашиваемую идентификационную информацию).

Ответ должен содержать атрибут AT_IDENTITY.

2.5. Пакет EAP-Request/AKA-Challenge (подтип-1) должен содержать данные для полной аутентификации пользователя и включать атрибуты AT_RAND, AT_MAC и AT_AUTN.

2.6. Пакет EAP-Response/AKA-Challenge должен содержать отклик пользователя и включать атрибуты AT_MAC и AT_RES.

2.7. Пакет EAP-Response/AKA-Authentication-Reject (подтип-2) должен передаваться, если пользователь не принимает параметр аутентификации сети AUTN.

2.8. Пакет EAP-Response/AKA-Synchronization-Failure (подтип-4) должен передаваться при ошибке в порядковом номере AUTN и включает атрибут AT_AUTS.

2.9. Пакет EAP-Request/AKA-Reauthentication (подтип-13) должен передаваться при запросе сервером повторной быстрой аутентификации пользователя после получения EAP-Response/Identity или EAP-Response/AKA-Identity и включать атрибут AT_MAC.

2.10. Пакет EAP-Response/AKA-Reauthentication должен передаваться в ответ на запрос AKA-Reauthentication и включать атрибуты AT_MAC, AT_IV и AT_ENCR_DATA.

2.11. Пакет EAP-Response/AKA-Client-Error (подтип-14) должен передаваться при обнаружении пользователем ошибки в пакете EAP /AKA, и содержать атрибут AT_CLIENT_ERROR_CODE.

2.12. Пакет EAP-Request/AKA-Notification (подтип-12) должен включать атрибут AT_NOTIFICATION AT_MAC и передаваться для передачи пользователю уведомления от идентифицирующей стороны.

2.13. Пакет EAP-Response/AKA-Notification должен передаваться в ответ на EAP-Request/AKA-Notification и включать атрибуты AT_ENCR_DATA и AT_IV.

2.14. Генерация ключа должна осуществляться с использованием функции SHA-1.

3. Требования к протоколу EAP-AKA′ должны соответствовать требованиям к EAP-AKA за исключением:

3.1. Для пакетов EAP-AKA′ значение поля "Тип" должно устанавливаться равным "50".

3.2. Должны использоваться новые атрибуты AT_KDF, AT_KDF_INPUT.

3.3. Генерация ключа должна осуществляться с использованием функции SHA-256.

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

Требования к параметрам протокола взаимодействия
сервера абонентских данных и/или центра аутентификации (далее - HSS/AuC) и отдельного устройства безопасности HSM (hardware security module - далее HSM), выполняющего криптографические функции аутентификации абонентов

1. Для взаимодействия сервера абонентских данных и/или центра аутентификации HSS/AuC и HSM, выполняющего криптографические функции аутентификации абонентов, должны использоваться следующие сообщения: "Запрос аутентификационной информации" (Authentication Information request-AIR), "Ответ с аутентификационной информацией" (Authentication Information answer-AIA), "Запрос аутентификации при ресинхронизации" (Authentication Resynchronization Request-ARR), "Ответ аутентификации при ресинхронизации" (Authentication Resynchronization Answer-ARA). Значение кодов сообщений HSM приведено в таблице N 1.

Таблица 1.

Название	Сокращение	Код/Code
Authentication Information Request без использования AK	AIR	0
Authentication Information Request c использованием AK	AIR	1
Authentication Information Answer	AIA	2
Authentication Resynchronization Request без использования AK	ARR	4
Authentication Resynchronization Request c использованием AK	ARR	5
Authentication Resynchronization Answer	ARA	6

1.1. Требования к информационным элементам сообщения "Запрос аутентификационной информации" приведены в таблице 2.

Таблица 2.

Информационный элемент	Требования к информационному элементу
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
K	Информационный элемент K должен содержать ключ K, который хранится в сервере абонентских данных HSS/AuC. Длина должна быть 128 бит.
AMF	Информационный элемент AMF должен содержать AMF, предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 16 бит.
SQN	Информационный элемент SQN должен содержать SQN, предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 48 бит.
AIR-Filler	Информационный элемент AIR-Filler должен обеспечивать превышение длиной запроса длины соответствующего ему ответа. Длина должна быть 448 бит.

1.2. Требования к информационным элементам сообщения "Ответ с аутентификационной информацией" приведены в таблице 3.

Таблица 3.

Информационный элемент	Требования к информационному элементу
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
Authentication Vector	Информационный элемент Authentication Vector должен содержать вектор аутентификации (AV), предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 576 бит.

1.3. Требования к информационным элементам сообщения "Запрос аутентификации при ресинхронизации" приведены в таблице 4.

Таблица 4.

Информационный элемент	Требования к информационному элементу
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
K	Информационный элемент K должен содержать ключ абонента K, предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 128 бит.
RAND	Информационный элемент RAND должен содержать RAND, предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 128 бит.
Conc(SQNMS)	Информационный элемент Conc(SQNMS) должен содержать Conc(SQNMS), предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 48 бит.

1.4. Требования к информационным элементам сообщения "Ответ аутентификации при ресинхронизации" приведены в таблице 5.

Таблица 5.

Информационный элемент	Требования к информационному элементу
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
XMACS	Информационный элемент XMACS должен содержать XMACS, предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 64 бит.
SQNMS	Информационный элемент должен содержать SQNMS, предусмотренный п.6.3 ETSI TS 133 102. Длина должна быть 48 бит.

2. Функциональные требования к протоколу взаимодействия HSS/AuC.

2.1. HSS/AuC должен отправлять запрос в HSM для генерации данных аутентификации.

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

2.3. HSS/AuC должен ожидать от HSM ответ для каждого отправленного запроса в течение определенного времени.

3. Функциональные требования к протоколу взаимодействия HSM.

3.1. HSM должен принимать корректный запрос от сервера абонентских данных HSS/AuC, обрабатывать и передавать ответ в HSS/AuC.

3.2. Адрес получателя протокола взаимодействия 4 уровня в ответах должен совпадать с адресом отправителя протокола взаимодействия 4 уровня в запросе.

3.3. HSM не должен отвечать на некорректные запросы.

3.4. HSM должен сигнализировать системе о своём отказе отключением интерфейса на физическом уровне взаимодействия.

4. Требования к UDP-реализации протокола взаимодействия 4 уровня (транспортного).

4.1. Для адресации запросов и ответов в протоколе взаимодействия 4 уровня должны использоваться UDP порты из диапазона (49152 - 65535).

4.2. Адреса протокола взаимодействия 4 уровня получателя запросов и отправителя ответов должны устанавливаться одинаковыми в конфигурациях HSS/AuC и HSM соответственно.

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

Справочно

Список используемых сокращений

1. 3GPP ? 3rd Generation Partnership Project (консорциум, разрабатывающий спецификации для сетей радиотелефонной связи).

2. AAA ? Authentication, Authorization и Accounting (аутентификация, проверка полномочий, учет).

3. AH ? Authentication Header (аутентификационный заголовок для протокола IP).

4. ANID ? Access Network Identity (идентификатор сети доступа).

5. APN ? Access Point Name (идентификатора точки доступа к PDN).

6. ARP ? Allocation and Retention Priority (назначение и сохранение приоритета).

7. AUTN ? Authentication Token (символ аутентификации).

8. CoA ? Care-of Аddress (адрес, назначаемый в момент регистрации пользователя в сети).

9. CN ? Core Network (базовая сеть).

10. DHCP ? Dynamic Host Configuration Protocol ( протокол динамической настройки узла).

11. DSMIP ? Dual-Stack Mobile IPv6 (двухстековый протокол IPv6 по обеспечению мобильности).

12. DPXA ? Diameter Proxy Agents (функция прокси протокола Diameter).

13. DRDA ? Diameter Redirect Agents (функция перенаправления протокола Diameter).

14. DRLA ? Diameter Relay Agents (функция переключения протокола Diameter).

15. EAP-AKA ? Extensible Authentication Protocol Method for UMTS Authentication and Key Agreement (расширяемый протокол Аутентификации для аутентификации и согласования ключей пользователей UMTS).

16. EIR ? Equipment Identity Register (регистр идентификации оборудования).

17. eNodeB ? Evolved NodeB (базовые станции стандарта LTE и LTE-Advanced).

18. ECM ? EPS Connection Management (управление соединением в EPS).

19. ECM-CONNECTED ? EPS Connection Management-CONNECTED (состояние процесса управления соединением для "абонентская радиостанция - соединение").

20. ECM-IDLE ? EPS Connection Management-IDLE (исходное состояние процесса управления соединением для AC в EPS).

21. EMM ? EPS Mobility Management (управление мобильностью в EPS).

22. EMM-DEREGISTERED ? EPS Mobility Management-DEREGISTERED (состояние процесса управления мобильностью для AC в EPS ? не зарегистрирована).

23. ЕРС ? Evolved Packet Core (базовая сеть стандартов LTE и LTE-Advanced).

24. ePDG ? Evolved Packet Data Gateway (оборудование, реализующее функции доступа к оборудованию коммутации стандарта LTE из сети Интернет при использовании доступа UTWAN).

25. EPS ? Evolved Packet System (сеть радиодоступа и базовая сеть стандартов LTE и LTE-Advanced).

26. ESP ? Encapsulating Security Payload (протокол защиты (шифрования) данных).

27. E-UTRAN ? Evolved UTRAN (сеть радиодоступа стандартов LTE и LTE-Advanced).

28. FA ? Foreign Agent (агент визитной сети).

29. FACoA ? Foreign Agent Care-of Address (адрес агента визитной сети).

30. GBR ? Guaranteed Bit Rate (гарантированная скорость передачи данных).

31. GRE ? Generic Routing Encapsulation (общая инкапсуляция маршрутов).

32. GSM ? Global System for Mobility (глобальная система мобильной связи).

33. GTP ? GPRS Tunnelling Protocol (протокол туннелирования GPRS).

34. HA ? Home Agent (агент домашней сети сети).

35. HBM ?Host Based Mobility (управление мобильностью на базе хостов).

36. HLR ? Home Location Register (домашний регистр местонахождения).

37. HMAC ? hash-based message authentication code (код аутентификации сообщений, использующий хеш-функции).

38. HPLMN ? Home Public Land Mobile Network (сеть Оператора мобильной связи, в которой абонент подписан на оказание услуг мобильной связи).

39. HSS ? Home Subscriber Server (сервер абонентских данных).

40. ICMP ? Internet Control Message Protocol (протокол управляющих сообщений в Интернет).

41. IKEv2 ? Internet Key Exchange version 2(Протокол обмена ключами в Интернет версия 2).

42. IMEI ? International Mobile Equipment Identity (международный идентификатор оборудования абонентской радиостанции).

43. IMEISV ? International Mobile Equipment Identity and Software Version (международный идентификатор оборудования и номер версии программного обеспечения оборудования абонентской радиостанции).

44. IMSI ? International Mobile Subscriber Identity (международный номер абонентской станции).

45. IP ? Internet Protocol (протокол Интернет).

46. IPSec ? Internet Protocol Security (протокол Интернет c поддержкой функций безопасности)

47. KDF ? key derivation function (функция формирования ключа).

48. LIPA ? Local IP Access (местный IP доступ).

49. LMA ? Local Mobility Anchor (локальный узел управления мобильностью).

50. LTE ? Long-Term Evolution (эволюция на длительный период).

51. LTE-Advanced ? (развитие стандарта LTE).

52. MAG ? Mobile Access Gateway (шлюз мобильного доступа).

53. MBR ? Maximum Bit Rate (максимальная скорость передачи).

54. MCM ? Multi-connection mode (режим нескольких соединений).

55. MD5 ? Message Digest 5 (128-битный алгоритм хеширования).

56. MIPv4 ? Mobile IP version 4 (расширение функциональности протокола IPv4 по обеспечению мобильности).

57. MME ? Mobility Management Entity (модуль управления мобильностью).

58. MSISDN ? Mobile Subscriber ISDN Number (международный номер AC в сети ISDN).

59. NAI ? Network Access Identifier (идентификатор доступа к сети).

60. NAS protocol ? Non-Access-Stratum protocol (протокол слоя без доступа).

61. NBM ? Network Based Mobility (управление мобильностью на базе сети).

62. NDP ? Neighbor Discovery Protocol (протокол обнаружения соседей).

63. Non-3GPP ? сеть радиодоступа, отличная от стандартов GSM 900/1800, UMTS, LTE, использующая передачу данных в диапазоне от 30 МГц до 66 ГГц

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

65. PCRF ? The Policy and Charging Rules Function (функция правил политики)

66. PDN ? Packet Data Network (сеть передачи данных).

67. PMIPv6 ? Proxy Mobile IP version 6 (расширение функциональности протокола IPv6 по обеспечению сетевой мобильности).

68. PPP ? Point-to-Point Protocol (протокол канала связи с непосредственным соединением).

69. PRF ? PSEUDO_RANDOM_FUNCTION (псевдо случайная функция).

70. QCI ? QoS Class Identifier (идентификатор класса качества обслуживания).

71. QoS ? Quality of Service (качество обслуживания).

72. RADIUS ? Remote Authentication in Dial-In User Service (протокол для аутентификации, авторизации удаленных пользователей).

73. S1-AP ? S1 Application Protocol (прикладной протокол для интерфейса S1).

74. SCM ? Single-connection mode (режим одного соединения).

75. SCTP ? Stream Control Transmission Protocol (протокол передачи с управлением потоками).

76. SGSN ? Serving GPRS Support Node (обслуживающий узел поддержки GPRS).

77. SGsAP ? SGs Application Part (прикладной протокол для интерфейса SGs).

78. S-GW ? Serving Gateway (обслуживающий шлюз).

79. SHA ? Secure Hash Algorithm (алгоритм криптографического хеширования).

80. SIPTO ? Selected IP Traffic Offload (возможность распределения трафика IP).

81. SRVCC ? Single Radio Voice Call Continuity (отдельная непрерывность голосового вызова на радиоинтерфейсе).

82. TCP ? Transmission Control Protocol (протокол управления передачей).

83. TEID ? Tunnel Endpoint Identifier (идентификатор конечной точки туннеля).

84. TLV ? Tag-length-value ("тип-длина-значение", метод записи данных в телекоммуникационных протоколах).

85. ТMAG ? Trusted Mobile Access Gateway (шлюз мобильного доступа).

86. TMSI ? Temporary Mobile Subscriber Identity (временный идентификатор мобильного абонента).

87. TSCM ? Transparent single-connection mode (режим одного прозрачного соединения).

88. TWAG ? TWAN Access Gateway (шлюз сети TWAN).

89. TWAN ? trusted WLAN (доверенный беспроводный доступ).

90. UDP ? User Datagram Protocol (протокол передачи дейтаграмм пользователя).

91. UE ? User Equipment (радиотелефонная станция стандартов GSM900/1800/UMTS/LTE, поддерживающая стандарт беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц).

92. UMTS ? Universal Mobile Telecommunications System (универсальная система мобильной связи)

93. USIM ? Universal Subscriber Identity Module (универсальный модуль идентификации абонента; карта мобильного пользователя для работы в сети UMTS).

94. UTRAN ? Universal Terrestrial Radio Access Network (сеть радиодоступа стандарта UMTS).

95. UTWAN ? Untrusted WLAN (ненадежный беспроводный доступ).

96. VPLMN ? Visited Public Land Mobile Network (гостевая сеть мобильной связи, в которой в настоящий момент обслуживается абонент).

97. WLAN - Wireless Local Area Network (локальная сеть, построенная на основе беспроводных технологий).

WLAN AN ? WLAN Access Network (сеть беспроводного абонентского доступа).

Обзор документа

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

Правила устанавливают обязательные требования к параметрам оборудования коммутации стандартов LTE и (или) LTE-Advanced, включая оборудование коммутации IMS, при оказании услуг передачи данных и телефонного соединения.

В частности, указываются требования к параметрам, обеспечивающим взаимодействие с узлами связи стандартов GSM 900/1800 и UMTS, а также к параметрам оборудования коммутации стандарта LTE для взаимодействия с беспроводным доступом, отличным от стандартов GSM 900/1800, UMTS, LTE и принадлежащим домашнему или визитному оператору сети подвижной радиотелефонной связи или другой сети связи общего пользования.

Для просмотра актуального текста документа и получения полной информации о вступлении в силу, изменениях и порядке применения документа, воспользуйтесь поиском в Интернет-версии системы ГАРАНТ:

Перепечатка