Проект Приказа Министерства цифрового развития, связи и массовых коммуникаций РФ "Об утверждении Правил применения оборудования коммутации систем подвижной радиотелефонной связи. Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020, используемого при оказании услуг передачи данных и телефонного соединения" (подготовлен Минцифры России 14.01.2022)

Проект Приказа Министерства цифрового развития, связи и массовых коммуникаций РФ "Об утверждении Правил применения оборудования коммутации систем подвижной радиотелефонной связи. Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020, используемого при оказании услуг передачи данных и телефонного соединения"
(подготовлен Минцифры России 14.01.2022 г.)

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

Пояснительная записка

В соответствии со статьей 41 Федерального закона от 7 июля 2003 г. N 126-ФЗ "О связи" (Собрание законодательства Российской Федерации, 2003, N 28, ст. 2895; 2019, N 23, ст. 2914) и пунктом 4 Правил организации и проведения работ по обязательному подтверждению соответствия средств связи, утвержденных постановлением Правительства Российской Федерации от 13 апреля 2005 г. N 214 (Собрание законодательства Российской Федерации, 2005, N 16, ст. 1463; 2018, N 49, ст. 7600),

приказываю:

1. Утвердить прилагаемые Правила применения оборудования коммутации систем подвижной радиотелефонной связи. Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020, используемого при оказании услуг передачи данных и телефонного соединения.

2. Установить, что настоящий приказ вступает в силу с 1 сентября 2022 г. и действует в течение шести лет с даты его вступления в силу.

Министр

М.И. Шадаев

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

Правила применения оборудования коммутации систем подвижной радиотелефонной связи. Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020, используемого при оказании услуг передачи данных и телефонного соединения

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

1. Правила применения оборудования коммутации систем подвижной радиотелефонной связи. Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020, используемого при оказании услуг передачи данных и телефонного соединения*(1) (далее - Правила) разработаны в целях обеспечения целостности, устойчивости функционирования и безопасности единой сети электросвязи Российской Федерации.

2. Правила устанавливают обязательные требования к параметрам оборудования коммутации стандарта 5G/IMT-2020, включая оборудование коммутации IMS, используемых при оказании услуг передачи данных и телефонного соединения с учетом обеспечения взаимодействия такого оборудования с сетями радиодоступа NG-RAN (далее NG-RAN) и Non-3GPP (далее - Non-3GPP).

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

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

1) средства связи, обеспечивающие выполнение одной или нескольких сетевых функций (далее NF):

а) сервера аутентификации (Authentication Server Function, AUSF);

б) управления доступом и мобильностью (Access and Mobility Management Function, AMF);

в) хранения неструктурированных данных (Unstructured Data Storage Function, UDSF);

г) отображения сетевых возможностей и событий (Network Exposure Function, NEF);

д) хранения информации о сетевых функциях (NF Repository Function, NRF);

е) выбора сегмента сети (Network Slice Selection Function, NSSF);

ж) управления политикой (Policy Control Function, PCF);

з) управления сессией (Session Management function, SMF);

и) управления унифицированными данными (Unified Data Management, UDM);

й) хранения унифицированных данных (Unified Data Repository, UDR);

к) плоскости передачи данных (User plane function, UPF);

л) прикладная функция (Application Function, AF);

м) управления доставкой коротких сообщений (Short Message Service Function, SMSF);

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

о) управления местоположением (Location Management Function, LMF);

п) прокси-сервера защиты сообщений (Security Edge Protection Proxy, SEPP);

р) анализа сетевых данных (Network Data Analytics Function, NWDAF);

с) взаимодействия с сетями, не относящимися к 3GPP (далее Non-3GPP) (Non-3GPP InterWorking Function) (далее N3IWF);

т) прокси-сервиса Service Communication Proxy (SCP);

у) оптимизации согласования параметров абонентского оборудования UE radio Capability Management Function (UCMF);

ф) шлюза доступа из доверенных беспроводных сетей Trusted Non-3GPP Gateway Function (TNGF);

х) шлюза доступа из сетей фиксированной связи Wireline Access Gateway Function (W-AGF);

ц) шлюза доступа из доверенных сетей для оборудования, не поддерживающего сообщения уровня NAS Trusted WLAN Interworking Function (TWIF);

ч) шлюза безопасности межсетевого обмена в плоскости передачи данных Inter PLMN UP Security (IPUPS);

2) оборудование коммутации IMS;

3) аппаратный модуль безопасности (далее - HSM) (в случае реализации криптографических алгоритмов аутентификации абонентов в отдельном аппаратном модуле безопасности).

4) аппаратный модуль безопасности (далее - HSM-SIDF), реализующий криптографические функции по расшифрованию значения SUPI из SUCI.

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

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

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

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

6. 5GC должна обеспечивать взаимодействие с сетями доступа NG-RAN (далее ? NG-RAN) и Non-3GPP (далее ? Non-3GPP).

NG-RAN должна поддерживать одну или несколько приведенных ниже технологий радиодоступа и обеспечивать возможность их взаимодействия:

только 5G (далее NR);

NR с возможностью перехода на E-UTRA (LTE);

только E-UTRA;

E-UTRA с возможностью перехода на NR.

7. Оборудование 5GC должно соответствовать требованиям Правил применения оборудования систем коммутации, включая программное обеспечение, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий. Часть I. Правила применения оборудования оконечно-транзитных узлов связи сетей подвижной радиотелефонной связи, включая программное обеспечение, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий, утвержденных приказом Министерства связи и массовых коммуникаций Российской Федерации от 12.12 2016 г. N 645 (зарегистрирован Министерством юстиции Российской Федерации 13 января 2017 г., регистрационный N 45201).

8. Перечень интерфейсов для подключения технических средств ОРМ приведен в приложении N 1 к Правилам применения оборудования систем коммутации, включая программное обеспечение, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий. Часть III. Правила применения оборудования коммутации и маршрутизации пакетов информации сетей передачи данных, включая программное обеспечение, обеспечивающего выполнение установленных действий при проведении оперативно-розыскных мероприятий, утвержденным приказом Министерства связи и массовых коммуникаций Российской Федерации от 16.04.2014 N 83 (зарегистрирован Министерством юстиции Российской Федерации 4 июня 2014 г., регистрационный N 32560) (далее - Правила N 83-14).

9. Перечень задаваемых с пункта управления техническими средствами ОРМ уполномоченного подразделения (ПУ) параметров контроля информации, относящейся к контролируемым соединениям и (или) сообщениям электросвязи и поступающей в процессе установления соединений и (или) передачи сообщений электросвязи на интерфейсы подключения к оборудованию коммутации технических средств ОРМ, приведен в пункте 4.4 Правил N 83-14.

В соответствии с Требованиями к сетям электросвязи для проведения оперативно-разыскных мероприятий. Часть I. Общие требования, утвержденными приказом Министерства информационных технологий и связи Российской Федерации от 16.01.2008 N 6 (зарегистрирован Министерством юстиции Российской Федерации 31 января 2008 г., регистрационный N 11057), в случае применения на каналах взаимодействия NF криптографической защиты информации содержимое информационного обмена должно поступать на интерфейсы подключения технических средств ОРМ в открытом (декодированном) виде.

II. Требования к параметрам оборудования коммутации 5G

10. Защита сигнального трафика между оборудованием 5GC и абонентскими терминалами должна обеспечиваться с использованием средств криптографической защиты информации, имеющих подтверждение соответствия требованиям по безопасности информации класса не ниже КС3, установленным федеральным органом исполнительной власти в области обеспечения безопасности.

11. Для оборудования 5GC идентификация криптографических механизмов шифрования и контроля целостности должна осуществляться следующим образом:

- NEA0 (идентификационный код "00002", шифрование данных отсутствует);

- 128-NEA1 (идентификационный код "00012", алгоритм шифрования на основе SNOW 3G, размерность ключа - 128 бит);

- 128-NEA2 (идентификационный код "00102", алгоритм шифрования на основе AES в режиме гаммирования (CTR), размерность ключа - 128 бит);

- 128-NEA3 (идентификационный код "00112", алгоритм шифрования на основе ZUC, размерность ключа - 128 бит);

- 256-NEA7 (идентификационный код "01112", алгоритм шифрования "Кузнечик" согласно ГОСТ Р 34.12-2015*(2) в режиме гаммирования согласно ГОСТ Р 34.13-2015*(3), размерность ключа - 256 бит);

- NIA0 (идентификационный код "00002", схема без контроля целостности сообщений);

- 128-NIA1 (идентификационный код "00012", контроль целостности сообщений на основе SNOW 3G, размерность ключа - 128 бит);

- 128-NIA2 (идентификационный код "00102", контроль целостности сообщений на основе AES в режиме CMAC, размерность ключа - 128 бит);

- 128-NIA3 (идентификационный код "00112", контроль целостности сообщений на основе ZUC, размерность ключа - 128 бит);

- 256-NIA7 (идентификационный код "01112", контроль целостности сообщений на основе алгоритма блочного шифрования "Кузнечик" согласно ГОСТ Р 34.12-2015 в режиме выработки имитовставки согласно ГОСТ Р 34.13-2015, размерность ключа - 256 бит).

12. Требования к параметрам системы нумерации и идентификации пользовательских терминалов (User Equipment, UE) (далее-UE) приведены в приложении N 1 к Правилам.

13. Требования к реализации сетевых функций и оборудованию 5GC приведены в приложении N 2 к Правилам.

14. Требования к интерфейсам и контрольным точкам сетевых функций 5GC приведены в приложении N 3 к Правилам.

15. Требования к реализации функций высокого уровня при обслуживании абонентских терминалов UE приведены в приложении N 4 к Правилам.

16. Требования к параметрам профиля схемы защиты SUPI приведены в приложении N 5 к Правилам.

17. Требования к оборудованию 5GC в режиме оказания услуг связи с использованием оборудования коммутации IMS приведены в приложении N 6 к Правилам.

18. Требования к протоколу взаимодействия UDM с HSM-SIDF, выполняющим криптографические функции расшифрования значения SUPI из SUCI, приведены в приложении N 7 к Правилам.

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

20. Требования к параметрам протоколов IP, UDP и TCP, в случае реализации, приведены в приложении N 7 к Правилам применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VI. Правила применения узлов связи с территориально распределенной архитектурой стандартов UMTS и/или GSM 900/1800, утвержденным приказом Министерства связи и массовых коммуникаций Российской Федерации от 27.06.2011 N 160 (зарегистрирован Министерством юстиции Российской Федерации 20 июля 2011 г., регистрационный N 21423), с изменениями, внесенными приказами Министерства связи и массовых коммуникаций Российской Федерации от 01.02.2012 N 30 (зарегистрирован Министерством юстиции Российской Федерации 22 февраля 2012 г., регистрационный N 23316), от 23.04.2013 N 93 (зарегистрирован Министерством юстиции Российской Федерации 14 июня 2013 г., регистрационный N 28788), от 24.10.2017 N 572 (зарегистрирован Министерством юстиции Российской Федерации 5 февраля 2018 г., регистрационный N 49882) и приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 13.06.2018 N 275 (зарегистрирован Министерством юстиции Российской Федерации 27 июня 2018 г., регистрационный N 51448) (далее - Правила N 160-11).

21. Требования к параметрам интерфейсов к сети передачи данных с использованием контроля несущей и обнаружением коллизий приведены в приложении 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) (далее ? Правила N 112-06).

22. Требования к параметрам протокола SCTP приведены в пункте 2 приложения N 14 к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи. Часть 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 28788), от 14.12.2015 N 543 (зарегистрирован Министерством юстиции Российской Федерации 18 января 2016 г., регистрационный N 40606) и приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 25.06.2018 N 319 (зарегистрирован Министерством юстиции Российской Федерации 31 июля 2018 г., регистрационный N 51741) (далее - Правила N 58-07).

