"ГОСТ Р 71851.4-2025. Национальный стандарт Российской Федерации. Граничные вычисления с множественным доступом. Часть 4. Идентификация пользовательского оборудования"
(утв. и введен в действие Приказом Росстандарта от 27.06.2025 N 631-ст)

1 РАЗРАБОТАН Автономной некоммерческой организацией "Научно-технический центр информатики" (АНО "НТЦИ")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 "Связь"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 июня 2025 г. N 631-ст

4 ВВЕДЕН ВПЕРВЫЕ

Настоящий стандарт устанавливает требования к идентификации пользовательского оборудования (UE) в системе граничных вычислений с множественным доступом (MEC) по ГОСТ Р 71851.2. В стандарте приведены интерфейсы прикладного программирования (API) по ГОСТ Р 71851.3.

Настоящий стандарт следует применять при разработке API для идентификации UE в системе MEC.

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ 33707 (ISO/IEC 2382:2015) Информационные технологии. Словарь

ГОСТ IEC 60050-732 Международный электротехнический словарь. Часть 732. Технологии компьютерных сетей

ГОСТ Р 71851.1 Граничные вычисления с множественным доступом. Часть 1. Термины и определения

ГОСТ Р 71851.2 Граничные вычисления с множественным доступом. Часть 2. Общие технические требования

ГОСТ Р 71851.3 Граничные вычисления с множественным доступом. Часть 3. Интерфейс прикладного программирования. Общие требования

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

В настоящем стандарте применены термины по ГОСТ 33707, ГОСТ IEC 60050-732 и ГОСТ Р 71851.1.

В настоящем стандарте применены следующие сокращения и обозначения:

AC - клиентское приложение (application client);

API - интерфейс прикладного программирования (application programming interface);

App/app - приложение (application/application);

AppD - дескриптор приложения (application descriptor);

ETag - служебный заголовок протокола HTTP (entity tag);

HTTP - протокол передачи гипертекста (hyper text transfer protocol);

HTTPS - HTTP через TLS (HTTP over TLS);

IP - интернет-протокол (Internet protocol);

JSON - обозначение объекта JavaScript (JavaScript object notation);

MEC - граничные вычисления с множественным доступом (multi-access edge computing);

TLS - безопасность транспортного уровня (transport layer security);

UE - пользовательское (абонентское) оборудование (user equipment);

URI - универсальный идентификатор ресурса (universal resource identifier);

3GPP - партнерский проект по системам третьего поколения (3rd Generation Partnership Project);

Mp1 - опорная точка 1 между пользовательскими приложениями MEC и платформой MEC (MEC platform reference point 1).

Экземпляр пользовательского приложения MEC предоставляет возможности сервера приложений MEC для AC, размещенного на UE, который может не иметь данных о сопоставлении информации о соединении, связанном с AC (например, IP-адреса AC, размещенного на UE) и конкретным UE.

Применяют процедуру, посредством которой сервер приложения MEC передает API идентификатора UE для сервера приложений MEC, чтобы предоставить серверу приложений MEC идентификатор, однозначно идентифицирующий UE. Этот идентификатор может являться идентификатором UE, присвоенным базовой сетью 3GPP или идентификатором MEC UE, сгенерированным сервером приложения MEC.

Если недостаточно наличия IP-адреса, то экземпляр пользовательского приложения MEC может получить идентификатор UE для других целей, таких как аутентификация доступа UE.

Процесс получения идентификатора MEC UE показан на рисунке 1.

Описание процесса получения идентификатора MEC UE, приведенного на рисунке 1:

1) экземпляр пользовательского приложения MEC активирует функцию идентификатора MEC UE, отправляя запрос к платформе MEC;

2) платформа MEC использует полученную информацию о соединении AC (например, IP-адрес) и получает идентификатор MEC UE;

3) платформа MEC предоставляет полученный идентификатор MEC UE в качестве идентификатора UE экземпляру пользовательского приложения MEC, который предназначен для данного экземпляра пользовательского приложения MEC.

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

Целью функций MEC UE является установление конкретных правил трафика UE в системе MEC. Если система MEC поддерживает функцию UE, то платформа MEC предоставляет функциональность (набор функций MEC) экземпляру пользовательского приложения MEC для регистрации тега или списка тегов (представляющих UE). Теги могут быть включены в дескриптор правил трафика, которые, в свою очередь, могут быть включены в дескриптор приложения AppD как часть пакета приложения. Правила трафика с фильтрами, связанные с экземпляром пользовательского приложения, также доступны через опорную точку между пользовательскими приложениями MEC и платформой MEC (Mp1). Каждый тег отображается на конкретное UE у оператора мобильной сети. Платформа MEC предоставляется вместе с информацией отображения.

Примечание - Описание процесса отображения в настоящем стандарте не приведено.

