Ядро 5G больше не предназначено только для связи между людьми. Подключенные автомобили, умные заводы, умные кампусы, телемедицина, беспилотники и многие другие отраслевые приложения все чаще должны динамически влиять на сетевые ресурсы в зависимости от условий сервиса или получать от оператора разрешенную информацию о состоянии сети. Если бы для каждого нового требования оператору приходилось вручную менять конфигурации AMF, SMF, PCF, UDM и других сетевых функций, масштабное внедрение 5G в вертикальных отраслях было бы крайне сложным.
Именно здесь используется NEF, или Network Exposure Function. Он располагается между 5GC и функциями приложений AF и преобразует внутренние возможности ядра в стандартизованные интерфейсы, доступные внешним приложениям. Одновременно он обеспечивает контроль безопасности, преобразование информации и предоставление параметров. Для сторонних приложений NEF является не просто API-шлюзом, а контролируемой точкой доступа к возможностям ядра 5G оператора.
Зачем 5GC нужен NEF
Бизнес-модель 4G в основном была ориентирована на B2C: сеть обеспечивала подключение, а абоненты через мобильный Интернет получали доступ к приложениям. С 5G модель расширилась в сторону B2B2X. Теперь сеть должна поддерживать не только отдельных пользователей, но и более глубокое автоматизированное взаимодействие с платформами производства, транспорта, кампусов, здравоохранения и других вертикальных отраслей.
Возникает важный вопрос: как отраслевые приложения могут использовать сетевые возможности оператора безопасно и в стандартизованном виде?
Представим промышленное предприятие, которому нужно обеспечить производственным терминалам в определенной зоне более предсказуемый QoS или направить трафик приложения в локальную сеть данных, расположенную ближе к заводу. Без единого механизма открытия возможностей прикладной платформе пришлось бы напрямую подключаться к нескольким функциям ядра и реализовывать разные настройки для разных поставщиков. Это увеличило бы сложность интеграции и открыло бы больше внутренних интерфейсов ядра.
NEF создает общую границу между отраслевыми приложениями и 5GC. Внешнему AF не требуется знать все внутренние детали AMF, SMF, PCF, UDM или UPF. Достаточно отправить через NEF запрос услуги, соответствующий стандартам. Затем NEF взаимодействует с нужными сетевыми функциями 5GC и возвращает результат приложению.
Такой подход переводит часть требований, которые иначе зависели бы от ручной координации и статической настройки, в стандартизованные сервисные вызовы и позволяет оператору более автоматизированно предоставлять сетевые возможности партнерам.
Где располагается NEF в 5GC
NEF развертывается между сетевыми функциями 5GC и AF. AF — это функциональная сущность прикладного уровня, отвечающая за бизнес-логику. Это может быть доверенное приложение, принадлежащее оператору или управляемое им, либо сторонняя платформа вне доверенного домена оператора. Стороннему приложению нельзя предоставлять неограниченный доступ к внутренним функциям ядра, поэтому контролируемое взаимодействие выполняется через NEF.
С точки зрения интерфейсов NEF фактически соединяет две разные среды. На северном направлении он обслуживает AF, например видеоплатформы, платформы подключенных автомобилей и промышленные системы управления. На южном направлении он подключается к внутренним функциям 5GC и взаимодействует с SMF, PCF, UDM и другими сущностями в зависимости от запрашиваемой услуги.
NEF развился из SCEF, применявшегося в 4G, но его область применения значительно шире. SCEF был в основном связан с отдельными сценариями IoT, тогда как NEF в 5GC поддерживает гораздо более широкий спектр приложений, ориентированных как на людей, так и на машины, и стал важной частью сервисной архитектуры открытия возможностей.
По своей архитектуре NEF делает гораздо больше, чем просто пересылает сообщения. Его основные задачи включают открытие сетевых возможностей и событий, безопасную передачу информации от внешних приложений в сеть 3GPP, преобразование информации между внешними и внутренними форматами, а также прием данных от других сетевых функций для хранения или последующего повторного предоставления.
Часть информации, полученной NEF, может храниться в UDR, поэтому она не должна оставаться привязанной к одному экземпляру NEF. NEF также может поддерживать функции PFD, создавая основу для более точного распознавания приложений и обработки политик.
Как открываются пять ключевых возможностей
Ценность NEF определяется услугами, которые он способен предоставлять. В практических развертываниях 5GC его основные возможности можно разделить на пять областей: открытие QoS, подписка на сетевые события, управление направлением трафика, предоставление параметров и управление PFD. Эти функции соответствуют наиболее распространенным требованиям взаимодействия между отраслевыми приложениями и сетями операторов.
Открытие возможностей QoS
Открытие QoS позволяет приложению партнера запрашивать определенное качество обслуживания для конкретного сервисного потока. Например, видеоприложение уже может работать через существующую PDU-сессию. Если пользователь выбирает видео более высокого качества, AF может через NEF запросить улучшенный QoS для этого потока трафика.
Получив запрос, NEF координируется с функциями ядра, например PCF. Затем PCF применяет логику политик и взаимодействует с SMF и другими сетевыми ресурсами, чтобы обеспечить подходящую обработку QoS для сервисного потока.
Суть не в том, чтобы просто выделить устройству больше полосы пропускания. Цель состоит в том, чтобы приложение могло выразить требования к сервису через стандартизованный интерфейс, при этом решения по политике и применение сетевых ресурсов оставались под контролем 5GC.
Мобильность и подписки на сетевые события
Сторонний AF также может через NEF подписываться на сетевые события, связанные с UE: потерю подключения, восстановление доступности, текущее или последнее известное местоположение, статус роуминга, причины ошибок связи и состояние доставки данных в нисходящем направлении.
Эти события обнаруживаются разными функциями ядра. AMF может определять доступность UE, потерю подключения и некоторые сбои связи. UDM может предоставлять сведения о статусе роуминга или изменениях привязки идентификаторов, а SMF — сообщать о состоянии доставки данных в нисходящем направлении.
AF не должен напрямую подключаться к каждой сетевой функции. Вместо этого он создает подписку на событие через NEF. Затем NEF устанавливает необходимую внутреннюю подписку в соответствующей сетевой функции. Когда целевое событие происходит, ядро уведомляет NEF, а NEF передает уведомление внешнему AF в соответствии с подпиской.
Этот механизм особенно полезен для отраслевых приложений, которым необходимо запускать автоматизированную бизнес-логику по состоянию устройства. Вместо постоянного опроса сети о состоянии UE внешняя платформа может получить уведомление именно в момент наступления нужного события.
Переперенаправление трафика
NEF также может принимать от AF запросы Traffic Influence и направлять трафик определенного UE или сервиса в Local DN, то есть Local Data Network. Local DN идентифицируется с помощью DNAI и обычно связан с периферийными вычислениями или регионально развернутыми сервисами.
Например, на автоматизированном заводе промышленный сервер управления может находиться в локальной сети рядом с производственной площадкой. Прикладная платформа может через NEF запросить у 5GC изменение маршрута пользовательской плоскости, чтобы трафик соответствующих устройств направлялся в нужный Local DN.
NEF не управляет UPF напрямую. Вместо этого он передает требование в процесс управления политиками. Затем PCF и SMF обрабатывают политику и конфигурацию пользовательской плоскости. В зависимости от ситуации SMF может повторно выбрать UPF либо добавить, заменить или удалить UPF в существующем маршруте, чтобы выполнить переперенаправление трафика.
Безопасное предоставление параметров
Внешний AF также может использовать NEF для передачи в 5GC определенных параметров, связанных с пользователем. Это не означает, что приложению разрешено свободно изменять параметры ядра. Диапазон данных, которые можно передавать, строго контролируется.
Типичные примеры включают Expected UE Behaviour и отдельные Network Configuration Parameters. Expected UE Behaviour может описывать ожидаемые характеристики мобильности устройства, а параметры конфигурации сети могут содержать максимальное время ответа, допустимую задержку передачи данных в нисходящем направлении или рекомендуемое число пакетов downlink для буферизации, когда UE недоступно.
NEF передает авторизованные запросы параметров в UDM, который совместно с UDR считывает и обновляет соответствующие данные. AMF или другие сетевые функции, подписанные на изменения этих данных, затем могут получать обновленные параметры для последующей сетевой обработки.
Управление PFD
PFD, или Packet Flow Description, можно рассматривать как набор правил для распознавания приложений. Сторонний AF может через NEF создавать информацию для идентификации приложения. Полученные правила могут храниться в UDR, извлекаться SMF через NEF и затем передаваться в UPF для распознавания приложений.
В отличие от идентификации трафика только по базовым портам или адресам, PFD позволяют описывать более конкретные характеристики приложения. Например, видеосервис можно распознавать по определенному шаблону URL или другим характеристикам трафика, что позволяет сети точнее сопоставлять трафик с нужными правилами политик.
Реальная техническая ценность NEF
С архитектурной точки зрения важнейшая роль NEF заключается не в добавлении еще одного узла пересылки, а в создании управляемого слоя открытия возможностей. Внешние AF видят сервисно-ориентированные интерфейсы, тогда как фактическая работа внутри 5GC по-прежнему выполняется такими функциями, как управление политиками PCF, управление сессиями SMF, управление данными UDM и обработка пользовательской плоскости UPF.
Поэтому NEF не следует воспринимать как обычный API-шлюз. Он должен понимать связь между внешними бизнес-запросами и возможностями ядра 3GPP, одновременно обеспечивая контроль безопасности, преобразование информации и координацию процессов между двумя сторонами.
NEF также не заменяет другие сетевые функции. Применение QoS по-прежнему зависит от управления политиками и настройки ресурсов сессии. Сетевые события обнаруживаются соответствующими NF. Маршруты пользовательской плоскости по-прежнему корректируются функциями вроде SMF, а данные пользователей обслуживаются UDM и UDR. Задача NEF — предоставлять эти внутренние возможности контролируемым и стандартизованным способом.
Эта возможность особенно важна для сервисов 5G B2B2X. Отраслевым приложениям не требуется знать полную внутреннюю топологию 5GC или создавать собственные интерфейсы к каждой сетевой функции. Они могут передавать сетевые требования через стандартизованные механизмы открытия возможностей. При этом оператор сохраняет контроль над границей ядра и превращает выбранные сетевые возможности в сервисы, доступные доверенным партнерам.
На практике NEF помогает ядру 5G перейти от сети, в основном предоставляющей подключение, к платформе, способной напрямую предоставлять сетевые возможности отраслевым приложениям.
Часто задаваемые вопросы
Все ли AF должны размещаться за пределами сети оператора?
Нет. AF может быть доверенным приложением, принадлежащим оператору или управляемым им, либо сторонним приложением вне доверенного домена оператора. Способы доступа и меры безопасности могут различаться в зависимости от типа AF.
Всегда ли бизнес-данные хранятся локально в NEF?
Нет. Часть информации, получаемой NEF, может храниться в UDR и затем использоваться другими сетевыми функциями или последующими процедурами. Поэтому хранение данных не обязательно должно быть привязано к одному экземпляру NEF.
Local DN — это то же самое, что UPF?
Нет. Local DN — это локальная сеть данных, в которой размещаются определенные приложения или сервисы данных, а UPF — сетевая функция пользовательской плоскости 5GC. Трафик может проходить через подходящий маршрут UPF к заданному Local DN, но эти сущности выполняют разные роли.
Создает ли UPF правила PFD самостоятельно?
Нет. Правила PFD могут предоставляться AF и управляться через NEF. SMF получает соответствующие правила и передает их UPF для более точного распознавания приложений в пользовательской плоскости.