23. Требования к протоколу IKEv2 приведены в приложении N 19 к Правилам применения оборудования коммутации сетей подвижной радиотелефонной связи. Часть VII. Правила применения оборудования коммутации стандарта LTE, утвержденным приказом Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 25.06.2018 N 319 (зарегистрирован Министерством юстиции Российской Федерации 31 июля 2018 г., регистрационный N 51741) (далее - Правила N 319-18).

24. Требования к протоколу IPsec приведены в приложении N 20 к Правилам N 319-18.

25. Требования к протоколу GTP приведены в пунктах 2.1-2.3 приложения N 7 к Правилам N 319-18.

Приложение N 1
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N_______

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

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

2. Каждому абоненту в сети подвижной радиотелефонной связи стандарта 5G/IMT-2020 (далее - сеть 5G) должен назначаться уникальный идентификатор подписки (Subscription Permanent Identifier) (далее - SUPI), который должен храниться в UDM/UDR на постоянной основе.

SUPI включает международный номер UE стандарта IMSI или идентификатор доступа к сети NAI вида: пользователь@область (сеть) (далее ? username@realm). При этом UE должны поддерживать обработку NAI до 72 октетов и формирование NAI до 253 октетов.

Для обеспечения роуминга SUPI должен содержать адрес сети связи оператора связи, в которой зарегистрирован абонент (далее - домашняя сеть).

Для взаимодействия с базовой сетью стандарта LTE SUPI, выделенный пользователю доступ 3GPP, должен быть в формате IMSI.

3. Каждому UE, осуществляющему доступ к сети 5G, должен быть присвоен уникальный идентификатор оборудования (Permanent Equipment Identifier, PEI). Если UE поддерживает одну из технологий доступа 3GPP, то UE должен быть присвоен PEI в формате IMEI/IMEISV.

Структура международного идентификатора UE и версия программного обеспечения IMEI/IMEISV (International Mobile Equipment Identity and Software version Number) приведена на рисунке 1.

IMEI 15 цифр

TAC	SNR	CD/SD
8 цифр	6 цифр	1 цифра

IMEISV 16 цифр

TAC	SNR	CD/SD	SVN
8 цифр	6 цифр	1 цифра	1 цифра

Рисунок1. Структура IMEI/IMEISV

IMEI должен постоянно храниться в UE и в EIR и должен содержать:

TAC (Type Allocation Code) - модель и страну происхождения UE (8 цифр);

SNR (Serial Number) - серийный номер (6 цифр), идентифицирующий оборудование в пределах TAC;

CD/SD - дополнительная цифра, которая вычисляется соответствующей формуле, во избежание ручного ввода IMEI в случае попытки регистрации похищенного UE.

Идентификатор IMEISV должен дополнительно включать поле SVN - номер версии программного обеспечения UE.

При включении UE абонента (пользователя) IMEI должен передаваться в сеть связи и автоматически проверяется на предмет наличия IMEI в черном/сером списках, хранящихся в EIR.

4. Оборудование 5GC должно обеспечивать расшифрование закрытого идентификатора подписки (Subscription Concealed Identifier, SUCI), принятое от UE, для получения значения SUPI. Структура SUCI приведена на рисунке 2.

Рисунок 2.

Структура SUCI состоит из следующих полей:

1) тип SUPI. При этом SUPI должен принимать значения от 0 до 7, идентифицировать тип SUPI, содержащийся в SUCI в пределах следующих значений:

"0": SUPI на основе IMSI;

"1": специфичный для сети 5G идентификатор пользователя;

от "2" до "7": резервные значения.

2) идентификатор домашней сети абонента.

При типе SUPI равном "0" идентификатор домашней сети должен состоять из двух частей:

код страны подвижной радиотелефонной связи (MCC) на основе IMSI, состоящий из трех десятичных цифр;

код сети подвижной связи (MNC), включающий до 2 десятичных цифр (для идентификации сети подвижной радиотелефонной связи в пределах страны регистрации UE) на основе IMSI.

При типе SUPI равном "1" идентификатор домашней сети должен состоять из строки символов переменной длины, представляющей имя домена;

3) идентификатор маршрутизации, состоящий из 1-4 десятичных цифр, назначенных оператором домашней сети, и предоставленных в USIM. При этом если в USIM не указан идентификатор маршрутизации, то в этом поле должно быть установлено значение "0";

4) идентификатор схемы защиты SUPI, принимающий значения в диапазоне от 0 до 15;

5) идентификатор открытого ключа домашней сети (HNPKI), принимающий значения в диапазоне от 0 до 255. В случае использования нулевой схемы это поле данных должно быть установлено в значение "0";

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

5. Оборудование 5GC должно обеспечивать поддержку схемы защиты SUPI в соответствии с требованиями к параметрам ее профиля, приведенным в Приложении N 5 к Правилам.

6. Криптографические преобразования для расшифрования значения SUPI из SUCI должны производиться на стороне оборудования 5GC с использованием средств криптографической защиты информации, имеющих подтверждение соответствия требованиям по безопасности информации, установленным федеральным органом исполнительной власти в области обеспечения безопасности, не ниже класса КА.

7. AMF должен назначать для UE глобальный уникальный временный идентификатор (Globally Unique Temporary Identifier) (далее - 5G-GUTI), который является общим для доступа 3GPP и non-3GPP. При этом AMF должен автоматически обновлять 5G-GUTI для UE.

5G-GUTI должен иметь следующую структуру:

<5G-GUTI>: = <GUAMI> <5G-TMSI>,

где GUAMI (Globally Unique AMF ID) должен идентифицировать обслуживающую AMF, а 5G-TMSI должен идентифицировать UE в AMF.

Глобально уникальный идентификатор AMF (далее - GUAMI) должен иметь следующую структуру:

<GUAMI>: = <MCC> <MNC> <идентификатор AMF>.

Идентификатор AMF включает: идентификатор региона AMF, идентификатор списка AMF в регионе и указатель AMF в списке.

Взамен 5G-GUTI используется 5G-S-TMSI:

<5G-S-TMSI>: = <идентификатор списка AMF><указатель AMF> <5G-TMSI>.

5G-TMSI имеет длину 32 бита, идентификатор региона AMF - 8 бит, идентификатор списка AMF - 10 бит, указатель AMF - 6 бит.

8. AMF назначается полное доменное имя.

9. Имя сети передачи данных (Data Network Name, DNN) представляет собой условное наименование сети передачи данных, к которой подключена сеть 5G, с максимальной длинной 63 байта.

10. В случае если абонент принадлежит к группе в сети связи, то этому абоненту должен присваиваться идентификатор внутренней группы (Internal-Group Identifier), который хранится в UDM и должен передаваться в SMF.

11. Общий публичный идентификатор подписки (Generic Public Subscription Identifier, GPSI) ассоциируется с SUPI и используется для адресации пользователя в сетях 3GPP и иных сетях связи.

GPSI должен корректно идентифицировать телефонный номер абонента сети подвижной радиотелефонной связи стандарта MSISDN и/или username@realm.

12. AMF UE NGAP ID используется для идентификации UE в AMF на N2. AMF UE NGAP ID должен назначать AMF и направлять его в сеть доступа.

AMF UE NGAP ID является уникальным для каждого набора AMF.

13. Оборудование 5GC должно осуществлять маршрутизацию соединения, используя телефонный номер абонента сети фиксированной/подвижной радиотелефонной связи или публичный идентификатор вызываемого пользователя PuUI, а также контактный адрес абонента в формате, определенном протоколами IPv4 или IPv6 соответственно.

Приложение N 2
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N_______

Требования к сетевым функциям, реализуемым оборудованием 5GC

1. Оказание услуг связи в сети 5G осуществляется с использованием технологий виртуализации сетевых функций и программно-определяемой сети.

2. NF должна выполнять функции, необходимые для оказания одной или нескольких услуг связи. Взаимодействие между двумя сетевыми функциями (потребителем и поставщиком услуги) осуществляется в виде:

запрос-ответ,

подписка-уведомление.

3. NF должна обеспечивать выполнение следующих функций:

регистрации и отмены регистрации услуги и экземпляра NF;

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

4. Функция, использующая услугу NF, должна осуществлять обнаружение функции, предоставляющей услугу, посредством NRF или иметь предварительные настройки ее адресации.

5. Ресурсы NF должны идентифицироваться унифицированным идентификатором ресурса URI, хранящимся в NRF с момента регистрации NF.

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

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

Повторный выбор необходим, если потребителю услуг не удается получить доступ к первоначально выбранному экземпляру услуги NF.

7. Каждая услуга NF должна быть доступна с использованием персонального интерфейса.

8. Описание NF и их услуг.

8.1. AUSF по запросу одной из функций должна обеспечивать аутентификацию UE в 5GC.

8.1.1. AUSF должна обеспечивать предоставление следующих услуг:

Nausf UEauthentication. При этом AUSF должна обеспечивать аутентификацию UE по запросу NF.

Nausf_SoRProtection. При этом AUSF должна предоставлять услугу защиты информации управления роумингом, запрашивающей NF.

8.2. AMF должна обеспечивать выполнение следующих функций:

1) завершения интерфейса AMF - NG RAN (N2);

2) завершения интерфейса без доступа NAS между UE и AMF (N1), шифрования NAS и контроля целостности сообщений уровня NAS с использованием алгоритма шифрования "Кузнечик" согласно ГОСТ Р 34.12-2015 в режиме гаммирования и в режиме выработки имитовставки по ГОСТ Р 34.13-2015;

3) управления регистрацией UE в сети и контроля возможных состояний регистрации: RM-DEREGISTERED, RM-REGISTERED;

4) управления соединением UE с сетью и контроль возможных состояний соединения: CM-IDLE, CM-CONNECTED;

5) управления доступностью UE в сети в состоянии CM-IDLE;

6) управления мобильностью UE в сети в состоянии CM-CONNECTED;

7) обеспечения разрешенного перехвата (для событий AMF и интерфейса с системами LI);

8) обеспечения транспортировки сообщений управления сессией между UE и SMF;

9) обеспечения оптимальной маршрутизация сообщений управления сессией SM;

10) обеспечения аутентификации доступа. При этом AMF должна: поддерживать первичную аутентификацию с использованием SUCI; назначение, перераспределение 5G-GUTI для UE; подтверждение SUPI от UE, в том числе и от домашней сети; должна отказывать в обслуживании UE, если это подтверждение не выполнено;

11) обеспечения авторизации доступа потребителей услуг;

12) обеспечения транспортировки SMS-сообщений между UE и SMSF;

13) обеспечения выполнения якорной функции безопасности (Security Anchor Functionality, SEAF). При этом SEAF должна взаимодействовать с AUSF и UE и получать промежуточный ключ, который устанавливается в результате процесса аутентификации UE;

14) управления контекстом безопасности (Security Context Management, SCM). При этом SCM должен получать ключ от SEAF для его использования и получения специальных ключей, обеспечивающих доступ к сети 5G;

15) управления услугами определения местонахождения. При этом должна обеспечиваться передача сообщений между UE и функцией управления местоположением LMF, а также передача сообщений между RAN и LMF;

16) присвоения идентификатора каналу для взаимодействия с EPS (Evolved Packet System).

8.2.1. AMF должна обеспечивать выполнение следующих функций для сетей доступа non-3GPP:

1) поддержки интерфейса N2 с N3IWF;

2) поддержки сигнализации NAS с UE через N3IWF, шифрования NAS и контроля целостности сообщений уровня NAS с использованием алгоритма шифрования "Кузнечик" согласно ГОСТ Р 34.12-2015 в режиме гаммирования и в режиме выработки имитовставки по ГОСТ Р 34.13-2015;

3) поддержки аутентификации UE, подключенных через N3IWF;

4) управления мобильностью, аутентификации и отдельными состояниями контекста безопасности UE, подключенных через доступ non-3GPP или через доступ 3GPP и доступ non-3GPP одновременно;

5) поддержки скоординированных данных регистрации UE для сетей доступа 3GPP и сетей доступа non-3GPP;

