Durante a análise de falhas em campo, um dos erros mais fáceis é ver um RRC Release e assumir que o desregistro do UE já terminou. A conexão de rádio pode realmente ter sido encerrada e o UE pode ter parado de transmitir dados, mas o contexto de registro no AMF, a sessão PDU no SMF, a sessão N4 no UPF, as associações de política no PCF e os registros no UDM não desaparecem todos ao mesmo tempo simplesmente porque “o sinal sumiu”. Em uma análise de sinalização, o que importa é a cadeia de limpeza entre funções de rede após o Deregistration Request: como o AMF determina o escopo do desregistro, como o SMF instrui o UPF a remover recursos do plano de usuário e até que ponto as associações no PCF e no UDM devem ser liberadas.
Desregistro iniciado pelo UE é o procedimento controlado para retirar do 5GS um UE que já está registrado. Ele começa com um NAS Deregistration Request e pode envolver a liberação de sessões PDU, a exclusão de sessões N4 e túneis do plano de usuário no UPF, o encerramento de associações SM Policy e AM Policy, a remoção do estado de registro relacionado no UDM e, por fim, a liberação da conexão de sinalização entre o UE e a rede de acesso. O desregistro normal e o desligamento podem parecer semelhantes na primeira parte do procedimento, mas terminam de forma diferente: um aguarda o Deregistration Accept, enquanto o outro não permanece conectado apenas para receber a confirmação. Essa diferença é fácil de deixar passar na análise de sinalização.
Por que o desregistro é mais do que simplesmente marcar o UE como offline?
Depois que um UE conclui o Initial Registration e estabelece uma sessão PDU, o 5GC não armazena apenas um único indicador de “online”. O AMF mantém o contexto de registro e mobilidade, o SMF gerencia o contexto da sessão PDU, o UPF mantém a sessão N4 junto com recursos de encaminhamento do plano de usuário, como FARs, QERs e URRs, o UDM armazena as relações de registro do AMF e do SMF, e o PCF pode manter associações de política AM, UE ou SM.
Se o UE simplesmente desaparecer da rede, esses recursos não serão removidos automaticamente exatamente no mesmo instante. Isso é especialmente importante quando ainda existe uma ou mais sessões PDU. A rede precisa saber quais sessões devem ser liberadas, quais regras do plano de usuário devem ser excluídas e quais assinaturas ou associações de política já não precisam permanecer.
Portanto, o desregistro iniciado pelo UE realiza uma desativação ordenada do estado de registro e dos recursos associados:
O UE indica que o registro 5GS atual deve terminar
→ O AMF determina o escopo do desregistro
→ As sessões PDU relacionadas são liberadas
→ O SMF instrui o UPF a remover os recursos do plano de usuário
→ As associações de sessão e de política são excluídas
→ O estado de registro é removido
→ A conexão de sinalização do lado de acesso é liberada
É por isso que o desregistro não deve ser confundido com RRC Release nem com uma liberação comum da conexão N2. A liberação de uma conexão RAN significa apenas que a conexão de sinalização de acesso atual terminou. O desregistro atua em um nível superior e remove a relação de registro 5GS juntamente com o estado de sessão e de política associado. Se uma captura mostrar apenas RRC Release, concluir que o UE já foi desregistrado pode facilmente confundir “liberação da conexão de acesso” com “remoção do registro”.
Como o Deregistration Request define de que forma e por qual acesso o UE sai?
Quando o UE sai ativamente do 5GS, ele envia ao AMF um NAS Deregistration Request. Para analisar a sinalização, os primeiros itens a verificar não são se mensagens PFCP aparecem mais tarde, mas o Deregistration type e o Access Type transportados na solicitação.
O Deregistration type informa primeiro à rede se o procedimento corresponde a um caso de desligamento. Em termos de engenharia, o desregistro iniciado pelo UE aparece normalmente em duas situações: desregistro normal, em que o UE sai de forma ordenada, e desligamento, em que o UE indica que está prestes a desligar ou entrar em uma condição equivalente de encerramento.
Access Type responde a outra pergunta: qual acesso está realmente sendo desregistrado. O UE pode se desregistrar apenas do acesso 3GPP, apenas do acesso não 3GPP ou, quando os dois tipos de acesso na mesma PLMN são atendidos pelo mesmo AMF, o procedimento pode abranger ambos quando aplicável. Portanto, “desregistro do UE” nem sempre significa que todo o estado de acesso associado a esse UE é removido de uma só vez.
O Deregistration Request também transporta informações de identidade do UE. Quando existe um 5G-GUTI válido, o UE pode usá-lo para ajudar o AMF a associar a mensagem NAS ao contexto existente do UE. Se não houver um 5G-GUTI válido, o tratamento da identidade depende da identidade 5GS atualmente disponível para o UE. Do ponto de vista do AMF, mapear corretamente essa mensagem NAS para o contexto existente do UE é um pré-requisito para liberar as sessões PDU e as associações de política corretas.
No desregistro normal, o UE envia a solicitação e aguarda a confirmação da rede. No desligamento, o objetivo é entregar a indicação “estou saindo” o mais rápido possível e então prosseguir com o desligamento, por isso o tratamento é diferente. O desregistro normal pode usar T3521 para supervisionar o período em que o UE aguarda Deregistration Accept, enquanto um procedimento de desligamento não espera a confirmação da rede da mesma forma.
Por que o AMF verifica primeiro se o UE ainda possui uma sessão PDU?
Após receber o Deregistration Request, uma das principais decisões do AMF é determinar se ainda existem sessões PDU estabelecidas no acesso de destino.
Se o UE não tiver uma sessão PDU relevante, não existe sessão de plano de usuário para desmontar individualmente, de modo que o procedimento pode ser significativamente mais curto. Porém, se uma ou mais sessões PDU ainda estiverem ativas, o AMF não pode simplesmente excluir seu próprio contexto de registro, pois o SMF e o UPF ainda considerariam essas sessões existentes.
Para cada sessão PDU que precisa ser liberada, o AMF pode invocar Nsmf_PDUSession_ReleaseSMContext no SMF correspondente. Isso pode ser entendido como uma instrução explícita do AMF para a camada de gerenciamento de sessão: o UE está deixando o acesso de destino, portanto o SM Context relacionado não deve mais ser mantido. Somente depois de receber essa instrução o SMF pode continuar excluindo a sessão N4, encerrando associações de política e limpando o estado de registro relevante no UDM.
Isso também destaca a diferença entre o desregistro e uma liberação independente de sessão PDU. Liberar uma sessão PDU não significa que o UE sai do 5GS; o UE pode permanecer em 5GS Registered. Em contraste, quando o UE inicia o desregistro, as sessões PDU associadas ao acesso de destino normalmente precisam ser limpas como parte do procedimento de desregistro mais amplo.
Portanto, se uma captura mostrar um Deregistration Request mas nenhum Nsmf_PDUSession_ReleaseSMContext depois, isso não deve ser tratado imediatamente como sinalização ausente. Primeiro confirme se o UE realmente tinha uma sessão PDU estabelecida no Access Type relevante. Se nenhuma sessão PDU existia, a ausência de um procedimento de liberação N4 pode ser exatamente o comportamento esperado.
Como o SMF e o UPF realmente desmontam o plano de usuário?
Depois que o AMF envia ao SMF a solicitação de liberação da sessão PDU, o SMF assume a responsabilidade de remover os recursos associados do plano de usuário. Quando existe uma sessão no UPF, o SMF a libera pela interface N4.
Em um caso típico, o SMF envia um PFCP Session Deletion Request. O UPF usa o F-SEID correspondente ou o contexto da sessão N4 para remover o estado de encaminhamento do usuário e retorna um PFCP Session Deletion Response. Em seguida, são removidos os túneis do plano de usuário, as regras de encaminhamento e o contexto relacionado associados à sessão PDU. A limpeza não se limita a um único túnel; ela também remove o estado das regras associado àquela sessão N4, incluindo FARs, QERs, URRs e outras regras aplicáveis.
A relação de controle pode ser resumida assim:
UE → AMF: quero me desregistrar
→ AMF → SMF: libere o contexto da sessão PDU deste UE
→ SMF → UPF: exclua a sessão N4 e os recursos do plano de usuário
→ UPF → SMF: confirme a exclusão
→ SMF → AMF: liberação do SM Context concluída
Se a sessão usar PCC dinâmico, o SMF também pode precisar encerrar a associação SM Policy correspondente, por exemplo por meio de Npcf_SMPolicyControl_Delete. Quando a sessão liberada for a última sessão PDU gerenciada por esse SMF para o DNN e o S-NSSAI relevantes, o SMF também poderá cancelar sua assinatura das alterações de Session Management Subscription Data no UDM e usar Nudm_UECM_Deregistration para remover do UDM a associação entre o SMF e o DNN/sessão PDU correspondente.
Do ponto de vista de uma captura no UPF, o ponto em que o desregistro realmente chega ao plano de usuário não é o NAS Deregistration Request em si, mas a liberação subsequente da sessão N4. Somente quando essa etapa é concluída os recursos de encaminhamento pertencentes à sessão PDU original são realmente removidos do plano de usuário.
Por que UDM e PCF ainda precisam limpar contexto adicional?
Quando a liberação da sessão PDU termina, o plano de usuário pode já ter sido removido, mas ainda podem permanecer associações do plano de controle no 5GC. Para que o desregistro seja totalmente concluído, a rede precisa determinar quais assinaturas, registros e relações de política ainda são válidos e quais devem ser removidos.
No lado do gerenciamento de sessão, se o SMF já não atender a última sessão PDU do usuário para o DNN e o S-NSSAI relevantes, ele poderá cancelar sua assinatura das atualizações de SM Data no UDM e remover o SMF Registration correspondente. Isso impede que o UDM continue enviando atualizações de Session Management a um SMF que já não atende aquela sessão.
No lado das políticas de acesso e mobilidade, se o UE já não estiver registrado por nenhum Access Type relevante e houver uma AM Policy Association entre o AMF e o PCF, o AMF precisa encerrar essa associação. Quando existir uma UE Policy Association, ela também deve ser liberada quando as condições aplicáveis forem atendidas. Se o AMF já não mantiver nenhum registro válido para esse UE, a relação de registro do AMF no UDM também poderá precisar ser removida por meio de Nudm_UECM_Deregistration.
Há aqui um limite importante: não presuma que todo o contexto do PCF e do UDM deve desaparecer simplesmente porque ocorreu um procedimento de desregistro. Se o UE continuar registrado por outro Access Type, ou se o mesmo SMF ainda gerenciar outras sessões PDU relevantes para esse UE, algumas associações ainda poderão ser necessárias.
Portanto, a limpeza de desregistro não é apenas uma sequência fixa de solicitações DELETE. Ela segue um princípio: remover apenas o estado que perdeu sua finalidade operacional por causa desse desregistro, preservando o contexto que ainda está sendo utilizado por outro acesso ou sessão. Essa é uma das áreas mais fáceis de interpretar incorretamente em implantações com múltiplos acessos e múltiplas sessões PDU.
Por que o desregistro normal e o desligamento terminam de forma diferente?
O desregistro normal e o desligamento podem ambos acionar a liberação de sessões PDU e recursos da rede central durante a primeira parte do procedimento, mas diferem na forma como o lado do UE chega ao fim.
Em um procedimento de desregistro normal, depois de enviar o Deregistration Request o UE aguarda a confirmação da rede. Quando o AMF conclui o processamento aplicável, ele retorna um Deregistration Accept, informando explicitamente ao UE que a rede aceitou o desregistro. Mecanismos NAS como T3521 podem supervisionar esse período de espera. Se T3521 expirar, o UE segue a retransmissão ou o tratamento de exceção definidos pelo protocolo, em vez de simplesmente assumir que o desregistro foi concluído.
Se o desregistro se aplicar ao acesso 3GPP e ainda existir uma conexão de sinalização N2 entre o AMF e o NG-RAN, o AMF poderá então prosseguir com N2 UE Context Release para encerrar a conexão de sinalização correspondente do lado de acesso.
O desligamento é diferente. O UE está prestes a desligar, portanto há pouco valor em mantê-lo conectado apenas para aguardar uma mensagem de confirmação. Quando o Deregistration type indica desligamento, o AMF não trata o lado do UE da mesma forma que no desregistro normal, exigindo um Deregistration Accept antes de o UE sair. Depois que o UE fizer sua melhor tentativa de entregar o Deregistration Request, ele poderá continuar o processo de desligamento.
Essa distinção é especialmente importante nas capturas de pacotes:
Desregistro normal
Deregistration Request
→ A rede central libera os recursos relacionados
→ Deregistration Accept
→ Liberação da sinalização / AN
desligamento
Deregistration Request
→ A rede central libera os recursos relacionados
→ O UE não espera Deregistration Accept antes de concluir o desligamento
Portanto, a ausência de Deregistration Accept em uma captura de desligamento não significa automaticamente que o procedimento falhou. O primeiro passo é verificar se o Deregistration type é desregistro normal ou desligamento. Se o UE já tiver desligado, perdido o enlace de rádio ou não tiver tido tempo suficiente para receber uma resposta, a rede poderá posteriormente recorrer a mecanismos como Mobile Reachable Timer e Implicit Deregistration para tratar o desaparecimento anormal do UE.
Perguntas frequentes
É garantido que o UE entregue Deregistration Request ao AMF ao desligar?
Não. O procedimento de desligamento é projetado para que o UE faça sua melhor tentativa de enviar a solicitação de desregistro antes de desligar, mas a rede pode nunca recebê-la se o UE já tiver perdido cobertura, se o enlace de rádio falhar ou se a alimentação desaparecer repentinamente. É por isso que o 5GC ainda precisa de mecanismos do lado da rede, como Mobile Reachable Timer e Implicit Deregistration, para lidar com UEs que desaparecem inesperadamente.
O desregistro do UE sempre aciona PFCP Session Deletion?
Não. Se não houver uma sessão PDU estabelecida no Access Type de destino, não existe uma sessão N4 de plano de usuário correspondente a liberar, portanto as etapas do SMF e do UPF associadas à limpeza da sessão PDU podem estar ausentes. PFCP Session Deletion só é necessário quando realmente existem uma sessão PDU relevante e seus recursos do plano de usuário.
O desregistro e a liberação de sessão PDU são o mesmo procedimento?
Não. A liberação de sessão PDU remove uma sessão de dados específica enquanto o UE pode permanecer em 5GS Registered. O desregistro remove a relação de registro do UE com o 5GS. Quando o UE se desregistra, as sessões PDU existentes normalmente precisam ser liberadas como recursos associados, mas os dois procedimentos operam em camadas diferentes e têm objetivos diferentes.
Por que algum contexto do UDM ou PCF pode permanecer após o desregistro do UE?
Primeiro verifique a qual Access Type o desregistro se aplica e se o UE continua registrado por outro acesso. Se o UE ainda tiver outro acesso válido, outras sessões PDU ou relações de política ainda em uso, algum contexto poderá precisar ser mantido. O desregistro não deve ser interpretado como uma exclusão incondicional de todo o estado do UE em todo o 5GC.
