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

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

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

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

В соответствии со статьей 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 при оказании услуг передачи данных и телефонного соединения.

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

Министр

М.И. Шадаев

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

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

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

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

2. Правила устанавливают обязательные требования к параметрам оборудования коммутации стандарта 5G при оказании услуг передачи данных и телефонного соединения.

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

4. Правила распространяются на средства связи, являющиеся элементами базовой сети 5G (далее5GC) и выполняющие следующие сетевые функции (далее - NF):

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

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

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

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

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

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

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

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

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

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

11) плоскости пользователя (User plane function, UPF);

12) приложения (Application Function, AF);

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

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

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

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

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

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

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

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

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

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

только E-UTRA;

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

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

6. При реализации процедур идентификации и аутентификации абонентов сети 5G должны использоваться средства криптографической защиты информации, реализующие криптографический алгоритм S3G-256, предусмотренный рекомендациями по стандартизации, утвержденными приказом Росстандарта от 24 октября 2017 г. N 1504-ст (Москва: Стандартинформ, 2017) и имеющие подтверждение соответствия требований по безопасности информации, установленное федеральным органом исполнительной власти в области обеспечения безопасности, не ниже класса КС3.

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

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

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

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

11. Требования к параметрам протоколов 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).

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

13. Требования к протоколу 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).

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

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

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

_____________

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

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

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

2. Каждому абоненту в сети 5G должен назначаться уникальный идентификатор подписки сети 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
8 цифр	6 цифр	2 цифры

Рисунок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. Для обеспечения конфиденциальности UE должен присваиваться закрытый идентификатор подписки (Subscription Concealed Identifier, SUCI). Расчет SUCI должен выполняться оператором связи, в которой зарегистрирован абонент на основании USIM/ME. Структура 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) идентификатор схемы защиты SAPI, принимающий значения в диапазоне от 0 до 15;

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

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

5. 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 бит.

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

7. Имя сети передачи данных (Data Network Name, DNN) должен определяться как сетью передачи данных, так и APN в EPS. Оба указанных идентификатора имеют одинаковое значение и несут одинаковую информацию.

Первая, обязательная часть DNN/APN, включает идентификатор внешней сети, к которой подключен PGW, и должен иметь максимальную длину, равную 63 октетам.

Вторая, необязательная часть DNN/APN, включает идентификатор оператора APN, в сети которого находится GGSN/PGW. Идентификатор оператора APN по умолчанию (доменное имя) формируется из IMSI следующим образом:

"mnc<MNC>.mcc<MCC>.gprs".

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

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

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

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

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

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

_____________

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

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

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

2. NF реализуется без сохранения состояния, когда ресурс "вычисления" не связан с ресурсом "хранения".

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

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

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

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

регистрации (при подключении к сети 5G) и отмены регистрации (при отключении от сети 5G) услуги NF и NF в NRF;

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

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

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

6. 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 и защиты целостности;

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. В случае аутентификации на основе USIM AMF должна извлекать данные для обеспечения безопасности из AUSF;

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;

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 и узлом сети доступа AN;

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) обеспечения разрешенного перехвата (уровень UP);

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

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

9) контроля трафика восходящего направления;

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

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

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

8.5. Функция управления политикой (PCF) должна обеспечить реализацию следующих задач:

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

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

3) обеспечения доступа к информации о подписке UE в UDR, находящейся в той же PLMN, что и PCF.

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 должна обеспечивать поддержку запуска UE;

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

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

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

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

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) информацию о конечных точках экземпляра для каждой поддерживаемой услуги;

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

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

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

13) информацию о местонахождении для конкретного экземпляра NF;

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

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

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

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

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

19) идентификатор группы 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;

2) поддержки закрытого идентификатора подписки с обеспечением конфиденциальности (SUCI);

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

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

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

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

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

8) обеспечения разрешенного перехвата (в случае исходящего роуминга UDM является единственной точкой взаимодействия с LI);

9) обеспечения договорных условий с абонентом;

10) управление доставкой SMS сообщений.

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

UDM должна на основании данных аутентификации в соответствии с договорными условиями об оказании услуг связи с абонентом, которые хранятся в UDR, реализовать логику приложения, без использования внутреннего хранилища для хранения данных об абоненте, в целях обслуживания транзакций конкретного абонента при использовании различных 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 в соответствии с договором об оказании услуг связи получение информации об определенных событиях (действиях) абонента NF.

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

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 должны быть доступны через Nudr.

Выбор требуемого 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. В случае доступа non-3GPP N3IWF должны обеспечиваться следующие условия:

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

2) окончание интерфейсов N2 и N3 для плоскости управления и плоскости абонента соответственно в сети 5GC;

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. Функция приложения (AF - Application Function) сети 5G должна взаимодействовать с опорной сетью.

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

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

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

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

8.13. Для передачи 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.14. Функция выбора сегмента сети (NSSF) должна поддерживать:

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

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

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

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

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

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

8.16. ФУНКЦИЯ УПРАВЛЕНИЯ МЕСТОПОЛОЖЕНИЕМ (LMF) ДОЛЖНА ОБЕСПЕЧИВАТЬ:

поддержку определения местоположения для UE;

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

получение данных определения местоположения по восходящей линии связи от NG RAN;

получение данных из NG RAN, не связанных с UE.

8.17. Прокси-сервер защиты сообщений (SEPP) должен поддерживать:

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

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

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

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

_____________