6) поддержки выделенных контекстов управления сессией для UE при их подключении через сеть доступа non-3GPP.

8.2.2. AMF должна обеспечивать предоставление следующих услуг:

Namf_Communication должна обеспечивать потребителю услуг NF взаимодействие с UE и/или сетью доступа через AMF, а также должна позволять SMF запрашивать выделение EBI для поддержки взаимодействия с EPS;

Namf_EventExposure должна обеспечивать потребителям услуг NF возможность подписываться или получать данные статистики и уведомления о событиях, связанных с мобильностью абонента;

Namf_MT должна обеспечивать потребителю услуг NF убедиться, что UE доступна;

Namf_Location должна обеспечивать потребителю услуг NF возможность запрашивать информацию о местоположении UE.

8.3. SMF должна обеспечивать выполнение следующих функций (в единичном экземпляре SMF должны поддерживаться часть или все функции SMF):

1) управления сессией: создание, изменение и завершение сессий, включая создание туннеля между UPF и узлом сети доступа;

2) распределения и управления IP-адресами UE;

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

4) управления функционированием шлюза UPF для обеспечения требуемых показателей качества QoS;

5) обеспечения динамической настройки UE абонента на основе протоколов DHCPv4 (сервер и клиент) и DHCPv6 (сервер и клиент);

6) обработки ARP (Address Resolution Protocol) запросов. При этом SMF должна отвечать на ARP запросы, предоставляя MAC-адрес, соответствующий IP-адресу, отправленному в запросе;

7) обеспечения выбора и управления функцией UPF;

8) управления UPF для маршрутизации трафика к требуемому месту назначения;

9) обеспечения взаимодействия с PCF;

10) обеспечения разрешенного перехвата (для событий управления сессией и интерфейса с системами LI);

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

12) обеспечения непрерывности предоставления услуг (Session and Service Continuity, SSC);

13) обеспечения сбора данных для тарификации от UPF;

14) создания конечной точки сообщений управления сессией NAS;

15) уведомления о наличии данных для передачи по нисходящей линии связи;

16) инициирования передачи информации для управления сессией в AN, (через AMF и N2);

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

обработку данных для поддержки показателей QoS для SLA в VPLMN;

обеспечение сбора данных для тарификации и поддержку интерфейсов для тарификации (VPLMN);

обеспечение разрешенного перехвата (для событий управления сессией и интерфейсом к LI-системе в VPLMN);

поддержку взаимодействия с внешней DN для передачи сигналов аутентификации для PDU сессии.

8.3.1. SMF должна обеспечивать предоставление следующих услуг:

Nsmf_PDUSession должна обеспечивать управление PDU сессиями с применением пользовательских правил политики и тарификации, полученных от PCF;

Nsmf_EventExposure должна обеспечивать отображение событий, происходящих при реализации PDU сессий, для потребителей услуг NF.

8.4. UPF должна обеспечивать выполнение следующих функций (в единичном экземпляре UPF должны поддерживаться часть или все функции UPF):

1) создания конечной точки для поддержки мобильности абонента в пределах одной и нескольких сетей доступа;

2) создания точки взаимодействия PDU сессии с внешней сетью передачи данных;

3) обеспечения маршрутизации и пересылки пакетов;

4) обеспечения анализа пакетов (обнаружение приложений на основе шаблона потока служебных данных и дополнительных PFD, полученных от SMF);

5) соблюдения пользовательской части правил политики;

6) обеспечения разрешенного перехвата (в плоскости передачи данных);

7) формирования отчетов о пропуске трафика;

8) маркировки пакетов данных в соответствии с требуемыми параметрами QoS;

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

10) отправки и пересылки одного или нескольких "конечных маркеров" на узел NG-RAN источника;

11) обработки ARP и/или поддержки протокола обнаружения соседей IPv6 (NDP) для Ethernet PDU.

8.5. PCF должна обеспечить выполнение следующих функций:

1) обеспечения единой структуры правил для управления сетью связи;

2) обеспечения доступа к информации о подписке UE.

8.5.1. PCF должна обеспечивать предоставление следующих услуг:

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

Npcf_SMPolicyControl должна обеспечивать потребителя услуг (SMF) информацией в соответствии с правилами политики для обслуживания PDU сессий;

Npcf_PolicyAuthorization должна обеспечивать авторизацию запроса AF и создание правил политики для PDU сессии, к которому привязан сеанс с AF. Услуга позволяет потребителю услуг NF подписываться/отписываться на уведомления о типе доступа и типе RAT, об идентификаторе PLMN и доступе к сетевой информации;

Npcf_BDTPolicyControl должна обеспечивать соблюдение правила базовой политики передачи данных и включает:

1) получение правил базовой политики передачи данных на основе запроса через NEF от AF;

2) обновление правил базовой политики передачи данных на основе выбора, предоставленного AF.

Npcf_UEPolicyControl должна обеспечивать потребителям услуг возможность управления правилами политики, ассоциированными с UE.

Npcf_EventExposure должна обеспечивать потребителям услуг возможность подписываться и получать уведомления о событиях PCF, связанных с группой UE или отдельными UE, объединенными DNN, S-NSSAI.

8.6. Функция отображения сетевых возможностей и событий (NEF) должна обеспечивать безопасное взаимодействие внешних платформ и приложений с опорной сетью 5GC. Для решения данной задачи NEF должна обеспечивать:

1) возможность платформам и приложениям подписываться на определённые события, генерируемые различными элементами сети, и получение уведомлений о возникновении следующих событий:

отсутствия соединения (от AMF);

данных о местоположении UE (от AMF);

доступности UE (от AMF, UDM (доступности для SMS));

изменения ассоциации SUPI-PEI (от UDM);

наличия роуминга в текущий момент (от UDM);

отсутствия связи на радиодоступе (от AMF);

возобновления связи с DNN (от AMF);

отсутствия информации о количестве UE в зоне обслуживания AF (от AMF);

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

обеспечения управления показателями QoS и правилами тарификации (PCC) по конкретным UE;

2) безопасную трансляцию информации от внешнего приложения в сеть 3GPP;

3) трансляцию внешней/внутренней информации при взаимодействии сетей;

4) взаимодействие с различными элементами, платформами и приложениями (или сетевыми функциями NFs) и поддержание множества прикладных программных интерфейсов API. При этом безопасность взаимодействия должна обеспечиваться посредством реализуемых NEF механизмов безопасности, включая аутентификацию и авторизацию соответствующих платформ и приложений;

5) сохранение информации, полученной от NF, в виде структурированных данных в UDR, посредством стандартного интерфейса Nudr;

6) обеспечение доступа к UDR, находящемуся в той же PLMN, что и NEF;

7) обеспечение поддержки функции PFD (Packet Flow Description). При этом функция PFD в NEF должна сохранять и извлекать PFD из UDR и по запросу предоставлять PFD в SMF.

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

8.6.1. NEF должна обеспечивать предоставление следующих услуг:

Nnef_EventExposure должна обеспечивать поддержку отображения произошедших событий;

Nnef_PFDManagement должна обеспечивать возможность создания, обновления или удаления данных описания потока пакетов PFD через NEF;

Nnef_ParameterProvision должна обеспечивать представление информации, которая используется для UE в 5GS;

Nnef_Trigger должна обеспечивать поддержку уведомления приложений на абонентском терминале о запросе со стороны прикладных функций;

Nnef_BDTPNegotiation должна обеспечивать согласование базовой политики передачи данных;

Nnef_TrafficInfluence должна обеспечивать управление маршрутизацией трафика;

Nnef_ChargeableParty должна обеспечивать запрос, определяющий сторону для оплаты сеанса данных UE;

Nnef_AFsessionWithQoS должна обеспечивать запрос сети связи для предоставления конкретного показателя QoS для сессии между UE и AF.

8.7. Функция хранения данных о сетевых функциях (NRF) должна поддерживать возможность обнаружения оказываемых услуг. При этом NRF, получив от конкретного экземпляра NF запрос на обнаружение требуемой NF, должна предоставлять информацию об обнаруженных NF запрашивающей NF.

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

Профиль экземпляра NF, содержащийся в NRF, включает следующую информацию:

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

2) тип сетевой функции;

3) идентификатор PLMN;

4) идентификатор(ы), связанный(е) с сетевым сегментом: S-NSSAI (Single Network Slice Selection Assistance Information), NSI ID;

5) полное доменное имя FQDN (Fully Qualified Domain Name) или IP-адрес сетевой функции;

6) информацию о производительности, пропускной способности сетевой функции;

7) информацию об авторизации услуг;

8) наименование поддерживаемых услуг;

9) информацию об адресации конкретного экземпляра NF и каждой поддерживаемой услуги;

10) идентификацию сохраненных данных/информации (для UDR);

11) параметры услуг;

12) иные параметры услуги (DNN, конечная точка уведомления для каждого типа уведомления, в получении которых заинтересована NF);

13) индикацию маршрутизации для UDM и AUSF;

14) сведения о GUAMI, в случае AMF;

15) идентификационные данные для зоны SMF, в случае UPF;

16) идентификатор группы UDM, диапазон(ы) SUPI, диапазон(ы) GPSI, диапазон(ы) идентификаторов внешней группы для UDM;

17) идентификатор группы UDR, диапазон(ы) SUPI, диапазон(ы) GPSI, диапазон(ы) идентификаторов внешней группы для UDR;

18) идентификатор группы AUSF, диапазон(ы) SUPI для AUSF.

Допускается развертывание NRF на различных уровнях при наличии в сети нескольких сетевых сегментов, при этом:

уровень PLMN (NRF включает информацию для всей PLMN);

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

уровень конкретного сегмента (NRF включает информацию, относящуюся к конкретному сегменту S-NSSAI).

NRF, находящиеся в роуминге могут быть развернуты в различных сетях связи, при этом:

NRF в гостевой PLMN (vNRF), включающие информацию для гостевой PLMN;

NRF в домашней PLMN (hNRF), с информацией для домашней PLMN, на которую ссылается vNRF через интерфейс N27.

8.7.1. NRF должна обеспечивать предоставление следующих услуг:

Nnrf_NFManagement должна обеспечивать регистрацию, отмену регистрации и обновление услуг NF, предоставлять потребителю услуг уведомления о новых зарегистрированных NF и услугах NF;

Nnrf_NFDiscovery должна обеспечивать потребителю услуг в описании зарегистрированных в NRF наборов экземпляров возможность обнаруживать функцию NF с конкретными услугами или требуемый тип NF;

Nnrf_AccessToken должна предоставлять информацию о наборах данных OAuth2 2.0 для авторизации NF.

8.8. UDM должна обеспечивать выполнение следующих функций:

1) генерацию данных для реализации протокола аутентификации и согласования ключей (далее - протокола 3GPP AKA) на базе набора криптографических алгоритмов S3G-256, предусмотренного рекомендациями по стандартизации Р 1323565.1.003-2017*(4), с использованием для взаимной аутентификация абонента и сети связи средств криптографической защиты информации;

2) реализацию функции расшифрования закрытого идентификатора подписки (SIDF);

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

4) хранения и управления идентификаторами подписки (SUPI);

5) авторизации доступа на основе договора об оказании услуг связи абонента (например, ограничения роуминга);

6) управления регистрацией NF, обслуживающих абонента;

7) поддержки непрерывности услуги/сеанса связи (хранение назначенных для текущих сеансов связи SMF/DNN);

8) обеспечения разрешенного перехвата;

9) управления доставкой SMS сообщений;

10) взаимодействия с HSM-SIDF, реализующим криптографические преобразования по расшифрованию значения SUPI из SUCI, в соответствии с Приложением N 7 к Правилам;

11) взаимодействия с отдельным аппаратным модулем безопасности HSM, выполняющим криптографические функции по выработке аутентификационных векторов c использованием набора криптографических алгоритмов S3G-256, в соответствии с протоколом, приведенным в приложении N 8 к Правилам.

