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

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

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

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

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

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

В настоящем стандарте установлены требования к данным и ресурсам, используемым в процессе жизненного цикла пользовательского приложения MEC для обмена информацией между системой MEC и приложением пользовательского оборудования (UE); определены информационные элементы и атрибуты API MEC.

Стандарт не распространяется на мобильные приложения MEC.

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

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

ГОСТ 7.67 Система стандартов по информации, библиотечному и издательскому делу. Коды названий стран

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

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

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

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

В настоящем стандарте применены термины по ГОСТ 33707, ГОСТ Р 71851.1, а также следующие термины с соответствующими определениями:

3.1.1

3.1.2

3.1.3 опорная точка Mx2 (Mx2 reference point): Точка отсчета между прокси-сервером управления жизненным циклом пользовательского приложения MEC и приложением UE.

3.1.4

3.1.5

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

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

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

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

HTTPS - HTTP через протокол TLS (HTTP over TLS);

JSON - текстовый формат обмена данными, основанный на языке JavaScript (JavaScript object notation);

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

OSS - система поддержки операций (operations support system);

req - запрос (request);

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

UALCMP - прокси-сервер управления жизненным циклом приложения пользователя (user application life cycle management proxy);

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

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

4.1 API MEC должен соответствовать требованиям настоящего стандарта.

4.2 Управление информационными потоками для API MEC в процессах жизненного цикла пользовательских приложений MEC осуществляется через опорную точку Mx2, которая используется приложением UE для запроса разрешения у системы MEC на создание и запуск этого приложения в системе MEC, а также для перемещения приложения в систему MEC или из нее.

4.3 API MEC осуществляет управление следующими процессами жизненного цикла пользовательских приложений MEC:

- поиск пользовательского приложения MEC;

- предоставление точки Mx2 в системе MEC для создания экземпляра пользовательского приложения MEC;

- создание экземпляра пользовательского приложения MEC;

- поддержка (предоставление уведомлений) экземпляра пользовательского приложения MEC;

- обновление экземпляра пользовательского приложения MEC;

- удаление экземпляра пользовательского приложения MEC;

4.4 Требования безопасности в системе MEC - по ГОСТ Р 71851.2-2025 (раздел 8), включая аутентификацию, авторизацию участников системы MEC и управление доступом к системе MEC.

Приложение UE должно предоставлять токен доступа UALCMP при каждом запросе для подтверждения разрешения на доступ к ресурсу API MEC с помощью конкретного метода. Токен доступа должен быть включен в поле заголовка запроса "Authorization" в качестве токена-носителя.

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

Описание процесса поиска доступного пользовательского приложения MEC, приведенного на рисунке 1:

1) приложение UE отправляет запрос "GET" в UALCMP. UALCMP авторизует запрос от приложения UE;

2) система MEC извлекает список пользовательских приложений MEC, доступных запрашивающему приложению UE;

3) если запрос удовлетворен, то UALCMP возвращает ответ "200 OK" приложению UE, при этом тело этого сообщения содержит структуру данных со списком доступных пользовательских приложений MEC. Если запрос не удовлетворен, то UALCMP возвращает приложению UE ответ "400 Bad Request", "401 Unauthorized", "404 Not Found" или "403 Forbidden" в зависимости от ошибки (см. 7.2.2).

Создание экземпляра пользовательского приложения MEC представляет собой процесс запроса на присоединение к доступному пользовательскому приложению MEC и создание экземпляра нового пользовательского приложения MEC. Процесс создания экземпляра пользовательского приложения MEC показан на рисунке 2.

Описание процесса создания экземпляра пользовательского приложения MEC, приведенного на рисунке 2:

1) приложение UE отправляет запрос "POST" в UALCMP. Тело этого сообщения содержит структуру данных для создаваемого экземпляра пользовательского приложения MEC. UALCMP авторизует запрос приложения UE;

2) запрос передается в OSS, которая принимает решение об удовлетворении запроса на создание экземпляра пользовательского приложения MEC. Оркестратор MEC инициирует создание экземпляра пользовательского приложения MEC;

3) если запрос удовлетворен, то UALCMP возвращает ответ "201 Created" приложению UE, при этом тело этого сообщения содержит структуру данных созданного экземпляра пользовательского приложения, которая включает в себя адрес(а) URI, предоставляемый(ые) пользователям, внешним по отношению к системе MEC, для взаимодействия с пользовательским приложением MEC. Заголовок ответного сообщения содержит адрес ресурса, относящегося к контексту экземпляра пользовательского приложения MEC, созданному и поддерживаемому системой MEC. Если запрос не удовлетворен, то UALCMP возвращает приложению UE ответ "400 Bad Request", "401 Unauthorized", "404 Not Found" или "403 Forbidden" в зависимости от ошибки (см. 7.3.2).

