Um smartphone pode já exibir o ícone 5G enquanto as páginas da Web continuam sem carregar. Quando isso acontece, o primeiro impulso costuma ser verificar o procedimento de Registration: o 5G-AKA foi concluído? O Registration Accept foi recebido? O T3512 expirou? Depois dessas verificações, o procedimento de Registration pode parecer totalmente normal, mas o serviço de dados ainda não funcionar.
Em muitos casos, o problema não está no Registration, mas na PDU Session. Registration responde à pergunta “o UE consegue se registrar no 5GS?”. PDU Session Establishment responde à seguinte: “o UE consegue realmente alcançar uma rede de dados?”. Este artigo acompanha o procedimento de estabelecimento da PDU Session do início ao fim: como o UE solicita uma sessão, como o AMF seleciona um SMF, como o SMF obtém informações de assinatura e de política, como o UPF é configurado e como o túnel N3 é finalmente concluído.
Depois que o UE conclui o 5GS Registration, o AMF já possui a identidade do usuário, o contexto de mobilidade, segurança e as informações de assinatura relacionadas. No entanto, o sucesso do registro não significa que um caminho de plano de usuário já exista. O UE ainda pode não ter um caminho ativo para a Internet ou para uma rede de dados corporativa.
PDU Session Establishment é o que leva o UE do estado “registrado” para “capaz de transportar tráfego de aplicações”. O UE solicita uma sessão, a rede seleciona o SMF e o UPF, recupera os dados de assinatura associados ao DNN e ao S-NSSAI, obtém a política de sessão, instala regras PFCP no UPF e coordena com o gNB o estabelecimento do túnel N3. Ao final do procedimento, o UE possui um endereço IP, regras de QoS e um caminho de plano de usuário em direção à Data Network.
O procedimento fica mais fácil de entender quando não é tratado como uma única mensagem NAS isolada. Três coisas acontecem em conjunto: gerenciamento de sessão, controle de políticas e configuração de recursos do plano de usuário. Elas acabam convergindo para uma PDU Session utilizável.
Limite funcional entre a sessão PDU e o registro no 5GS
No 5GC, a divisão entre Registration e PDU Session é direta: um estabelece o registro na rede, enquanto a outra estabelece a conectividade de dados.
Registration determina se o UE pode entrar no 5GS. O AMF verifica a identidade do UE, realiza a autenticação, estabelece a segurança NAS, recupera dados de assinatura relacionados à mobilidade e cria o contexto necessário para RM (Registration Management) e CM (Connection Management). Depois que essas etapas são concluídas, a relação de gerenciamento entre o UE e a rede central fica estabelecida.
Uma PDU Session está associada ao serviço de dados real. Se o UE precisa de acesso à Internet, conectividade IMS ou uma rede privada corporativa, apenas o Registration não é suficiente. A rede ainda precisa determinar qual DNN será usado, qual S-NSSAI se aplica, qual SMF controla a sessão, qual UPF transporta o plano de usuário e quais parâmetros de QoS e largura de banda estão autorizados.
Comparar isso com o EPC torna a diferença mais fácil de memorizar. O LTE usa os conceitos de PDN Connection e EPS Bearer. No 5GC, esse modelo é substituído por PDU Session + QoS Flow. Depois que uma PDU Session é estabelecida, a rede cria regras de QoS e recursos de QoS Flow em vez de um Default EPS Bearer no estilo LTE.
Outro ponto importante é que uma PDU Session não precisa ser estabelecida ao mesmo tempo que o Registration inicial. Um UE pode concluir o Registration e permanecer sem uma PDU Session até que uma aplicação realmente exija serviço de dados. Por exemplo, o dispositivo pode se registrar ao ser ligado, mas a PDU Session talvez só seja criada quando o usuário abrir um aplicativo de vídeo meia hora depois.
Essa distinção é útil durante a análise de rastreamentos de sinalização. Se o Registration foi concluído com sucesso, mas o PDU Session Establishment não, verificar repetidamente 5G-AKA, Registration Accept ou T3512 normalmente não resolve o problema do serviço de dados, porque a investigação está concentrada no procedimento errado.
DNN, S-NSSAI e tipo de solicitação na solicitação de sessão PDU
PDU Session Establishment começa com uma mensagem NAS enviada pelo UE. Um PDU Session Establishment Request faz mais do que simplesmente informar à rede central “preciso de acesso a dados”. Os elementos de informação transportados na solicitação influenciam a seleção posterior de NF e a configuração da sessão.
Uma solicitação inicial típica pode incluir PDU Session ID, Request Type, PDU Session Type, SSC Mode, DNN e S-NSSAI.
PDU Session ID diferencia várias sessões pertencentes ao mesmo UE. Um UE pode manter várias PDU Sessions ao mesmo tempo — por exemplo, uma para acesso à Internet e outra para uma rede privada corporativa. O SUPI identifica o assinante, mas, sozinho, não identifica qual PDU Session individual está sendo processada naquele momento.
DNN identifica a Data Network que o UE deseja alcançar. O acesso à Internet da operadora, o IMS e as redes corporativas podem usar DNNs diferentes. O DNN também participa da seleção do SMF, da seleção do UPF e das decisões de política posteriormente no procedimento.
S-NSSAI associa a sessão a uma fatia de rede (Network Slice) específica. O AMF e o SMF precisam determinar se a fatia solicitada é compatível com a assinatura do usuário, o DNN solicitado e as capacidades da rede implantada.
Request Type identifica o contexto da solicitação. Além de uma nova PDU Session, o procedimento também pode estar associado a uma sessão existente, mudanças de acesso ou cenários de serviço de emergência. Durante a análise de rastreamentos de sinalização, a presença de um PDU Session Establishment Request não deve ser interpretada automaticamente como o mesmo cenário todas as vezes.
O caso mais comum é um Initial Request: o UE já concluiu o Registration e agora cria uma nova PDU Session para um DNN específico. A seleção do SMF, a recuperação da assinatura no UDM, o controle de política pelo PCF e o estabelecimento de recursos no UPF são orientados por esse contexto de sessão.
Seleção do SMF e criação do SM Context pelo AMF
A mensagem NAS de gerenciamento de sessão do UE primeiro chega ao gNB e depois é encaminhada ao AMF por meio do NGAP junto com informações relacionadas ao acesso, como NR-CGI e TAI. O gNB não toma decisões de controle da PDU Session; ele transporta as informações NAS em direção à rede central.
Após receber a solicitação, o AMF precisa identificar um SMF capaz de atender ao S-NSSAI e ao DNN solicitados.
Em uma arquitetura 5GC baseada em serviços, o AMF pode usar o NRF para descoberta de NF. Os critérios de descoberta podem incluir o tipo de NF de destino, o serviço Nsmf_PDUSession necessário, S-NSSAI, DNN e o PLMN de serviço. O NRF retorna instâncias candidatas de SMF, e o AMF então seleciona o SMF que realmente atenderá a sessão de acordo com a política da rede.
O AMF então invoca o serviço PDU Session do SMF para criar um SM Context. Além de SUPI, PDU Session ID, DNN e S-NSSAI, a solicitação carrega o PDU Session Establishment Request original do UE como informação N1 SM.
A partir desse ponto, o centro do controle da sessão passa do AMF para o SMF. O AMF continua gerenciando acesso e mobilidade e continua encaminhando sinalização N1 SM entre o UE e o SMF, mas o SMF é responsável por decidir como a PDU Session será criada, qual UPF será selecionado, quais políticas serão aplicadas e como as regras do plano de usuário serão configuradas.
Um ponto prático é importante durante a solução de problemas: o número de transações NRF observado em uma rede comercial pode não corresponder exatamente a um diagrama de sinalização de referência. Resultados de descoberta de NF podem estar em cache, pode ser usada configuração estática ou um SCP pode fornecer roteamento de serviços. A questão mais importante não é se uma consulta NRF específica aparece no rastreamento de sinalização, mas se o SMF selecionado realmente suporta o DNN, o S-NSSAI e as capacidades de serviço necessárias.
Dados de assinatura UDM e processamento da política de sessão PCF
Depois que o SMF entende que tipo de sessão o UE está solicitando, ele ainda não pode criar imediatamente o plano de usuário. Primeiro precisa determinar que tipo de PDU Session o assinante está realmente autorizado a estabelecer.
Em um procedimento típico, o SMF localiza o UDM apropriado, registra-se como o SMF que atende ao SUPI e à PDU Session e recupera os Session Management Subscription Data associados ao S-NSSAI e ao DNN solicitados.
Os dados de assinatura podem conter o PDU Session Type permitido, SSC Mode, Session-AMBR e configurações padrão relacionadas a QoS. Esses valores definem os limites da sessão no nível do assinante. Por exemplo, se o UE solicitar uma PDU Session IPv4, o SMF ainda precisa verificar se o DNN permite esse PDU Session Type e se o SSC Mode solicitado está autorizado.
O SMF também pode assinar alterações nos dados de assinatura SM. Se a assinatura de gerenciamento de sessão relevante for modificada posteriormente no UDM, o UDM pode notificar o SMF em serviço por meio do Callback URI registrado.
Se a implantação usar controle dinâmico de SM Policy, o SMF seleciona um PCF e estabelece uma SM Policy Association. O SMF fornece contexto como SUPI, PDU Session ID, DNN, S-NSSAI, localização do UE e parâmetros de QoS assinados. Em seguida, o PCF retorna a política de sessão autorizada, que pode incluir Session-AMBR, QoS padrão e outras regras de política aplicáveis.
Essa etapa pode ser vista como uma convergência dos parâmetros de sessão:
Solicitação de serviço do UE → limites de assinatura do UDM → autorização de política do PCF → o SMF finaliza os parâmetros de controle da sessão
As regras de QoS e de encaminhamento instaladas posteriormente no UPF são baseadas nesses resultados.
Estabelecimento de sessão N4 e instalação de regras de plano de usuário no UPF
Depois que os parâmetros de sessão são determinados, o SMF seleciona um UPF capaz de atender ao DNN, ao S-NSSAI e à localização do UE solicitados e estabelece uma PFCP Session sobre a interface N4.
PFCP Session Establishment Request é um dos pontos mais importantes do procedimento PDU Session Establishment. Até esse estágio, a rede trabalhou principalmente com requisitos abstratos de serviço. Em N4, esses requisitos são convertidos em regras que o UPF pode executar sobre pacotes reais de usuário.
O SMF pode instalar regras PDR, FAR, QER e URR no UPF:
PDR: informa ao UPF como identificar pacotes pertencentes à PDU Session ou a um fluxo de tráfego específico;
FAR: define o que deve acontecer com os pacotes correspondentes, como encaminhamento, descarte, armazenamento em buffer ou outra ação aplicável;
QER: aplica no UPF o controle de QoS necessário;
URR: define os requisitos de medição e relatório de uso do plano de usuário.
Essas regras não devem ser tratadas como quatro funções sem relação entre si. Juntas, elas definem como o UPF processa o tráfego. O PDR identifica o fluxo de pacotes e referencia os FAR, QER e URR aplicáveis para que o UPF saiba para onde os pacotes devem seguir, quais controles de QoS aplicar e se o uso precisa ser medido.
Quando o UPF aceita o PFCP Session Establishment, ele retorna seu F-SEID e os parâmetros de plano de usuário criados. Um dos resultados mais importantes é o endereço de plano de usuário do lado do UPF e o TEID usados para N3.
Nesse ponto, porém, o caminho descendente ainda pode não estar completo, porque o gNB ainda não terminou de alocar seus recursos N3. Portanto, o PDU Session Establishment não termina com uma única solicitação PFCP. O procedimento ainda precisa que a RAN conclua sua parte da configuração do plano de usuário.
A sinalização N1/N2 conclui o túnel N3 e a configuração de QoS Flow
Depois que os recursos do lado do UPF estão prontos, o SMF precisa retornar dois conjuntos diferentes de informações por meio do AMF.
O primeiro é N1 SM information, finalmente entregue ao UE. Ele contém o PDU Session Establishment Accept junto com os parâmetros de que o UE precisa após o estabelecimento da sessão, como PDU Session Type, SSC Mode, DNN, S-NSSAI, endereço IP do UE, Session-AMBR e a QoS Rule padrão.
O segundo é N2 SM information, destinado ao gNB. Ele informa à RAN qual PDU Session está sendo criada, quais QoS Flows estão envolvidos e qual endereço IP do UPF e TEID devem ser usados em N3.
O AMF envia um PDU Session Resource Setup Request ao gNB por NGAP. O gNB aloca os recursos de rádio e N3 necessários e encaminha o PDU Session Establishment Accept ao UE.
Após a configuração dos recursos, o gNB retorna um PDU Session Resource Setup Response contendo seu próprio endereço de plano de usuário N3 e TEID, juntamente com informações sobre os QoS Flows estabelecidos com sucesso.
Há um detalhe importante de temporização. Quando o SMF estabeleceu inicialmente a PFCP Session, ele já conhecia as informações N3 do lado do UPF, mas talvez ainda não conhecesse as informações finais do túnel do lado do gNB. Assim que o gNB retorna seu endereço N3 e TEID, o AMF encaminha essas informações ao SMF. O SMF então usa PFCP Session Modification para atualizar o FAR correspondente no UPF, permitindo que os pacotes de enlace descendente sejam encapsulados no túnel GTP-U correto em direção ao gNB.
Nesse ponto, os caminhos de enlace ascendente e descendente do plano de usuário ficam completos:
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
Por esse motivo, receber um PDU Session Establishment Accept, por si só, não comprova que todos os elementos do plano de usuário estão corretos. Os parâmetros do túnel N3, o PFCP Session Modification e as regras finais do UPF ainda precisam ser verificados em relação ao encaminhamento real de pacotes.
Solução de problemas de sinalização no estabelecimento da sessão PDU
PDU Session Establishment envolve muitas funções de rede. Solucionar o procedimento comparando todas as mensagens desde o primeiro pacote pode se tornar confuso rapidamente. Um método mais eficiente é dividir o procedimento em vários pontos de verificação e reduzir o domínio de falha passo a passo.
Verifique se a solicitação de sessão chega corretamente ao AMF
Primeiro, confirme que o UE concluiu o 5GS Registration necessário. Depois, inspecione o PDU Session Establishment Request e verifique se PDU Session ID, Request Type, DNN, S-NSSAI, PDU Session Type e SSC Mode são apropriados. Se a solicitação já contiver um parâmetro inválido no ponto de entrada, mesmo um SMF e um UPF saudáveis não conseguirão produzir a sessão desejada.
Verifique se o SMF cria um SM Context válido
Em seguida, verifique se o AMF seleciona um SMF apropriado e se Create SM Context é concluído com sucesso. O objetivo não é simplesmente encontrar uma mensagem NRF no rastreamento de sinalização, mas confirmar se o SMF selecionado suporta o DNN, o S-NSSAI e as capacidades de serviço necessárias.
Depois, verifique se os dados de assinatura SM retornados pelo UDM permitem a PDU Session solicitada e se a política do PCF é compatível com a configuração de QoS esperada.
Verifique se os recursos do UPF e de N3 estão completos
Se o plano de controle já retornou PDU Session Establishment Accept, mas o UE ainda não consegue transmitir dados, a investigação deve avançar para N4 e N3.
Verifique na seguinte sequência:
se PFCP Session Establishment é concluído com sucesso e o UPF cria a sessão correspondente;
se PDR, FAR, QER e outras regras são compatíveis com a direção de tráfego esperada;
se o gNB retorna corretamente seu endereço IP de plano de usuário N3 e o TEID;
se o SMF atualiza o UPF com as informações de túnel do gNB por meio de PFCP Session Modification;
se pacotes GTP-U usando o TEID esperado realmente aparecem em N3;
se o UPF consegue enviar e receber tráfego com sucesso em direção à Data Network de destino por N6.
Seguir essa sequência ajuda a restringir o problema a NAS, SBI, N4, N3 ou ao encaminhamento de pacotes no UPF, em vez de tratar todo o 5GC como um único domínio de falha indiferenciado.
Perguntas frequentes
Por que um UE pode concluir o Registration 5G e ainda assim não acessar a Internet?
Registration estabelece o contexto de acesso, identidade, segurança e mobilidade entre o UE e o 5GC. Ele não cria automaticamente um caminho de dados do usuário. Antes que o UE possa acessar a Internet ou outra Data Network, ainda é necessária uma PDU Session para que o SMF possa configurar os parâmetros da sessão, os recursos do UPF e o plano de usuário N3.
Uma PDU Session é sempre estabelecida quando o UE é ligado?
Não. Uma PDU Session pode ser estabelecida por volta do momento do Registration, mas também pode ser iniciada mais tarde, quando o UE realmente precisar de um serviço de dados. O 5GS permite que um UE permaneça registrado sem uma PDU Session ativa, portanto a conclusão do Registration e o PDU Session Establishment não devem ser tratados como o mesmo evento.
O sucesso do PDU Session Establishment garante que o UE consiga acessar a Internet?
Não. Um PDU Session Establishment Accept na camada NAS, por si só, não é prova suficiente de conectividade de dados bem-sucedida. O tráfego real do usuário também depende do túnel N3 entre o gNB e o UPF, das regras PDR/FAR/QER no UPF, da conexão N6 e da Data Network de destino. Um UE pode receber um endereço IP enquanto o encaminhamento do plano de usuário ainda está incorreto.
Por que PFCP Session Modification ocorre depois de PFCP Session Establishment?
Quando a PFCP Session inicial é criada no UPF, o gNB pode ainda não ter concluído a alocação de recursos N3, de modo que o SMF talvez ainda não conheça o endereço IP final do plano de usuário do gNB nem o TEID. Depois que o gNB retorna esses valores no PDU Session Resource Setup Response, o SMF atualiza as regras correspondentes no UPF por meio de PFCP Session Modification, permitindo que o tráfego descendente seja enviado pelo túnel N3 GTP-U correto.
QFI em uma PDU Session e QER na interface N4 são o mesmo conceito?
Não. QFI identifica um QoS Flow no 5GS, enquanto QER é uma QoS Enforcement Rule configurada pelo SMF no UPF por meio de N4. Uma QER participa da aplicação de QoS e pode ser associada a um QFI quando aplicável, mas o próprio QFI não é uma QER e os dois conceitos não devem ser tratados como intercambiáveis.
