Uma Registration Request já chegou a um AMF; então por que o AMF que atende o UE ainda precisaria mudar enquanto o registro está em andamento? Isso significa que o gNB escolheu o AMF errado? Se o UE não incluir um Requested NSSAI na Registration Request, em que momento a rede poderá determinar de qual slice de rede o UE realmente precisa? Essas perguntas apontam para um ramo específico do Initial Registration no 5GC: a realocação de AMF. Em discussões de engenharia, esse processo costuma ser chamado de “reseleção de AMF”, embora, no procedimento 3GPP, seja mais correto tratá-lo como uma realocação do AMF durante o registro.
A principal diferença entre a realocação de AMF e um Initial Registration normal não é um procedimento adicional de autenticação nem uma troca de AMF motivada por balanceamento de carga. O Initial AMF obtém informações mais completas de assinatura e de slices, conclui que não consegue atender o S-NSSAI finalmente requerido pelo UE, aciona o NSSF para identificar um escopo de serviço AMF adequado e, em seguida, transfere o procedimento de registro para um Target AMF.
A forma mais útil de compreender esse fluxo de sinalização não é decorar em qual passo o AMF muda, mas acompanhar três pontos sucessivos de decisão: quais informações o gNB possui na primeira seleção de AMF, quais informações adicionais o Initial AMF aprende durante o registro e quais critérios o NSSF usa, por fim, para direcionar o UE a um novo AMF de serviço.
Quando a realocação de AMF é acionada?
O Initial Registration com realocação de AMF não é o caminho padrão para todo registro 5GC. As condições de acionamento são específicas: há Network Slicing implantado e o AMF que inicialmente recebe a Registration Request não consegue atender o slice de rede que o UE termina por exigir.
Em um cenário de registro normal, o Initial AMF selecionado pelo gNB já oferece suporte ao S-NSSAI necessário. O tratamento de identidade, a autenticação, a obtenção dos dados de assinatura e o Registration Accept podem, portanto, permanecer no mesmo AMF durante todo o procedimento.
A realocação só se torna necessária quando informações obtidas mais tarde mostram que o AMF atual não corresponde ao slice que o UE está autorizado a usar ou que deve usar por padrão. A lógica pode ser resumida assim:
Registration Request chega ao Initial AMF
→ O Initial AMF executa o processamento de registro necessário
→ São obtidas informações completas de assinatura e de slices do UE
→ O Initial AMF determina que não consegue atender o S-NSSAI de destino
→ O NSSF é acionado para determinar o escopo de serviço adequado
→ O registro é transferido para o Target AMF
É importante evitar um equívoco comum: o aparecimento de dois AMFs na mesma captura de registro não significa automaticamente que o AMF original falhou ou que ocorreu balanceamento de carga em um AMF Pool. Nesse procedimento, o verdadeiro gatilho é uma incompatibilidade entre a capacidade do AMF atual de atender slices e o slice de rede finalmente exigido pelo UE.
Por que o gNB pode selecionar inicialmente um AMF inadequado?
Ao analisar pela primeira vez uma realocação de AMF, é fácil supor que o gNB cometeu um erro. Se AMFs diferentes atendem slices diferentes, por que a RAN não envia o UE diretamente ao AMF correto desde o início?
A principal razão é que o gNB pode não ter informações suficientes quando realiza a seleção inicial de AMF. Considere um veículo conectado sendo ligado pela primeira vez com um USIM 5G com assinatura para dois slices de rede:
Slice eMBB (S-NSSAI1): usado para entretenimento e informação no veículo e para serviços gerais de dados;
Slice V2X (S-NSSAI3): usado para comunicação veículo-com-tudo (V2X) e serviços relacionados à condução automatizada.
Suponha que o Default S-NSSAI do assinante seja o slice V2X, mas que o UE esteja entrando no 5GS pela primeira vez, não tenha um 5G-GUTI válido e não inclua um Requested NSSAI na Registration Request. Nesse momento, o gNB não possui uma base direta para saber que o UE deverá, no fim, ser atendido pelo AMF associado ao slice V2X.
Em condições normais, ao selecionar um AMF, o gNB pode usar informações como GUAMI, o S-NSSAI solicitado pelo UE e a configuração local de AMF. Neste cenário, porém, nem o GUAMI nem o Requested NSSAI estão disponíveis; portanto, o gNB só pode escolher um Initial AMF usando as informações que possui naquele momento e sua política local de seleção padrão.
Se o gNB selecionar inicialmente o AMF1, que atende o slice eMBB, a Registration Request será transportada até o AMF1 em uma NGAP Initial UE Message.
O fato de esse AMF não corresponder ao requisito final de slice do UE não indica necessariamente um erro de configuração do gNB. Uma interpretação mais precisa é: quando ocorre a primeira seleção de AMF, a RAN ainda não possui informações suficientes para determinar o AMF específico do slice final do UE.
Como o Initial AMF detecta a incompatibilidade de slice?
Quando a Registration Request chega ao Initial AMF, ele não consulta imediatamente o NSSF. Nesse momento, ainda não possui informações suficientes sobre o assinante para determinar se é o AMF de serviço final correto.
Primeiro, o AMF segue a lógica normal do Initial Registration e executa os procedimentos necessários, incluindo tratamento da identidade do UE, seleção do AUSF, autenticação 5G-AKA e os procedimentos de segurança NAS relacionados.
Um resultado importante dessa fase é a confirmação da identidade do UE pelo AMF e a obtenção do SUPI. Com o SUPI disponível, o Initial AMF pode localizar o UDM apropriado e obter os Access and Mobility Subscription Data do UE.
Nessa etapa, a rede já possui muito mais informações do que quando a Registration Request chegou inicialmente. Os dados de assinatura retornados pelo UDM podem incluir o Subscribed NSSAI e o Default S-NSSAI do assinante.
Retomando o exemplo do veículo conectado, o Initial AMF pertence ao domínio de serviço eMBB, mas os dados de assinatura mostram que o UE é assinante de eMBB e V2X, com o Default S-NSSAI apontando para V2X, ou S-NSSAI3.
O Initial AMF pode agora chegar a uma conclusão que o gNB não conseguia tomar antes: embora tenha sido capaz de receber e iniciar o processamento do Initial Registration, ele não é o AMF adequado para prestar serviço contínuo ao slice V2X padrão do UE. Essa determinação se torna o ponto de acionamento da realocação de AMF.
Etapa do gNB: apenas informações limitadas de acesso estão disponíveis
→ Etapa do Initial AMF: a identidade do UE é confirmada
→ Etapa do UDM: são obtidas as informações reais do NSSAI subscrito
→ O AMF atual é identificado como incompatível com o slice de destino
Portanto, a realocação de AMF não é uma mudança arbitrária de decisão no meio do registro. Ela ocorre porque a rede central consegue tomar uma decisão mais precisa sobre o AMF de serviço depois que a identidade do assinante e as informações de slice se tornam completas.
Como o NSSF identifica o novo AMF de serviço?
Depois que o Initial AMF determina que não consegue atender o slice de destino, ele não escolhe simplesmente outro AMF por conta própria. Em vez disso, aciona a Network Slice Selection Function, ou NSSF.
O Initial AMF utiliza o serviço Nnssf_NSSelection para solicitar Network Slice Selection. As entradas podem incluir o S-NSSAI subscrito pelo UE, informações sobre o AMF atual e o TAI atual do UE. O objetivo é determinar quais slices estão autorizados na área de registro atual e qual conjunto de AMFs deve prestar o serviço.
As Authorized Network Slice Information retornadas pelo NSSF podem incluir:
Allowed NSSAI: os slices de rede que o UE está autorizado a usar nas condições atuais;
Configured NSSAI: configuração de slices que pode ser fornecida ao UE quando necessário;
Target AMF Set: o conjunto de AMFs capazes de atender o slice de rede correspondente;
Rejected NSSAI: slices que não podem ser aceitos no TA atual ou sob condições relacionadas.
É importante distinguir Target AMF Set de Target AMF. A primeira responsabilidade do NSSF é determinar qual conjunto de AMFs é apropriado, reduzindo o escopo de candidatos de acordo com as condições de slice e localização, em vez de retornar diretamente o endereço de um AMF específico.
Depois de obter o Target AMF Set, o Initial AMF pode usar as informações de instâncias NF registradas no NRF para recuperar endereços, capacidades, pesos e estado operacional dos AMFs desse conjunto. Em seguida, pode determinar qual Target AMF específico deve assumir o Registration.
A relação pode ser resumida assim:
UDM: fornece as informações de assinatura de slices do UE
→ Initial AMF: determina que sua própria capacidade de serviço não corresponde
→ NSSF: determina os slices autorizados e o Target AMF Set
→ NRF: fornece informações sobre instâncias AMF disponíveis dentro do conjunto
→ Initial AMF: seleciona o Target AMF
O papel do NSSF nesse procedimento não é o balanceamento de carga convencional. Ele mapeia um requisito de slice para um escopo de serviço AMF capaz de suportar esse requisito.
Como a Registration Request é transferida para o Target AMF?
Depois que o Target AMF é determinado, o UE não precisa enviar uma Registration Request completamente nova. A rede só precisa transferir o procedimento de registro já em andamento, junto com o contexto necessário, para que o novo AMF continue o processamento.
Há dois mecanismos de encaminhamento disponíveis: encaminhamento indireto pelo gNB ou encaminhamento direto entre o Initial AMF e o Target AMF.
Encaminhamento indireto pelo gNB
No encaminhamento indireto, o Initial AMF envia um NGAP Reroute NAS Request ao gNB. A mensagem transporta informações associadas ao Initial UE Message original, além do Target AMF Set ID, instruindo a NG-RAN a redirecionar a mensagem NAS Registration atual.
O gNB então envia um novo Initial UE Message ao Target AMF contendo o NAS-PDU da Registration Request original. O caminho do plano de controle pode ser representado assim:
UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF
O UE não precisa realizar novamente o acesso RRC. A NG-RAN simplesmente redireciona a mensagem NAS Registration já existente para o AMF apropriado.
Encaminhamento direto entre AMFs
No encaminhamento direto, o Initial AMF não devolve a mensagem pelo gNB. Em vez disso, transfere diretamente a mensagem N1 e o Registration Context ao Target AMF pela interface baseada em serviços do 5GC.
O Initial AMF invoca Namf_Communication_N1MessageNotify e envia a Registration Request completa, juntamente com o Registration Context Container, ao Target AMF.
As informações transferidas não se limitam a uma única mensagem NAS. O Registration Context também pode incluir UE Context, Access Type, informações do gNB, User Location, Allowed NSSAI, Configured NSSAI, Rejected NSSAI e outros dados necessários para continuar o processamento do registro.
UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF
Os caminhos de sinalização são diferentes, mas o objetivo é o mesmo: o Target AMF recebe a mensagem NAS e o contexto necessários para continuar o Registration sem reiniciar todo o procedimento de Initial Registration.
Depois de assumir o procedimento, o Target AMF conclui o restante do processamento de registro e devolve um Registration Accept ao UE. A resposta reflete os resultados da seleção de slice e da realocação de AMF e pode incluir Allowed NSSAI, Configured NSSAI, Rejected NSSAI e um novo 5G-GUTI.
Do ponto de vista do UE, o resultado importante é que o registro seja concluído com sucesso e que a rede forneça os slices disponíveis na área atual junto com o novo contexto de mobilidade 5GS. A alteração interna do AMF de serviço permanece transparente para o UE.
Como verificar a realocação de AMF em uma captura de sinalização?
Um Initial Registration com realocação de AMF pode ser facilmente confundido com roteamento anormal de registro ou com uma primeira seleção de AMF malsucedida. Um método de diagnóstico mais eficaz não é comparar números de mensagens um a um, mas acompanhar duas linhas principais: a determinação do slice e a transferência de contexto.
Uma sequência normal de sinalização deve permitir que o engenheiro responda às seguintes perguntas:
Por que a Registration Request chegou primeiro a este Initial AMF?
→ De onde o Initial AMF obteve o Subscribed / Default NSSAI do UE?
→ O que levou o AMF a determinar que não poderia continuar atendendo o UE?
→ Qual Target AMF Set o NSSF retornou?
→ Qual Target AMF específico foi finalmente selecionado?
→ Qual caminho foi usado para transferir o Registration Context?
Se o Initial AMF já obteve as informações de assinatura de slices e determinou que não pode atender o UE, mas nenhum procedimento de seleção NSSF aparece em seguida, a investigação deve se concentrar na descoberta do NSSF, na solicitação Nnssf_NSSelection e na configuração de slice relacionada.
Se o NSSF retorna um Target AMF Set, mas nenhum Target AMF específico pode ser identificado, as próximas verificações devem incluir a configuração do AMF Set, os NF Profiles no NRF, o estado das instâncias AMF e suas informações de capacidade.
Se houver um NGAP Reroute NAS Request, mas o Target AMF nunca receber o novo Initial UE Message, o foco do diagnóstico deve passar da seleção de slice para o redirecionamento NAS no gNB e a alcançabilidade N2 até o Target AMF.
Se for usado encaminhamento direto, a captura deve ser verificada em busca de Namf_Communication_N1MessageNotify e do Registration Context, em vez de aguardar um Reroute NAS Request que não aparecerá nesse caminho.
Observando o procedimento completo, a realocação de AMF resolve um problema específico: as informações disponíveis durante a primeira seleção de AMF são incompletas, e a rede central corrige posteriormente a decisão do AMF de serviço depois de obter a identidade completa do assinante e as informações de assinatura de slices.
Quando o UE entra pela primeira vez na rede, o gNB pode ter apenas informações limitadas de GUAMI, informações de Requested NSSAI ou sua configuração padrão de AMF. Depois da autenticação e da obtenção dos dados de assinatura, o 5GC pode finalmente determinar quais slices o assinante está autorizado a usar. O NSSF converte então o requisito de slice em um Target AMF Set, enquanto o NRF ajuda a identificar a instância AMF real que pode continuar o Registration.
Portanto, a pergunta mais útil ao analisar esse fluxo de sinalização não é “Por que o AMF mudou no meio do registro?”, mas: em que momento a rede finalmente obteve informações suficientes para determinar qual AMF deveria continuar atendendo o UE?
Perguntas frequentes
A realocação de AMF é igual ao balanceamento de carga em um AMF Pool?
Não. O balanceamento de carga em um AMF Pool normalmente se concentra em capacidade, pesos e distribuição de alta disponibilidade entre várias instâncias AMF. Nesse procedimento, a realocação de AMF é motivada pelo fato de o Initial AMF não conseguir atender o slice de rede finalmente exigido pelo UE. Os dois mecanismos podem resultar em um AMF de serviço diferente, mas as condições de acionamento e a lógica de sinalização são fundamentalmente distintas.
Todo ambiente com Network Slicing exige seleção pelo NSSF e realocação de AMF?
Não. Mesmo quando há Network Slicing implantado, a realocação de AMF é desnecessária se o AMF inicialmente selecionado pelo gNB já puder atender o slice finalmente requerido pelo UE. A realocação é um ramo condicional do registro, não uma etapa obrigatória em toda rede com slicing.
O UE consegue detectar diretamente que o AMF mudou durante o registro?
Do ponto de vista do UE, o principal é saber se o Registration foi concluído e quais valores de Allowed NSSAI, Configured NSSAI, Rejected NSSAI e 5G-GUTI são retornados pela rede. A realocação de AMF e a transferência do Registration Context são procedimentos internos de controle do 5GC e permanecem, em grande parte, transparentes para o UE.
O encaminhamento indireto ou direto é sempre mais comum?
Não é possível tirar uma conclusão universal apenas da definição do procedimento. O mecanismo utilizado depende da arquitetura de implantação do 5GC, da implementação do fornecedor, dos recursos de comunicação baseada em serviços entre os AMFs e da configuração da RAN e da rede central. O diagnóstico real deve seguir o caminho de sinalização observado na rede em operação.
