В сети 5G после завершения регистрации UE ядру сети необходимо сохранять общее представление о его местоположении, чтобы устройство можно было найти при процедуре пейджинга, входящих сервисах или поступлении нисходящих данных. Однако UE не остаётся на одном месте. Оно может перемещаться из одной Tracking Area в другую или даже покинуть зону обслуживания текущего AMF. Если бы UE выполняло новую регистрацию после каждого перемещения, объём сигнализации плоскости управления стал бы чрезмерным. Если же местоположение никогда не обновлялось бы, сеть со временем могла бы потерять понимание того, где искать UE. Mobility Registration Update предназначено для баланса между точностью местоположения и сигнальной нагрузкой.
При первом изучении сигнализации 5GC часто возникает вопрос: если UE уже зарегистрировано, зачем после перемещения в новую область снова отправлять Registration Request? Всегда ли переход к другому gNB запускает обновление? Всегда ли вход в новую Tracking Area означает необходимость смены AMF? Все эти вопросы сводятся к одному принципу: UE остаётся в состоянии 5GS Registered, но его текущее местоположение может оказаться за пределами Registration Area, ранее назначенной сетью. Поэтому 5GC должен обновить местоположение UE, определить, должен ли обслуживающий AMF остаться прежним, и назначить Registration Area для следующего этапа мобильности. Это не повторная регистрация после включения питания, и UE не регистрируется заново при каждой смене соты. Это механизм поддержания непрерывности контекста мобильности 5GS.
Выход из Registration Area — ключевое условие запуска обновления мобильности
Регистрация в 5GC не ограничивается Initial Registration. Поле 5GS registration type в Registration Request различает такие процедуры, как Initial Registration, Mobility Registration Update, Periodic Registration Update и Emergency Registration. В сценариях мобильности одним из наиболее частых источников путаницы является разница между Tracking Area (TA) и Registration Area.
TA — одна из базовых областей, используемых сетью для управления местоположением, тогда как Registration Area представляет собой набор TA, внутри которого AMF разрешает UE оставаться зарегистрированным. Registration Area может содержать одну TA или несколько. Предположим, AMF обслуживает TA1, TA2, TA3 и TA4, но для конкретного UE на основании его характера перемещений назначает текущей Registration Area только TA1 и TA2. При перемещении из TA1 в TA2 UE всё ещё находится в зарегистрированной области и не обязано выполнять Mobility Registration Update только потому, что изменилась TA.
Ситуация меняется, когда UE переходит в TA3, а TA3 не входит в текущую сохранённую Registration Area. UE обнаруживает, что текущий TAI находится за пределами зарегистрированной области, отправляет новый NAS Registration Request и устанавливает 5GS registration type в mobility registration updating. Поэтому смена соты сама по себе не запускает Mobility Registration Update, и даже смена TA не всегда приводит к обновлению. Типичный триггер — вход в TA, находящуюся за пределами текущей Registration Area UE.
Именно для этого существует понятие Registration Area. Оно позволяет UE перемещаться в пределах заданного диапазона без взаимодействия с 5GC при каждом пересечении границы TA, помогая сбалансировать точность местоположения и нагрузку сигнализации плоскости управления. Сеть может назначить более широкий список TA для UE с большим радиусом мобильности или уменьшить Registration Area, если требуется более точное отслеживание местоположения. Таким образом, сама Registration Area является частью политики управления мобильностью.
Как Registration Request переносит существующее состояние мобильности обратно в 5GC?
Наиболее очевидное отличие Mobility Registration Update от Initial Registration заключается в том, что UE не является полностью неизвестным абонентом. Оно уже завершило регистрацию в 5GS и обычно сохраняет такие данные, как назначенный сетью 5G-GUTI, Registration Area и соответствующий NAS-контекст. Поэтому новый Registration Request используется не для формирования идентичности с нуля. По сути, он сообщает сети: «Я то же UE, которое вам уже известно, но моё местоположение изменилось».
Сначала UE устанавливает доступ к плоскости управления через новый gNB. Затем gNB передаёт NAS Registration Request к AMF внутри NGAP Initial UE Message. Помимо NAS-PDU, Initial UE Message содержит сведения о местоположении доступа, например текущие NR-CGI и TAI. В типичном Mobility Registration Update Registration Request может содержать несколько важных информационных элементов: 5GS registration type определяет процедуру как mobility registration updating; 5G-GUTI помогает сети определить AMF или GUAMI, связанный с предыдущей регистрацией UE; Last Visited Registered TAI даёт ссылку на ранее зарегистрированное местоположение; UE Security Capability описывает поддерживаемые алгоритмы NAS для шифрования и защиты целостности; PDU Session Status показывает, какие PDU-сессии UE считает активными; Requested NSSAI при необходимости указывает запрошенные UE сетевые срезы.
Поэтому при анализе трассы первым вопросом должно быть не то, выполняется ли аутентификация позднее. Сначала нужно проверить, что сам Registration Request однозначно определяет процедуру как Mobility Registration Update, а не Initial Registration. Если тип регистрации истолкован неверно, весь последующий поток сигнализации легко анализировать с неправильной точки зрения.
Почему обновления в пределах одного AMF и между AMF идут по разным путям?
Выход из Registration Area не обязательно означает выход из зоны обслуживания текущего AMF. Это различие напрямую определяет сложность дальнейшей процедуры сигнализации и является одной из первых развилок, которые нужно установить при анализе Mobility Registration Update.
Serving AMF остаётся прежним
Предположим, AMF обслуживает и TA1, и TA2, а сеть ранее назначила UE только TA1 в качестве Registration Area. При перемещении UE из TA1 в TA2 область TA2 оказывается вне текущей Registration Area, поэтому требуется Mobility Registration Update. Однако TA2 всё ещё находится в зоне обслуживания того же AMF.
В этом случае реального перехода от Old AMF к New AMF нет. Текущий AMF уже хранит контекст мобильности UE и должен лишь обработать новое местоположение, обновить Registration Area и освежить необходимые сведения политики или контекста. Registration Area меняется, но Serving AMF остаётся прежним.
Serving AMF меняется
Процедура становится сложнее, когда UE переходит из TA, обслуживаемой одним AMF, в TA, которую обслуживает другой AMF. Например, UE могло завершить регистрацию под AMF1 и получить 5G-GUTI, связанный с AMF1. После перемещения через новый gNB в зону обслуживания AMF2 New AMF должен понять, что это за UE, какой AMF обслуживал его ранее и какой контекст можно использовать повторно.
Поэтому Mobility Registration Update между AMF — это не только обновление местоположения. Оно также включает передачу контекста управления мобильностью UE от прежнего Serving AMF к новому.
Как New AMF находит Old AMF и получает контекст UE?
В сценарии мобильности между AMF первая задача New AMF после получения Registration Request — не выяснить, может ли абонент установить сервис передачи данных, а определить, какой AMF ранее управлял UE. Здесь важную роль играет 5G-GUTI. Сведения, связанные с GUAMI и содержащиеся во временной идентичности, помогают сети определить AMF, ранее обслуживавший UE. Затем New AMF может определить Old AMF и запросить существующий UE Context через сервис Namf_Communication.
Типовая логика проста: UE отправляет Mobility Registration Update со своим прежним 5G-GUTI; New AMF извлекает из 5G-GUTI идентификатор, связанный с AMF; определяется Old AMF; New AMF запрашивает UE Context; Old AMF возвращает контекст мобильности, пригодный для передачи. Эти сведения помогают New AMF восстановить данные идентичности и мобильности, такие как SUPI, GPSI, PEI и части Access and Mobility Context, чтобы новый Serving AMF продолжил работу на основе уже существующего состояния UE, а не рассматривал устройство как полностью неизвестное.
Получение контекста от Old AMF не означает, что все последующие процедуры безопасности всегда можно пропустить. Если имеющихся данных идентичности или контекста безопасности недостаточно, сеть всё ещё может повторно запросить SUCI UE и выполнить проверку идентичности или аутентификацию 5G-AKA в соответствии с текущими условиями безопасности. Поэтому при анализе трассы следует избегать двух жёстких предположений: Mobility Registration Update не всегда требует полной новой аутентификации, но наличие доступного Old AMF Context также не гарантирует, что аутентификация никогда не повторится. Появление Identity Request или полного 5G-AKA зависит от переданного UE Context, NAS Security Context и политики сети.
Как UDM, NRF и PCF завершают переход обслуживания к новому Serving AMF?
Получение UE Context от Old AMF не означает, что сервисная связь полностью перенесена. В 5GC местоположение пользователя и состояние обслуживания распределены между несколькими сетевыми функциями. В частности, UDM должен знать, какой AMF теперь отвечает за обслуживание UE.
New AMF может использовать NRF для обнаружения UDM, предоставляющего необходимые сервисы, а затем зарегистрировать новую 3GPP Access Registration в UDM. Этот шаг особенно важен в сценарии между AMF, потому что запись о Serving AMF в UDM должна перейти от Old AMF к New AMF. После этого UDM может инициировать соответствующий Deregistration Notification в сторону Old AMF, чтобы предыдущая сервисная связь была освобождена.
New AMF также нужны актуальные Access and Mobility Subscription Data, которые могут включать GPSI, Subscribed NSSAI, UE-AMBR, параметры периодической регистрации, ограничения RAT и ограничения доступа по зонам. Если последующая обработка PDU Session требует выбора SMF, AMF также может получить SMF Selection Subscription Data, включая сведения DNN и Default DNN, связанные с соответствующим S-NSSAI, и подписаться на изменения этих данных. PCF дополняет процесс, предоставляя Access and Mobility Policy. New AMF может выбрать подходящий PCF и создать AM Policy Association для получения сведений о политике мобильности, например ограничений по зонам.
Эти шаги решают разные задачи. Old AMF Context сообщает New AMF, в каком состоянии UE находилось ранее. UDM Registration сообщает ядру сети, какой AMF теперь обслуживает UE. Subscription Data определяют, какими возможностями абоненту разрешено пользоваться. PCF Policy сообщает AMF, какие правила мобильности и доступа действуют сейчас. Поэтому Mobility Registration Update нельзя сводить к формуле «AMF обновляет TAI». В сценарии между AMF процедура также передаёт ответственность за управление мобильностью от одного AMF к другому.
Как Registration Accept определяет следующий диапазон мобильности UE?
После завершения обработки идентичности, контекста, данных подписки и политик AMF должен применить новое состояние регистрации и к gNB, и к UE. В типичном процессе AMF может использовать NGAP Initial Context Setup Request для создания или обновления UE-контекста в gNB и одновременно передать UE сообщение NAS Registration Accept.
Самое важное в Registration Accept — не только подтверждение успешной регистрации. Сообщение также передаёт параметры, определяющие работу UE на следующем этапе мобильности. После перехода между AMF может быть назначен новый 5G-GUTI, отражающий новый Serving AMF. Allowed NSSAI определяет сетевые срезы, разрешённые UE в текущий момент. T3512 задаёт тайминг будущего Periodic Registration Update. TA List, то есть Registration Area, показывает UE, по каким TA оно может перемещаться, оставаясь зарегистрированным и не запуская очередной Mobility Registration Update того же типа.
После завершения соответствующей обработки контекста gNB возвращает Initial Context Setup Response, а UE отправляет Registration Complete. На этом текущий Mobility Registration Update завершается. С точки зрения переходов состояния поток можно описать так: UE покидает существующую Registration Area; Registration Request переносит прежнюю мобильную идентичность в 5GC; сеть определяет, нужно ли менять Serving AMF; при необходимости UE Context передаётся от Old AMF; New AMF завершает регистрацию в UDM и получает необходимые данные подписки и политики; Registration Accept передаёт новый 5G-GUTI и Registration Area; после чего UE возвращает Registration Complete.
Диагностику можно вести по той же цепочке состояний. Если Registration Request достигает New AMF, но Old AMF не удаётся найти, следует проверить 5G-GUTI, GUAMI и адресацию AMF. Если Old AMF Context успешно получен, но процедура останавливается на этапе UDM, нужно проверить обнаружение UDM, AMF Registration и получение данных подписки. Если внутренняя обработка в ядре завершена, но Registration Accept не доходит до UE, анализ следует продолжить по результатам политики, ограничениям по зонам, нисходящей NGAP-сигнализации и установлению контекста RAN. Цель понимания 5GC Mobility Registration Update — не запоминать десятки сообщений HTTP/2 и NGAP, а понять, как сеть после перемещения зарегистрированного UE отвечает на три вопроса: где сейчас находится UE, какой AMF должен продолжать им управлять и какая Registration Area должна действовать на следующем этапе мобильности?
Часто задаваемые вопросы
Выполняет ли UE Mobility Registration Update каждый раз при входе в новую Tracking Area?
Не обязательно. Ключевой вопрос — входит ли новая TA в текущую Registration Area UE. Если AMF уже назначил TA1 и TA2 как Registration Area UE, переход из TA1 в TA2 обычно не запускает обновление только из-за смены TA. Типичный триггер — вход в TA, находящуюся за пределами Registration Area.
Всегда ли Mobility Registration Update меняет AMF?
Нет. UE может покинуть текущую Registration Area, но новая TA всё ещё может относиться к зоне обслуживания того же AMF. В таком случае Serving AMF не меняется. Передача контекста от Old AMF к New AMF требуется только тогда, когда UE переходит в область, которую должен обслуживать другой AMF.
Повторяется ли 5G-AKA при каждом Mobility Registration Update?
Фиксированного правила предполагать нельзя. Повторение процедур идентификации или 5G-AKA зависит от доступного UE Context, NAS Security Context и политики сети. Если действительный контекст можно продолжать использовать, некоторые процедуры безопасности могут не требовать полного повторения. Если данных идентичности или условий безопасности недостаточно, сеть может снова выполнить необходимые шаги аутентификации.
Чем 5GC Mobility Registration Update отличается от обновления при переходе UE с 4G на 5G?
В обоих сценариях может использоваться тип регистрации Mobility Registration Update, но источник контекста мобильности различается. Мобильность полностью внутри 5GS обычно связана с контекстом мобильности между Old AMF и New AMF. Сценарий межсетевого взаимодействия в режиме ожидания при переходе с 4G на 5G может дополнительно включать MME, N26 и преобразование между контекстами EPS и 5GS. При анализе сигнальной трассы первым шагом следует определить, перемещается ли UE внутри 5GS или входит в 5GC из EPC.
