Considere uma sessão PDU já estabelecida e transportando tráfego normalmente. O UE possui um endereço IP, o gNB mantém os recursos correspondentes da sessão PDU e os fluxos de QoS, e o UPF tem uma sessão PFCP ativa para encaminhamento no plano do usuário. Se o usuário decidir encerrar a conexão de dados, uma função de política exigir o término da sessão ou a rede determinar que ela não deve continuar ativa, o 5GC deixa de apenas modificar alguns parâmetros de QoS. É necessário desmontar a sessão tanto no plano de controle quanto no plano do usuário.
Essa é a finalidade da liberação de sessão PDU. O procedimento define como remover uma sessão PDU estabelecida: o contexto 5GSM do UE é apagado, os recursos da RAN são liberados, a sessão N4 e o estado de encaminhamento no UPF são excluídos e, quando aplicável, a associação de políticas é encerrada. O objetivo é levar AMF, SMF, gNB, UPF e UE a um estado consistente no qual aquela sessão PDU não exista mais.
Esse procedimento não está no mesmo nível do registro (Registration). Um UE pode liberar uma sessão PDU e permanecer registrado no 5GS, enquanto outras sessões PDU ativas continuam operando. Ao analisar essa sinalização, a principal tarefa é acompanhar como os recursos associados a um ID específico de sessão PDU são removidos do UE, da RAN, do SMF, do UPF e das camadas de controle de políticas, em vez de reiniciar a análise do rastreamento a partir de Registration Request.
Diferenças entre liberação, estabelecimento, modificação e cancelamento de registro
O estabelecimento, a modificação e a liberação de sessões PDU, assim como o cancelamento de registro no 5GS, podem aparecer no mesmo conjunto de rastreamentos, mas atendem a objetivos muito diferentes.
| Procedimento | Finalidade principal | Estado resultante |
|---|---|---|
| Estabelecimento de sessão PDU | Criar uma nova sessão de dados e recursos do plano do usuário | Uma nova sessão PDU fica ativa |
| Modificação de sessão PDU | Alterar QoS, política ou recursos de uma sessão existente | A sessão PDU permanece ativa |
| Liberação de sessão PDU | Encerrar uma sessão PDU específica e liberar seus recursos | Aquela sessão PDU deixa de existir |
| Cancelamento de registro no 5GS | Encerrar a relação de registro entre o UE e o 5GS | O UE deixa o estado registrado correspondente no 5GS |
É especialmente fácil confundir liberação e cancelamento de registro. Suponha que um UE mantenha uma sessão PDU para acesso à Internet e outra para uma rede corporativa privada. Liberar uma delas não remove automaticamente a outra, nem necessariamente apaga o contexto de registro do UE no AMF.
RRC Release também não deve ser tratado como liberação de sessão PDU. RRC Release altera principalmente o estado da conexão de rádio entre o UE e o gNB, enquanto a sessão PDU pode permanecer ativa na rede central. Em contraste, a liberação de sessão PDU remove os recursos associados a um ID de sessão PDUespecífico.
Para verificar como a sessão foi criada originalmente, consulteProcedimento de estabelecimento de sessão PDU na rede central 5GC. Se a sessão continuar ativa e apenas seus parâmetros de QoS ou política forem alterados, consulteProcedimento de modificação de sessão PDU na rede central 5GC.
Principais motivos para a liberação de sessão PDU
A liberação de uma sessão PDU pode ser iniciada em diversos pontos da rede. Uma sessão ativa pode terminar por uma ação do UE, decisão de controle de políticas, inconsistência no estado da rede ou condição relacionada a recursos.
Entre os motivos mais comuns estão:
Iniciada pelo UE: o UE envia PDU Session Release Request quando não precisa mais da sessão de dados atual;
Iniciada pelo PCF: o controle de políticas exige o encerramento porque a autorização do serviço, as condições de uso ou outra regra já não permitem que a sessão permaneça ativa;
Iniciada pelo AMF: o AMF detecta uma inconsistência entre os estados da sessão PDU no UE e na rede, ou a fatia de rede (Network Slice) associada deixa de estar disponível;
Iniciada pela RAN: por exemplo, todos os fluxos de QoS associados à sessão PDU já foram liberados e a RAN informa o estado resultante à rede central;
Iniciada pelo SMF: o SMF determina que a sessão deve terminar com base em política local ou informações recebidas de funções como UDM ou CHF.
Como o motivo inicial pode surgir de diferentes funções de rede, as primeiras etapas de sinalização nem sempre são iguais. O procedimento acaba convergindo para o SMF, pois ele mantém o contexto de controle da sessão PDU e coordena o plano do usuário do UPF, os recursos de acesso do AMF/RAN e a associação de políticas do PCF.
Na análise de rastreamentos de pacotes, identificar qual entidade solicitou a liberação primeiro costuma ser mais útil do que começar diretamente por PDU Session Release Command. Um Release Request do UE indica um procedimento iniciado pelo terminal. Uma notificação de término do PCF indica uma liberação baseada em política. Uma solicitação do AMF para liberar um SM Context pertence a outra ramificação iniciada pela rede.
Sinalização N1, N2 e N4 em uma liberação iniciada pelo UE
Uma liberação iniciada pelo UE mostra claramente como os recursos de sessão são removidos nas diferentes camadas.
Suponha que o UE esteja usando o ID de sessão PDU 5 para acesso a dados. Quando não precisa mais da sessão, o dispositivo gera uma PDU Session Release Request e a envia em um N1 SM Container. O gNB encaminha a mensagem NAS ao AMF usando UL NAS Transport, e o AMF identifica o SMF responsável pelo ID de sessão PDU especificado.
Na interface baseada em serviços, o AMF encaminha a solicitação de liberação pelo SM Context existente, por exemplo, invocando Nsmf_PDUSession_UpdateSMContext. Não se trata de criar outro SM Context: o contexto já existe, e o AMF está informando ao SMF que a sessão ativa entrou no procedimento de liberação.
Em seguida, o SMF executa a limpeza do plano do usuário. Para uma sessão N4 existente, ele envia uma PFCP Session Deletion Request ao UPF. O UPF remove o estado do plano do usuário associado à sessão PFCP correspondente e retorna PFCP Session Deletion Response.
Isso é fundamentalmente diferente de PFCP Session Modification durante a modificação de sessão PDU. Uma modificação atualiza regras em uma sessão N4 existente, enquanto uma exclusão remove o estado da sessão do UPF.
Depois de iniciar a limpeza do plano do usuário, o SMF prepara as informações para a RAN e o UE:
N2 SM: instrui o gNB a liberar o recurso correspondente da sessão PDU;
N1 SM: transporta PDU Session Release Command até o UE.
O AMF envia PDU Session Resource Release Command ao gNB por NGAP. A mensagem pode incluir o PDU Session Release Command NAS destinado ao UE. Após liberar os recursos de acesso associados à sessão PDU, o gNB retorna PDU Session Resource Release Response.
Depois de receber Release Command, o UE remove seu contexto local da sessão PDU e envia PDU Session Release Complete como confirmação 5GSM.
Uma sequência típica iniciada pelo UE pode ser resumida assim:
Solicitação de liberação do UE → AMF → SMF → Exclusão de sessão PFCP → Liberação de recursos N2 → Comando de liberação de sessão PDU → Confirmação do UE
Se o UE estiver inicialmente em CM-IDLE, a rede real poderá precisar primeiro de um Service Request para restabelecer a conexão de sinalização necessária à continuação da liberação. Portanto, não se deve esperar que todos os rastreamentos de pacotes comecem no mesmo estado de rádio.
Liberação iniciada pela rede e encerramento de política do PCF
Na liberação iniciada pela rede, o UE não envia primeiro PDU Session Release Request. A mudança pode começar na camada de controle de políticas ou em outra função da rede central.
Considere um caso iniciado pelo PCF. A sessão PDU está transportando tráfego normalmente, mas depois o PCF determina que ela deve ser encerrada conforme a política. O PCF notifica o SMF pelo mecanismo de notificação estabelecido para a associação de políticas existente.
Após receber o acionamento de liberação por política, o SMF ainda precisa desmontar o plano do usuário. Por isso, PFCP Session Deletion Request e Response podem aparecer antes de o SMF enviar as informações N1 e N2 necessárias por meio do AMF:
SMF → AMF → gNB / UE
A transferência AMF N1N2 Message Transfer pode transportar tanto as informações N2 relacionadas à liberação de recursos da sessão PDU quanto o PDU Session Release Command destinado ao UE.
Do ponto de vista do UE, independentemente de a liberação inicial ter sido acionada pelo PCF, SMF ou outra função de rede, um procedimento NAS explícito de liberação ainda envolve o envio de PDU Session Release Commandpela rede, seguido da resposta do UE com PDU Session Release Complete.
Entretanto, na análise de rastreamentos da rede central, essas duas mensagens NAS não bastam para identificar o motivo original. A evidência importante aparece antes de Release Command: término de política do PCF, solicitação de liberação de SM Context pelo AMF, evento relacionado à RAN ou decisão local do SMF.
Essa distinção é importante tanto para análise técnica quanto para diagnóstico: PDU Session Release Command mostra que a rede está instruindo o UE a encerrar a sessão, mas não identifica, por si só, qual entidade iniciou a liberação.
Limpeza de recursos do UPF, da RAN e do contexto de políticas
A liberação de uma sessão PDU não deve ser considerada concluída apenas porque o UE deixou de enviar dados. Os recursos associados precisam ser removidos nas funções de rede relevantes para o cenário de liberação.
N4 exclui a sessão do UPF
PFCP Session Deletion é uma etapa fundamental de limpeza do plano do usuário. Quando o UPF exclui a sessão N4 correspondente, PDRs, FARs, QERs, URRs e outros estados de encaminhamento aplicáveis deixam de operar como parte da sessão PDU liberada.
Os recursos N3 associados à sessão PDU, assim como outros recursos aplicáveis de terminação no plano do usuário, também são liberados ao fim do ciclo de vida da sessão.
N2 libera os recursos do gNB
O gNB mantém os recursos de acesso associados à sessão PDU e aos seus fluxos de QoS. Depois de receber PDU Session Resource Release Command, a RAN remove os recursos relevantes e informa o resultado à rede central por meio da resposta correspondente.
Portanto, uma PFCP Session Deletion bem-sucedida não comprova sozinha que toda a liberação da sessão PDU terminou. Se o UPF já foi limpo, mas o gNB ainda mantém o recurso da sessão PDU, a rede continua em estado inconsistente.
O UE remove seu contexto de sessão 5GSM
Ao receber PDU Session Release Command, o UE limpa seu contexto local de sessão e confirma a operação com PDU Session Release Complete. Para uma sessão PDU do tipo IP, o endereço IP ou prefixo associado também entra no processo de liberação.
O SMF notifica o AMF e limpa o estado de políticas
Quando a sessão chega ao estado Released, o SMF pode enviar uma SM Context Status Notification ao AMF para que ele sincronize o estado de sessão armazenado.
Se a sessão PDU tiver uma SM Policy Association, a relação de políticas correspondente com o PCF também precisa ser encerrada ou excluída conforme a ramificação aplicável. Se for a última sessão que exige determinado DNN, S-NSSAI ou estado relacionado à assinatura, o SMF poderá realizar limpeza adicional de informações de assinatura ou registro envolvendo UDM ou UDR quando as condições forem atendidas. Essas ações são condicionais e não aparecem necessariamente em toda liberação.
Portanto, a limpeza abrange um conjunto de estados vinculados ao ID da sessão PDU, e não apenas um túnel:
Contexto UE + Recurso RAN + Contexto SM + Sessão N4 do UPF + Associação de políticas
Verificação da conclusão da liberação nos rastreamentos de sinalização
Falhas na liberação de sessão PDU nem sempre são perceptíveis ao usuário. O UE pode já ter parado de transferir dados enquanto estados antigos permanecem em uma ou mais funções da rede central. Em outro cenário, o UE pode ter removido sua sessão local, mas a sessão PFCP no UPF continua ativa.
Em vez de memorizar todas as sequências possíveis de mensagens, um método mais eficaz de diagnóstico é estabelecer pontos de verificação com base no ID da sessão PDU afetada.
Identificar a sessão em liberação: concentrar a análise no ID correto da sessão PDU para não misturar sinais de outra sessão simultânea no rastreamento;
Identificar o acionamento: determinar se o primeiro evento é um UE Release Request, uma notificação de término do PCF, uma solicitação do AMF ou outro evento de rede;
Verificar o processamento do SMF: confirmar que a solicitação chegou ao SMF responsável pela sessão PDU e que o SMF entrou no procedimento de liberação;
Verificar os recursos N4: confirmar que PFCP Session Deletion Request e Response foram concluídos e que as regras da sessão original no UPF foram excluídas;
Verificar os recursos N2: confirmar que o gNB recebeu a sinalização de liberação de recursos da sessão PDU e retornou o resultado correspondente;
Verificar o estado N1: em um procedimento explícito de liberação NAS aplicável, confirmar que o UE recebeu Release Command e retornou PDU Session Release Complete;
Verificar o estado final: confirmar que o estado da sessão PDU no AMF, o contexto do SMF e qualquer associação do PCF estejam consistentes com o resultado Released.
Por exemplo, se o UE já retornou PDU Session Release Complete, mas a sessão PFCP correspondente ainda está no UPF, a investigação deve começar pelo SMF e pela limpeza dos recursos N4. Se o estado PFCP foi removido, mas o gNB ainda mantém o recurso relacionado à sessão PDU, o próximo passo é verificar o caminho de liberação N2.
Por outro lado, observar apenas RRC Release não é suficiente para concluir que a sessão PDU foi encerrada se não houver PDU Session Release Request, Release Command ou limpeza correspondente de recursos da rede central.
A nomenclatura de mensagens entre camadas de especificação também pode causar confusão. Algumas descrições usam o termo “PDU Session Release Ack” para uma etapa do fluxo, enquanto a mensagem NAS 5GSM efetivamente enviada pelo UE depois de aceitar PDU Session Release Command é PDU Session Release Complete. A análise de rastreamentos da interface de rádio e de NAS deve seguir o Message Type real.
Portanto, um critério de conclusão mais confiável é perguntar: os estados associados ao ID original da sessão PDU foram removidos do UE, da RAN, do SMF e do UPF, em vez de apenas verificar se uma determinada mensagem “final” apareceu?
Perguntas frequentes
A liberação de sessão PDU cancela o registro do UE?
Não necessariamente. A liberação de sessão PDU encerra apenas a sessão de dados especificada. O UE pode permanecer registrado no 5GS e continuar usando outras sessões PDU ativas. O cancelamento de registro é o procedimento que encerra a relação de registro entre o UE e o 5GS.
A liberação de sessão PDU também libera o endereço IP do UE?
Para uma sessão PDU do tipo IP, o endereço IP ou prefixo associado é um dos recursos que precisam ser liberados. Após a conclusão, ele não deve mais ser usado como endereço válido do plano do usuário da sessão liberada. A devolução ao conjunto de endereços disponíveis e uma eventual nova atribuição dependem da implementação da rede.
PFCP Session Deletion é o mesmo que liberação de sessão PDU?
Não. PFCP Session Deletion é o procedimento N4 usado pelo SMF para remover a sessão do UPF e suas regras do plano do usuário. Em geral, é uma parte importante da liberação de sessão PDU, mas o procedimento completo também pode envolver UE, RAN, AMF, PCF e outros contextos associados.
Qual é a principal diferença entre liberação e modificação de sessão PDU?
A modificação de sessão PDU mantém a sessão ativa enquanto altera QoS, política ou recursos associados. A liberação encerra a sessão especificada e remove os recursos relacionados. Se o mesmo ID de sessão PDU ainda estiver válido e transportando tráfego, em geral a liberação não foi concluída.
Por que a rede envia PDU Session Release Command depois de uma solicitação iniciada pelo UE?
UE Release Request expressa a solicitação do UE para encerrar a sessão, mas o SMF ainda precisa coordenar os estados entre UPF, RAN e UE. Depois que a rede inicia a liberação, PDU Session Release Command instrui o UE a limpar o contexto de sessão 5GSM correspondente, e o UE responde com PDU Session Release Complete.
