Entre um UE totalmente conectado e um UE completamente ocioso, o 5G introduz um estado que parece silencioso para o usuário, mas continua tecnicamente relevante dentro da NG-RAN. Esse estado é o RRC Inactive. Ele foi acrescentado ao gerenciamento de conexões 5G para resolver um problema prático: muitos dispositivos precisam voltar rapidamente à transmissão de dados, mas manter todos eles permanentemente em RRC Connected desperdiçaria recursos de sinalização, recursos de rádio e energia da bateria.

Um smartphone pode verificar mensagens em segundo plano, um sensor pode enviar pequenos surtos de dados e um aplicativo pode despertar por pouco tempo depois de um longo período sem atividade. Esses padrões de tráfego nem sempre justificam o retorno completo ao estado ocioso seguido de todo o procedimento de estabelecimento da conexão. O RRC Inactive oferece uma camada intermediária. O UE pode reduzir a atividade, preservar o contexto essencial e retomar a conexão com mais rapidez quando surgem dados de uplink ou downlink.

O ponto principal é que RRC Inactive não é o mesmo que RRC Idle. Em RRC Idle, o UE também está em CM-IDLE na perspectiva da rede central. Em RRC Inactive, o UE permanece em CM-CONNECTED, enquanto a camada RRC fica suspensa em relação à operação conectada ativa. O gNodeB mantém o contexto do UE, o UE conserva o contexto AS e a rede pode levá-lo de volta a RRC Connected por meio de um procedimento de retomada, sem reiniciar tudo desde o início.

Por que o 5G precisa desse estado

O gerenciamento de conexões 5G precisa atender muitos tipos de tráfego ao mesmo tempo. Alguns serviços exigem alta vazão e conexão contínua. Outros precisam apenas de trocas curtas e ocasionais de dados. Alguns terminais permanecem silenciosos por longos períodos, mas ainda devem responder rapidamente quando a rede ou o aplicativo precisa deles. Se todos os UEs fossem mantidos em RRC Connected, a rede suportaria sobrecarga de controle desnecessária. Se todos os UEs inativos fossem totalmente movidos para RRC Idle, a recuperação da conexão poderia ficar mais lenta e exigir mais sinalização.

O RRC Inactive reduz essa lacuna. O UE pode interromper o processamento ativo de dados próprio do RRC Connected, mas o contexto importante do estrato de acesso não é descartado. Isso permite que um procedimento de retomada futuro recupere a conexão mais rapidamente. Para o usuário, o dispositivo pode continuar parecendo responsivo. Para a rede, o sistema evita manter recursos ativos por mais tempo do que o necessário.

Esse projeto é especialmente útil para aplicativos que despertam com frequência, mas não mantêm sessões longas. Serviços de mensagens, sincronização em segundo plano, relatórios intermitentes de sensores, pequenos surtos de dados de uplink e notificações curtas de downlink podem se beneficiar de um estado que permite retorno mais rápido à operação conectada.

Em termos de arquitetura de rede, o RRC Inactive também é útil porque transfere parte da responsabilidade de mobilidade e paging para a NG-RAN. O AMF não precisa tratar cada movimento dentro de uma área local de notificação RAN como um evento de mobilidade da rede central. O gNodeB pode gerenciar o contexto do UE e o paging local com mais eficiência.

Como o estado é definido

O RRC Inactive possui várias características definidoras. Primeiro, o UE ainda é considerado CM-CONNECTED. Essa é uma diferença fundamental em relação ao RRC Idle, no qual o UE também está em CM-IDLE. A relação de conexão com o núcleo 5G permanece estabelecida, embora a conexão RRC não esteja transportando ativamente dados normais do modo conectado.

Segundo, o estado é em grande parte transparente para a rede central. Na operação normal, o AMF não precisa gerenciar diretamente o RRC Inactive da mesma forma que a NG-RAN. O último gNodeB de serviço mantém o contexto do UE e conhece a RAN Notification Area à qual o UE pertence. Essa retenção de contexto torna possível a recuperação rápida.

