Enciclopédia
2026-07-23 18:10:42
Como a mobilidade ociosa de 4G para 5G desencadeia uma atualização de registo de mobilidade?
Este artigo explica como a mobilidade ociosa de 4G para 5G desencadeia uma Atualização de Registro de Mobilidade, por que a interface N26 é importante, como o contexto do UE passa da MME para a AMF e como o 5GC conclui o registo, o tratamento de subscrição, o controlo de políticas e a preparação do contexto de sessão sem transferência em estado conectado.

Becke Telcom

Como a mobilidade ociosa de 4G para 5G desencadeia uma atualização de registo de mobilidade?

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.

Mobilidade em modo inativo de 4G para 5G mostrando o UE a mover‑se da cobertura LTE eNodeB para a cobertura 5G gNodeB com a interface MME AMF N26 e atualização de registo de mobilidade
Na mobilidade em modo inativo, o UE move‑se da cobertura 4G para a cobertura 5G e inicia uma Atualização de Registo de Mobilidade em vez de um registo inicial normal.

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.

Transferência de contexto N26 entre MME e AMF mostrando 5G‑GUTI mapeado, pesquisa DNS, Pedido de Contexto GTPv2, Resposta de Contexto, Contexto EPS MM e conversão para Contexto 5G MM
A N26 permite que a AMF obtenha o contexto do UE junto do MME e converta as informações de mobilidade EPS em contexto de mobilidade 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).

Produtos Recomendados
Catálogo
Atendimento ao cliente Telefone
We use cookie to improve your online experience. By continuing to browse this website, you agree to our use of cookie.

Cookies

This Cookie Policy explains how we use cookies and similar technologies when you access or use our website and related services. Please read this Policy together with our Terms and Conditions and Privacy Policy so that you understand how we collect, use, and protect information.

By continuing to access or use our Services, you acknowledge that cookies and similar technologies may be used as described in this Policy, subject to applicable law and your available choices.

Updates to This Cookie Policy

We may revise this Cookie Policy from time to time to reflect changes in legal requirements, technology, or our business practices. When we make updates, the revised version will be posted on this page and will become effective from the date of publication unless otherwise required by law.

Where required, we will provide additional notice or request your consent before applying material changes that affect your rights or choices.

What Are Cookies?

Cookies are small text files placed on your device when you visit a website or interact with certain online content. They help websites recognize your browser or device, remember your preferences, support essential functionality, and improve the overall user experience.

In this Cookie Policy, the term “cookies” also includes similar technologies such as pixels, tags, web beacons, and other tracking tools that perform comparable functions.

Why We Use Cookies

We use cookies to help our website function properly, remember user preferences, enhance website performance, understand how visitors interact with our pages, and support security, analytics, and marketing activities where permitted by law.

We use cookies to keep our website functional, secure, efficient, and more relevant to your browsing experience.

Categories of Cookies We Use

Strictly Necessary Cookies

These cookies are essential for the operation of the website and cannot be disabled in our systems where they are required to provide the service you request. They are typically set in response to actions such as setting privacy preferences, signing in, or submitting forms.

Without these cookies, certain parts of the website may not function correctly.

Functional Cookies

Functional cookies enable enhanced features and personalization, such as remembering your preferences, language settings, or previously selected options. These cookies may be set by us or by third-party providers whose services are integrated into our website.

If you disable these cookies, some services or features may not work as intended.

Performance and Analytics Cookies

These cookies help us understand how visitors use our website by collecting information such as traffic sources, page visits, navigation behavior, and general interaction patterns. In many cases, this information is aggregated and does not directly identify individual users.

We use this information to improve website performance, usability, and content relevance.

Targeting and Advertising Cookies

These cookies may be placed by our advertising or marketing partners to help deliver more relevant ads and measure the effectiveness of campaigns. They may use information about your browsing activity across different websites and services to build a profile of your interests.

These cookies generally do not store directly identifying personal information, but they may identify your browser or device.

First-Party and Third-Party Cookies

Some cookies are set directly by our website and are referred to as first-party cookies. Other cookies are set by third-party services, such as analytics providers, embedded content providers, or advertising partners, and are referred to as third-party cookies.

Third-party providers may use their own cookies in accordance with their own privacy and cookie policies.

Information Collected Through Cookies

Depending on the type of cookie used, the information collected may include browser type, device type, IP address, referring website, pages viewed, time spent on pages, clickstream behavior, and general usage patterns.

This information helps us maintain the website, improve performance, enhance security, and provide a better user experience.

Your Cookie Choices

You can control or disable cookies through your browser settings and, where available, through our cookie consent or preference management tools. Depending on your location, you may also have the right to accept or reject certain categories of cookies, especially those used for analytics, personalization, or advertising purposes.

Please note that blocking or deleting certain cookies may affect the availability, functionality, or performance of some parts of the website.

Restricting cookies may limit certain features and reduce the quality of your experience on the website.

Cookies in Mobile Applications

Where our mobile applications use cookie-like technologies, they are generally limited to those required for core functionality, security, and service delivery. Disabling these essential technologies may affect the normal operation of the application.

We do not use essential mobile application cookies to store unnecessary personal information.

How to Manage Cookies

Most web browsers allow you to manage cookies through browser settings. You can usually choose to block, delete, or receive alerts before cookies are stored. Because browser controls vary, please refer to your browser provider’s support documentation for details on how to manage cookie settings.

Contact Us

If you have any questions about this Cookie Policy or our use of cookies and similar technologies, please contact us at support@becke.cc .