Em uma rede 5G, depois que o UE conclui o registro, a rede principal precisa manter uma noção geral de onde ele está para poder alcançá-lo quando houver paginação, serviços de entrada ou dados de enlace descendente. No entanto, um UE não permanece em um único local. Ele pode se mover de uma Tracking Area para outra ou até sair da área de serviço do AMF atual. Se o UE tivesse de fazer um novo registro após cada movimento, a sinalização do plano de controle se tornaria excessiva. Se nunca atualizasse sua localização, a rede poderia acabar perdendo a referência de onde encontrá-lo. Mobility Registration Update foi projetada para equilibrar a precisão de localização com a sobrecarga de sinalização.
Uma dúvida comum ao estudar a sinalização do 5GC pela primeira vez é: se o UE já está registrado, por que precisa enviar outra Registration Request depois de se mover para uma nova área? Entrar em outro gNB sempre dispara uma atualização? Entrar em uma nova Tracking Area significa necessariamente que o AMF precisa mudar? Essas perguntas apontam para o mesmo princípio: o UE permanece no estado 5GS Registered, mas sua localização atual pode ter saído da Registration Area atribuída anteriormente pela rede. Por isso, o 5GC precisa atualizar a localização do UE, determinar se o AMF de serviço deve permanecer o mesmo e atribuir a Registration Area aplicável à próxima etapa de mobilidade. Isso não é um novo registro de inicialização, nem o UE se registra novamente toda vez que troca de célula. É um mecanismo para manter a continuidade do contexto de mobilidade 5GS do UE.
Sair da Registration Area é o principal gatilho da atualização de mobilidade
O registro no 5GC não se limita ao Initial Registration. O campo 5GS registration type transportado na Registration Request distingue procedimentos como Initial Registration, Mobility Registration Update, Periodic Registration Update e Emergency Registration. Em cenários de mobilidade, uma das fontes mais comuns de confusão é a diferença entre uma Tracking Area (TA) e uma Registration Area.
Uma TA é uma das áreas básicas usadas pela rede para gerenciamento de localização, enquanto uma Registration Area é um conjunto de TAs dentro do qual o AMF permite que o UE permaneça registrado. Uma Registration Area pode conter apenas uma TA ou várias. Suponha que um AMF atenda TA1, TA2, TA3 e TA4, mas atribua TA1 e TA2 a um determinado UE como sua Registration Area atual com base no comportamento de mobilidade. Quando esse UE se move de TA1 para TA2, continua dentro da área registrada e não precisa executar uma Mobility Registration Update apenas porque a TA mudou.
A situação muda quando o UE segue para TA3 e TA3 não faz parte da Registration Area atualmente armazenada. O UE detecta que o TAI atual está fora de sua área registrada, envia uma nova NAS Registration Request e define o 5GS registration type como mobility registration updating. Portanto, uma mudança de célula não dispara automaticamente uma Mobility Registration Update, e mesmo uma mudança de TA nem sempre a dispara. O gatilho típico é a entrada em uma TA que esteja fora da Registration Area atual do UE.
Esse é o objetivo do conceito de Registration Area. Ele permite que o UE se mova dentro de uma faixa definida sem interagir com o 5GC toda vez que cruza um limite de TA, ajudando a equilibrar precisão de localização e carga de sinalização do plano de controle. A rede pode atribuir uma lista de TAs maior a um UE com padrão de mobilidade mais amplo ou reduzir a Registration Area quando for desejável um rastreamento de localização mais preciso. A própria Registration Area, portanto, faz parte da política de gerenciamento de mobilidade.
Como a Registration Request leva o estado de mobilidade existente de volta ao 5GC?
A diferença mais clara entre Mobility Registration Update e Initial Registration é que o UE não é um assinante totalmente desconhecido. Ele já concluiu o registro 5GS e normalmente mantém informações como o 5G-GUTI atribuído pela rede, sua Registration Area e o contexto NAS relevante. Portanto, a nova Registration Request não é usada para estabelecer a identidade do zero. Em vez disso, informa à rede: “Sou o mesmo UE que você já conhece, mas minha localização de mobilidade mudou.”
O UE primeiro estabelece o acesso ao plano de controle pelo novo gNB. Em seguida, o gNB transporta a NAS Registration Request até o AMF em uma NGAP Initial UE Message. Além da NAS-PDU, a Initial UE Message fornece informações de localização de acesso, como o NR-CGI e o TAI atuais. Em uma Mobility Registration Update típica, a Registration Request pode transportar vários elementos de informação importantes: o 5GS registration type identifica o procedimento como mobility registration updating; o 5G-GUTI ajuda a rede a identificar o AMF ou GUAMI associado ao registro anterior do UE; Last Visited Registered TAI fornece uma referência à localização registrada anteriormente; UE Security Capability descreve os algoritmos NAS compatíveis de criptografia e proteção de integridade; PDU Session Status reflete quais sessões PDU o UE considera ainda ativas; e Requested NSSAI pode fornecer as fatias de rede solicitadas pelo UE quando aplicável.
Durante a análise de rastros, a primeira pergunta não deve ser se a autenticação ocorrerá mais adiante no procedimento. A primeira verificação é se a própria Registration Request identifica claramente o processo como Mobility Registration Update, e não como Initial Registration. Se o tipo de registro for interpretado incorretamente, o restante do fluxo de sinalização poderá ser analisado facilmente sob a perspectiva errada.
Por que atualizações no mesmo AMF e entre AMFs seguem caminhos diferentes?
Sair da Registration Area não significa necessariamente sair da área de serviço do AMF atual. Essa distinção determina diretamente a complexidade do restante do procedimento de sinalização e é uma das primeiras ramificações que devem ser identificadas durante a análise de uma Mobility Registration Update.
O Serving AMF permanece o mesmo
Suponha que um AMF atenda TA1 e TA2, enquanto a rede havia atribuído anteriormente apenas TA1 como Registration Area do UE. Quando o UE se move de TA1 para TA2, TA2 fica fora da Registration Area atual, portanto é necessária uma Mobility Registration Update. No entanto, TA2 ainda está dentro da área de serviço do mesmo AMF.
Nesse caso, não existe uma migração real de Old AMF para New AMF. O AMF atual já mantém o contexto de mobilidade do UE e precisa apenas processar a nova localização, atualizar a Registration Area e renovar qualquer informação necessária de política ou contexto. A Registration Area muda, mas o Serving AMF não.
O Serving AMF muda
O procedimento se torna mais complexo quando o UE se move de uma TA atendida por um AMF para uma TA atendida por outro AMF. Por exemplo, o UE pode ter concluído o registro sob o AMF1 e recebido um 5G-GUTI associado ao AMF1. Depois de se mover por um novo gNB para a área de serviço do AMF2, o New AMF precisa saber quem é o UE, qual AMF o atendia anteriormente e qual contexto pode ser reutilizado.
Uma Mobility Registration Update entre AMFs, portanto, é mais do que uma atualização de localização. Ela também envolve a transferência do contexto de gerenciamento de mobilidade do UE do AMF de serviço anterior para o novo.
Como o New AMF encontra o Old AMF e recupera o contexto do UE?
Em um cenário de mobilidade entre AMFs, o primeiro problema que o New AMF precisa resolver após receber a Registration Request não é saber se o assinante pode estabelecer serviço de dados. É identificar qual AMF gerenciava o UE anteriormente. O 5G-GUTI desempenha um papel importante aqui. As informações relacionadas ao GUAMI contidas na identidade temporária ajudam a rede a identificar o AMF que atendia o UE antes. O New AMF pode então determinar o Old AMF e solicitar o UE Context existente por meio do serviço Namf_Communication.
A lógica típica é direta: o UE envia uma Mobility Registration Update usando seu 5G-GUTI anterior; o New AMF extrai do 5G-GUTI a identidade relacionada ao AMF; o Old AMF é identificado; o New AMF solicita o UE Context; e o Old AMF retorna o contexto de mobilidade transferível. Essas informações podem ajudar o New AMF a recuperar dados de identidade e mobilidade, como SUPI, GPSI, PEI e partes do Access and Mobility Context, permitindo que o novo Serving AMF continue a partir de um estado existente do UE em vez de tratar o dispositivo como totalmente desconhecido.
Obter contexto do Old AMF não significa que todos os procedimentos de segurança subsequentes possam sempre ser ignorados. Se as informações de identidade disponíveis ou o contexto de segurança forem insuficientes, a rede ainda poderá solicitar novamente o SUCI do UE e executar verificação de identidade ou autenticação 5G-AKA de acordo com as condições de segurança atuais. A análise de rastros deve, portanto, evitar duas suposições rígidas: uma Mobility Registration Update nem sempre exige uma nova autenticação completa, mas um Old AMF Context disponível também não garante que a autenticação nunca ocorrerá. A presença de Identity Request ou de um 5G-AKA completo depende do UE Context transferido, do NAS Security Context e da política da rede.
Como UDM, NRF e PCF concluem a transferência de responsabilidade do Serving AMF?
Recuperar o UE Context do Old AMF não significa que a relação de serviço foi totalmente transferida. No 5GC, a localização do usuário e o estado de serviço estão distribuídos entre várias funções de rede. Em particular, o UDM precisa saber qual AMF agora é responsável pelo atendimento do UE.
O New AMF pode usar o NRF para descobrir um UDM que forneça os serviços necessários e, em seguida, registrar o novo 3GPP Access Registration no UDM. Essa etapa é especialmente importante em um cenário entre AMFs porque o registro do Serving AMF no UDM precisa passar do Old AMF para o New AMF. O UDM pode então acionar a Deregistration Notification relevante em direção ao Old AMF para liberar a relação de serviço anterior.
O New AMF também precisa dos Access and Mobility Subscription Data atuais, que podem incluir GPSI, Subscribed NSSAI, UE-AMBR, parâmetros de registro periódico, restrições RAT e restrições de acesso por área. Se o tratamento posterior de PDU Session exigir seleção de SMF, o AMF também pode recuperar SMF Selection Subscription Data, incluindo informações de DNN e Default DNN associadas ao S-NSSAI relevante, e subscrever notificações de alterações nos dados de assinatura correspondentes. O PCF complementa esse processo fornecendo Access and Mobility Policy. O New AMF pode selecionar o PCF apropriado e estabelecer uma AM Policy Association para obter informações de política de mobilidade, como restrições de área.
Essas etapas resolvem problemas diferentes. O Old AMF Context informa ao New AMF qual era o estado anterior do UE. UDM Registration informa à rede principal qual AMF atende agora o UE. Subscription Data informa ao New AMF o que o assinante está autorizado a usar. PCF Policy informa ao AMF quais regras de mobilidade e acesso se aplicam atualmente. Por isso, uma Mobility Registration Update não deve ser reduzida a “o AMF atualiza um TAI”. Em um cenário entre AMFs, ela também transfere a responsabilidade pelo gerenciamento de mobilidade de um AMF para outro.
Como Registration Accept define a próxima faixa de mobilidade do UE?
Depois que o processamento de identidade, contexto, dados de assinatura e política é concluído, o AMF precisa aplicar o novo estado de registro tanto ao gNB quanto ao UE. Em um procedimento típico, o AMF pode usar uma NGAP Initial Context Setup Request para estabelecer ou atualizar o contexto relacionado ao UE no gNB enquanto entrega a NAS Registration Accept ao UE.
A parte mais importante da Registration Accept não é apenas o fato de o registro ter sido concluído com sucesso. A mensagem também fornece parâmetros que definem como o UE deve operar durante a próxima etapa de mobilidade. Um novo 5G-GUTI pode ser atribuído após um movimento entre AMFs para refletir o novo Serving AMF. Allowed NSSAI identifica as fatias de rede atualmente permitidas ao UE. T3512 define a temporização associada a uma futura Periodic Registration Update. A TA List, ou Registration Area, informa ao UE por quais TAs ele pode se mover enquanto permanece registrado sem disparar outra Mobility Registration Update do mesmo tipo.
Depois que o gNB conclui o processamento de contexto correspondente, ele retorna uma Initial Context Setup Response, e o UE envia Registration Complete. A Mobility Registration Update atual é então finalizada. Do ponto de vista de transição de estados, o fluxo pode ser resumido assim: o UE sai de sua Registration Area existente; a Registration Request leva a identidade de mobilidade anterior ao 5GC; a rede determina se o Serving AMF deve mudar; o UE Context é transferido do Old AMF quando necessário; o New AMF conclui o registro no UDM e obtém as informações necessárias de assinatura e política; Registration Accept fornece o novo 5G-GUTI e a Registration Area; e, por fim, o UE retorna Registration Complete.
A solução de problemas pode seguir a mesma cadeia de estados. Se a Registration Request chegar ao New AMF, mas o Old AMF não puder ser localizado, as verificações devem se concentrar em 5G-GUTI, GUAMI e endereçamento do AMF. Se o Old AMF Context for recuperado com sucesso, mas o procedimento parar na etapa do UDM, as próximas verificações devem abranger descoberta do UDM, AMF Registration e recuperação de dados de assinatura. Se o processamento interno da rede principal for concluído, mas nenhuma Registration Accept chegar ao UE, a investigação deve continuar com resultados de política, restrições de área, sinalização NGAP de enlace descendente e estabelecimento do contexto RAN. Portanto, o objetivo de compreender a 5GC Mobility Registration Update não é memorizar dezenas de mensagens HTTP/2 e NGAP, mas entender como a rede responde a três perguntas depois que um UE registrado se move: onde está o UE agora, qual AMF deve continuar gerenciando-o e qual Registration Area deve se aplicar ao próximo período de mobilidade?
Perguntas frequentes
O UE executa uma Mobility Registration Update toda vez que entra em uma nova Tracking Area?
Não necessariamente. A questão principal é se a nova TA ainda faz parte da Registration Area atual do UE. Se o AMF já tiver atribuído TA1 e TA2 como Registration Area do UE, mover-se de TA1 para TA2 normalmente não dispara essa atualização apenas porque a TA mudou. Entrar em uma TA fora da Registration Area é a condição típica de disparo.
A Mobility Registration Update sempre muda o AMF?
Não. O UE pode sair de sua Registration Area atual enquanto a nova TA ainda pertence à área de serviço do mesmo AMF. Nesse caso, o Serving AMF permanece inalterado. A transferência de contexto de Old AMF para New AMF só é necessária quando o UE entra em uma área que precisa ser atendida por outro AMF.
Toda Mobility Registration Update repete o 5G-AKA?
Não se deve presumir uma regra fixa. A repetição de procedimentos de identidade ou de 5G-AKA depende do UE Context disponível, do NAS Security Context e da política da rede. Se um contexto válido puder continuar sendo usado, alguns procedimentos de segurança talvez não precisem ser repetidos integralmente. Se as condições de identidade ou segurança forem insuficientes, a rede poderá executar novamente as etapas de autenticação necessárias.
Como uma 5GC Mobility Registration Update difere de uma atualização quando um UE passa de 4G para 5G?
Ambos os cenários podem usar o tipo de registro Mobility Registration Update, mas a origem do contexto de mobilidade é diferente. A mobilidade inteiramente dentro do 5GS normalmente envolve contexto de mobilidade entre um Old AMF e um New AMF. Um cenário de interoperabilidade em modo ocioso de 4G para 5G pode envolver adicionalmente o MME, N26 e a tradução entre contextos EPS e 5GS. Ao analisar um rastro de sinalização, o primeiro passo é determinar se o UE está se movendo dentro do 5GS ou entrando no 5GC a partir do EPC.