Terceiro, o UE e o gNodeB mantêm o contexto da camada AS. Como o contexto do estrato de acesso é preservado, o UE não precisa de uma configuração totalmente nova quando o serviço é retomado. Em vez disso, pode usar um processo RRC Resume para voltar a RRC Connected.

A transição para RRC Inactive ocorre por meio de uma mensagem RRC Release com configuração de suspensão. Por isso, o estado costuma ser discutido junto com os procedimentos de suspensão e retomada. A rede libera a conexão RRC ativa, mas orienta o UE a suspender seu contexto em vez de descartá-lo completamente.

Quando a atividade volta a ser necessária, o UE pode passar de RRC Inactive para RRC Connected. Isso pode ocorrer quando o UE tem dados de uplink para enviar ou recebe paging RAN devido a dados de downlink. Se a condição de inatividade durar demais, o UE Inactivity Timer do gNodeB pode acabar levando à liberação de N2, movendo o UE em direção a RRC Idle e CM-IDLE.

O que o UE ainda pode fazer

RRC Inactive não significa que o UE esteja paralisado. Vários procedimentos continuam possíveis enquanto ele não está ativamente em RRC Connected. O UE pode realizar seleção de PLMN, receber a transmissão de informações do sistema, executar resseleção de célula e responder ao paging iniciado pela RAN. Essas funções ajudam a manter o UE alcançável sem uma conexão RRC totalmente ativa.

A rede também continua ativa de maneiras específicas. A NG-RAN gerencia a RAN Notification Area, configura DRX para paging RAN e mantém o contexto AS do UE. O gNodeB sabe a qual RNA o UE pertence, podendo determinar o alcance do paging local quando dados ou sinalização exigem que o UE retome a conexão.

Outro ponto importante é que os contextos de conexão N2 e N3 podem permanecer estabelecidos para o UE nesse modelo operacional. Isso importa quando chegam dados de downlink. O UPF ainda pode conhecer o endereço do gNodeB e encaminhar os dados ao último gNodeB de serviço. O gNodeB então aciona o paging dentro do RNA configurado, em vez de forçar do zero um processo de paging da rede central.

Esses elementos preservados explicam por que o RRC Inactive é útil, mas também mais complexo que um simples comportamento ocioso. A rede precisa manter contexto suficiente para recuperar rapidamente, mas não tantos recursos ativos a ponto de o estado se tornar equivalente a RRC Connected. O valor desse estado está nesse equilíbrio de projeto.

Como o RNA controla a mobilidade

RNA significa RAN Notification Area. É uma área de notificação do lado RAN utilizada para UEs em RRC Inactive. Um RNA é formado por várias células, normalmente dentro da mesma Tracking Area. Quando o UE se move dentro do RNA atribuído, não precisa informar a rede sempre que muda de célula. Isso evita sinalização desnecessária quando o UE se desloca apenas localmente.

O RNA é identificado por um RNA ID. A identidade é formada pelo TAC e pelo RAN Area Code. A faixa do RAN Area Code vai de 0 a 255. Na prática, isso oferece à NG-RAN uma forma compacta de definir áreas locais nas quais UEs inativos podem se mover sem atualizações frequentes.

O último gNodeB de serviço atribui o RNA ID por meio da configuração de suspensão na mensagem RRC Release. Esse é um detalhe importante, pois o gNodeB que atendeu o UE por último fica responsável por conhecer o contexto RNA do UE. Se dados de downlink aparecerem depois, esse gNodeB poderá decidir como fazer paging do UE na área correta.

O UE ainda precisa atualizar a rede em certas condições. Se o temporizador periódico de atualização RNA expirar ou se o UE sair do RNA configurado, ele deve iniciar o procedimento de atualização RNA. Isso impede que a NG-RAN perca o conhecimento prático da área local do UE, ao mesmo tempo que evita sinalização excessiva durante movimentos normais dentro do RNA.