Для оборудования коммутации стандарта 5G/IMT-2020, обеспечивающего выполнение функции управления унифицированными данными (UDM), устанавливаются требования к:

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

б) протоколу взаимодействия UDM с отдельным аппаратным модулем безопасности HSM-SIDF, выполняющим криптографические функции по расшифрованию значения SUPI из SUCI (приложение N 7 к Правилам);

в) протоколу взаимодействия UDM с отдельным аппаратным модулем безопасности HSM, выполняющим криптографические функции аутентификации и идентификации абонентов (Приложение N 8 к Правилам).

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

UDM должна находиться в домашней сети абонентов, которых она обслуживает;

UDM должна получать доступ к информации UDR, расположенной в той же PLMN.

8.8.1. UDM должна обеспечивать предоставление следующих услуг.

Nudm_UECM должна предоставлять потребителю услуг NF информацию, относящуюся к транзакции UE, разрешать ему регистрироваться и отменять регистрацию своих данных в UDM при обслуживании UE, а также позволять потребителю услуг NF обновлять контекстную информацию для UE в UDM;

Nudm_SDM должна позволять потребителю услуг NF получать данные об абоненте и предоставлять указанные обновленные данные этого абонента потребителю услуг NF;

Nudm_UEAuthentication должна предоставлять потребителю услуг по запросу NF возможность получать данные аутентификации абонента и направлять их в UDM;

Nudm_EventExposure должна обеспечить потребителю услуг NF получение информации об определенных событиях (действиях) абонента;

Nudm_ParameterProvision должна предоставлять информацию, которая доступна для UE в UDM.

8.9. Хранилище унифицированных данных (UDR) должно поддерживать выполнение следующих функций:

1) поиска данных об абоненте в UDM и их хранения;

2) поиска данных политики в PCF и их хранения;

3) хранения и поиска структурированных данных;

4) использования приложений NEF.

Хранилище унифицированных данных UDR допускается размещать в каждой PLMN, при этом:

UDR, к которому обращается NEF, должно принадлежать только к PLMN, где размещается NEF;

UDR, к которому обращается UDM, должно принадлежать только к PLMN, где расположен UDM, если UDM поддерживает распределенную архитектуру;

UDR, к которому обращается PCF, должно принадлежать той же PLMN, где расположен PCF;

UDR находится в той же PLMN, что и функции NF, являющиеся потребителями его услуг.

Каждая NF, получающая доступ к UDR через интерфейс Nudr, должна добавлять, изменять, обновлять или удалять только те данные, которые ей разрешено. Это разрешение обеспечивается UDR по каждому списку данных и типу функции NF и по каждому конкретному UE.

Выбор требуемого UDR должен осуществляться по следующим параметрам:

SUPI или GPSI, или идентификатору внешней группы;

идентификатору набора данных (Data Set Identifier), хранящемуся в UDR. При этом установлены три типа данных: данные подписки, данные политики и данные отображения сетевых возможностей и событий, при совместной реализации UDR и UDSF.

8.9.1. UDR должна обеспечивать предоставление следующих услуг.

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

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

1) идентификатор набора данных должен гарантированно идентифицировать запрашиваемый набор данных в UDR;

2) идентификатор подмножества данных должен гарантированно идентифицировать подмножество данных в каждом наборе данных;

3) ключи данных и дополнительные ключи представлены в таблице, приведенной ниже.

Таблица.

Набор данных	Подмножество данных	Ключ данных	Дополнительный ключ
Данные подписки	Доступ и мобильность	SUPI
	Выбор SMF	SUPI
	Контекст UE в SMF	SUPI	ID PDU сессии или DNN
	Данные для управления SMS	SUPI
	Данные SMS	SUPI
	Данные для управления сессией	SUPI	S-NSSAI
			DNN
	Данные для выбора сегмента	SUPI
Данные приложений	Описание потока пакетов	Application ID

8.10. N3IWF должна обеспечивать выполнение следующих функций:

1) поддержки создания туннеля IPsec с UE: N3IWF взаимодействует с UE через NWu с использованием протоколов IKEv2/IPsec и передает через N2 к AMF информацию, необходимую для аутентификации UE и авторизации доступа к сети 5G;

2) завершения интерфейсов N2 и N3 для плоскости управления и плоскости передачи данных;

3) ретрансляции сигналов плоскости управления NAS (N1) по восходящей и нисходящей линиям связи между UE и AMF;

4) обработки сигнализации от SMF (переданной AMF по N2), связанной с PDU сессиями и QoS;

5) создания ассоциации безопасности IPsec (IPsec SA) для поддержки PDU сессии;

6) ретрансляции пакетов плоскости передачи данных по восходящей и нисходящей линии связи между UE и UPF: декапсуляцию/инкапсуляцию пакетов для туннелирования IPSec в N3;

7) обеспечения показателей QoS для пакетов интерфейса N3 с учетом требований QoS, полученных по N2;

8) маркировки пакетов плоскости передачи данных на интерфейсе N3 в восходящей линии связи;

9) создания точки локальной мобильности в сетях доступа non-3GPP;

10) выбора AMF.

8.11. Функция хранения неструктурированных данных (UDSF) должна поддерживать хранение и поиск информации для NF.

UDSF, в которой хранятся данные (контексты) сетевой функции, должна относиться к той же PLMN, что и сетевая функция. Плоскости управления (CP) нескольких NF должны совместно использовать UDSF для хранения собственных неструктурированных данных или каждая из них должна иметь собственную UDSF.

Сетевые функции NF должны взаимодействовать с системами хранения данных UDSF через интерфейс N18.

8.12. Для передачи SMS через NAS функция управления доставкой коротких сообщений (SMSF) должна поддерживать:

проверку подписки на услугу SMS;

трансляцию/управление SM (SM-RP/SM-CP) с UE;

трансляцию SM от UE к SMS-GMSC/IWMSC/SMS-Router;

трансляцию SM от SMS-GMSC/IWMSC/SMS-Router к UE;

формирование CDR связанного с SMS;

обеспечение разрешенного перехвата;

уведомление AMF и SMS-GMSC о том, что UE недоступна для передачи SMS (для последующего уведомления UDM);

выбор соответствующего домена для повторной попытки доставки сообщения MT SM, если доставка через SMSF не удалась.

8.13. NSSF должна обеспечивать выполнение следующих функций:

определение конфигурации сетевого сегмента для обслуживания UE в домашней или обслуживающей сети;

определение информации NSSAI (Network Slice Selection Assistance Information), которая должна предоставляться обслуживающей сетью и выполнять сопоставление с S-NSSAI из подписки UE;

формирование информации NSSAI для UE и выполнять сопоставление с S-NSSAI из подписки;

определение набора AMF, которые должны использоваться для обслуживания UE.

NSSF должна обеспечивать предоставление услуг для AMF в рамках домашней сети и (или) NSSF обслуживающей сети через интерфейс Nnssf (N22, N31).

8.14. 5G-EIR должна определять наличие PEI в черном списке.

8.15. LMF ДОЛЖНА ОБЕСПЕЧИВАТЬ ОПРЕДЕЛЕНИЕ МЕСТОПОЛОЖЕНИЯ ДЛЯ UE.

8.16. Прокси-сервер защиты сообщений (SEPP) должен обеспечивать выполнение следующих функций:

фильтрации сообщений и применение правил политики на интерфейсах плоскости управления между PLMN;

сокрытия топологии сети.

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

8.17. Функция анализа сетевых данных (NWDAF) должна осуществлять анализ сетевых данных для сегментов сети и предоставлять результаты тем NF, которые на них подписаны.

Приложение N 3
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N_______

Требования к интерфейсам и контрольным точкам сетевых функций 5GC

1. Для выполнения услуг сетевые функции должны предоставлять следующие интерфейсы (Service Based Interfaces, SBI):

Namf: предоставляется AMF;

Nsmf: предоставляется SMF;

Nnef: предоставляется NEF;

Npcf: предоставляется PCF;

Nudm: предоставляется UDM;

Naf: предоставляется AF;

Nnrf: предоставляется NRF;

Nnssf: предоставляется NSSF;

Nausf: предоставляется AUSF;

Nudr: предоставляется UDR;

Nudsf: предоставляется UDSF;

N5g-eir: предоставляется 5G-EIR;

Nlmf: предоставляется LMF.

2. Для взаимодействия сетевых функций должны использоваться контрольные точки (далее - КТ).

2.1. КТ, которые должны использоваться при обслуживании доступа 3GPP:

N1: КТ между UE и AMF;

N2: КТ между (R) AN и AMF;

N3: КТ между (R) AN и UPF;

N4: КТ между SMF и UPF;

N6: КТ между UPF и сетью передачи данных;

N9: КТ между двумя UPF;

N5: КТ между PCF и AF;

N7: КТ между SMF и PCF;

N24: КТ между PCF гостевой сети и PCF домашней сети;

N8: КТ между UDM и AMF;

N10: КТ между UDM и SMF;

N11: КТ между AMF и SMF;

N12: КТ между AMF и AUSF;

N13: КТ между UDM и AUSF;

N14: КТ между двумя AMF;

N15: КТ между PCF и AMF в случае сценария без роуминга, PCF гостевой сети и AMF в случае роуминга;

N16: КТ между двумя SMF (между SMF гостевой сети и SMF домашней сети в случае роуминга);

N17: КТ между AMF и 5G-EIR;

N18: КТ между любой NF и UDSF;

N22: КТ между AMF и NSSF;

N26 (при наличии): КТ между AMF и оборудованием коммутации подвижной радиотелефонной связи стандарта LTE;

N27: КТ между NRF гостевой сети и NRF домашней сети;

N31: КТ между NSSF в посещаемой сети и NSSF в домашней сети;

КТ должны быть задействованы между SMF и системой учета стоимости (CDF и OCS);

N32: КТ между SEPP гостевой сети и SEPP в домашней сети;

N33: КТ между NEF и AF.

N70 (при наличии): РТ между SBI совместимым I/S-CSCF и SBI совместимым HSS;

N71 (при наличии): РТ между SBI совместимыми IMS AS и SBI совместимым HSS.

2.2. КТ, которые должны использоваться при обслуживании доступа Non-3GPP:

N2, N3, N4, N6

Y1: КТ между UE и доступом Non-3GPP.

Y2: КТ между сетью с недоверенным доступом Non-3GPP и N3IWF для передачи трафика NWu.

NWu: КТ между UE и N3IWF для установления защищенного туннеля(ей) между UE и N3IWF, для передачи данных плоскости управления и плоскости передачи данных.

3. Стек протоколов, используемых сетевыми функциями на интерфейсах Namf, Nsmf, Nudm, Nnrf, Nnssf, Nausf, Nnef, Nsmsf, Nudr, Npcf, N5g-eir, Nlmf, Nudsf, Nhss_ims для оказания услуг (SBI) приведен на рисунке 1.

Рисунок1. Стек протоколов для интерфейсов SBI

3.1. Для защиты на транспортном уровне все NF 5GC должны поддерживать протокол защиты транспортного уровня TLS в соответствии с рекомендациями Р 1323565.1.020-2020*(5) и Р 1323565.1.030-2020*(6).

3.2. В качестве формата представления прикладных данных должен использоваться текстовый формат JavaScript Object Notation (JSON).

3.3. В качестве языка определения интерфейса (IDL) SBI должна использоваться спецификация OpenAPI.

3.4. Требования к HTTP/2.

3.4.1. Между NF 5GC взаимодействие должно осуществляться с помощью запросов/ответов (клиент/сервер) одного потока HTTP. Целевой ресурс должен идентифицироваться с помощью URI (URI ресурса, URI пользовательской операции или URI обратного вызова).

3.4.2. Каждое сообщение HTTP должно включать:

стартовую строку (Starting line);

заголовок (Headers);

тело сообщения (Message Body) (опционально).

