При поиске неисправностей на объекте одна из самых простых ошибок — увидеть RRC Release и решить, что дерегистрация UE уже завершена. Радиосоединение действительно могло быть разорвано, а UE мог перестать передавать данные, однако контекст регистрации в AMF, PDU-сессия в SMF, N4-сессия в UPF, ассоциации политик в PCF и регистрационные записи в UDM не исчезают одновременно лишь потому, что «пропал сигнал». При анализе трассировки важно проследить цепочку очистки между сетевыми функциями после Deregistration Request: как AMF определяет область дерегистрации, как SMF поручает UPF удалить ресурсы пользовательской плоскости и в каком объёме должны быть освобождены связи PCF и UDM.
Дерегистрация, инициированная UE — это контролируемая процедура вывода уже зарегистрированного UE из 5GS. Она начинается с NAS Deregistration Request и может включать освобождение PDU-сессий, удаление N4-сессий и туннелей пользовательской плоскости в UPF, завершение связей SM Policy и AM Policy, удаление соответствующего регистрационного состояния в UDM и, наконец, освобождение сигнального соединения между UE и сетью доступа. Обычная дерегистрация и выключение в первой части процедуры могут выглядеть похоже, но завершаются по-разному: в одном случае UE ждёт Deregistration Accept, в другом — не остаётся в сети только ради получения подтверждения. При разборе трасс это различие легко пропустить.
Почему дерегистрация — это больше, чем просто перевод UE в состояние «офлайн»?
После завершения Initial Registration и установления PDU-сессии 5GC хранит не один флаг «онлайн». AMF поддерживает контекст регистрации и мобильности, SMF управляет контекстом PDU-сессии, UPF хранит N4-сессию вместе с ресурсами пересылки пользовательской плоскости, такими как FAR, QER и URR, UDM хранит регистрационные связи AMF и SMF, а PCF может поддерживать ассоциации политик AM, UE или SM.
Если UE просто исчезает из сети, эти ресурсы не удаляются автоматически в один и тот же момент. Это особенно важно, когда ещё существуют одна или несколько PDU-сессий. Сеть должна знать, какие сессии следует освободить, какие правила пользовательской плоскости удалить и какие подписки или ассоциации политик больше не требуется сохранять.
Поэтому инициированная UE дерегистрация выполняет упорядоченное удаление регистрационного состояния и связанных с ним ресурсов:
UE указывает, что текущая регистрация 5GS должна быть завершена
→ AMF определяет область дерегистрации
→ Связанные PDU-сессии освобождаются
→ SMF поручает UPF удалить ресурсы пользовательской плоскости
→ Связи сессий и политик удаляются
→ Регистрационное состояние удаляется
→ Сигнальное соединение со стороны доступа освобождается
Именно поэтому дерегистрацию нельзя путать с RRC Release или обычным освобождением соединения N2. Освобождение соединения RAN означает только завершение текущего сигнального соединения доступа. Дерегистрация действует на более высоком уровне и удаляет регистрационную связь 5GS вместе со связанным состоянием сессий и политик. Если в трассе присутствует только RRC Release, вывод о том, что UE уже дерегистрирован, легко приводит к путанице между «освобождением соединения доступа» и «удалением регистрации».
Как Deregistration Request определяет способ выхода UE и тип доступа, из которого он выходит?
Когда UE активно покидает 5GS, он отправляет AMF сообщение NAS Deregistration Request. При анализе сигнализации сначала нужно проверять не наличие последующих PFCP-сообщений, а поля Deregistration type и Access Type в запросе.
Deregistration type прежде всего сообщает сети, относится ли процедура к случаю выключения. С инженерной точки зрения инициированная UE дерегистрация обычно встречается в двух ситуациях: обычная дерегистрация, когда UE корректно завершает работу в сети, и выключение, когда UE сообщает, что собирается выключиться или перейти в эквивалентное состояние завершения работы.
Access Type отвечает на другой вопрос: какой именно доступ дерегистрируется. UE может дерегистрироваться только из 3GPP-доступа, только из non-3GPP-доступа или, если оба типа доступа в одной PLMN обслуживаются одним AMF, процедура при соответствующих условиях может охватывать оба. Поэтому «дерегистрация UE» не всегда означает одновременное удаление всего состояния доступа, связанного с этим UE.
Deregistration Request также содержит идентификационные данные UE. Если доступен действительный 5G-GUTI, UE может использовать его, чтобы помочь AMF связать NAS-сообщение с существующим контекстом UE. Если действительного 5G-GUTI нет, обработка идентификатора зависит от того, какая 5GS-идентификация доступна UE в данный момент. Для AMF корректное сопоставление этого NAS-сообщения с существующим контекстом UE является обязательным условием освобождения нужных PDU-сессий и связей политик.
При обычной дерегистрации UE отправляет запрос и ждёт подтверждения завершения от сети. При выключении задача состоит в том, чтобы как можно быстрее передать указание «я ухожу» и продолжить выключение, поэтому обработка отличается. При обычной дерегистрации T3521 может контролировать период ожидания Deregistration Accept, тогда как процедура выключения не ждёт подтверждения сети таким же образом.
Почему AMF сначала проверяет, осталась ли у UE PDU-сессия?
После получения Deregistration Request одним из ключевых решений AMF является определение того, существуют ли на целевом доступе ещё установленные PDU-сессии.
Если у UE нет соответствующей PDU-сессии, отсутствует отдельная пользовательская сессия, которую нужно демонтировать, поэтому процедура может быть значительно короче. Но если одна или несколько PDU-сессий всё ещё активны, AMF не может просто удалить собственный регистрационный контекст, потому что SMF и UPF продолжат считать эти сессии существующими.
Для каждой PDU-сессии, которую требуется освободить, AMF может вызвать Nsmf_PDUSession_ReleaseSMContext в направлении соответствующего SMF. Это можно понимать как явную команду AMF уровню управления сессиями: UE покидает целевой доступ, поэтому связанный SM Context больше не должен поддерживаться. Только после получения этой команды SMF может продолжить удаление N4-сессии, завершение связей политик и очистку соответствующего регистрационного состояния в UDM.
Это также подчёркивает отличие дерегистрации от самостоятельного освобождения PDU-сессии. Освобождение одной PDU-сессии не означает, что UE покидает 5GS; UE может оставаться в состоянии 5GS Registered. Напротив, когда UE инициирует дерегистрацию, PDU-сессии, связанные с целевым доступом, обычно должны быть очищены в рамках более широкой процедуры дерегистрации.
Поэтому, если трасса содержит Deregistration Request, но после него нет Nsmf_PDUSession_ReleaseSMContext, это не следует сразу считать пропущенной сигнализацией. Сначала нужно подтвердить, действительно ли на соответствующем Access Type у UE была установлена PDU-сессия. Если PDU-сессии не было, отсутствие процедуры освобождения N4 может быть именно тем, что предусмотрено потоком.
Как SMF и UPF фактически демонтируют пользовательскую плоскость?
После того как AMF отправляет SMF запрос на освобождение PDU-сессии, SMF отвечает за удаление связанных ресурсов пользовательской плоскости. Если существует сессия в UPF, SMF освобождает её через интерфейс N4.
В типичном случае SMF отправляет PFCP Session Deletion Request. UPF использует соответствующий F-SEID или контекст N4-сессии, чтобы удалить состояние пересылки пользователя, и возвращает PFCP Session Deletion Response. Затем удаляются туннели пользовательской плоскости, правила пересылки и связанный контекст PDU-сессии. Очистка не ограничивается одним туннелем; также удаляется состояние правил, связанное с этой N4-сессией, включая FAR, QER, URR и другие применимые правила.
Управляющую связь можно представить так:
UE → AMF: я хочу дерегистрироваться
→ AMF → SMF: освободить контекст PDU-сессии этого UE
→ SMF → UPF: удалить N4-сессию и ресурсы пользовательской плоскости
→ UPF → SMF: подтвердить удаление
→ SMF → AMF: освобождение SM Context завершено
Если сессия использует динамический PCC, SMF также может потребоваться завершить соответствующую ассоциацию SM Policy, например через Npcf_SMPolicyControl_Delete. Если освобождаемая сессия является последней PDU-сессией, которой этот SMF управляет для соответствующих DNN и S-NSSAI, SMF также может отменить подписку на изменения Session Management Subscription Data в UDM и использовать Nudm_UECM_Deregistration для удаления из UDM связи между SMF и соответствующим DNN/PDU Session.
С точки зрения трассировки UPF точкой, где дерегистрация действительно достигает пользовательской плоскости, является не сам NAS Deregistration Request, а последующее освобождение N4-сессии. Только после завершения этого шага ресурсы пересылки исходной PDU-сессии действительно удаляются из пользовательской плоскости.
Почему UDM и PCF всё ещё требуется дополнительная очистка контекста?
После освобождения PDU-сессии пользовательская плоскость уже может быть удалена, однако в 5GC всё ещё могут оставаться связи управляющей плоскости. Для полного завершения дерегистрации сеть должна определить, какие подписки, регистрации и ассоциации политик остаются действительными, а какие следует удалить.
На стороне управления сессиями, если SMF больше не обслуживает последнюю PDU-сессию пользователя для соответствующих DNN и S-NSSAI, он может отменить подписку на обновления SM Data в UDM и удалить связанную SMF Registration. Это предотвращает дальнейшую отправку UDM обновлений Session Management в SMF, который больше не обслуживает эту сессию.
На стороне политики доступа и мобильности, если UE больше не зарегистрирован ни через один соответствующий Access Type и между AMF и PCF существует AM Policy Association, AMF должен завершить эту связь. Если существует UE Policy Association, она также должна быть освобождена при выполнении соответствующих условий. Если AMF больше не поддерживает ни одной действительной регистрации для этого UE, регистрационная связь AMF в UDM также может потребовать удаления через Nudm_UECM_Deregistration.
Здесь есть важная граница: не следует считать, что весь контекст PCF и UDM обязан исчезнуть только потому, что была выполнена одна процедура дерегистрации. Если UE остаётся зарегистрированным через другой Access Type или тот же SMF всё ещё управляет другими соответствующими PDU-сессиями этого UE, некоторые связи могут по-прежнему быть необходимы.
Поэтому очистка при дерегистрации — это не просто фиксированная последовательность DELETE-запросов. Она следует одному принципу: удалять только то состояние, которое утратило практический смысл из-за этой дерегистрации, сохраняя контекст, который продолжает использоваться другим доступом или другой сессией. Это один из аспектов, которые легче всего неверно интерпретировать в развёртываниях с несколькими доступами и несколькими PDU-сессиями.
Почему обычная дерегистрация и выключение завершаются по-разному?
Обычная дерегистрация и выключение в первой части процедуры могут обе запускать освобождение PDU-сессий и ресурсов ядра сети, но отличаются тем, как завершается процедура на стороне UE.
При обычной дерегистрации после отправки Deregistration Request UE ждёт подтверждения сети. Когда AMF завершает необходимую обработку, он возвращает Deregistration Accept, явно сообщая UE, что сеть приняла дерегистрацию. NAS-механизмы, такие как T3521, могут контролировать этот период ожидания. Если T3521 истекает, UE выполняет предусмотренную протоколом повторную передачу или обработку исключения, а не просто считает дерегистрацию завершённой.
Если дерегистрация относится к 3GPP-доступу и между AMF и NG-RAN всё ещё существует сигнальное соединение N2, AMF может затем выполнить N2 UE Context Release, чтобы завершить соответствующее сигнальное соединение на стороне доступа.
Выключение обрабатывается иначе. UE собирается выключиться, поэтому нет смысла оставлять его в сети только ради ожидания подтверждающего сообщения. Когда Deregistration type указывает на выключение, AMF не требует от UE получить Deregistration Accept перед выходом так, как это происходит при обычной дерегистрации. После того как UE предпринял разумную попытку передать Deregistration Request, оно может продолжить выключение.
Это различие особенно важно в пакетных трассах:
Обычная дерегистрация
Deregistration Request
→ Ядро сети освобождает связанные ресурсы
→ Deregistration Accept
→ Освобождение сигнализации / AN
выключение
Deregistration Request
→ Ядро сети освобождает связанные ресурсы
→ UE не ждёт Deregistration Accept перед завершением выключения
Поэтому отсутствие Deregistration Accept в трассе выключения не означает автоматически, что процедура завершилась с ошибкой. Сначала нужно проверить, соответствует ли Deregistration type обычной дерегистрации или выключению. Если UE уже выключилось, потеряло радиосвязь или не успело получить ответ, сеть позже может использовать такие механизмы, как Mobile Reachable Timer и Implicit Deregistration, для обработки ненормального исчезновения UE.
Часто задаваемые вопросы
Гарантируется ли доставка Deregistration Request в AMF при выключении UE?
Нет. Процедура выключения предусматривает, что UE предпримет максимально возможную попытку отправить запрос на дерегистрацию перед выключением, однако сеть может его не получить, если UE уже потеряло покрытие, радиолиния отказала или питание внезапно исчезло. Поэтому 5GC по-прежнему нужны сетевые механизмы, такие как Mobile Reachable Timer и Implicit Deregistration, для обработки UE, которые исчезают неожиданно.
Всегда ли дерегистрация UE вызывает PFCP Session Deletion?
Нет. Если на целевом Access Type нет установленной PDU-сессии, отсутствует соответствующая N4-сессия пользовательской плоскости, которую нужно освободить, поэтому этапы SMF и UPF, связанные с очисткой PDU-сессии, могут отсутствовать. PFCP Session Deletion требуется только тогда, когда соответствующая PDU-сессия и её ресурсы пользовательской плоскости реально существуют.
Являются ли дерегистрация и освобождение PDU-сессии одной и той же процедурой?
Нет. Освобождение PDU-сессии удаляет конкретную сессию данных, при этом UE может оставаться в состоянии 5GS Registered. Дерегистрация удаляет регистрационную связь UE с 5GS. При дерегистрации UE существующие PDU-сессии обычно должны быть освобождены как связанные ресурсы, однако две процедуры работают на разных уровнях и имеют разные цели.
Почему после дерегистрации UE часть контекста UDM или PCF может сохраниться?
Сначала нужно проверить, к какому Access Type относится дерегистрация и остаётся ли UE зарегистрированным через другой доступ. Если у UE сохраняется другой действующий доступ, другие используемые PDU-сессии или ассоциации политик, часть контекста может потребоваться сохранить. Дерегистрацию нельзя трактовать как безусловное удаление всего состояния UE во всём 5GC.