O projeto do RNA afeta a eficiência do paging. Um RNA muito pequeno pode causar atualizações frequentes quando o UE se move. Um RNA muito grande pode aumentar a sobrecarga de paging, pois mais células talvez precisem ser chamadas quando chegam dados de downlink. Portanto, um bom planejamento depende dos padrões de mobilidade, da disposição das células, dos limites dos gNodeBs e do comportamento esperado do serviço.

Como os dados de downlink são entregues

O tratamento de dados de downlink é um dos exemplos mais claros da razão de existir do RRC Inactive. Quando chegam dados do UPF enquanto o UE está em RRC Inactive, eles podem ser enviados ao último gNodeB de serviço. O gNodeB então inicia o paging dentro do RNA porque sabe que o UE está inativo, mas pode ser alcançado localmente por paging no nível RAN.

Se todas as células do RNA pertencerem ao último gNodeB de serviço, o processo é relativamente direto. O gNodeB faz paging do UE nas células relevantes. O UE recebe a mensagem de paging RAN, inicia o processo RRC Resume e volta a RRC Connected. Depois da retomada, o UE pode receber os dados de downlink.

Se o RNA incluir células atendidas por gNodeBs vizinhos, o último gNodeB de serviço poderá usar sinalização Xn. Ele pode enviar uma mensagem XnAP RAN Paging ao gNodeB vizinho para que o paging também ocorra nessas células. Assim, o alcance do paging acompanha o RNA em vez de ficar limitado apenas às células do último gNodeB de serviço.

A mesma ideia geral também se aplica quando chega do AMF sinalização de downlink associada ao UE, exceto em casos como UE Context Release Command, nos quais se usa outro caminho de tratamento. O ponto principal é que a NG-RAN pode gerenciar o paging de um UE inativo sem tratá-lo imediatamente como um caso completo de paging da rede central em modo ocioso.

Do ponto de vista do serviço, a experiência do usuário depende da rapidez com que o UE recebe o paging e conclui a retomada. Do ponto de vista da rede, o sistema se beneficia porque o contexto é reutilizado e a sinalização fica mais localizada.

Como funcionam as transições de retomada

O RRC Inactive pode voltar a RRC Connected a partir do lado do UE ou da rede. Uma transição iniciada pelo UE ocorre quando ele possui dados de uplink ou uma necessidade de sinalização. O UE envia uma RRC Resume Request ao gNodeB. Se o gNodeB atual não for o último gNodeB de serviço, talvez seja necessário recuperar o contexto do UE desse último gNodeB antes de concluir a retomada.

Um processo típico iniciado pelo UE pode incluir RRC Resume Request, Retrieve UE Context Request, Retrieve UE Context Response, RRC Resume e RRC Resume Complete. Se o gNodeB de serviço mudar, podem ser necessários procedimentos adicionais, como Xn-U Address Indication e Path Switch Request em direção ao AMF. Depois que a mudança de caminho é tratada, o contexto antigo pode ser liberado quando apropriado.

A transição iniciada pela rede começa de outra forma. O último gNodeB de serviço recebe dados de downlink ou sinalização relevante e aciona o paging RAN. O UE é chamado dentro do RNA. Após receber o paging, retoma a partir de RRC Inactive e volta a RRC Connected para tratar os dados ou a sinalização pendentes.

Essas transições foram projetadas para ser mais leves que um estabelecimento completo de conexão a partir do modo ocioso. Isso não significa que sejam triviais. O comportamento correto depende do contexto armazenado, da coordenação entre gNodeBs, da mudança de caminho no AMF quando necessária e da liberação correta do contexto após o estabelecimento do novo caminho de serviço.