Приложение N 3
к Правилам применения оборудования коммутации
систем подвижной радиотелефонной связи.
Часть IX. Правила применения оборудования
стандарта 5G при оказании услуг передачи
данных и телефонного соединения, утвержденным
приказом Министерством цифрового развития,
связи и массовых коммуникаций Российской
Федерации от ________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;

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

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

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

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

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

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 для оказания услуг (SBI) приведен на рисунке 1.

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

3.1. Для защиты на транспортном уровне все NF доступа 3GPP должны поддерживать протокол защиты транспортного уровня TLS, а также обеспечивать безопасность сети на аналогичном уровне иными средствами.

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

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

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

3.4.1. Между NF 3GPP взаимодействие должно осуществляться с помощью запросов/ответов (клиент/сервер) одного потока 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, оказывающих услуги в 3GPP сетях, приведены в таблице 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 status code	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. Коды и причины ошибок протоколов и приложений общих для нескольких спецификаций API 5GC SBI, которые NF, должны включать в HTTP-ответ, приведены в таблице N 3.

Таблица N 3.

Ошибки протоколов и приложений	HTTP status code	Описание
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. Требования к протоколам плоскости управления, используемым на контрольной точке N2.

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

Рисунок 2.

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

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

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

Рисунок 3.

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

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

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

Рисунок 4.

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

6.2. Требования к параметрам интерфейсов сети передачи данных с использованием контроля несущей и обнаружением коллизий приведены в приложении 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. При сеансе PDU IPv6/v4 пакеты данных должны соответствовать пакетам IPv6/v4. При сеансе PDU Ethernet пакеты данных должна соответствовать кадрам Ethernet.

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

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

______________

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

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

1. Оказание услуг передачи данных и телефонного соединения в сетях подвижной радиотелефонной связи стандарта 5G должны оказываться операторами связи пользователям услугами связи на основании договора об оказании услуг связи, заключенного в соответствии с гражданским законодательством и правилами оказания услуг связи (далее - договор об оказании услуг связи)*(2).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8.1. Договор об оказании услуг связи в части использования UE должен включать несколько различных DNN (для различных S-NSSAI) и содержать один DNN, используемый по умолчанию.

8.2. При установлении соединения UE должен запросить один из следующих типов сеансов PDU: IPv4, IPv6, IPv4v6, Ethernet неструктурированный.

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

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

8.5. SMF должна обеспечивать проверку соответствия запросов UE в соответствии с договором об оказании услуг связи. Поэтому SMF должен запросить и получить уведомления об обновлениях данных договора об оказании услуг связи уровня SMF от UDM:

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

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

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

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

политика безопасности плоскости пользователя из подписки;

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

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

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

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

S-NSSAI;

DNN;

тип сеанса PDU;

режим SSC;

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

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

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

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

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

Модель 5G QoS также поддерживает формирование QoS потока на основе QoS обслуженных потоков.

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

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

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

профилем QoS, предоставляемым в AN из SMF (через AMF) через контрольную точку N2 или предварительно сконфигурированным в AN;

одним или несколькими правилами QoS, которые предоставлены SMF для UE (через AMF) через опорную точку N1, и/или сформированы UE путем формирования QoS на основе анализа QoS обслуженных потоков;

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

9.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.

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

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

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

9.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 соответствующие ресурсы доступа.

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

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

1) UE использует предоставленные ей правила QoS для определения соответствия между трафиком пользовательской плоскости UL и QoS потока. UE отмечает UL PDU с помощью QFI правила QoS и передает UL PDU с использованием соответствующего ресурса;

2) (R)AN включает значение QFI в заголовок инкапсуляции и передает PDU по туннелю N3 в направлении UPF;

3) (R)AN выполняет маркировку пакетов транспортного уровня, например, на основе 5QI и ARP соответствующего потока QoS;

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

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

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

Характеристики 5G QoS должны соответствовать правилам обработки PDU потока между UE и UPF из конца в конец. Характеристики 5G QoS ассоциируются с 5QI и включают:

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 не поддерживается в данной версии спецификации.

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

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

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

Обслуживающей PLMN сегмент включает:

сеть радиодоступа NG,

функции N3IWF для сети доступа non-3GPP.

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

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

10.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 по умолчанию.

В запросе регистрации от UE должен быть указан S-NSSAI отличный от S-NSSAI согласно договору об оказании услуг связи. В случае роуминга UDM предоставляет в VPLMN S-NSSAI в соответствии с договором об оказании услуг связи.

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

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

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

Узел сети 5G-AN должен поддерживать множество ассоциаций TNL для AMF.

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

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

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

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

В случае, когда UE находится в состоянии CM-Connected, то узел 5G-AN должен обеспечить поддержание связи NG-AP UE-TNLA, до тех пор, пока AMF не инициирует команду о прекращении связи.

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

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

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

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

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

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

11.2. Управление AMF включает добавление/обновление, плановое удаление AMF.

_____________

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

Справочно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

72. UPF - User plane function (функция плоскости пользователя).

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

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

75. USIM - Universal Subscriber Identity Module (универсальный модуль идентификации абонента; карта мобильного пользователя для осуществления доступа к сети UMTS).

_____________

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

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

*(2) Правила оказания услуг телефонной связи, утвержденные постановлением Правительства Российской Федерации от 9 декабря 2014 г. N 1342 (Собрание законодательства РФ", 2014, N 51, ст. 7431)

ГАРАНТ:

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