3.4.3. Стартовая строка запроса должна включать: тип запроса (далее - Метод), URI, HTTP/Версия.

3.4.3.1 Метод должен принимать следующие значения:

GET получение ресурса;

POST создание ресурса;

PUT обновление ресурса;

DELETE удаление ресурса.

3.4.3.2 URI должно определять путь к запрашиваемому ресурсу.

3.4.3.3 HTTP/Версия пара разделённых точкой цифр.

3.4.4. Стартовая строка ответа должна включать: HTTP/Версия, код состояния, комментарий.

HTTP/Версия представляет пару разделённых точкой цифр, как в запросе.

Код состояния (Status Code) должен содержать три цифры, которые определяют содержимое сообщения.

Комментарий (Reason Phrase) представляет текстовое короткое пояснение к коду ответа для абонента и не является обязательным.

3.4.5. Стандартные заголовки HTTP/2, обработка и формирование которых должна обязательна для SBI.

3.4.5.1 Имена стандартных заголовков запросов должны содержать:

Accept;

Accept-Encoding;

Content-Length;

Content-Type;

User-Agent;

Cache-Control;

If-Modified-Since;

If-None-Match;

If-Match;

Via;

Authorization.

3.4.5.2 Имена стандартных заголовков ответов должны содержать:

Content-Length;

Content-Type;

Location;

Retry-After;

Content-Encoding;

Cache-Control;

Age;

Last-Modified;

ETag;

Via;

Allow;

WWW-Authenticate.

3.4.6. Обязательные поля заголовков HTTP для NF 5GC приведены в таблице N 1.

Таблица N 1. 

Имя	Описание
3gpp-Sbi-Message-Priority	Используется для указания приоритета сообщения HTTP/2 на интерфейсах, используемых для оказания услуг 3GPP. Этот заголовок включается в сообщения HTTP/2, когда необходимо передать приоритет сообщения
3gpp-Sbi-Callback	Используется, чтобы указать, является ли сообщение HTTP/2 обратным (например, уведомление). Этот заголовок включается в сообщения HTTP POST для обратных сообщений к потребителю(ям) услуг NF в другой PLMN через SEPP

3.4.7. Коды состояний HTTP, используемые в ответах для SBI, приведены в таблице N 2.

Таблица N 2.

Коды состояний HTTP	HTTP метод
	DELETE	GET	PATCH	POST	PUT
1	2	3	4	5	6
100 Continue	N/A	N/A	N/A	N/A	N/A
200 OK (прим 1, прим 2)	SS	M	SS	SS	SS
201 Created	N/A	N/A	N/A	SS	SS
202 Accepted	SS	N/A	SS	SS	SS
204 No Content (NOTE 2)	M	N/A	SS	SS	SS
300 Multiple Choices	N/A	N/A	N/A	N/A	N/A
303 See Other	SS	SS	N/A	SS	SS
307 Temporary Redirect	SS	SS	SS	SS	SS
308 Permanent Redirect	SS	SS	SS	SS	SS
1	2	3	4	5	6
400 Bad Request	M	M	M	M	M
401 Unauthorized	M	M	M	M	M
403 Forbidden	M	M	M	M	M
404 Not Found	M	M	M	M	M
405 Method Not Allowed	SS	SS	SS	SS	SS
406 Not Acceptable	N/A	M	N/A	N/A	N/A
408 Request Timeout	SS	SS	SS	SS	SS
409 Conflict	N/A	N/A	SS	SS	SS
410 Gone	SS	SS	SS	SS	SS
411 Length Required	N/A	N/A	M	M	M
412 Precondition Failed	SS	SS	SS	SS	SS
413 Payload Too Large	N/A	N/A	M	M	M
414 URI Too Long	N/A	SS (примечание 3)	N/A	N/A	SS
415 Unsupported Media Type	N/A	N/A	M	M	M
429 Too Many Requests	M	M	M	M	M
500 Internal Server Error	M	M	M	M	M
501 Not Implemented	SS	SS	SS	SS	SS
503 Service Unavailable	M	M	M	M	M
504 Gateway Timeout	SS	SS	SS	SS	SS
ПРИМЕЧАНИЕ: 1. Ответ "200 OK", используемый в SBI, должен содержать тело сообщения. 2. Если NF, действующая в качестве HTTP-клиента, получает код ответа 2xx, который отсутствует в таблице, NF обрабатывает полученный ответ 2xx как: "204 Нет содержимого", если ответ 2xx не содержит тела; или как "200 OK", если ответ 2xx содержит тело. 3. Если метод GET включает в себя какой-либо параметр запроса, NF, выступающая в качестве клиента HTTP, должна поддерживать код состояния "414 URI Too Long". М обязательная поддержка обработки кода всеми NF 3GPP; SS требование к обработке кода состояния HTTP, которое зависит от определения конкретного API; N/A код состояния HTTP не используется для конкретного метода HTTP в NF 3GPP.

3.4.8. Коды и причины ошибок протоколов и приложений, которые NF должны включать в HTTP-ответ, приведены в таблице N 3.

Таблица N 3.

Ошибки протоколов и приложений	Коды состояний HTTP	Описание
1	2	3
INVALID_API	400 Bad Request	HTTP запрос в URI содержит неподдерживаемое имя или версию API
INVALID_MSG_FORMAT	400 Bad Request	HTTP запрос имеет недопустимый формат
INVALID_QUERY_PARAM	400 Bad Request	HTTP запрос в URI содержит неподдерживаемый параметр
MANDATORY_QUERY_PARAM_INCORRECT	400 Bad Request	Получен некорректный параметр обязательного HTTP метода в URI
OPTIONAL_QUERY_PARAM_INCORRECT	400 Bad Request	Получен некорректный параметр опционального HTTP метода в URI
MANDATORY_IE_INCORRECT	400 Bad Request	Обязательные или условные информационные элементы в HTTP методе имеют некорректное значение
OPTIONAL_IE_INCORRECT	400 Bad Request	В структуре данных HTTP метода получено семантически неверное значение необязательного IE, которое мешает успешной обработке запроса на обслуживание
MANDATORY_IE_MISSING	400 Bad Request	IE, который определен как обязательный или условный, не включен в запрос
UNSPECIFIED_MSG_FAILURE	400 Bad Request	Запрос отклонен из-за неуказанной ошибки клиента
MODIFICATION_NOT_ALLOWED	403 Forbidden	Запрос отклонен, поскольку содержащиеся в нем инструкции по модификации IE пытаются изменить элемент, который не может быть изменен
SUBSCRIPTION_NOT_FOUND	404 Not Found	Запрос на изменение или удаление подписки отклонен, поскольку подписка в NF не найдена
RESOURCE_URI_STRUCTURE_NOT_FOUND	404 Not Found	Запрос отклонен, поскольку фиксированная часть URI не найдена в NF
INCORRECT_LENGTH	411 Length Required	Запрос отклонен из-за неправильного значения поля заголовка Content-length
NF_CONGESTION_RISK	429 Too Many Requests	Запрос отклонен из-за чрезмерного трафика, который может привести к перегрузке
INSUFFICIENT_RESOURCES	500 Internal Server Error	Запрос отклонен из-за недостатка ресурсов
UNSPECIFIED_NF_FAILURE	500 Internal Server Error	Запрос отклонен по неизвестной причине
SYSTEM_FAILURE	500 Internal Server Error	Запрос отклонен из-за системной ошибки в NF
NF_CONGESTION	503 Service Unavailable	NF испытывает перегрузку и выполняет перезагрузку, что не позволяет обрабатывать запрос

3.5. Требования к параметрам интерфейсов к сети передачи данных с использованием контроля несущей и обнаружением коллизий приведены в приложении 25 к Правилам N 112-06.

4. Требования к протоколам плоскости управления, используемым на контрольной точке N 2.

4.1. Протоколы плоскости управления контрольной точки N2 между AN и AMF приведены на рисунке 2.

Рисунок 2.

4.2. Требования к параметрам интерфейсов к сети передачи данных с использованием контроля несущей и обнаружением коллизий приведены в приложении N 25 к Правилам N 112-06.

5. Требования к протоколам плоскости управления между UE и AMF, UE и SMF.

5.1. Протоколы плоскости управления между UE и AMF, UE и SMF приведены на рисунке 3.

Рисунок 3.

5.2. Требования к параметрам интерфейсов сети передачи данных с использованием контроля несущей и обнаружением коллизий приведены в приложении N 25 к Правилам N 112-06.

6. Требования к протоколам плоскости управления между AN и SMF.

6.1. Стек протоколов плоскости управления между AN и SMF приведен на рисунке 4.

Рисунок 4.

Необходимую информацию NG-AP (N2 SM) AMF должна транслировать между AN и SMF по N 11.

6.2. Требования к параметрам интерфейсов сети передачи данных с использованием контроля несущей и обнаружением коллизий приведены в приложении N 25 к Правилам N 112-06.

7. Требования к протоколам плоскости управления для ненадежного доступа Non-3GPP

7.1. Протоколы плоскости управления для взаимодействия с сетями недоверенного доступа Non-3GPP перед установкой ассоциации безопасности сигнализации IPsec (SA) приведены на рисунке 5.

Рисунок 5.

7.2. Протоколы плоскости управления для взаимодействия с сетями недоверенного доступа Non-3GPP после установки ассоциации безопасности сигнализации IPsec (SA) приведены на рисунке 6.

Рисунок 6.

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

8.1. Стек протоколов плоскости передачи данных между AN и UPF приведен на рисунке 7.

Рисунок 7.

8.1.1. Уровень PDU должен передавать пакеты данных абонента между UE и DN с помощью PDU сессии.

8.1.2. Требования к параметрам интерфейсов к сети передачи данных с использованием контроля несущей и обнаружением коллизий приведены в приложении N 25 к Правилам N 112-06.

8.1.3. Протокол туннелирования GPRS для плоскости передачи данных (GTP U) должен использоваться для туннелирования пакетов данных между 5G-AN и UPF (N3) и между UPF (N9), а также на интерфейсе N4.

Приложение N 4
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от ______________N______

Требования к реализации функций высокого уровня при обслуживании UE

1. Для обеспечения непрерывности обслуживания UE PLMN должна выполнить процедуру определения местоположения UE.

2. Процедура аутентификации должна инициироваться сетью связи в рамках любой процедуры, устанавливающей соединение NAS между UE и сетью связи.

3. Для проверки PEI сеть связи должна запросить 5G-EIR.

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

1) периодически (период задается оператором);

2) при перемещении в новую зону обслуживания.

В результате процедуры регистрации идентификатор AMF, обслуживающей UE, должен быть зарегистрирован в UDM.

5. Для управления соединением между UE и сетью должны быть выполнены функции установления и освобождения сигнального соединения NAS между UE и AMF через интерфейс N1, а также установления и отмены соединения между AN и AMF через интерфейс N2 для этого UE.

6. Базовая сеть должна определить ограничения мобильности UE на основе информации подписки UE, местоположения UE и правил политики обслуживающей сети.

Ограничения мобильности UE включают:

ограничение доступных технологий радиодоступа 3GPP (3GPP RAT),

запретную зону,

ограничения зон обслуживания,

ограничения базовых сетей, разрешенных для подключения.

7. Оборудование 5GC должно обеспечивать возможность передачи данных между UE и сетью передачи данных с идентификатором DNN.

7.1. 5GC должна поддерживать следующие типы PDU сессий: IPv4, IPv6, IPv4v6, Ethernet неструктурированный.

7.2. PDU сессии устанавливаются по запросу UE, модифицируются по запросу UE и 5GC и освобождаются по запросу UE и 5GC с использованием сигнализации NAS SM, которой обмениваются по интерфейсам N1, N11 между UE и SMF.

7.3. По запросу AF 5GC должно активировать приложение в UE для установления PDU сессии с конкретным DNN.

