Quando um dispositivo móvel se desloca da cobertura 4G para a cobertura 5G, a rede nem sempre trata o evento como um registo 5G completamente novo. O comportamento real depende do estado do dispositivo, da arquitetura de interfuncionamento e de a rede suportar ou não a interface N26 entre o EPC e o 5GC. Num cenário típico, o equipamento do utilizador (UE) já está ligado à rede 4G, estabeleceu um portador padrão, entrou em estado inativo e depois moveu‑se para uma área com cobertura 5G. Nesse momento, o dispositivo inicia um procedimento de registo 5G, mas o tipo de registo não é um registo inicial. É uma Atualização de Registo de Mobilidade (Mobility Registration Update).
Esta diferença é importante. O registo inicial normalmente significa que o UE começa de novo em 5G. A Atualização de Registo de Mobilidade significa que a rede já possui contexto útil do lado 4G e que o núcleo 5G precisa de assumir as informações de mobilidade e de sessão do utilizador da forma mais suave possível. Numa implementação baseada em N26, a AMF pode solicitar o contexto do UE ao MME, reutilizar ou transformar informações chave e continuar o processo de registo do lado 5G.
A forma mais fácil de compreender o procedimento é imaginar um utilizador que estava fora de um estádio sob cobertura 4G, já tinha ligado ao LTE/EPC e estabelecido um portador padrão, depois parou de usar dados ativamente e entrou em estado inativo. Quando o utilizador entra no estádio, a área interior está coberta por 5G. O UE descobre a célula 5G, inicia o registo através do gNodeB e a rede começa o procedimento de mobilidade em modo inativo de 4G para 5G.
Por que razão este cenário existe
O interfuncionamento 4G‑5G não é apenas um problema de acesso rádio. É também um problema de continuidade do núcleo de rede. Do lado rádio, o ponto de acesso muda de eNodeB para gNodeB. Do lado do núcleo, a âncora de mobilidade muda de MME para AMF. Ao mesmo tempo, algumas funções podem manter‑se logicamente contínuas porque são implementadas de forma combinada. Por exemplo, o HSS e o UDM podem estar coubicados, o PGW‑C e o SMF podem estar combinados, e o PGW‑U e o UPF podem estar combinados. Isto permite que a rede reutilize parte do contexto de serviço 4G existente enquanto move o UE para o sistema 5G.
O procedimento aqui discutido pressupõe o modo de registo único com a interface N26. A N26 permite que a AMF e o MME troquem o contexto do UE. Esta é a principal razão pela qual o lado 5G não precisa de reconstruir tudo do zero. Sem esta troca de contexto, o registo 5G dependeria de uma abordagem de interfuncionamento diferente e a continuidade da sessão seria tratada de outra forma.
A parte “inativo” do cenário é tão importante como a parte “4G para 5G”. O UE não está numa transferência ativa em estado conectado. Já entrou em ECM‑IDLE no lado LTE/EPC. Portanto, a tarefa principal não é comutar um túnel de plano de utilizador em tempo real. A tarefa principal é migrar e interpretar o contexto do UE para que o 5GC possa continuar a gerir o assinante após o UE se registar na cobertura 5G.