O caminho controlado por temporizador também é importante. Se o UE permanecer inativo além da política do UE Inactivity Timer do gNodeB, a rede poderá movê-lo para RRC Idle. Isso normalmente envolve a liberação de N2 e altera o estado da rede central para CM-IDLE. Nesse ponto, as vantagens de retomada rápida do RRC Inactive deixam de se aplicar.

Como o AMF recebe relatórios de estado

O RRC Inactive costuma ser descrito como transparente para a rede central, mas essa afirmação precisa ser interpretada com cuidado. Em geral, o AMF não controla diretamente o estado RRC do UE da mesma forma que a NG-RAN. Porém, pode solicitar relatórios de transições de estado RRC por meio da sinalização NGAP.

O AMF pode incluir um parâmetro RRC Inactive Transition Report Request em mensagens como Initial Context Setup Request ou UE Context Modification Request. Quando a solicitação é configurada para relatar transições posteriores, o gNodeB deve informar quando o UE entra ou sai de RRC Inactive.

Quando ocorre uma mudança de estado, o gNodeB envia ao AMF um RRC Inactive Transition Report. O relatório inclui o valor RRC State, como Inactive ou Connected. Esse mecanismo oferece visibilidade ao AMF quando solicitada, sem mudar o fato básico de que a NG-RAN gerencia o comportamento de RRC Inactive.

Essa capacidade de relatório é útil para coordenação de rede, ciência de políticas e monitoramento operacional. Ela também explica por que RRC Inactive não deve ser descrito de forma simplista como totalmente invisível para a rede central. Uma visão mais precisa é que ele é gerenciado principalmente pela RAN, enquanto o AMF pode obter informações de transição de estado em condições especificadas.

Para análise de engenharia, essa distinção é importante. Se um procedimento falhar, a solução de problemas pode precisar examinar tanto o comportamento da RAN quanto o relatório NGAP. O estado do UE, o contexto do gNodeB, a configuração RNA, o paging RAN, a solicitação de relatório do AMF e o tratamento da mudança de caminho podem influenciar o resultado final.

Perguntas frequentes

Por que RRC Inactive não é o mesmo que RRC Idle?

RRC Inactive mantém o UE em CM-Connected e preserva o contexto do estrato de acesso, enquanto RRC Idle pertence a uma relação ociosa com a rede central, na qual a recuperação da conexão exige um procedimento mais pesado.

O que faz o UE retomar a partir de RRC Inactive?

A retomada pode ser acionada por dados de uplink do UE, uma necessidade de sinalização do UE ou paging RAN causado por dados de downlink ou sinalização de downlink compatível.

Por que o RNA reduz a sinalização?

O RNA permite que o UE se mova dentro de uma área de notificação RAN definida sem informar a rede sobre cada mudança de célula, reduzindo sinalização desnecessária de mobilidade local.

O que acontece se o UE sair do RNA?

O UE deve iniciar um procedimento de atualização RNA para que a NG-RAN atualize as informações de área usadas para paging local e alcançabilidade no estado inativo.

Por que gNodeBs vizinhos podem participar do paging?

Se o RNA incluir células atendidas por gNodeBs vizinhos, o último gNodeB de serviço poderá enviar XnAP RAN Paging para que essas células também façam paging do UE.

Quando o AMF fica sabendo das mudanças de estado RRC?

O AMF pode receber relatórios de transição quando os solicita por meio do parâmetro RRC Inactive Transition Report Request em procedimentos NGAP compatíveis.

O RRC Inactive é uma das melhorias mais práticas do gerenciamento de conexões 5G. Ele mantém contexto suficiente para retomada rápida, reduz o uso desnecessário de recursos de conexão ativa, permite mobilidade local por meio do RNA e ajuda a NG-RAN a tratar o paging com mais eficiência. Seu valor vem do equilíbrio: é mais rápido que retornar do estado totalmente ocioso, mais leve que permanecer totalmente conectado e flexível o bastante para os padrões modernos de tráfego móvel.