В рамках создания экземпляра пользовательского приложения система MEC создает связанный контекст пользовательского приложения и поддерживает его в течение всего срока использования пользовательского приложения. Контекст пользовательского приложения содержит информацию, специфичную для экземпляров(а) пользовательского приложения, таких как уникальные идентификаторы в системе MEC и адрес(а) URI, предоставляемые пользователям, внешним по отношению к системе MEC, для взаимодействия с пользовательским приложением MEC.

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

Описание процесса удаления экземпляра пользовательского приложения MEC, приведенного на рисунке 3:

1) приложение UE отправляет запрос "DELETE" в UALCMP для удаления экземпляра пользовательского приложения MEC;

2) UALCMP авторизует запрос из приложения UE. Запрос передается в OSS, которая принимает решение об удовлетворении запроса на удаление экземпляра пользовательского приложения MEC. Оркестратор MEC инициирует удаление экземпляра пользовательского приложения и соответствующего ресурса, поддерживаемого системой MEC, который его представляет;

3) UALCMP возвращает ответ "204 No Content" приложению UE.

UALCMP осуществляет процесс обновления экземпляра пользовательского приложения MEC, который показан на рисунке 4.

Описание процесса обновления экземпляра пользовательского приложения MEC, приведенного на рисунке 4:

1) приложение UE обновляет конкретный контекст экземпляра пользовательского приложения MEC, отправляя запрос "PUT" к ресурсу в системе MEC, который его представляет, при этом тело сообщения содержит измененную структуру данных AppContext, в которой дана ссылка на обратный вызов и/или ограничения местоположения пользовательского приложения MEC, предназначенные для обновления;

2) если запрос удовлетворен, то UALCMP возвращает ответ "204 No Content" приложению UE. Если запрос не удовлетворен, то UALCMP возвращает приложению UE ответ "400 Bad Request", "401 Unauthorized", "404 Not Found" или "403 Forbidden" в зависимости от ошибки (см. 7.4.2).

На рисунке 5 представлен процесс предоставления приложению UE уведомления о событии в системе MEC.

Описание процесса предоставления приложению UE уведомления о событии в системе MEC, приведенного на рисунке 5:

1) UALCMP отправляет запрос "POST" на адрес обратного вызова, предоставленный приложением UE как часть созданного экземпляра пользовательского приложения MEC. При этом тело сообщения содержит структуру данных {Notification}. Данные {Notification} являются переменными и заменяются данными, указанными для конкретных событий, о которых предоставляется соответствующее уведомление пользователю в системе MEC (см. раздел 6), например, данные об изменении адреса экземпляра пользовательского приложения MEC;

2) если запрос удовлетворен, то приложение UE отправляет ответ "204 No content" в UALCMP. Если запрос не удовлетворен, то UALCMP возвращает приложению UE ответ "400 Bad Request", "401 Unauthorized", "404 Not Found" или "403 Forbidden" в зависимости от ошибки (см. 7.5.2).

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

Описание процесса предоставления точки Mx2 в системе MEC, приведенного на рисунке 6:

1) приложение UE отправляет запрос "POST" в UALCMP. Тело этого сообщения содержит структуру данных, идентифицирующих приложение UE;

2) UALCMP авторизует запрос приложения UE. Затем система MEC оценивает местоположение приложения UE;

3) если запрос удовлетворен, то UALCMP возвращает ответ "200 OK" приложению UE. При этом тело сообщения содержит структуру данных со списком возможных точек Mx2 в системе MEC для создания экземпляра пользовательского приложения MEC. Если запрос не удовлетворен, то UALCMP возвращает приложению UE ответ "400 Bad Request", "401 Unauthorized", "404 Not Found" или "403 Forbidden" в зависимости от ошибки (см. 7.5.2).

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

Элементы данных типа "ApplicationList" приведены в таблице 1.

Данные типа "AppContext" представляют собой информацию об экземпляре пользовательского приложения, созданного системой MEC. Элементы данных типа "AppContext" приведены в таблице 2.

Данные типа "ApplicationLocationAvailability" представляют собой информацию о местоположении точек Mx2 в системе MEC для создания экземпляров новых пользовательских приложений MEC.