O que muda na rede
A mudança mais visível está no lado da RAN. Originalmente, o UE era servido por um eNodeB LTE e, mais tarde, liga‑se através de um gNodeB 5G. O gNodeB recebe a sinalização relacionada com o registo do UE e encaminha‑a para a AMF selecionada. Este é o primeiro passo para mover o UE do ambiente de acesso LTE/EPC para o ambiente de acesso 5GS.
A mudança do lado do núcleo é mais complexa. Em 4G, o MME detém as informações de gestão de mobilidade e tem o contexto MM e SM do UE após a ligação e o estabelecimento do portador padrão. Em 5G, a AMF torna‑se responsável pela gestão do acesso e da mobilidade. Durante este procedimento, a AMF precisa de obter o contexto do UE junto do MME para poder construir o contexto de mobilidade correto do lado 5G.
As âncoras de plano de utilizador e de controlo de sessão podem não mudar fisicamente se o PGW‑C estiver combinado com o SMF e o PGW‑U estiver combinado com o UPF. Esta implementação combinada torna a transição mais fácil de compreender: o UE muda de domínio de controlo de acesso e mobilidade, enquanto a âncora de serviço pode permanecer logicamente contínua. A atualização de registo ajuda o núcleo 5G a tomar conhecimento do que já existia do lado 4G.
Em termos práticos, a rede não está simplesmente a “iniciar sessão do utilizador na 5G”. Está a traduzir um estado de mobilidade e de portador 4G para um quadro de gestão de mobilidade e de sessão 5G. É por isso que o procedimento inclui mapeamento de GUTI, pedido de contexto, resposta de contexto, registo no UDM, obtenção de políticas, criação de contexto SM e, finalmente, aceitação do registo.
Como o registo realmente começa
Antes de o UE se poder registar através do acesso 5G, precisa de uma identidade que a rede 5G consiga compreender. Neste cenário, o UE mapeia o 4G‑GUTI existente num 5G‑GUTI de acordo com as regras de interfuncionamento. Esta identidade mapeada não é igual a um 5G‑GUTI nativo atribuído num registo 5G anterior, mas dá à rede informação suficiente para localizar o contexto relacionado do lado 4G.
De seguida, o UE envia um Pedido de Registo NAS (Registration Request). O tipo de registo é Atualização de Registo de Mobilidade. O pedido pode incluir o 5G‑GUTI mapeado, informações de estado do UE e um Contentor de Mensagem NAS EPS que transporta um Pedido de TAU (Tracking Area Update). O estado do UE é significativo porque o dispositivo não está registado em modo N1, mas ainda está registado em modo S1. Isto indica à rede que não se trata de um início 5G autónomo e limpo; é um caso de interfuncionamento a partir do lado EPS.
O gNodeB encaminha então o pedido de registo para uma AMF. A seleção da AMF depende da informação de identidade disponível na sinalização RRC. Se o UE tiver um 5G‑GUTI nativo, o gNodeB pode encaminhar para a AMF relacionada com base no GUAMI. Se o UE apenas fornecer uma identidade mapeada do EPS, o gNodeB pode selecionar uma nova AMF com base na informação do GUAMI mapeado.
Esta primeira parte do procedimento define a direção de tudo o que se segue. A AMF precisa agora de perceber de onde veio o UE, qual o MME que pode deter o contexto 4G e como pedir esse contexto através da interface correta.
Como o contexto se move pela N26
Depois de receber o pedido de registo, a AMF extrai informação do 5G‑GUTI mapeado. Pode converter a informação relacionada com o GUAMI numa forma que ajude a identificar o MME correspondente. A AMF constrói então o FQDN do nó MME e utiliza DNS para obter o endereço da interface S10 do MME. Este passo é necessário porque a AMF precisa de um caminho de transporte para pedir o contexto do UE ao MME.
A AMF envia um Pedido de Contexto GTPv2 (Context Request) ao MME. O pedido pode incluir o RAT Type definido como NR, o 4G‑GUTI mapeado, a mensagem completa de pedido TAU copiada do Pedido de Registo, e informações de endereçamento S10 como endereço IP e TEID. É aqui que a N26 se torna visível no procedimento. A AMF não está a adivinhar o estado do UE; está a pedir ao MME o contexto que já existia no EPC.
O MME utiliza o contexto de segurança 4G para verificar o pedido TAU e depois procura o contexto do UE com base na identidade do UE. Se o contexto for encontrado e aceite, o MME devolve uma Resposta de Contexto GTPv2 (Context Response). Esta resposta pode incluir o IMSI, o contexto MM, informações relacionadas com segurança, o UE‑AMBR, os algoritmos de integridade e cifra NAS selecionados, informação de restrição de acesso e informações de ligação PDN.
As informações de ligação PDN são especialmente úteis porque ligam o mundo dos portadores 4G aos passos posteriores de gestão de sessão 5G. Podem incluir o APN, o EBI, o APN‑AMBR, informações S5‑C do lado PGW, contexto de portador, QoS do portador e informações S5‑U do lado PGW. A AMF pode então transformar o Contexto EPS MM recebido num Contexto 5G MM.
Pode também haver uma transferência de contexto de uma AMF antiga em alguns casos. Se o UE tiver estado anteriormente em 5G, movido para 4G e depois regressado a 5G, o pedido de registo pode transportar um GUTI Adicional (Additional GUTI). Nessa situação, a AMF pode contactar a AMF antiga para obter o contexto do UE. Mas isto é opcional e não aparece em todos os cenários de mobilidade em modo inativo de 4G para 5G.

