Uma sessão PDU pode estar funcionando normalmente há algum tempo: o UE já possui um endereço IP, o caminho N3 do plano de usuário está ativo e o tráfego das aplicações flui como esperado. Depois, as condições do serviço mudam. Pode ser necessário reduzir a taxa de dados anteriormente autorizada, atribuir um 5QI diferente a um fluxo de QoS ou limitar a taxa máxima da sessão a 10 Mbps.
Nessa situação, o 5GC não precisa encerrar e reconstruir toda a sessão PDU. A sessão existente pode permanecer ativa enquanto apenas as regras de QoS, os parâmetros dos fluxos de QoS ou as políticas de aplicação no plano de usuário afetadas são atualizados. Essa é a função de PDU Session Modification.
A diferença em relação a PDU Session Establishment é direta. O estabelecimento cria uma sessão que antes não existia; a modificação altera uma sessão que já está ativa. Assim, as principais questões deixam de ser como o SMF foi selecionado ou como o UPF foi criado inicialmente e passam a ser o que provocou a mudança, como o SMF obtém a nova política, o que o UE e o gNB precisam atualizar e se a nova política de QoS é realmente aplicada no UPF.
Escopo da modificação de sessão PDU
PDU Session Modification possui um pré-requisito importante: a sessão PDU de destino já deve existir. O UE, o SMF, o PCF e o contexto RAN correspondente já estão associados à sessão, e o plano de usuário normalmente está operacional.
O objetivo do procedimento de modificação é alterar parâmetros mantendo a sessão ativa. QoS é um dos exemplos mais comuns. Um fluxo de QoS existente pode precisar de outro 5QI, MBR, MFBR ou outro parâmetro autorizado. Uma mudança de política também pode exigir a atualização do controle de taxa já aplicado no UPF.
Uma modificação de QoS não deve ser entendida como a simples alteração de um campo NAS. Uma única atualização de QoS pode afetar três partes diferentes do sistema:
Lado do UE: o UE precisa receber a nova regra de QoS ou os novos parâmetros do fluxo de QoS;
Lado da RAN: o gNB pode precisar modificar o recurso de sessão PDU correspondente ou os recursos do fluxo de QoS;
Lado do UPF: se a aplicação no plano de usuário mudar, as regras PFCP correspondentes precisam ser atualizadas por N4.
Por isso, PDU Session Modification é melhor compreendida como uma reconfiguração on-line de uma sessão ativa. A identidade da sessão permanece inalterada e a modificação é aplicada ao PDU Session ID existente e aos fluxos de QoS associados.
Também é importante observar um limite. PDU Session Modification pode atualizar um fluxo de QoS existente e, em cenários de serviço aplicáveis, também pode ser usada para estabelecer um novo fluxo de QoS dentro da mesma sessão PDU. Por exemplo, uma política orientada por aplicação para uma chamada VoNR pode exigir um fluxo adicional com características de QoS específicas. Aqui, porém, o foco é modificar os parâmetros de um fluxo de QoS existente, e não criar um novo.
Principais gatilhos para modificação da sessão
Uma diferença importante em relação a PDU Session Establishment é que o UE não é o único gatilho possível. Uma sessão PDU ativa pode ser reconfigurada por uma solicitação do UE, uma mudança de política de rede, uma atualização dos dados de assinatura ou alterações nas condições de rádio.
As fontes de acionamento mais comuns podem ser agrupadas em cinco categorias:
Acionada pelo UE: o UE envia um PDU Session Modification Request para solicitar uma mudança de QoS ou de outros parâmetros da sessão;
Acionada pelo PCF: o controle de políticas muda, por exemplo quando um limite de uso é atingido e a rede reduz a taxa autorizada, ou quando uma política de aplicação exige outra QoS;
Acionada pelo UDM: os dados de assinatura de gerenciamento de sessão mudam, como uma atualização do nível do assinante ou do perfil de QoS contratado;
Acionada pelo SMF: o SMF decide reconfigurar a sessão de acordo com a política local, a configuração da rede ou o estado atual da sessão;
Gatilho relacionado à RAN: o gNB informa condições de rádio ou de recursos, após o que o SMF determina que os parâmetros da sessão devem ser modificados.
Todos esses gatilhos acabam convergindo no SMF, porque o SMF mantém o contexto de controle da sessão PDU e transforma uma nova exigência de serviço ou de política em parâmetros que podem ser aplicados pelo UE, pela RAN e pelo UPF.
Ao diagnosticar PDU Session Modification, o primeiro passo não deve ser começar em PDU Session Modification Command e avançar a partir daí. É mais útil identificar o primeiro evento de controle que provocou a mudança. Se o primeiro evento for uma UE Modification Request, o procedimento foi iniciado pelo UE. Se o PCF enviar uma nova política ao SMF por uma Notification URI, a mudança é orientada por política. Se uma atualização de dados de assinatura do UDM aparecer primeiro, a investigação deve seguir o caminho da alteração de assinatura.
Modificação de sessão PDU iniciada pelo UE
Um procedimento iniciado pelo UE é mais fácil de entender como um caso em que uma aplicação precisa de uma QoS diferente.
Suponha que o UE esteja usando atualmente o PDU Session ID 5 e que um de seus fluxos de QoS ainda utilize a configuração original. Uma aplicação introduz um novo requisito de serviço, então o UE solicita parâmetros de QoS diferentes enviando um PDU Session Modification Request.
A mensagem NAS passa primeiro pelo gNB até o AMF. Em seguida, o AMF atualiza o SM Context existente junto ao SMF. Na interface baseada em serviços, o AMF usa:
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
Isso é diferente de Create SM Context. O SM Context já existe; a rede agora está atualizando o contexto de uma sessão existente.
A solicitação do UE pode conter Requested QoS Rules, Requested QoS Flow Descriptions e Packet Filters relacionados. Depois de receber a solicitação, o SMF precisa determinar se a rede pode autorizar a mudança solicitada. Se a sessão usar controle dinâmico de políticas, o SMF também envia a solicitação de serviço ao PCF para autorização.
Por exemplo, se o UE solicitar 5QI 8 para determinado fluxo, o SMF pode invocar o serviço PCF SM Policy Control para modificar a Policy Association atual. O PCF avalia a política do assinante, as regras do serviço e as condições atuais da rede e, em seguida, retorna os parâmetros de QoS realmente autorizados.
Uma distinção é importante: a QoS solicitada pelo UE não é necessariamente a QoS que será efetivamente aplicada. O UE expressa a necessidade do serviço, enquanto os parâmetros finais dependem da autorização do SMF e do PCF.
Depois que os parâmetros autorizados são definidos, o SMF gera dois tipos de informação:
N1 SM: PDU Session Modification Command levando ao UE os novos parâmetros relacionados à QoS;
N2 SM: informações para o procedimento PDU Session Resource Modify, instruindo o gNB a modificar os recursos do fluxo de QoS correspondente.
O AMF entrega as informações N2 ao gNB por NGAP e encaminha ao UE o PDU Session Modification Command contido em N1.
Após ajustar os recursos correspondentes, o gNB retorna um PDU Session Resource Modify Response. Quando o UE aceita os novos parâmetros, envia PDU Session Modification Complete por NAS.
Somente depois de receber os resultados de execução correspondentes o SMF pode confirmar que os novos parâmetros de sessão passaram da autorização de política para a implementação real no lado de acesso e no UE.
Modificação de QoS no lado da rede acionada pelo PCF
A modificação no lado da rede segue uma lógica diferente. O UE não solicitou uma nova QoS; a mudança começa na camada de controle de políticas.
Considere um exemplo de limite de uso. Um usuário já possui uma sessão PDU ativa e transfere dados continuamente. O PCF exige que a sessão reporte ou monitore informações de uso. Quando o uso acumulado atinge um limite configurado, a política pode reduzir para 10 Mbps a taxa máxima da sessão ou do fluxo relacionado.
O PCF então notifica o SMF pela Notification URI registrada quando a SM Policy Association foi estabelecida. A notificação carrega a nova SM Policy Decision, como o MBR atualizado e o Policy Control Trigger correspondente.
Do ponto de vista do SMF, isso não é a criação de uma nova sessão. É a modificação de uma sessão PDU que continua válida e ativa.
Se a nova taxa precisar ser aplicada no UPF, o SMF envia um PFCP Session Modification Request por N4. O QER correspondente pode ser atualizado, por exemplo alterando o MBR para 10 Mbps. Somente depois que o UPF aceitar a modificação o novo limite de taxa passa a valer no plano de usuário.
Dois usos diferentes da palavra “Modification” não devem ser confundidos:
PDU Session Modification: o procedimento geral do 5GS para modificar uma sessão PDU ativa;
PFCP Session Modification: o procedimento específico de controle N4 usado pelo SMF para atualizar regras do plano de usuário no UPF.
Eles atuam em camadas diferentes. Uma PDU Session Modification pode incluir uma PFCP Session Modification, mas a presença de uma mensagem de modificação PFCP não significa que toda a modificação da sessão PDU foi concluída.
Depois que o UPF começa a aplicar o novo QER, o SMF ainda pode precisar atualizar a RAN e o UE. As informações N1/N2 são enviadas pelo AMF, o gNB recebe um PDU Session Resource Modify Request e o UE recebe um PDU Session Modification Command.
Quando o gNB termina de atualizar os recursos de rádio e o UE aceita os novos parâmetros de QoS, ambos retornam seus resultados de execução. O SMF pode então informar o resultado bem-sucedido ao PCF para que o sistema de políticas saiba que a decisão de QoS foi realmente aplicada, e não apenas armazenada como decisão de política.
Modificação coordenada em N1, N2 e N4
Uma das partes mais confusas de PDU Session Modification é que a mesma mudança de QoS pode gerar procedimentos de modificação em NAS, NGAP e PFCP ao mesmo tempo.
A lógica fica mais clara quando os três caminhos são separados.
N1 atualiza os parâmetros de sessão do UE
N1 SM transporta informações de gerenciamento de sessão entre o UE e o SMF. Depois que a rede decide modificar a sessão, o SMF envia um PDU Session Modification Command ao UE por meio do AMF.
O UE atualiza os parâmetros locais da sessão PDU e confirma a aceitação com PDU Session Modification Complete.
N2 atualiza os recursos da RAN
Quando os recursos de rádio associados a um fluxo de QoS precisam mudar, o SMF gera as informações N2 SM correspondentes e as entrega ao gNB por meio do AMF. O gNB modifica os recursos do fluxo de QoS usando o procedimento PDU Session Resource Modify e retorna o resultado, incluindo os QFIs modificados com sucesso quando aplicável.
N4 atualiza as regras de aplicação do UPF
Se a mudança afetar o encaminhamento do plano de usuário ou a aplicação de QoS, o SMF atualiza as regras correspondentes do UPF por meio de PFCP Session Modification.
Uma mudança no limite de taxa pode exigir a atualização de um QER. Outras mudanças de política podem afetar um PDR, FAR ou outra regra do plano de usuário. As regras modificadas dependem do serviço e da política de controle; uma PDU Session Modification não precisa reescrever todas as regras PFCP.
Uma mudança completa de QoS pode, portanto, ser resumida assim:
Política / solicitação do UE
→ o SMF recalcula os parâmetros da sessão
→ N4 atualiza a aplicação no UPF
→ N2 atualiza os recursos do gNB
→ N1 atualiza os parâmetros do UE
→ cada lado confirma o resultado
A ordem exata das mensagens pode variar de acordo com o gatilho e os parâmetros que estão sendo modificados. Durante o diagnóstico, não é útil exigir que todos os cenários tenham uma sequência idêntica de mensagens. É melhor confirmar que cada ponto de execução que precisa mudar realmente recebe e aplica os novos parâmetros.
Conclusão da modificação e diagnóstico da sinalização
Os problemas de PDU Session Modification têm uma característica que os diferencia das falhas de estabelecimento: a sessão PDU pode permanecer ativa e o usuário ainda pode transferir dados, embora a QoS resultante não corresponda à política pretendida.
Por exemplo, a política pode exigir que a taxa seja reduzida para 10 Mbps e o PCF pode já ter emitido a nova decisão de política, mas um teste real de vazão ainda mostra uma taxa muito maior. A continuidade da sessão PDU não prova que a modificação foi bem-sucedida. A investigação precisa determinar em que ponto os novos parâmetros deixaram de ser aplicados.
Uma sequência prática de diagnóstico pode usar os seguintes pontos de verificação:
Identificar o gatilho: determinar se o primeiro evento foi uma UE Modification Request, uma PCF Notification, uma alteração de dados do UDM ou um evento do lado SMF/RAN;
Verificar a decisão do SMF: confirmar se o SMF aceitou a solicitação e se o PCF retornou a decisão de política esperada;
Verificar a aplicação em N4: se o UPF precisar aplicar a nova QoS, confirmar que PFCP Session Modification foi concluída com sucesso e que os parâmetros QER correspondentes realmente mudaram;
Verificar a execução em N2: confirmar que o gNB recebeu o PDU Session Resource Modify Request e retornou os fluxos de QoS modificados com sucesso;
Verificar a confirmação em N1: confirmar que o UE recebeu o PDU Session Modification Command e retornou PDU Session Modification Complete;
Validar o resultado do serviço: confirmar que o tráfego real agora segue a taxa, a QoS ou a política de serviço atualizadas.
Se o PCF já autorizou 10 Mbps, mas o QER no UPF ainda contém o MBR antigo, a investigação deve se concentrar no caminho SMF-N4. Se o UPF já aplica a nova taxa, mas o fluxo de QoS do gNB ainda usa os parâmetros antigos, o procedimento N2 Resource Modify precisa de uma análise adicional. Se o lado da rede concluiu todas as mudanças necessárias, mas o UE nunca retorna Modification Complete, o lado NAS deve ser verificado para determinar se as novas regras de QoS foram aceitas.
Um nome de mensagem também pode causar confusão. Alguns diagramas de procedimento usam a expressão “PDU Session Modification Command Ack” para descrever a etapa de confirmação do UE. No entanto, na sinalização NAS 5GSM, a mensagem real enviada pelo UE após aceitar PDU Session Modification Command é PDU Session Modification Complete. Portanto, a análise de pacotes deve usar o NAS Message Type real.
Esse método de diagnóstico em camadas é muito mais eficaz do que reiniciar a investigação a partir de Registration Request. A sessão PDU já existe. O problema é que uma sessão ativa não foi atualizada de forma consistente de acordo com a nova política. O domínio da falha deve, portanto, permanecer concentrado no SM Context atual, na política, no fluxo de QoS e na aplicação no plano de usuário.
Perguntas frequentes
PDU Session Modification reatribui o endereço IP do UE?
Uma modificação normal de QoS atualiza uma sessão PDU existente e seus fluxos de QoS em vez de reconstruir toda a sessão. A alteração de outros atributos depende do cenário específico, mas uma modificação limitada a parâmetros como 5QI ou MBR não deve ser tratada como outro procedimento PDU Session Establishment.
PDU Session Modification é sempre iniciada pelo UE?
Não. O UE pode solicitar uma modificação por PDU Session Modification Request, mas uma mudança de política do PCF, uma atualização dos dados de assinatura do UDM, uma decisão local do SMF ou um evento relacionado à RAN também podem acionar uma modificação no lado da rede. Normalmente, o SMF coordena as atualizações necessárias entre o UE, a RAN e o UPF.
Qual é a diferença entre PDU Session Modification e PFCP Session Modification?
PDU Session Modification é o procedimento geral do 5GS para modificar uma sessão ativa e pode envolver o UE, a RAN, o SMF, o PCF e o plano de usuário. PFCP Session Modification ocorre especificamente pela interface N4 entre o SMF e o UPF e altera regras concretas do plano de usuário no UPF. A segunda pode fazer parte da primeira, mas as duas não são equivalentes.
Se o QER já foi atualizado, por que o gNB e o UE ainda precisam ser modificados?
O QER controla a aplicação de QoS no UPF, mas um fluxo de QoS não é definido apenas no UPF. O UE pode precisar de uma nova regra de QoS ou descrição de fluxo, enquanto a RAN pode precisar ajustar os recursos de rádio correspondentes. Por isso, algumas modificações de QoS exigem consistência entre N1, N2 e N4. Atualizar somente o UPF não significa que todo o procedimento PDU Session Modification foi concluído.
PDU Session Modification pode adicionar um novo fluxo de QoS?
Sim. PDU Session Modification pode atualizar os parâmetros de um fluxo de QoS existente e, em cenários aplicáveis, também pode ser usada para estabelecer um novo fluxo de QoS dentro da mesma sessão PDU. Por exemplo, um serviço VoNR orientado por aplicação pode exigir um fluxo de QoS adicional com um 5QI específico. Esse cenário tem um contexto de serviço diferente de uma simples atualização de um fluxo existente e é melhor analisado separadamente.
