Какому абоненту принадлежит этот UE?
Разрешён ли ему доступ к текущей сети?
Существует ли прежний контекст мобильности, который ещё можно использовать повторно?
На какие сетевые срезы и возможности доступа подписан UE и какой AMF должен его обслуживать?
Когда устройство 5G включается, сеть ядра должна ответить на эти базовые вопросы до того, как смогут быть установлены сервисы пользовательских данных. Это происходит в процессе первичной регистрации 5G. С точки зрения трассировки сигнализации процедура значительно сложнее простого сценария «Registration Request, за которым следует успешная регистрация». Между отправкой UE сообщения Registration Request и окончательным возвратом Registration Complete сеть может выполнять обработку идентификаторов, получение контекста прежнего AMF, аутентификацию 5G-AKA, установление безопасности NAS, регистрацию в UDM, получение данных подписки и обработку политики доступа.
Распространённая ошибка при изучении этой процедуры — попытка запомнить каждое сообщение по порядку. Гораздо практичнее понимать, какую задачу AMF решает на каждом этапе. Полный путь сигнализации можно представить так: идентифицировать запрашивающий UE, установить доверенную идентичность, дополнить необходимый контекст абонента и только после этого завершить регистрацию.
Первичная регистрация устанавливает право UE на доступ к сети
Регистрация в 5GS не является одной-единственной процедурой. В зависимости от причины UE может выполнять Initial Registration, Mobility Registration Update, Periodic Registration Update или Emergency Registration. Применимую процедуру UE указывает в поле 5GS registration type сообщения Registration Request.
Initial Registration обычно выполняется, когда UE включается и входит в 5GS. В учебных целях её часто сравнивают с процедурой Attach в LTE/EPC, однако считать их идентичными не следует. В сервисно-ориентированной архитектуре 5G Core управление мобильностью, аутентификация, данные подписки и управление политиками распределены между такими сетевыми функциями, как AMF, AUSF, UDM и PCF. Поэтому одна процедура регистрации может включать несколько сервисных взаимодействий между сетевыми функциями.
Ещё важнее то, что Initial Registration в первую очередь устанавливает состояние управления доступом и мобильностью, а не сессию пользовательских данных. Сеть должна идентифицировать UE, сформировать контекст мобильности, определить разрешённую NSSAI и применимые ограничения по зонам, а также создать отношения безопасности, необходимые для последующей сигнализации. Только после выполнения этих условий у UE появляется основа для запроса PDU Session.
Поэтому получение Registration Accept не означает автоматически, что абонент уже может выходить в Интернет. Регистрация и установление PDU Session — отдельные этапы работы 5G Core.
Registration Request вводит UE в процедуру регистрации 5G Core
Процедура регистрации в сети ядра начинается с NAS Registration Request. Сначала UE отправляет NAS-сообщение по радиоинтерфейсу на gNB. Затем gNB переносит NAS-PDU к AMF внутри NGAP Initial UE Message. Для инженера сети ядра именно это сообщение является точкой входа во всю процедуру регистрации.
Помимо Registration Request, Initial UE Message передаёт AMF информацию о местоположении доступа, например NR-CGI и TAI. Само NAS-сообщение может содержать такие параметры, как 5GS registration type, 5GS mobile identity, UE Security Capability и Requested NSSAI.
Эти параметры — не просто список возможностей UE. AMF использует их, чтобы определить дальнейший ход регистрации. Registration Type показывает, выполняет ли UE Initial Registration или иной тип обновления регистрации. mobile identity позволяет понять, можно ли связать существующий контекст абонента с данным UE. Requested NSSAI указывает сетевые срезы, запрашиваемые UE, а UE Security Capability предоставляет данные для последующего выбора алгоритмов безопасности NAS.
Есть деталь, которую легко понять неверно: UE, выполняющий Initial Registration, не обязательно полностью лишён предыдущей информации 5G. Если UE всё ещё хранит ранее назначенный 5G-GUTI, он может включить эту идентичность в новый Initial Registration Request. Возможность сети повторно использовать связанную с ней информацию напрямую влияет на следующие этапы процедуры.
Новый AMF определяет идентичность и прежний контекст UE
Рассмотрим UE, который ранее был зарегистрирован в 5GS в Гуанчжоу, затем был выключен, переместился в Пекин и снова включился через пекинский gNB. Теперь UE обслуживается новым AMF, однако он всё ещё может хранить 5G-GUTI, ранее назначенный AMF в Гуанчжоу.
GUAMI, содержащийся в 5G-GUTI, может предоставить информацию, помогающую определить прежний AMF. Если новый AMF считает, что старая сетевая функция всё ещё хранит полезный контекст UE, он может запросить UE Context Transfer через взаимодействие между AMF и получить такие данные, как SUPI, GPSI, PEI и части контекста управления мобильностью.
Это показывает важный момент: «Initial» описывает тип текущей процедуры регистрации. Это не означает, что абонент впервые входит в сеть 5G. UE может продолжать хранить ранее назначенную идентичность 5G, а новый AMF при возможности может повторно использовать контекст старого AMF.
Взаимодействие со старым AMF требуется не при каждой Initial Registration. Если новый AMF уже располагает необходимой информацией об идентичности либо прежний контекст UE недоступен, путь сигнализации может отличаться. Если AMF всё ещё требуется SUCI UE, он может отправить Identity Request, а UE вернёт запрошенную идентичность в Identity Response.
Поэтому отсутствие Identity Request или UE Context Transfer в трассировке пакетов само по себе не указывает на ошибку регистрации. Сначала следует выяснить, какими сведениями об идентичности и контексте AMF уже располагает.
5G-AKA превращает заявленную идентичность в доверенного абонента
Знать, кем UE себя объявляет, недостаточно, чтобы сеть могла ему доверять. Поэтому процедура переходит к одному из важнейших этапов безопасности — аутентификации.
AMF должен определить AUSF, способный аутентифицировать абонента. В сервисно-ориентированном 5G Core это обычно включает обнаружение сетевых функций через NRF. На основе требуемого сервиса и информации об абоненте AMF выбирает подходящий экземпляр AUSF и отправляет запрос аутентификации.
Затем AUSF взаимодействует с функциями аутентификации, связанными с UDM домашней сети. При использовании SUCI домашняя сеть может восстановить соответствующий SUPI и подготовить данные аутентификации, необходимые для 5G-AKA. После этого AMF передаёт UE параметры RAND и AUTN в сообщении NAS Authentication Request. UE выполняет расчёт аутентификации с использованием учётных данных, хранящихся в USIM, и возвращает Authentication Response, содержащий RES*.
Аутентификация не сводится к одному сравнению, выполняемому одной сетевой функцией. Сторона обслуживающей сети и сторона домашней сети выполняют собственные проверки. AMF вычисляет HRES* из ответа UE и сравнивает его с HXRES*. AUSF проверяет возвращённый RES* относительно ожидаемого XRES*. Только после успешного прохождения необходимых проверок сеть принимает идентичность абонента как аутентифицированную.
После аутентификации сеть обычно создаёт или обновляет NAS Security Context. На основании таких данных, как UE Security Capability, AMF выбирает подходящие алгоритмы защиты целостности и шифрования и использует процедуру Security Mode, чтобы защитить последующую критически важную NAS-сигнализацию.
С инженерной точки зрения этот этап формирует чёткую границу безопасности: до аутентификации сеть обрабатывает устройство, запрашивающее доступ; после успешного установления аутентификации и безопасности NAS AMF располагает доверенным и защищённым контекстом плоскости управления UE.
Данные подписки и политики завершают формирование контекста UE
Успешная аутентификация отвечает на вопрос, является ли идентичность абонента подлинной, но AMF всё ещё должен знать, что именно этому абоненту разрешено делать в сети. Следующий этап превращает аутентифицированную идентичность в рабочий контекст доступа и мобильности.
AMF выбирает подходящий UDM и регистрирует себя как AMF, который в данный момент обслуживает SUPI через доступ 3GPP. Эта регистрация важна, потому что UDM должен знать, какой AMF должен впоследствии получать уведомления о мобильности, события дерегистрации или изменения данных подписки данного абонента.
Затем AMF получает Access and Mobility Subscription Data. В зависимости от профиля абонента они могут включать Subscribed NSSAI, UE-AMBR, параметры периодической регистрации, ограничения RAT и ограничения по зонам. Таким образом, аутентификация подтверждает действительность идентичности, а данные подписки отвечают на другой вопрос: что разрешено этому действительному абоненту в текущей сети?
AMF также может получить данные подписки, которые позднее будут использоваться для выбора SMF, включая сведения, связанные с S-NSSAI, DNN и DNN по умолчанию. При чтении трасс сигнализации это часто вызывает путаницу: если SMF Selection Subscription Data уже появляются во время регистрации, означает ли это, что SMF уже участвует в процедуре?
Не обязательно. На этом этапе AMF лишь получает информацию, которая может понадобиться для будущего выбора SMF. Initial Registration не требует одновременного установления PDU Session, поэтому AMF может получить эти данные подписки без создания SM Context и без запуска активной процедуры управления сессиями с SMF.
Для политики доступа AMF также может выбрать PCF и установить AM Policy Association. Политика, возвращаемая PCF, может влиять, например, на ограничения доступа в определённых зонах. К этому моменту контекст UE в AMF развивается от базовой идентичности до совокупности данных об идентичности, безопасности, подписке, сетевых срезах, местоположении и политике.
Registration Accept применяет результат к UE и gNB
Большая часть предыдущей обработки выполняется внутри сети ядра. Однако итоговый результат ещё необходимо доставить в сеть доступа и UE. После выполнения необходимых условий AMF отправляет gNB сообщение Initial Context Setup Request, передавая информацию для создания контекста UE и направляя NAS Registration Accept к UE.
Registration Accept может включать вновь назначенный 5G-GUTI, Allowed NSSAI, таймер периодической регистрации T3512 и применимый список зон отслеживания. Эти параметры определяют, как UE сохраняет регистрацию в 5GS, какие сетевые срезы он может использовать в данный момент и когда позднее должен выполнить Periodic Registration Update.
Одновременно gNB формирует соответствующий контекст UE в рамках процедуры Initial Context Setup. После завершения обработки gNB возвращает Initial Context Setup Response. Затем UE подтверждает результат регистрации, отправляя NAS Registration Complete в AMF.
Таким образом, Registration Accept и Registration Complete — это не просто уведомления об успехе. Они применяют результат регистрации, сформированный внутри сети ядра, одновременно к UE и RAN, приводя сеть, gNB и устройство к согласованному состоянию регистрации 5GS.
Регистрация и установление PDU Session используют разные пути сигнализации
Это различие принципиально важно при анализе полной последовательности сигнализации. После завершения 5GS Initial Registration AMF знает, кто является абонентом, где находится UE, какие зоны доступа и сетевые срезы разрешены и какой контекст безопасности и мобильности действует. Ни один из этих шагов автоматически не создаёт путь пользовательских данных в пользовательской плоскости.
Для доступа в Интернет или корпоративную сеть данных UE всё ещё должен выполнить PDU Session Establishment. На этом этапе SMF отвечает за управление сессиями, выбирает или управляет UPF и настраивает через N4 правила пользовательской плоскости, такие как PDR, FAR, QER и URR. Ресурсы N3 между gNB и UPF также подготавливаются в рамках установления сессии.
При эксплуатационной диагностике это формирует две совершенно разные категории отказов:
Ошибка регистрации: проверять идентичность UE, аутентификацию, безопасность NAS, данные подписки UDM, NSSAI, ограничения по зонам и обработку политик AMF.
Регистрация успешна, но сервис данных не работает: перенести диагностику на PDU Session Establishment, SMF, UPF, сигнализацию N3/N4 и пересылку в пользовательской плоскости, а не многократно проверять Registration Request и Registration Accept.
Чёткое понимание этой границы может значительно сократить диагностику 5GC. Значок 5G на устройстве показывает только то, что радиодоступ и регистрация достигли определённого состояния. Наличие реального соединения данных по-прежнему зависит от процедур управления сессиями и пользовательской плоскости.
Читайте трассу как переход состояний, а не как список сообщений
Стандартные диаграммы сигнализации намеренно делаются исчерпывающими, поскольку должны охватывать разных операторов, сценарии роуминга, типы доступа и необязательные сетевые функции. Однако в трассе реальной сети вовсе не обязательно присутствует каждый шаг эталонной процедуры. Взаимодействия с предыдущим AMF может не быть, Identity Request может не потребоваться, EIR может не использоваться, а стандартный доступ NR не включает сетевые функции, предназначенные только для других типов доступа.
Для диагностики Initial Registration полезнее отслеживать, как изменяется состояние UE:
Registration Request поступает в AMF
→ определяются идентичность UE и прежний контекст
→ устанавливаются аутентификация и безопасность NAS
→ данные подписки получаются из UDM
→ применимая политика доступа получается от PCF
→ AMF завершает формирование контекста регистрации
→ передаётся Registration Accept
→ UE возвращает Registration Complete
Если Registration Request поступил в AMF, но аутентификация так и не начинается, сначала следует проверить обработку идентичности и выбор сетевых функций. Если аутентификация успешна, но Registration Accept не возвращается, продолжите анализ данных UDM, NSSAI, ограничений доступа и обработки политик. Если Registration Accept уже завершён, а проблема состоит в отсутствии пользовательских данных, диагностику нужно быстро перенести на путь сигнализации PDU Session.
Поэтому понимание 5G Initial Registration связано не столько с запоминанием десятков сообщений, сколько с отслеживанием того, как контекст UE внутри AMF постепенно становится полным: от получения запроса на доступ и определения абонента до доказательства доверенности его идентичности и, наконец, определения условий, на которых ему разрешено оставаться зарегистрированным в 5GS.
Часто задаваемые вопросы
Какую функцию выполняет T3512 в Registration Accept?
T3512 управляет поведением UE при периодическом обновлении регистрации после её завершения. UE не остаётся зарегистрированным бесконечно без периодического взаимодействия с управлением мобильностью. Сеть может использовать этот таймер, чтобы определить, когда UE должен выполнить Periodic Registration Update.
Почему EIR отсутствует в некоторых трассах коммерческой регистрации 5G?
Проверка идентичности оборудования является необязательной. Наличие EIR и условия запуска проверка идентичности оборудования зависят от архитектуры и эксплуатационных политик оператора. Поэтому отсутствие сигнализации EIR в остальном нормальной процедуре Initial Registration само по себе не является достаточным признаком неисправности.
Почему N3IWF обычно отсутствует при стандартной регистрации 5G NR?
N3IWF в основном используется для недоверенного non-3GPP-доступа, например в некоторых сценариях подключения по Wi-Fi к 5G Core. Когда UE подключается напрямую через gNB по стандартному доступу 3GPP NR, путь доступа предоставляет NG-RAN, поэтому N3IWF обычно не участвует в сигнализации регистрации.
Почему число операций обнаружения сетевых функций через NRF может различаться в трассах разных производителей?
Реальные реализации 5G Core могут различаться из-за кэширования обнаружения сетевых функций, статической конфигурации, моделей развертывания SCP и специфичной для производителя маршрутизации сервисов. Поэтому полный обмен для обнаружения сетевых функций через NRF не обязан появляться перед каждой сервисной операцией. При анализе трассы следует сопоставлять выбранный экземпляр NF с последующим сервисным запросом, а не оценивать процедуру только по количеству сообщений NRF.