7.4. SMF должна обеспечивать проверку запросов UE на создание PDU сессии на соответствие договору об оказании услуг связи, а также запрашивать и получать уведомления от UDM об обновлениях данных договора об оказании услуг связи в части касающейся SMF, включая:

разрешенные типы PDU сессий и тип PDU сессии по умолчанию;

разрешенные режимы SSC и режим SSC по умолчанию;

информацию о QoS: Session-AMBR из подписки, 5QI по умолчанию и ARP по умолчанию;

статический IP-адрес/префикс;

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

характеристики тарификации, которые связаны с PDU сессией.

7.5. UE может запросить перемещение PDU сессии между доступами 3GPP и non-3GPP. Решение о перемещении PDU сессии между сетями доступа 3GPP и сетями доступа non-3GPP должен приниматься UE для каждой PDU сессии независимо.

7.6. В сообщении запроса на установление PDU сессии, отправляемом в сеть связи, UE должен представить идентификатор PDU сессии. Идентификатор PDU сессии является уникальным для каждой UE и используется для уникальной идентификации одной из PDU сессий UE. Идентификатор PDU сессии хранится в UDM.

7.7. Атрибуты PDU сессии:

S-NSSAI;

DNN;

тип PDU сессии;

режим SSC;

идентификатор PDU сессии.

8. Модель качества обслуживания в 5G (5G QoS).

8.1. Модель 5G QoS обеспечивает обслуживание:

потоков, которые требуют гарантии определенной скорости передачи данных (потоки GBR QoS);

потоков, которые не требуют гарантированной скорости (потоки non-GBR QoS).

Для идентификации QoS потока в системе 5GC должен использоваться идентификатор QoS потока QFI (QoS Flow ID).

QFI должен передаваться на интерфейсах N3 и N9 в заголовке инкапсуляции без изменений из конца в конец. QFI должен задаваться для всех типов PDU сессий. QFI уникален в пределах PDU сессии и соответствует идентификатору качества обслуживания 5G 5QI.

8.2. Для любого потока QoS характеризуется:

профилем QoS, предоставляемым в сеть доступа из SMF;

одним или несколькими правилами QoS, которые предоставлены SMF для UE;

одним или несколькими правилами обработки пакетов (PDR) для UL и DL, предоставленных SMF для UPF.

8.2.1. Требования к параметрам профиля QoS:

1) для всех потоков:

идентификатор качества обслуживания 5G (5QI). 5QI используется в качестве ссылки на характеристики 5G QoS;

приоритет назначения и удержания ресурсов канала (ARP). Диапазон уровней приоритета ARP от 1 до 15, где 1 наивысший уровень приоритета;

2) для потоков non-GBR QoS профиль должен включать параметр атрибута формирования QoS (RQA)

3) для каждого потока GBR QoS профиль должен содержать следующие параметры:

гарантированная скорость передачи данных потока (GFBR) для UL и DL;

максимальная битовая скорость потока (MFBR) для UL и DL;

4) для потоков GBR QoS профиль должен содержать следующие параметры:

управление уведомлениями о выполнении GBR QoS для потока;

максимальная скорость потери пакетов для UL и DL.

8.3. Требования к управлению QoS потоков.

Для потоков non-GBR QoS, когда используется заданный 5QI значение 5QI должно использоваться в качестве QFI QoS потока.

Для всех иных случаев (включая потоки GBR QoS и non-GBR) должен использоваться динамически назначенный QFI.

8.4. Требование к управлению QoS при DL трафике.

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

1) UPF разделяет трафик плоскости передачи данных на потоки QoS на основе PDR;

2) UPF обеспечивает Session-AMBR и подсчет пакетов для тарификации;

3) UPF передает PDU сессии в одном туннеле между 5GC и (R)AN, UPF включает QFI в заголовок инкапсуляции. Кроме того, UPF в заголовок инкапсуляции включает указание для активации формирования QoS;

4) UPF выполняет маркировку пакетов транспортного уровня;

5) (R)AN на основе QFI правил QoS потока выделяет для PDU сессии соответствующие ресурсы доступа.

8.5. Требования к управлению QoS при UL трафике.

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

1) UPF проверяет, совпадают ли QFI в PDU UL с правилами QoS, предоставленными UE или сформированными UE;

2) UPF выполняет принудительное обеспечение Session-AMBR и подсчет пакетов для тарификации.

8.6. Требования к характеристикам 5G QoS.

Характеристики 5G QoS включают:

1) тип ресурса (GBR QoS, GBR для данных критических к задержкам или non-GBR);

2) уровень приоритета связанный с 5G. QoS указывает приоритет в планировании ресурсов среди QoS потоков;

3) верхнюю границу времени задержки пакета между UE и UPF (PDB);

4) коэффициент потерь пакетов;

5) окно усреднения (только для потоков GBR QoS) определяет время, в течение которого должны быть определены значения GFBR и MFBR;

6) максимальный объем пакета данных MDBV (только для типов ресурсов GBR, критичных к задержке), который обслуживается при заданной задержке пакета (для 5QI в 5G-AN PDB <= 20 мс).

Значения 5QI и соответствующие им характеристики представлены в Таблице.

Таблица.

Значение 5QI	Тип ресурса	Уровень приоритета по умолчанию	Packet Delay Budget	Коэфф. потерь пакетов	MDBV по умолча-нию (прим. 2)	Averaging window по умолчанию	Пример услуги
1	GBR прим.1	20	100 мс Примечание 11 и 13	10-2	N/A	2000 мс	Речь
2		40	150 мс Примечание 11 и 13	10-3	N/A	2000 мс	Видео (потоковое)
3 Примечание 14		30	50 мс Примечание 11 и 13	10-3	N/A	2000 мс	Игры в реальном времени, Сообщения V2X Распределение электроэнергии - среднее напряжение, Автоматизация процессов -мониторинг
4		50	300 мс Примечание 11 и 13	10-6	N/A	2000 мс	Видео (буферизированное)
65 Примечание 9 и 12		7	75 мс Примечание 11 и 13	10-2	N/A	2000 мс	Push To Talk для критически важных служб, UP (голос)
66 Приме чание12		20	100 мс Примечание 11 и 13	10-2	N/A	2000 мс	Push To Talk для не критически важных служб, UP (голос)
67 Примечание 12		15	100 мс Примечание 11 и 13	10-3	N/A	2000 мс	Критически важные службы, видео (UP)
75 Примечание 14

5	Non-GBR Примечание 1	10	100 мс Примечание 10, 13	10-6	N/A	N/A	IMS сигнализация
6		6	300 мс Примечание 10, 13	10-6	N/A	N/A	Видео (буферизованное) на основе TCP
7		70	100 мс Примечание 10, 13	10-3	N/A	N/A	Голос, видео (потоковое), игры в реальном времени
8		80	300 мс Примечание 13	10-6	N/A	N/A	Видео (буферизован-ное) на основе TCP
9		90
69 Примечание 9 и 12		5	60 мс Примечание 7 и 8	10-6	N/A	N/A	Сигнализация критических служб чувствительная к задержкам
70 Примечание 12		55	200 мс Примечание 7 и 10	10-6	N/A	N/A	Данные критических служб
79		65	50 мс Примечание 10 и13	10-2	N/A	N/A	Сообщения V2X (обмен данными между транспортными средствами элементами дорожной инфраструктуры и другими участниками движения)
80		68	10 мс Примечание 10 и 5	10-6	N/A	N/A	Приложения eMBB с низкой задержкой
82	GBR для данных крит. к задерж-кам	19 Примечание 4	10 мс	10-4	255 Б	2000 мс	Дистанционное управление, мниторинг
83		22 Примечание 4	10 мс Примечание 5	10-4	1354 Б Примечание 3	2000 мс	Дистанционное управление, мниторинг
84		24 Примечание 6	30 мс	10-5	1354 Б Примечание 3	2000 мс	Интеллектуаль-ные транспортные системы
85		21 Примечание 5	5 мс	10-5	255 Б	2000 мс	Распределение высоковольтного напряжения
Примечание: 1. Пакет, задержка которого превышает значение задержки PDB, не считается потерянным и не учитывается в PER. 2. PLMN, поддерживающая соответствующие 5QI, по умолчанию должна поддерживать MDBV. 3. Значение MDBV должно составлять 1354 байта, чтобы избежать фрагментации IP для GTP на основе IPv6, защищенного IPSec туннеля к узлу 5G-AN. 4. Для определения параметров задержки пакета на радиоинтерфейсе из заданного PDB для задержки между оконечным UPF и 5G-AN необходимо вычесть 1 мс. 5. Для определения параметров задержки пакета на радиоинтерфейсе из заданного PDB для задержки между оконечным UPF и 5G-AN необходимо вычесть 2 мс. 6. Для определения параметров задержки пакета на радиоинтерфейсе из заданного PDB для задержки между оконечным UPF и 5G-AN необходимо вычесть 5 мс. 7. Для критических служб UPF расположен вблизи диапазона 5G_AN (порядка 10 мс). Поэтому для определения параметров задержки пакета на радиоинтерфейсе из заданного PDB для задержки между оконечным UPF и 5G-AN необходимо вычесть 10 мс. 8. В режимах RRC Idle и RRC Connected требование PDB для этих 5QI может быть ослаблено (но не для значения более 320 мс) для первого пакета (пакетов) в пакете данных или сигнализации нисходящей линии связи для экономии заряда батареи (DRX). 9. Параметры 5QI-65 и 5QI-69 предполагается использовать совместно для предоставления критически важного сервиса Push-to-Talk. 10. В режимах RRC Idle и RRC Connected требование к PDB для этих 5QI может быть занижено для первого пакета (ов) в пакете данных или сигнализации нисходящей линии связи для экономии заряда батареи (DRX). 11. В режиме RRC Idle требование PDB для данных 5QI может быть занижено для первого(ых) пакета(ов) в нисходящей линии связи. 12. Параметр 5QI может быть установлено только по запросу со стороны сети связи. 13. Для определения параметров задержки пакета на радиоинтерфейсе из заданного PDB для задержки между оконечным UPF и 5G-AN необходимо вычесть 20 мс. 14. Параметр 5QI не поддерживается в данной версии спецификации.

9. Требования к сетевым сегментам.

9.1. Экземпляр сетевого сегмента в PLMN должен включать:

сетевые функции плоскости управления и плоскости передачи данных базовой сети.

сеть доступа, включая сеть радиодоступа NG и функции N3IWF для сети доступа non-3GPP.

5GC должно поддерживать процедуру выбора экземпляра сетевого сегмента в соответствии с информацией, идентифицирующей тип сегмента S-NSSAI. Правила NSSP, URSP и S-NSSAI в соответствии с договором об оказания услуг связи должны содержать значения S-NSSAI для реализуемых в домашней сети сегментов.

Сконфигурированная информация для выбора сегмента NSSAI должна предоставляться в UE.

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

Параметр S-NSSAI содержит информацию, определяющую выбор конкретного сетевого сегмента.

S-NSSAI включает:

тип сегмента/услуги (SST), который поддерживает определенные функции и услуги;

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

Стандарт реализует типовые сегменты, имеющие следующие значения SST:

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

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

3) сегмент, используемый для обработки массовых межмашинных соединений - mMTC (Massive Machine-Type Communications) или MIoT.

Если характеристики сегмента NSSAI в домашней сети отличаются от типовых, то обслуживание UE в таком сегменте гарантируется только в домашней сети.

Данные абонентской подписки пользователя включают одно или несколько значений S-NSSAI, которые используются по умолчанию.

За каждым значением S-NSSAI из подписки закрепляется одно или несколько значений DNN и одно DNN по умолчанию.

В случае роуминга UDM предоставляет в гостевую (визитную) S-NSSAI в соответствии с договором об оказании услуг связи.

10. Требования к поддержке виртуализации сетевых функций.

10.1. Поддержка архитектуры виртуализации на N2.

10.1.1. Описание ассоциации транспортного уровня сети (TNL).

AMF должна предоставлять узлу сети доступа требуемые параметры нагрузки для каждой ассоциации TNL.