При регистрации тега идентификации UE платформа MEC активирует соответствующие правила трафика, связанные с данным тегом. Если экземпляр пользовательского приложения не использует правило трафика для данного пользователя, то он может отменить регистрацию тега идентификации UE, выполнив процесс отмены регистрации.

На рисунке 2 показан процесс регистрации тега идентификации UE, который используется в функции идентификации UE.

Описание процесса регистрация тега идентификации UE, приведенного на рисунке 2:

1) экземпляр приложения UE MEC отправляет запрос "PUT", тело которого содержит структуру данных идентификатора UE "UeIdentityTagInfo", о состоянии "REGISTERED" на платформу MEC. Переменная {appInstanceId} содержит идентификатор экземпляра приложения UE MEC;

2) если запрос удовлетворен, то платформа MEC отправляет ответ "200 OK", тело которого содержит структуру данных ресурса "UeIdentityTagInfo" о состоянии "REGISTERED". Если запрос не удовлетворен, то платформа ME возвращает приложению UE ответ "400 Bad Request", "404 Not Found", "403 Forbidden" или "412 Precondition Failed" в зависимости от ошибки (см. 5.3.3.2).

После успешной регистрации тега или списка тегов на платформе MEC соответствующие правила трафика активируются.

На рисунке 3 показан процесс отмены регистрации тега идентификации UE.

Описание процесса отмены регистрации тега идентификации UE, приведенного на рисунке 3:

1) экземпляр приложения UE MEC отправляет запрос "PUT", тело которого содержит структуру данных ресурса "UeIdentityTagInfo" о состоянии "UNREGISTERED" на платформу MEC. Переменная {appInstanceId} содержит идентификатор экземпляра приложения UE MEC;

2) если запрос удовлетворен, то платформа MEC отправляет ответ "200 OK", тело которого содержит структуру данных ресурса "UeIdentityTagInfo о состоянии "UNREGISTERED". Если запрос не удовлетворен, то платформа ME возвращает приложению UE ответ "400 Bad Request", "404 Not Found", "403 Forbidden" или "412 Precondition Failed" в зависимости от ошибки (см. 5.3.3.2).

После отмены регистрации тега или списка тегов на платформе MEC соответствующие правила трафика деактивируются.

Данные типа "UeIdentityTagInfo" представляют информацию тега идентификации UE. Элементы данных типа "UeIdentityTagInfo" приведены в таблице 1.

URI заданного API должен иметь корневой URI: {apiRoot}/{apiName}/{apiVersion}/.

В URI параметр "apiRoot" обнаруживается с помощью реестра служб. В URI для параметра "apiName" должно быть установлено значение "ui", для параметра "apiVersion" - значение "v1". URI ресурса должен включать в себя схему "https", хост и дополнительный порт, а также строку префикса. Заданный API должен поддерживать протокол HTTP через TLS (HTTPS) версии TLS 1.2. HTTP без протокола TLS использовать не допускается.

Примечание - Следует учитывать, что версии TLS ранее 1.2 в системе MEC не поддерживаются и не используются. Протокол версии TLS 1.3 в системе MEC поддерживается (включая новые специальные требования к реализации TLS 1.2).

Все URI в приведенных ниже подразделах определены относительно указанного выше корневого URI.

Контент должен поддерживать формат JSON.

Формат JSON обозначается типом контента "application/json".

Заданный API требует предоставления и использования учетных данных UE типа OAuth 2.0 с токенами носителя. Конечная точка токена может быть обнаружена как часть процесса запроса на предоставление услуги в системе MEC.

Заданный API поддерживает дополнительную информацию об ошибках, связанную с пользовательским приложением, которая должна предоставляться в ответе HTTP при возникновении ошибки.

На рисунке 4 показана структура ресурса URI заданного API идентификации UE.

В таблице 2 представлено описание ресурса "Individual UeIdentityTagInfo", включая методы HTTP.

Примечание - Описание методов PATCH, POST, DELETE в настоящем стандарте не приведено.

URI обозначают: {apiRoot}/ui/v1/{appInstanceId}/ue_identity_tag_info.

Переменные URI ресурса "Individual UeIdentityTagInfo" определены в таблице 3.

5.3.3.1 Метод "GET"

Метод "GET" используют для получения информации о конкретных данных типа "UeIdentityTagInfo".

Метод "GET" должен соответствовать параметрам запроса URI, структурам данных запроса и ответа, а также кодам ответа согласно таблицам 4 и 5.

5.3.3.2 Метод "PUT"

Метод "PUT" используют в процессе обновления экземпляра пользовательского приложения MEC для регистрации или отмены регистрации одного или нескольких тегов идентификации UE.

Метод "PUT" используют в процессе регистрации тега UE, как в методе GET.

Метод "PUT" должен соответствовать параметрам запроса URI, структурам данных запроса и ответа, а также кодам ответа согласно таблицам 6 и 7.