Registration Request уже поступил в AMF — почему же обслуживающий AMF всё ещё может измениться во время регистрации? Означает ли это, что gNB изначально выбрал неверный AMF? Если UE не передаёт Requested NSSAI в Registration Request, на каком этапе сеть сможет определить, какой сетевой срез действительно нужен UE? Эти вопросы относятся к специальной ветви Initial Registration в 5GC — перераспределению AMF. В инженерной практике это часто называют «повторным выбором AMF», однако в процедуре 3GPP точнее рассматривать этот процесс как перераспределение AMF во время регистрации.
Ключевое отличие перераспределения AMF от обычного Initial Registration заключается не в дополнительной аутентификации и не в смене AMF из-за балансировки нагрузки. Initial AMF получает более полные сведения о подписке и срезах, определяет, что не может обслуживать S-NSSAI, который в итоге требуется UE, обращается к NSSF для определения подходящей области обслуживания AMF, а затем передаёт процедуру регистрации Target AMF.
Лучше всего понимать этот сигнальный процесс не через запоминание номера шага, на котором меняется AMF, а через три последовательные точки принятия решения: какая информация есть у gNB при первом выборе AMF, какие дополнительные сведения Initial AMF получает во время регистрации и по каким критериям NSSF в итоге направляет UE к новому обслуживающему AMF.
Когда запускается перераспределение AMF?
Initial Registration с перераспределением AMF не является стандартным маршрутом для каждой регистрации в 5GC. Условия запуска конкретны: в сети используется Network Slicing, а AMF, который первым получил Registration Request, не способен обслуживать сетевой срез, который в итоге требуется UE.
При обычной регистрации Initial AMF, выбранный gNB, уже поддерживает требуемый S-NSSAI. Поэтому обработка идентификации, аутентификация, получение данных подписки и Registration Accept могут выполняться на одном и том же AMF на протяжении всей процедуры.
Перераспределение требуется только тогда, когда информация, полученная позднее, показывает, что текущий AMF не соответствует срезу, который UE разрешено использовать или который должен использоваться по умолчанию. Логика выглядит так:
Registration Request поступает в Initial AMF
→ Initial AMF выполняет необходимую обработку регистрации
→ Получается полная информация о подписке UE и сетевых срезах
→ Initial AMF определяет, что не может обслуживать целевой S-NSSAI
→ Вызывается NSSF для определения подходящей области обслуживания
→ Регистрация передаётся Target AMF
Важно не допустить распространённую ошибку: появление двух AMF в одной трассировке регистрации не означает автоматически отказ исходного AMF или балансировку нагрузки в AMF Pool. В этой процедуре фактической причиной является несоответствие между возможностями текущего AMF по обслуживанию срезов и сетевым срезом, который в итоге требуется UE.
Почему gNB может первоначально выбрать неподходящий AMF?
При первом знакомстве с перераспределением AMF легко предположить, что gNB ошибся. Если разные AMF обслуживают разные срезы, почему RAN сразу не направляет UE к правильному AMF?
Основная причина в том, что в момент первоначального выбора AMF у gNB может не быть достаточной информации. Рассмотрим подключённый автомобиль, который впервые включается с 5G USIM, подписанной на два сетевых среза:
Срез eMBB (S-NSSAI1): для автомобильной информационно-развлекательной системы и обычных сервисов передачи данных;
Срез V2X (S-NSSAI3): для связи автомобиля со всем окружением (V2X) и сервисов, связанных с автоматизированным вождением.
Предположим, что Default S-NSSAI абонента — это срез V2X, но UE впервые входит в 5GS, не имеет действительного 5G-GUTI и не передаёт Requested NSSAI в Registration Request. В этот момент у gNB нет прямых данных, позволяющих понять, что UE в конечном итоге должен обслуживаться AMF, связанным со срезом V2X.
В обычных условиях при выборе AMF gNB может использовать такие сведения, как GUAMI, S-NSSAI, запрошенный UE, и локальную конфигурацию AMF. В данном сценарии, однако, недоступны и GUAMI, и Requested NSSAI, поэтому gNB может выбрать Initial AMF только на основе имеющейся информации и локальной политики выбора по умолчанию.
Если gNB первоначально выбирает AMF1, обслуживающий срез eMBB, Registration Request передаётся в AMF1 внутри NGAP Initial UE Message.
То, что этот AMF не соответствует окончательному требованию UE по срезу, не обязательно указывает на ошибку конфигурации gNB. Точнее это можно сформулировать так: в момент первого выбора AMF RAN ещё не располагает достаточной информацией, чтобы определить AMF, соответствующий конечному срезу UE.
Как Initial AMF обнаруживает несоответствие среза?
Когда Registration Request поступает в Initial AMF, он не обращается к NSSF немедленно. На этом этапе у него ещё недостаточно информации об абоненте, чтобы определить, является ли он правильным конечным обслуживающим AMF.
Сначала AMF следует обычной логике Initial Registration и выполняет необходимые процедуры, включая обработку идентичности UE, выбор AUSF, аутентификацию 5G-AKA и связанные процедуры безопасности NAS.
Одним из ключевых результатов этого этапа является подтверждение идентичности UE и получение SUPI. После появления SUPI Initial AMF может найти подходящий UDM и получить Access and Mobility Subscription Data UE.
На этом этапе сеть располагает значительно большим объёмом информации, чем при первоначальном поступлении Registration Request. Данные подписки, возвращённые UDM, могут содержать Subscribed NSSAI и Default S-NSSAI абонента.
Продолжая пример с подключённым автомобилем: Initial AMF относится к области обслуживания eMBB, но данные подписки показывают, что UE подписан и на eMBB, и на V2X, а Default S-NSSAI указывает на V2X, то есть S-NSSAI3.
Теперь Initial AMF может сделать вывод, который gNB не мог сделать ранее: хотя он смог принять Initial Registration и начать его обработку, он не является подходящим AMF для дальнейшего обслуживания среза V2X, используемого UE по умолчанию. Этот вывод становится точкой запуска перераспределения AMF.
Этап gNB: доступна только ограниченная информация о доступе
→ Этап Initial AMF: подтверждается идентичность UE
→ Этап UDM: получаются фактические сведения о NSSAI из подписки
→ Обнаруживается несовместимость текущего AMF с целевым срезом
Поэтому перераспределение AMF — не произвольная смена решения в середине регистрации. Оно происходит потому, что ядро сети может точнее выбрать обслуживающий AMF после получения полной информации об идентичности абонента и его сетевых срезах.
Как NSSF определяет новый обслуживающий AMF?
После того как Initial AMF определяет, что не может обслуживать целевой срез, он не выбирает другой AMF самостоятельно. Вместо этого он обращается к Network Slice Selection Function — NSSF.
Initial AMF использует сервис Nnssf_NSSelection для запроса Network Slice Selection. Входные данные могут включать S-NSSAI из подписки UE, сведения о текущем AMF и текущий TAI UE. Цель состоит в том, чтобы определить, какие срезы разрешены в текущей зоне регистрации и какой набор AMF должен предоставлять обслуживание.
Authorized Network Slice Information, возвращаемая NSSF, может включать:
Allowed NSSAI: сетевые срезы, которые UE разрешено использовать в текущих условиях;
Configured NSSAI: конфигурацию срезов, которая при необходимости может быть передана UE;
Target AMF Set: набор AMF, способных обслуживать соответствующий сетевой срез;
Rejected NSSAI: срезы, которые нельзя принять в текущем TA или при соответствующих условиях.
Важно различать Target AMF Set и Target AMF. Первая задача NSSF — определить, какой набор AMF подходит, то есть сузить круг кандидатов с учётом среза и местоположения, а не просто вернуть адрес одного конкретного AMF.
Получив Target AMF Set, Initial AMF может использовать информацию об экземплярах NF, зарегистрированную в NRF, чтобы получить адреса, возможности, веса и рабочее состояние AMF внутри этого набора. После этого он определяет, какой конкретный Target AMF должен продолжить Registration.
Взаимодействие можно представить так:
UDM: предоставляет информацию о подписке UE на сетевые срезы
→ Initial AMF: определяет, что его собственные возможности обслуживания не подходят
→ NSSF: определяет разрешённые срезы и Target AMF Set
→ NRF: предоставляет сведения о доступных экземплярах AMF внутри набора
→ Initial AMF: выбирает Target AMF
Роль NSSF в этой процедуре не сводится к обычной балансировке нагрузки. Он сопоставляет требование к срезу с областью обслуживания AMF, способной поддержать это требование.
Как Registration Request передаётся Target AMF?
После определения Target AMF UE не нужно отправлять полностью новую Registration Request. Сети достаточно передать уже выполняемую процедуру регистрации вместе с необходимым контекстом, чтобы новый AMF продолжил обработку.
Доступны два механизма передачи: косвенная передача через gNB или прямая передача между Initial AMF и Target AMF.
Косвенная передача через gNB
При косвенной передаче Initial AMF отправляет gNB сообщение NGAP Reroute NAS Request. Оно содержит сведения, связанные с исходным Initial UE Message, а также Target AMF Set ID и указывает NG-RAN перенаправить текущий NAS Registration message.
Затем gNB отправляет Target AMF новый Initial UE Message, содержащий NAS-PDU исходной Registration Request. Путь плоскости управления можно представить так:
UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF
UE не требуется повторно выполнять RRC-доступ. NG-RAN просто перенаправляет существующее сообщение NAS Registration к подходящему AMF.
Прямая передача между AMF
При прямой передаче Initial AMF не отправляет сообщение обратно через gNB. Вместо этого он напрямую передаёт N1 message и Registration Context в Target AMF через сервисный интерфейс 5GC.
Initial AMF вызывает Namf_Communication_N1MessageNotify и отправляет полную Registration Request вместе с Registration Context Container в Target AMF.
Передаваемая информация не ограничивается одним NAS-сообщением. Registration Context также может включать UE Context, Access Type, сведения о gNB, User Location, Allowed NSSAI, Configured NSSAI, Rejected NSSAI и другие данные, необходимые для продолжения обработки регистрации.
UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF
Сигнальные пути различаются, но цель одна: Target AMF получает NAS-сообщение и контекст, необходимые для продолжения Registration без перезапуска всей процедуры Initial Registration.
После принятия процедуры Target AMF завершает оставшуюся обработку регистрации и отправляет UE Registration Accept. Ответ отражает результаты выбора среза и перераспределения AMF и может содержать Allowed NSSAI, Configured NSSAI, Rejected NSSAI и вновь назначенный 5G-GUTI.
С точки зрения UE важно, что регистрация успешно завершается, а сеть сообщает доступные в текущей зоне срезы и новый контекст мобильности 5GS. Внутренняя смена обслуживающего AMF остаётся прозрачной для UE.
Как проверить перераспределение AMF в сигнальной трассировке?
Initial Registration с перераспределением AMF легко принять за аномальную маршрутизацию регистрации или неудачный первоначальный выбор AMF. Более эффективный способ диагностики — не сравнивать номера сообщений по одному, а проследить две основные линии: определение среза и передачу контекста.
Нормальная последовательность сигнализации должна позволять инженеру ответить на следующие вопросы:
Почему Registration Request сначала поступил именно в этот Initial AMF?
→ Откуда Initial AMF получил Subscribed / Default NSSAI UE?
→ Что заставило AMF определить, что он не может продолжать обслуживание UE?
→ Какой Target AMF Set вернул NSSF?
→ Какой конкретный Target AMF был выбран в итоге?
→ По какому пути был передан Registration Context?
Если Initial AMF уже получил сведения о подписке на срезы и определил, что не может обслуживать UE, но после этого не следует процедура выбора NSSF, следует проверить обнаружение NSSF, запрос Nnssf_NSSelection и связанную конфигурацию срезов.
Если NSSF возвращает Target AMF Set, но конкретный Target AMF определить не удаётся, следующими объектами проверки должны быть конфигурация AMF Set, NF Profiles в NRF, состояние экземпляров AMF и сведения об их возможностях.
Если присутствует NGAP Reroute NAS Request, но Target AMF так и не получает новый Initial UE Message, фокус диагностики следует перенести с выбора среза на перенаправление NAS в gNB и доступность N2 до Target AMF.
При использовании прямой передачи в трассировке следует искать Namf_Communication_N1MessageNotify и Registration Context, а не ожидать Reroute NAS Request, которого на этом пути не будет.
Если рассматривать процедуру целиком, перераспределение AMF решает конкретную задачу: при первом выборе AMF доступная информация неполна, а после получения полной идентичности абонента и сведений о подписке на срезы ядро сети корректирует решение об обслуживающем AMF.
Когда UE впервые входит в сеть, gNB может иметь лишь ограниченные сведения GUAMI, информацию Requested NSSAI или свою конфигурацию AMF по умолчанию. После аутентификации и получения данных подписки 5GC наконец может определить, какие срезы разрешено использовать абоненту. Затем NSSF преобразует требование к срезу в Target AMF Set, а NRF помогает определить конкретный экземпляр AMF, который сможет продолжить Registration.
Поэтому наиболее полезный вопрос при анализе этого сигнального потока звучит не так: «Почему AMF изменился в середине регистрации?», а так: на каком этапе сеть наконец получила достаточно информации, чтобы определить, какой AMF должен продолжить обслуживание UE?
Часто задаваемые вопросы
Перераспределение AMF — это то же самое, что балансировка нагрузки в AMF Pool?
Нет. Балансировка нагрузки в AMF Pool обычно связана с ёмкостью, весами и распределением высокой доступности между несколькими экземплярами AMF. В данной процедуре перераспределение AMF запускается потому, что Initial AMF не может обслуживать сетевой срез, который в итоге требуется UE. Оба механизма могут привести к выбору другого обслуживающего AMF, но условия запуска и логика сигнализации принципиально различаются.
Требует ли любое развертывание Network Slicing выбора NSSF и перераспределения AMF?
Нет. Даже при использовании Network Slicing перераспределение AMF не требуется, если AMF, первоначально выбранный gNB, уже способен обслуживать срез, который в итоге нужен UE. Перераспределение — это условная ветвь регистрации, а не обязательный шаг в каждой сети со slicing.
Может ли UE напрямую определить, что AMF изменился во время регистрации?
С точки зрения UE главное — успешность Registration и значения Allowed NSSAI, Configured NSSAI, Rejected NSSAI и 5G-GUTI, возвращаемые сетью. Перераспределение AMF и передача Registration Context являются внутренними процедурами управления 5GC и в значительной степени прозрачны для UE.
Косвенная или прямая передача всегда встречается чаще?
Универсальный вывод нельзя сделать только из определения процедуры. Используемый механизм зависит от архитектуры развертывания 5GC, реализации поставщика, возможностей сервисного взаимодействия между AMF, а также конфигурации RAN и ядра сети. При реальной диагностике следует ориентироваться на сигнальный путь, наблюдаемый в рабочей сети.
