В ядре 5G функция AMF располагает первичной информацией о мобильности UE, включая текущую зону отслеживания, состояние достижимости, изменения регистрации, состояние CM и изменения типа доступа. Когда такие сетевые функции, как SMF, NEF или UDM, нуждаются в этих данных, повторные запросы к AMF дают лишь снимок состояния в конкретный момент и не позволяют эффективно отслеживать изменения. Namf_EventExposure решает эту задачу, превращая управляемую AMF информацию о мобильности в сервис событий, на который другие сетевые функции могут подписываться и получать последующие уведомления.
-
Название сервиса: Namf_EventExposure
Основная модель: Подписка на события + уведомление об изменении состояния
Типичные потребители: SMF, NEF, UDM
Контекст версии: На основе соответствующих определений 3GPP Release 15.6
Роль и границы сервиса
Namf_EventExposure — это сервис AMF, который предоставляет другим сетевым функциям события, связанные с мобильностью. Поскольку AMF отвечает за управление доступом и мобильностью, она непосредственно хранит такие сведения, как местоположение UE, статус регистрации и состояние управления соединением. Другим сетевым функциям не требуется заново реализовывать ту же логику определения состояния. Вместо этого они могут через данный сервис указать интересующие события, а AMF определяет момент их наступления и отправляет уведомления при выполнении настроенных условий.
Подписка на события принципиально отличается от обычного запроса состояния. Запрос отвечает на вопрос «Каково текущее состояние?», а подписка — «Когда состояние изменится?». Например, SMF не обязана постоянно проверять, достижим ли UE; ей может быть достаточно уведомления в момент перехода UE из состояния «достижим» в «недостижим». NEF может интересовать только вход UE в заданную область, а UDM — изменения регистрации или достижимости. Таким образом, предоставление событий обеспечивает асинхронный обмен информацией по условию только тогда, когда это действительно требуется.
AMF не распространяет всю внутреннюю информацию без разбора. События предоставляются в рамках установленных отношений подписки. Потребитель, целевой UE, тип события и URI уведомления совместно определяют область подписки. Такой подход уменьшает лишнюю сигнализацию и позволяет каждой сетевой функции подписываться только на ту информацию о мобильности, которая нужна ее собственной сервисной логике.
Типы событий и ключевые параметры
AMF может предоставлять события, охватывающие различные аспекты мобильности, регистрации, подключения и достижимости UE. Вместо запоминания каждого события по отдельности удобнее разделить их на три группы: события местоположения и области, события регистрации и состояния доступа, а также события достижимости или исключительных ситуаций.
События местоположения и области
Одним из наиболее прямых типов событий является отчет о местоположении UE. Потребитель может подписаться на изменения местоположения одного UE или группы UE; уведомления могут содержать TAI и идентификатор соты. Отчет AOI, то есть область интереса, отражает отношение UE к заранее определенной области: вошел ли UE в нее, вышел из нее или находится в неизвестном состоянии.
Отчеты AOI особенно полезны, когда приложению не нужны непрерывные точные обновления местоположения, а достаточно знать, находится ли UE внутри заданной области. Например, если нужно лишь определить, входит ли UE в область, состоящую из TA1 и TA2, нет необходимости формировать постоянные уведомления, пока UE остается внутри нее. Отчет требуется только при входе в настроенную область или выходе из нее.
Состояния регистрации, доступа и соединения
Отчет о регистрации различает состояния REGISTERED и DEREGISTERED, а отчет по управлению соединением показывает, находится ли UE в CM-IDLE или CM-CONNECTED. Для сетевых функций, которым важно понимать, можно ли немедленно установить пользовательскую или сигнальную связь, эти состояния имеют разное значение.
AMF также может предоставлять изменения типа сети доступа UE, например переходы между 3GPP и non-3GPP доступом, а также изменения текущего часового пояса UE. Обычно такие параметры не нужно опрашивать с высокой частотой, однако их изменение может повлиять на решения по политикам или обработку сервиса. Поэтому они хорошо подходят для модели событийной подписки.
События достижимости и исключений
Отчет о достижимости показывает, считает ли AMF, что UE достижим через сеть. Возможные результаты включают «достижим», «недостижим» и REGULATORY-ONLY. REGULATORY-ONLY означает, что UE достижим только для услуг с регуляторным приоритетом. Достижимость не следует путать с состоянием соединения: UE в CM-IDLE может оставаться достижимым, хотя перед восстановлением соединения может потребоваться процедура поискового вызова.
События исключений описывают сбои или потерю связи. Отчеты о сбое связи могут содержать значения причины освобождения соединения RAN или NAS. Отчет о потере связи может быть сформирован, когда AMF определяет, например по истечении таймера мобильной достижимости, что связь с UE потеряна, после чего подписчик получает соответствующий идентификатор UE.
Помимо событий для отдельного UE или группы UE, AMF может предоставлять статистику по количеству UE в определенной области. В этом случае потребителя интересует общее число UE в регионе, а не состояние конкретного абонента. Это показывает, что предоставление событий не ограничивается уведомлениями по отдельным UE и может передавать статистическую информацию, связанную с мобильностью.
Подписка, обновление и уведомление
Namf_EventExposure организует изменения состояния вокруг полного жизненного цикла подписки. Сначала сетевой потребитель создает подписку, а AMF сохраняет соответствующую связь. Если позднее требуется изменить условия события, подписку можно обновить. Когда событие больше не нужно, подписку можно удалить. Фактические результаты события затем доставляются AMF на настроенный адрес уведомления.
Для создания подписки потребитель отправляет POST-запрос на новую подписку. При успешной обработке AMF возвращает созданные данные подписки вместе с идентификатором, который можно использовать в последующих операциях. Если требуется изменить условия события, потребитель может выполнить PATCH для соответствующей подписки вместо удаления и повторного создания. Когда событие больше не нужно, отправляется DELETE для удаления отношения подписки, после чего AMF перестает отправлять уведомления по ней.
Notify — ключевой шаг, который доставляет фактическое изменение состояния. Когда выполняется условие подписанного события, AMF отправляет POST-уведомление о событии на eventNotificationUri, сохраненный в подписке. После обработки уведомления потребителем и возврата ответа данная транзакция считается завершенной. Типичная последовательность выглядит так:
-
Потребитель определяет UE и событие, которое требуется отслеживать;
-
AMF создает и поддерживает контекст подписки;
-
AMF продолжает отслеживать соответствующее состояние мобильности;
-
При выполнении условия события AMF отправляет уведомление;
-
Потребитель обрабатывает событие и выполняет требуемую сервисную логику;
-
При изменении требований сервиса подписка обновляется или удаляется.
Отчетность может быть настроена как одноразовая или непрерывная. Одноразовый отчет подходит, если потребителю нужен только текущий результат или один факт наступления события. При непрерывной отчетности подписка остается активной, и последующие изменения состояния, соответствующие заданным условиям, могут инициировать дополнительные уведомления. Поэтому с инженерной точки зрения «на какое событие подписываются» и «сколько отчетов требуется» следует рассматривать как отдельные параметры конфигурации.
Инженерный взгляд и вывод
С точки зрения сервис-ориентированной архитектуры 5GC Namf_EventExposure определяет границу ответственности: какая сетевая функция обнаруживает состояние и какая его потребляет. Поскольку AMF уже располагает данными управления мобильностью, эффективнее предоставить их через стандартизованный событийный механизм, чем заставлять SMF, NEF или UDM многократно выводить то же состояние UE посредством дополнительной сигнализации.
Именно поэтому модель подписки хорошо подходит для предоставление событий. Местоположение UE, регистрация, состояние соединения и достижимость — это информация о состоянии. Большую часть времени значения остаются неизменными, но при изменении могут сразу влиять на поведение другой сетевой функции. Постоянный периодический опрос создавал бы значительный объем сигнализации с небольшой эксплуатационной ценностью, тогда как подписка и уведомления передают данные только при реальном событии.
При практическом анализе сигнализации Namf_EventExposure особенно важны четыре элемента: какая NF создала подписку, какое событие запрошено, какой UE или область отслеживаются и куда отправляется уведомление. Совместное отслеживание ID подписки и eventNotificationUri обычно позволяет восстановить полное взаимодействие от создания и изменения подписки до финального сообщения Notify.
Наиболее эффективный способ понять Namf_EventExposure — использовать простую модель: AMF поддерживает состояние мобильности, потребитель заявляет свой интерес, подписка устанавливает связь, а Notify доставляет результат при изменении состояния. После понимания этой модели конкретные события, такие как местоположение, AOI, регистрация, состояние соединения и достижимость, интерпретировать значительно проще.
FAQ
В чем принципиальная разница между Namf_EventExposure и прямым запросом к AMF?
Прямой запрос получает состояние в конкретный момент времени. предоставление событий заранее фиксирует интерес и позволяет AMF уведомлять потребителя при изменении соответствующего состояния. Первый вариант подходит для точечных запросов, второй — для постоянного мониторинга событий.
Может ли один потребитель подписаться на события нескольких UE?
Да. Поддерживаемая область назначения зависит от типа события. Некоторые события применяются к одному UE или группе UE, а статистика, например количество UE в заданной области, может охватывать произвольное число UE.
Означает ли CM-IDLE, что UE недостижим?
Нет. Состояние CM описывает состояние управления соединением UE, а достижимость — возможность сети связаться с UE. UE в CM-IDLE может оставаться достижимым, хотя для связи обычно требуется сначала восстановить соединение.
Почему для уведомления о событии нужен отдельный URI обратного вызова?
Создание подписки и наступление события не обязаны происходить одновременно. При создании подписки потребитель указывает URI уведомления, поэтому AMF может позже отправить сообщение Notify при выполнении настроенного условия события, не сохраняя исходное соединение запроса открытым.