AMF должна запрашивать узел сети доступа в целях добавления или удаления ассоциации TNL.

AMF должна иметь возможность указывать узлу сети доступа набор ассоциаций TNL, используемых для сигнализации, связанной с UE и набор ассоциаций TNL, используемых для сигнализации, не связанной с UE.

10.1.2. Обеспечение связи между ассоциацией NG-AP UE и конкретной TNLA для данного UE.

AMF должна иметь функцию возобновления связи NG-AP UE-TNLA (изменить ассоциацию TNL для UE) в состоянии CM-CONNECTED в требуемый момент времени.

10.1.3. Описание выбора ассоциации TNL для N2.

Для передачи сообщений N2 узел 5G-AN должен учитывать следующие факторы при выборе ассоциации TNL для AMF:

наличие кандидатов в ассоциации TNL;

параметры нагрузки кандидатов в ассоциации TNL.

Для инициирования поискового вызова AMF должен использует доступную ассоциацию TNL, предназначенную для обеспечения сигнализации, не связанной с UE.

Приложение N 5
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N______

Требования к параметрам профиля схемы защиты SUPI

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

1. Выработка временного (эфемерного) ключа осуществляется по протоколу Диффи-Хеллмана с использованием параметров и идентификаторов эллиптических кривых, определенных рекомендациями по стандартизации Р 1323565.1.024-2019*(7) (id-tc26-gost-3410-2012-256-paramSetA).

2. Выработка ключевого материала осуществляется с использованием функции PRF_IPSEC_PRFPLUS_GOSTR3411_2012_256, определенной рекомендациями по стандартизации Р 50.1.113-2016*(8), на основе хэш функции согласно ГОСТ Р 34.11-2012*(9).

3. Защита постоянного идентификатора SUPI обеспечивается с использованием алгоритма блочного шифрования согласно ГОСТ Р 34.12-2015 в режиме гаммирования и вычисления имитовставки согласно ГОСТ Р 34.13-2015.

Приложение N 6
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N______

Требования
к оборудованию коммутации стандарта 5G/IMT-2020 в режиме оказания услуг связи с использованием оборудования коммутации IMS

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

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

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

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

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

процедуру регистрации в серверах приложений IMS (IMS AS).

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

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

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

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

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

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

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

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

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

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

"01" - голос только через IMS;

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

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

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

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

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

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

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

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

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

Если UE меняет свой IP-адрес, например под влиянием изменений в ходе 5GС процедур, тогда UE должен перерегистрироваться в IMS.

Абонентские данные пользователя сети IMS хранятся в HSS IMS. Абонентские данные хранятся в виде единого профиля IMS подписки, несмотря на то что UE может получать доступ к IMS сети, используя разные сети доступа.

Для использования NF подсистемы IMS определены следующие сервис-ориентированные интерфейсы:

Npcf: Сервис-ориентированный интерфейс, предоставляемый PCF;

Nhss_ims: Сервис-ориентированный интерфейс, предоставляемый SBI совместимым HSS.

Для взаимодействия NF подсистемы IMS и 5GC должны использоваться следующие РТ:

N5: РТ между PCF и P-CSCF.

N70: РТ между SBI совместимым I/S-CSCF и SBI совместимым HSS.

N71: РТ между SBI совместимыми IMS AS и SBI совместимым HSS.

Приложение N 7
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N______

Требования к протоколу взаимодействия UDM с HSM-SIDF, выполняющим криптографические функции расшифрования значения SUPI из SUCI

1. UDM при реализации протокола взаимодействия с HSM-SIDF должен обеспечить:

1) отправку в HSM-SIDF запросов на:

получение постоянного идентификатора абонента SUPI;

обновление публичного ключа домашней сети Home Network Public Key;

2) установку для каждого отправленного запроса уникального адреса отправителя сообщения, действительного в течение времени не менее, чем установленного в соответствии с подпунктом 3 пункта 1 настоящего приложения, согласно протоколу взаимодействия 4 уровня (транспортного протокола передачи дейтаграмм пользователя UDP);

3) задание максимального времени ожидания ответа от HSM-SIDF для отправляемых запросов.

2. HSM-SIDF при реализации протокола взаимодействия с UDM должен обеспечить:

1) принятие от UDM корректных запросов на:

получение постоянного идентификатора подписки SUPI;

обновление публичного ключа домашней сети Home Network Public Key;

2) выполнение криптографических преобразований для:

расшифрования постоянного идентификатора подписки SUPI;

формирования и подписания публичного ключа домашней сети Home Network Public Key и идентификатора публичного ключа домашней сети Network Public Key Identifier;

3) отправку в UDM ответов с постоянным идентификатором подписки SUPI и обновленными публичным ключом домашней сети Home Network Public Key и идентификатором публичного ключа домашней сети Network Public Key Identifier;

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

5) отказ в ответе при поступлении от UDM некорректного запроса;

3. Реализация протокола взаимодействия 4 уровня должна осуществляться с учетом следующих требований:

1) для адресации запросов и ответов согласно протоколу взаимодействия 4 уровня должны использоваться UDP-порты из диапазона 49152-65535;

2) адреса получателя ответов и отправителя ответов согласно протоколу взаимодействия 4 уровня должны устанавливаться одинаковыми в конфигурации UDM и HSM-SIDF соответственно;

3) информация, передаваемая в сообщениях согласно протоколу взаимодействия 4 уровня между UDM и HSM-SIDF, не должна передаваться в открытом виде через сети общего доступа.

4. Для взаимодействия UDM с HSM-SIDF должны использоваться следующие сообщения:

1) De-Concealing Crypto Request, DCR - запрос со стороны UDM на получение постоянного идентификатора абонента SUPI по закрытому идентификатору подписки SUCI.

Содержание информационных элементов сообщения De-Concealing Crypto Request, DCR приведено в таблице 1.

Таблица 1 - Содержание информационных элементов сообщения De-Concealing Crypto Request, DCR

Информационный элемент	Содержание информационного элемента
Code	Код сообщения UDM. Длина: 48 битов.
SUCI	Закрытый идентификатор подписки SUCI. Длина: 53 байта.

2) De-Concealing Crypto Answer, DCA - ответ HSM-SIDF с постоянным идентификатором абонента SUPI.

Содержание информационных элементов сообщения De-Concealing Crypto Answer, DCA приведено в таблице N 2.

Таблица 2 - Содержание информационных элементов сообщения De-Concealing Crypto Answer, DCA

Информационный элемент	Содержание информационного элемента
Code	Код сообщения HSM-SIDF. Длина: 48 битов.
SUPI	Постоянный идентификатор абонента SUPI Длина: 5 байтов
FUPK	Указатель обновления публичного ключа домашней сети Длина: 8 битов.
DCA-Filler	Заполнитель, обеспечивающий выравнивание длины ответа по длине соответствующего запроса. Длина: 47 байтов

3) Updating-PK Crypto Request, UPKCR - запрос со стороны UDM на обновление публичного ключа домашней сети Home Network Public Key для абонента с идентификатором ключа Kid.

Содержание информационных элементов сообщения Updating-PK Crypto Request, UPKCR приведено в таблице 3.

Таблица 3 - Содержание информационных элементов сообщения Updating-PK Crypto Request, UPKCR

Информационный элемент	Содержание информационного элемента
Code	Код сообщения UDM. Длина: 48 битов.
Kid	Идентификатор ключа Kid абонента, который хранится к UDM. Длина: 128 битов.
UPKCR-Filler	Заполнитель, обеспечивающий выравнивание длины запроса по длине соответствующего ответа. Длина: 1160 битов

4) Updating-PK Crypto Answer, UPKCA - ответ HSM-SIDF с обновленными публичным ключом домашней сети Home Network Public Key и идентификатором публичного ключа домашней сети Network Public Key Identifier, подписанными секретным ключом домашней сети Home Network Private Key и зашифрованными на публичном ключе абонента с идентификатором ключа Kid.

Содержание информационных элементов сообщения Updating-PK Crypto Answer, UPKCA приведено в таблице 4.

Таблица 4 - Содержание информационных элементов сообщения Updating-PK Crypto Answer, UPKCA

Информационный элемент	Содержание информационного элемента
Code	Код сообщения HSM-SIDF. Длина: 48 битов.
UPK	Обновленные публичный ключ домашней сети (Home Network Public Key) и идентификатор публичного ключа домашней сети (Network Public Key Identifier), подписанные секретным ключом домашней сети (Home Network Private Key) и зашифрованные на публичном ключе абонента с идентификатором ключа Kid. Длина: 1288 битов.

5. Значения кодов сообщений при взаимодействии UDM с HSM-SIDF должны соответствовать значениям, приведенным в таблице 5.

Таблица 5 - Значения кодов сообщений при взаимодействии UDM с HSM-SIDF

Сообщение	Аббревиатура	Значение кода сообщение Code
De-Concealing Crypto Request	DCR	16 десятичное
De-Concealing Crypto Answer	DCA	32 десятичное
Updating-PK Crypto Request	UPKCR	64 десятичное
Updating-PK Crypto Answer	UPKCA	96 десятичное

Приложение N 8
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N______

Требования к протоколу взаимодействия UDM с отдельным аппаратным модулем безопасности HSM, выполняющим криптографические функции аутентификации и идентификации абонентов

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

1.1. Запрос со стороны UDM аутентификационной информации (Authentication Crypto Request - ACR).

Содержание информационных элементов, используемых в данном сообщении, приведено в таблице 1.

Таблица N 1 - Содержание информационных элементов в сообщении Authentication Crypto Request - ACR

Информационный элемент	Содержание информационного элемента
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
Kid	Информационный элемент Kid должен содержать идентификатор ключа Kid, который хранится в UDM. Длина должна быть 128 бит.
AMF	Информационный элемент AMF (Authentication management field), предусмотренный спецификацией ETSI TS 133 102. Длина должна быть 16 бит.
SQN	Информационный элемент SQN (sequence number), предусмотренный спецификацией ETSI TS 133 102. Длина должна быть 48 бит.
AIR-Filler	Информационный элемент должен обеспечивать превышение длиной запроса длины соответствующего ему ответа. Длина должна быть 448 бит.

1.2. Ответ HSM с аутентификационной информацией (Authentication Crypto Answer - ACA).

Содержание информационных элементов, используемых в данном сообщении, приведено в таблице 2.

Таблица 2 - Содержание информационных элементов в сообщении Authentication Crypto Answer - ACA

Информационный элемент	Содержание информационного элемента
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
Authentication Vector	Информационный элемент Authentication Vector (AV), предусмотренный спецификацией ETSI TS 133 102. Длина должна быть 576 бит.

1.3. Запрос со стороны UDM аутентификационной информации при ресинхронизации (Resynchronization Crypto Request - RCR).

Содержание информационных элементов, используемых в данном сообщении, приведено в таблице 3.

Таблица 3 - Содержание информационных элементов в сообщении Resynchronization Crypto Request - RCR

Информационный элемент	Содержание информационного элемента
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
Kid	Информационный элемент Kid должен содержать идентификатор ключа Kid, который хранится в UDM. Длина должна быть 128 бит.
RAND	Информационный элемент RAND должен содержать RAND, предусмотренный спецификацией ETSI TS 133 102. Длина должна быть 128 бит.
Conc (SQN MS)	Информационный элемент Conc(SQN MS) должен содержать Conc(SQNMS), предусмотренный спецификацией ETSI TS 133 102. Длина должна быть 48 бит.

1.4. Ответ HSM с аутентификационной информацией при ресинхронизации (Resynchronization Crypto Answer - RCA).

Содержание информационных элементов, используемых в данном сообщении, приведено в таблице 4.

Таблица 4 - Содержание информационных элементов в сообщении Resynchronization Crypto Answer - RCA