Элементы данных типа "ApplicationLocationAvailability" приведены в таблице 3.

Данные типа "AddressChangeNotification" представляют собой информацию об изменении адреса экземпляра пользовательского приложения MEC, направляемую в ответном сообщении от UALCMP.

Элементы данных типа "AddressChangeNotification" приведены в таблице 4.

Данные типа "ApplicationContextDeleteNotification" представляют собой информацию об удалении экземпляра пользовательского приложения MEC, направляемую в ответном сообщении от UALCMP.

Элементы данных типа "ApplicationContextDeleteNotification" приведены в таблице 5.

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

Элементы данных типа "ApplicationContextUpdateNotification" приведены в таблице 6.

Данные типа "ApplicationLocationAvailabilityNotification" представляют собой информацию о доступности точки Mx2 в системе MEC для создания экземпляра пользовательского приложения (если это не удалось выполнить на момент запроса), направляемую в ответном сообщении от UALCMP.

Элементы данных типа "ApplicationLocationAvailabilityNotification" приведены в таблице 7.

Элемент данных типа "LocationConstraints" представляет собой информацию о конкретном местоположении создания пользовательского приложения MEC.

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

- буквенный код страны на латинском языке по ГОСТ 7.67;

- фактический адрес в сочетании с кодом страны;

- географическая зона, условно соответствующая коду страны.

Атрибуты элемента данных типа "LocationConstraints" приведены в таблице 8.

Все ресурсы конкретного API MEC должны иметь корневой URI {apiRoot}/{apiName}/{apiVersion}/.

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

В API MEC должен поддерживаться формат контента JSON, который обозначают типом контента "application/json".

В API MEC используют учетные данные пользователя типа OAuth 2.0 с токенами-носителями. Конечная точка токена-носителя может быть реализована как часть процесса запроса на доступ к системе MEC.

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

На рисунке 7 показана структура URI конкретного API MEC.

В таблице 9 представлен перечень ресурсов, определенных в настоящем стандарте, с указанием соответствующих методов HTTP.

У данного ресурса приложение UE запрашивает данные о доступных пользовательских приложениях MEC.

URI ресурса "meAppList": {apiRoot}/dev_app/v1/app_list.

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

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

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

Для ресурса "meAppList" методы "PUT", "PATCH", "POST", "DELETE" не применяют.

Ресурс "Общий devAppContexts" представляет собой родительский ресурс для всех отдельных ресурсов экземпляров пользовательских приложений MEC.

URI ресурса "Общий devAppContexts": {apiRoot}/dev_app/v1/app_contexts.

Переменные URI ресурса "Общий devAppContexts" определены в таблице 13.

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

Метод "POST" должен соответствовать параметрам запроса URI, структурам данных запроса и ответа, а также кодам ответа как указано в таблицах 14 и 15.

Для ресурса "Общий devAppContexts" методы "GET", "PUT", "PATCH", "DELETE" не применяют.

Ресурс "Индивидуальный AppContext" представляет один индивидуальный экземпляр пользовательского приложения MEC.

URI ресурса "Индивидуальный AppContext": {apiRoot}/dev_app/v1/app_contexts/ {contextId}.

Переменные URI ресурса "Индивидуальный AppContext" определены в таблице 16.

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

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

Метод "DELETE" используют в процессе удаления экземпляра пользовательского приложения MEC.

Метод "DELETE" должен соответствовать параметрам запроса URI, структурам данных запроса и ответа, а также кодам ответа, указанным в таблицах 19 и 20.

Для ресурса "Индивидуальный AppContext" методы "GET", "PATCH", "POST" не применяют.

Ресурс "Предоставление точки Mx2 в системе MEC" используют в процессе предоставления приложению UE информации о точках Mx2 для создания и реализации конкретного пользовательского приложения MEC.

URI ресурса "Предоставление точки Mx2 в системе MEC": {apiRoot}/dev_app/v1/obtain_app_loc_availability.

Переменные URI ресурса "Предоставление точки Mx2 в системе MEC" определены в таблице 21.

Метод "POST" используют в процессе предоставления приложению UE точки Mx2 в системе MEC для создания экземпляра пользовательского приложения MEC.

Метод "POST" должен соответствовать параметрам запроса URI, структурам данных запроса и ответа, а также кодам ответа, указанным в таблицах 22 и 23.

Для ресурса "Предоставление точки Mx2 в системе MEC" методы "GET", "PUT", "PATCH", "DELETE" не применяют.