Como o 5GC conclui a atualização
Assim que a AMF dispõe do contexto necessário, o procedimento começa a parecer‑se mais com um processo normal de registo de mobilidade 5G. A AMF interage com o UDM/HSS para concluir o registo de acesso 3GPP, obter dados de subscrição de acesso e mobilidade, recuperar dados de subscrição de seleção de SMF e subscrever futuras alterações nos dados de subscrição. Estes passos garantem que a AMF tem a informação de assinante correta para a gestão do acesso 5G.
A AMF pode também interagir com a NRF para descobrir as funções de rede corretas. Por exemplo, quando a AMF precisa de serviços UDM, pode descobrir um UDM que suporte o serviço requerido, como SDM ou UECM. Quando precisa de trabalhar com o SMF, pode usar informação relacionada com o FQDN do PGW‑C/SMF e descobrir o endereço da interface N11 do SMF através de procedimentos relacionados com a NRF.
O controlo de políticas também aparece no procedimento. Se a AMF já tiver recebido informação utilizável do PCF a partir da AMF antiga, pode continuar a usar esse PCF. Caso contrário, pode selecionar um PCF e obter informação de controlo de políticas de acesso e mobilidade. A resposta de política pode incluir restrições de acesso, como áreas ou áreas de rastreamento onde o acesso não é permitido.
A parte relativa ao SMF converte o lado da sessão do contexto EPS herdado para o quadro de serviços 5G. A AMF pede ao PGW‑C/SMF que crie um contexto SM usando a informação de ligação PDN EPS recebida do MME. O pedido pode transportar contexto EPS, a lista de sessões PDU a ativar, se presente, e o estado do contexto de portador EPS reportado pelo UE. Uma resposta com estado de ativação indica que os recursos de plano de utilizador, como o túnel N3, estão a ser preparados.
Finalmente, o antigo registo EPC é limpo. O HSS/UDM pode desencadear um Cancel Location para o MME, e o MME pode notificar o SGW para libertar os recursos associados. Em seguida, a AMF envia a Aceitação de Registo (Registration Accept) ao UE. Esta mensagem pode incluir o novo 5G‑GUTI, o NSSAI permitido, o temporizador T3512, a lista de áreas de rastreamento (TA list) e o Estado do Portador EPS (EPS Bearer Status). O UE verifica o Estado do Portador EPS recebido e remove localmente as regras de fluxo QoS ou parâmetros QoS que não estejam associados ao estado de portador EPS indicado. Depois, o UE envia o Registo Completo (Registration Complete).
Por que razão a mobilidade em modo inativo é diferente
O ponto chave deste procedimento é que o UE estava inativo quando entrou na cobertura 5G. Como não há nenhuma transferência de plano de utilizador em estado conectado, a rede não precisa de realizar uma comutação de túnel em tempo real para uma sessão de dados em curso, tal como faria durante a mobilidade em modo conectado. Em vez disso, o foco está na migração de contexto e na atualização de registo.
Isto explica por que razão o procedimento dedica tanto esforço ao mapeamento de identidade, à descoberta por DNS, ao pedido de contexto, à conversão do contexto MM, ao registo no UDM, à obtenção de políticas e à criação do contexto SM. A rede está a reconstruir o estado do plano de controlo do lado 5G do UE a partir do estado do lado 4G. Não está simplesmente a reencaminhar uma ligação rádio ativa do eNodeB para o gNodeB.
Para os engenheiros que estudam a sinalização, esta distinção ajuda a evitar um mal‑entendido comum. Ver mobilidade 4G‑5G não significa automaticamente uma transferência (handover). Se o UE estiver inativo, o procedimento é mais parecido com um novo registo controlado com contexto herdado. Se o UE estiver conectado e em movimento ativo, a rede tem de considerar a transferência rádio e a continuidade do plano de utilizador em tempo real de uma forma diferente.
É também por isso que uma explicação baseada num cenário é muitas vezes mais fácil de entender do que um único grande diagrama da norma. Um diagrama de norma pode incluir muitos passos opcionais e cenários combinados. Uma explicação prática pode restringir a visão: um UE ligado em 4G, que entrou em estado inativo, se deslocou para a cobertura 5G e usou a N26 para transferir o contexto do MME para a AMF.
Notas finais
O procedimento de mobilidade em modo inativo de 4G para 5G não é apenas uma simples mudança de cobertura. É um processo estruturado de interfuncionamento que permite a um UE previamente ligado em LTE/EPC registar‑se no 5GS através de uma Atualização de Registo de Mobilidade. O procedimento depende fortemente da N26 quando a rede pretende transferir o contexto do UE entre o MME e a AMF.
A lógica mais importante é a continuidade do contexto. O UE mapeia o 4G‑GUTI para 5G‑GUTI, o gNodeB encaminha o pedido de registo, a AMF descobre o MME, o MME devolve o contexto EPS MM e SM, e a AMF converte e continua o registo do lado 5G. As interações com UDM, NRF, PCF e SMF completam depois a preparação da subscrição, descoberta, política e contexto de sessão.
Para a aprendizagem de redes, a lição prática é clara: a mobilidade em modo inativo de 4G para 5G realiza principalmente a migração do contexto do UE do EPC para o 5GC. Não deve ser confundida com a transferência em estado conectado, onde o caminho do plano de utilizador em tempo real tem de ser comutado enquanto o UE permanece ativo.
Perguntas frequentes
Qual é o tipo de registo neste cenário?
O tipo de registo é Atualização de Registo de Mobilidade (Mobility Registration Update). É diferente do registo inicial porque o UE já possui contexto do lado 4G proveniente de uma ligação LTE/EPC anterior.
Por que é importante a interface N26?
A N26 permite que a AMF e o MME troquem o contexto do UE, possibilitando que o núcleo 5G obtenha informações de mobilidade e de sessão que estavam anteriormente no EPC.
O que muda quando o UE passa de 4G para 5G?
O lado do acesso muda de eNodeB para gNodeB, e a função de gestão de mobilidade muda de MME para AMF. Algumas funções de núcleo combinadas, como HSS/UDM ou PGW‑C/SMF, podem permanecer logicamente contínuas.
A mobilidade em modo inativo requer uma transferência de plano de utilizador em tempo real?
Não. Neste cenário, o UE está inativo, pelo que a tarefa principal é a migração de contexto e a atualização de registo, e não a comutação de túneis de plano de utilizador em tempo real.
O que recebe o UE no final?
O UE recebe a Aceitação de Registo (Registration Accept), que pode incluir um novo 5G‑GUTI, o NSSAI permitido, um temporizador de registo, a lista de áreas de rastreamento e o Estado do Portador EPS. De seguida, o UE conclui o procedimento com o Registo Completo (Registration Complete).