Информационный элемент	Содержание информационного элемента
Code	Информационный элемент Code должен содержать код сообщения HSM. Длина должна быть 48 бит.
XMACS	Информационный элемент должен содержать криптографически защищенную имитовставку XMACS, предусмотренную спецификацией ETSI TS 133 102. Длина должна быть 64 бит.
SQN MS	Информационный элемент должен содержать SQN MS, предусмотренный спецификацией ETSI TS 133 102. Длина должна быть 48 бит.

2. UDM при реализации протокола взаимодействии с HSM должен обеспечить:

2.1. Отправку запроса в HSM для генерации данных аутентификации;

2.2. Установку для каждого отправленного запроса уникального адреса отправителя сообщения, действительного в течение времени не менее, чем установленного в соответствии с пунктом 2.3 настоящего приложения, согласно протоколу взаимодействия 4 уровня (транспортного протокола передачи дейтаграмм пользователя - UDP);

2.3. Задание максимального времени ожидания ответа от HSM для отправляемых запросов.

3. HSM при реализации протокола взаимодействии с UDM должен обеспечить:

3.1. Принятие от UDM корректного запроса для выработки данных аутентификации, обработку запроса и передачу ответа в UDM;

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

3.3. Отказ в ответе при поступлении от UDM некорректных запросов;

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

4.1. Для адресации запросов и ответов согласно протоколу взаимодействия 4 уровня должны использоваться UDP-порты из диапазона 49152 - 65535;

4.2. Адреса получателя ответов и отправителя ответов согласно протоколу взаимодействия 4 уровня должны устанавливаться одинаковыми в конфигурациях UDM и HSM соответственно;

4.3. Информация, передаваемая в сообщениях согласно протоколу взаимодействия 4 уровня между UDM и HSM не должна передаваться в открытом виде через сети общего доступа.

5. Значения кодов информационных сообщений при взаимодействии UDM с HSM должны соответствовать значениям, приведенным в таблице 5.

Таблица 5 - Значения кодов информационных сообщений при взаимодействии UDM с HSM

N	Информационное сообщение	Аббревиатура	Значение кода/Code
1.1	Authentication Crypto Request без использования AK	ACR5	256
1.2	Authentication Crypto Request с использованием AK	ACR5	768
2.	Authentication Crypto Answer	ACA5	1280
3.1	Resynchronization Crypto Request без использования AK	RCR5	2304
3.2	Resynchronization Crypto Request с использованием AK	RCR5	2816
4.	Resynchronization Crypto Answer	RCA5	3328

Приложение N 9
к Правилам применения оборудования коммутации систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования коммутации стандарта 5G/IMT-2020,
используемого при оказании услуг передачи данных и телефонного соединения,
утвержденным приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской Федерации
от _________________N______

Список используемых сокращений

1. 3GPP - 3 Generation Partnership Project (организация сотрудничества по созданию системы третьего поколения).

2. 5G/IMT-2020 - 5 Generation/International Mobile Telecommunications (подвижная радиотелефонная связь пятого поколения).

3. 5GS 5 Generation System (система радиотелефонной связи 3GPP, состоящая из сети доступа и базовой сети связи стандарта пятого поколения).

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

5. AF Application Function (функция приложения).

6. AMF Access and Mobility Management Function (функция управления доступом и мобильностью).

7. AMF UE NGAP ID - AMF User Equipment NG Application Protocol Identification (идентификатор региона абонентского устройства, который обслуживается модулем AMF).

8. AN Access Network (сеть доступа).

9. ARP ? Allocation and Retention Priority (приоритет назначения и удержания ресурсов).

10. AUSF Authentication Server Function (функция сервера аутентификации).

11. DL - Downlink (направление передачи к UE).

12. DNN Data Network Name (имя сети передачи данных).

13. DNS Domain Name System (система доменных имен).

14. GBR guaranteed bit rate (гарантированная скорость передачи бит).

15. GFBR guaranteed flow bit rate (гарантированная скорость передачи бит потока).

16. DHCP Dynamic Host Configuration Protocol (протокол динамической настройки узла).

17. eMBB Extreme Mobile BroadBands (усовершенствованная широкополосная мобильная связь).

18. EPS Evolved Packet System (сеть радиодоступа и базовая сеть стандартов LTE и LTE-Advanced).

19. HSM - Hardware Security Module (аппаратный модуль безопасности, выполняющий криптографические функции аутентификации и идентификации абонентов).

20. HSM-SIDF - аппаратный модуль безопасности, выполняющий криптографические функции по расшифрованию значений SUPI из SUCI.

21. IKEv2 ? Internet Key Exchange version 2 (Протокол обмена ключами в Интернет-версии 2).

22. IMEISV International Mobile Equipment Identity and Software version Number (международный идентификатор мобильного оборудования и версия программного обеспечения).

23. IMSI International Mobile Subscriber Identity (международный идентификатор мобильного абонента).

24. IPsec Internet Protocol Security (протокол Интернет с поддержкой функций безопасности).

25. JSON JavaScript Object Notation (текстовый формат обмена данными).

26. LMF Location Management Function (функция управления местоположением).

27. LTE Long-Term Evolution (эволюция на длительный период).

28. MCC ? Mobile Country Code (код страны, состоящий из трех цифр, в которой абонент заключил договор об оказании услуг подвижной радиотелефонной связи).

29. MDBV Maximum Data Burst Volume (максимальный объем пакета данных).

30. MFBR Maximum Flow Bit Rate (максимальная скорость передачи бит потока).

31. MNC ? Mobile Network Code (код сети подвижной связи, состоящий из двух или трех цифр, идентифицирует домашнюю сеть абонента).

32. MSISDN ? Mobile Station ISDN number (номер мобильного абонента в формате сети ISDN).

33. N3IWF ? Non-3GPP InterWorking Function (функция взаимодействия с сетями не относящимися к 3GPP).

34. NAI Network Access Identifier (идентификатор доступа к сети).

35. NAS-MM Non-Access-Stratum Mobility Management (протокол слоя без доступа к функции управления мобильностью).

36. NAS-SM Non-Access-Stratum Session Management (протокол слоя без доступа к функции управления сессией).

37. NEF Network Exposure Function (функция отображения сетевых возможностей и событий).

38. NG-AP Next Generation Application Protocol (протокол прикладного уровня сети следующего поколения).

39. NG RAN Next Generation Radio Access Network (сеть радиодоступа будущего поколения).

40. Non-3GPP сеть радиодоступа, не относящаяся к 3GPP.

41. NR - New Radio (сеть радиодоступа стандарта 5G).

42. NRF ? NF Repository Function (функция хранения информации о сетевых функциях).

43. NSSF Network Slice Selection Function (функция выбора сегмента сети).

44. NSSP Network Slice Selection Policy (политика выбора сегмента сети).

45. NWDAF Network Data Analytics Function (функция анализа сетевых данных).

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

47. PCF Policy Control Function (функция управления политикой).

48. PDB Packet Delay Budget (верхняя граница времени задержки пакета между UE и UPF).

49. PEI - Permanent Equipment Identifier (постоянный идентификатор оборудования пользователя).

50. PER Packet Error Rate (скорость потери пакетов).

51. PDU Protocol Data Unit (фрагмент данных протокола).

52. PFD Packet Flow Description (описание потока пакетов).

53. PDR Packet Detection Rule (правила обнаружения пакетов).

54. SIDF Subscription Identifier De-concealing Function (функция расшифрования закрытого идентификатора подписки).

55. QoS Quality of Service (качество обслуживания).

56. QFI QoS Flow ID (реализация фреймворка архитектуры управления качеством (QoS), включая маркировку восходящих и нисходящих пакетов данных соответствующими параметрами QFI).

57. RAT Radio Access Technology (технологии сети радиодоступа 3GPP).

58. SBI Service Based Interfaces (интерфейсы используемые для оказания услуг).

59. SEPP Security Edge Protection Proxy (прокси-сервер защиты сообщений).

60. Session-AMBR Session Aggregate Maximum Bit Rate (максимальная скорость передачи бит в сессии).

61. SMF Session Management function (функция управления сессией).

62. SMSF Short Message Service Function (функция управления доставкой коротких сообщений).

63. S-NSSAI - Single Network Slice Selection Assistance Information (информация, определяющая выбор одного сетевого сегмента).

64. SSC Service and Session Continuity (обслуживание и непрерывность сессии).

65. SST Slice/Service Type (тип сегмента/услуги).

66. SUPI Subscription Permanent Identifier (постоянный идентификатор подписки).

67. SUCI Subscription Concealed Identifier (закрытый идентификатор подписки).

68. TLS Transport Layer Security (протокол защиты транспортного уровня).

69. TNLA Transport Network Layer Association (ассоциации транспортного уровня сети).

70. TNL Transport Network Layer (транспортный уровень сети).

71. UE User Equipment (абонентский терминал стандартов GSM900/1800/UMTS/LTE/5G, поддерживающий стандарт беспроводной передачи данных в диапазоне от 30 МГц до 66 ГГц).

72. UDM Unified Data Management (функция управления унифицированными данными).

73. UDR Unified Data Repository (хранилище унифицированных данных).

74. UDSF Unstructured Data Storage Function (функция хранения неструктурированных данных).

75. UL - Uplink (направление передачи от UE).

76. UPF User plane function (функция плоскости передачи данных).

77. URLLC Ultra-reliable and low latency communications (высоконадежная межмашинная связь с низкими задержками и высоким уровнем мобильности).

78. URSP UE Route Selection Policy (политика выбора маршрута UE).

79. USIM Universal Subscriber Identity Module (универсальный модуль идентификации абонента).

-------------------------------------------

*(1) Список используемых сокращений приведен в Приложении N 9 к Правилам.

*(2) ГОСТ Р 34.12-2015. "Национальный стандарт Российской Федерации. Информационная технология. Криптографическая защита информации. Блочные шифры", введенный в действие приказом Федерального агентства по техническому регулированию и метрологии от 19.06.2015 N 749-ст (М.: Стандартинформ, 2016).

*(3) ГОСТ Р 34.13-2015. "Национальный стандарт Российской Федерации. Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров", введенный в действие приказом Федерального агентства по техническому регулированию и метрологии от 19.06.2015 N 750-ст (М.: Стандартинформ, 2016).

*(4) Р 1323565.1.003-2017 "Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Криптографические алгоритмы выработки ключей шифрования информации и аутентификационных векторов, предназначенные для реализации в аппаратных модулях доверия для использования в подвижной радиотелефонной связи", утвержденные и введенные в действие приказом Федерального агентства по техническому регулированию и метрологии от 24.10.2017 N 1504-ст (М.: Стандартинформ, 2017).

*(5) 

*(6) Р 1323565.1.020-2020. "Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)", утвержденные приказом Федерального агентства по техническому регулированию и метрологии от 18.12.2020 N 1327-ст.

8 Р 1323565.1.030-2020. "Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.3), утвержденные и введенные в действие приказом Федерального агентства по техническому регулированию и метрологии от 27.02.2020 N 84-ст (М.: Стандартинформ, 2020).

*(7) Р 1323565.1.024-2019 "Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Параметры эллиптических кривых для криптографических алгоритмов и протоколов", утвержденные и введенные в действие приказом Федерального агентства по техническому регулированию и метрологии от 15.05.2019 N 190-ст (М.: Стандартинформ, 2019).

*(8) Р 50.1.113-2016 "Рекомендации по стандартизации. Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов электронной цифровой подписи и функции хэширования", утвержденные и введенные в действие приказом Федерального агентства по техническому регулированию и метрологии от 28.11.2016 N 1828-ст (М.: Стандартинформ, 2016).

*(9) ГОСТ Р 34.11-2012. "Национальный стандарт Российской Федерации. Информационная технология. Криптографическая защита информации. Функция хэширования", введенный в действие приказом Федерального агентства по техническому регулированию и метрологии от 07.08.2012 N 216-ст (М.: Стандартинформ, 2013).

ГАРАНТ:

См. Сводный отчет, загруженный при публикации проекта