O que são Modos, Estados e Transições em GSM, UMTS e LTE?

Postado por leopedrini segunda-feira, 4 de abril de 2016 15:17:00 Categories: Curso LTE UMTS
Rate this Content 6 Votes

Olá amigos. Hoje vamos falar sobre um tema extremamente importante para quem trabalha com comunicações móveis: quais são os diferentes modos e estados que um telefone móvel pode assumir, e também como ocorre a transição entre cada um deles.

O conceito é bem simples, porém a grande quantidade de detalhes pode acabar tornando o tema um extenso ou complexo. Isso acaba fazendo com que muitas pessoas simplesmente desistam de tentar entender, ou que nem mesmo se interessem em conhecer tais detalhes.

Porém, o desconhecimento desses pontos chave do funcionamento (quando ocorrem as transições, porque ocorrem, etc.) acaba afetando o entendimento de outras áreas da rede móvel, já que o funcionamento de toda a rede se baseia nisso. Sem entender bem essa base fundamental de funcionamento, aí sim é que corremos o risco de achar que tudo é complicado demais.

Então vamos tentar mostrar de uma forma bem simplificada todos os principais conceitos envolvidos nos modos, estados e transições que um móvel pode ter em uma rede 2G/3G/4G. Esperamos que ao final deste tutorial tudo o que está mostrado na figura a seguir estejam mais claros para você.

 

Nota: Este tutorial acabou ficando um pouco extenso, e poderia ser sido dividido em ‘partes’. Entretanto, decidimos pela manutenção do conteúdo centralizado. Fique à vontade para lê-lo da forma como preferir - por partes, de uma só vez. Tudo bem?

Então vamos, respire fundo, e vamos começar.

 

 

 

Modo ​Desligado (Dead)

Para demonstrar (sempre usando nossa maneira simples de exemplificar) vamos começar pelo modo mais básico que o móvel pode estar: Desligado!

Nesse caso, não temos muito que falar, não é mesmo? Quando o móvel está desligado, ele não 'aparece' para a rede. Não gasta bateria, não consome os recursos da rede. Em termos da rede, não serve para nada.

Mas serve pelo menos para começarmos a entender os conceitos de hoje: esse é um ‘modo’ que o móvel pode estar!

 

Localização

Já fazendo uma pequena parada, antes mesmo de avançar: um parêntesis em nossa conversa. Antes de seguir para os próximos modos e estados, precisamos falar de outro assunto importante, bastante relacionado com o tema de hoje, e que também deve estar bem entendido: a localização do móvel, e como a rede o enxerga.

Isso porque a localização do móvel tem papel significativo nos modos e principalmente na transição de estados que o mesmo pode assumir. Devemos recordar, mesmo que muito rapidamente, alguns conceitos básicos de localização em sistemas celulares.

A regra geral é que sempre que o móvel detecta que ele mudou de célula, ele realiza um procedimento para informar à rede a sua nova localização, ou seja, faz uma atualização de seu posicionamento, informando seus ‘identificadores de localização’ atuais, em mensagens específicas.

 

A figura a seguir mostra os diferentes identificadores de localização possíveis, do ponto de vista da RAN (Radio Access Network) e também do Core CS (Circuit-Switched) e Core PS (Packet-Switched).

 

Por exemplo, se o móvel se move da área de cobertura célula ‘A’ para a área de cobertura da célula ‘D’, ele realiza um procedimento ‘cell update’, e informa à rede que agora encontra-se na célula ‘D’.

Esta é a regra geral, e procedimentos similares ocorrem sempre que há mudança de uma área qualquer para outra (seja uma área da célula, URA, RAC ou LAC).

É claro a regra acima não define tudo - ainda existem muitos outros aspectos e conceitos a considerar (por exemplo, o cell update pode ser disparado por outros eventos, não apenas referente à localização). Mas não é nosso objetivo hoje, já que estamos buscando conhecer apenas os modos e estados. Então, vamos continuar, mas fique à vontade para estender depois o estudo nas áreas que tiver interesse - certamente vai valer a pena.

 

Modo Idle

Então vamos continuar conhecendo os modos.

O próximo modo que o móvel pode assumir é bem intuitivo: ligado. Mas o nome do modo não é esse - após ser ligado e consequentemente passar a ser percebido pela rede, dizemos que o móvel encontra-se em modo ‘Idle’.

No modo Idle, além de ser visto (conhecido) pela rede, o móvel também passa a enxergar (conhecer) a rede, podendo então interagir com a mesma.

Como exemplo de interação no modo Idle, o móvel pode ‘acampar’ em uma determinada célula.

 

Mesmo sem sabermos até o momento o que significa o móvel ‘acampar’ em uma célula, podemos afirmar que quando está no modo Idle o móvel realiza uma enorme quantidade de operações, dependendo por exemplo de suas tecnologias disponíveis (2G, 3G e/ou 4G) ou da rede onde se encontra.

E realmente é muita coisa que acontece. Você pode conferir na tela, assim que ligar o seu móvel: primeiro aparece uma mensagem informando que o móvel está buscando a rede. Assim que ele encontra, surgem as barras de antena, seguido de alguma indicação do tipo de tecnologia que ele conseguiu se conectar (GSM, HSDPA, LTE, etc.). E para concluir, aparece o nome da Operadora (ou alguma outra mensagem que a mesma utiliza como identificação).

Neste momento, dizemos que o móvel está ‘acampado’ em uma célula da rede.

Podemos entender que ele está 'atento', tanto para originar quanto para receber uma chamada terminada. Ele ainda não tem um canal dedicado alocado, e não pode fazer ou receber chamadas. Por isso deve ficar constantemente monitorando os canais e comunicação disponíveis, para saber o que fazer quando chegar o momento certo.

Nesse estado, o móvel não tem nenhuma conexão ativa com a rede, e qualquer transmissão de dados vai demandar um estabelecimento (ou reestabelecimento) de uma conexão de controle, para só então passar a transmitir dados. Ele não transmite quase nada nesse estado (somente em alguns casos pequenas informações de atualização de sua área de registro).

Ou seja, o Rádio fica ‘dormindo’ na maior parte do tempo, e só acorda quando for necessário - quando recebe instruções de participar de alguma atividade.

No caso mais específico de móvel 4G em modo Idle, ele tem as atividades de suporte ao DRX (Discontinuous Reception), informações do sistema (SI System Information) para o acesso, cell reseleção e informação de paging.

E no caso mais específico de móvel 3G em modo Idle, ele fica ouvindo ouve o canal CPICH (Common Pilot Channel) da célula onde se encontra acampado e também das vizinhas. E ouve também o canal PICH (Paging Indicators Channel). Nesse último, ele busca seu ‘Paging Indicator’ – um valor verdadeiro ou falso que o informa se ele deve ler o Canal de Paging. Em outras palavras o seu ciclo ‘Idle DRX’ (Discontinuous Reception).

Para entrar nesse modo, o móvel faz contato com a sua PLMN, buscando uma célula adequada que possa lhe fornecer o serviço, e sintoniza em seu canal de controle. Como já mencionamos, esta escolha ou sintonia é o que chamamos de 'acampar' na célula - o móvel vai registrar sua presença nessa área de registro.

Caso o móvel perca a cobertura dessa célula, ele reseleciona (busca) outra célula mais adequada disponível, e acampa nessa outra - fazendo uma reseleção.

Mas vamos parar um pouco aqui: embora a seleção e reseleção de células sejam conceitos muito relacionados com os modos, estados e transições, estamos nos aprofundando muito num tema que não é o objetivo principal de hoje. Voltemos então ao modo Idle, de forma geral. Se for o caso, e se houver interesse, falamos mais especificamente sobre esse ou outros temas em outro tutorial.

Voltando (e resumindo) então, o objetivo do móvel acampar em uma célula no modo Idle é que ele possa receber informações da rede. No caso de chamadas originadas pelo mesmo, ele já inicia a mesma pelo canal de controle correspondente, da célula onde está acampado. E no caso de chamadas terminadas, a rede já conhece previamente as informações do mesmo, como em qual área ele se encontra, e então envia uma mensagem de 'paging' para  ele nos canais de controle dessa área de registro, por onde o móvel responde.

Se buscamos o significado direto de Idle, encontramos algo como ‘não fazendo nada’. Porém, não é bem exatamente o que acontece. Além dos procedimentos iniciais que descrevemos acima (procedimento power-on), o móvel continua realizando muitas outras atividades.

 

Modo Avião

Embora não esteja ilustrado na figura acima, o ato de ligar (power-on) não é o único que leva o móvel para o modo Idle. O móvel pode ir para o modo Idle também quando desligamos o modo ‘avião’ do mesmo.

 

Esse é um modo extremamente particular, e em termos de rede, podemos considerar o ato de colocar o móvel em modo avião como ‘desligar a rede’. Da mesma forma, desligar o modo avião equivale a ‘ligar a rede’.

O modo avião, como o próprio nome sugere, teve origem devido à proibição do uso de aparelhos móveis celulares em aviões. O ‘problema’ na verdade refere-se apenas à utilização da radiofrequência do aparelho. Então, criou-se a opção de ‘desligar’ apenas a parte rádio do aparelho, deixando os usuários livres para utilizar outras funções, como jogos e ferramentas como editores de texto e planilhas.

E é claro, não é necessário estar em um avião para usar este modo. O modo avião pode ser usado sempre que haja necessidade de desligar/ligar os rádios do aparelho - sem ter que aguardar que o mesmo reinicie completamente.

Quando o móvel é ligado (ou quando o Modo Avião é desligado), ele entra no modo que já conhecemos: o modo Idle.

Vamos continuar e conhecer um outro modo que o móvel pode estar.

A menos que você faça (por exemplo, ligue para alguém) ou receba uma chamada de voz, ou então que faça ou receba uma chamada de dados (por exemplo, navegando em uma página de Internet), você permanecerá no modo Idle.

Mas se uma chamada ocorre, então tudo muda. O móvel passa para o modo conhecido como Modo Conectado.

 

Modo Conectado

Certo, até agora já entendemos como o móvel chega no modo Idle, e também que, embora o nome não indique isso, é um modo muito importante, onde muita coisa acontece.

Mas o objetivo de todo móvel é transferir dados na forma de chamadas, sejam elas de voz ou dados. E quando o móvel faz uma dessas chamadas, dizemos que ele está no modo conectado!

Diferente do modo Idle, onde podemos fazer praticamente as mesmas considerações para as tecnologias 2G, 3G e 4G, as considerações do modo Conectado são diferentes para cada uma.

O fato comum à todos é que, quando o móvel precisa iniciar a comunicação, ele precisa estabelecer uma conexão de controle, e posteriormente uma conexão que o permita trafegar as informações.

No caso do 3G e 4G: quando o móvel inicia uma chamada, ele primeiro envia uma solicitação para estabelecer uma conexão de sinalização.  Em seguida então é iniciado o procedimento de estabelecimento de conexão RRC (Radio Resource Control). Quando a conexão RRC é estabelecida, o móvel entra no modo Conectado.

Nota: No caso do 2G, a ideia é a mesma, mas alguns outros conceitos aparecem. Como o nosso tutorial deve ficar um pouco extenso devido ao número de conceitos que serão abordados, e também porque a transição de estados 2G requer um pouco mais de explicações adicionais (conceitos apenas 2G), vamos deixar essas explicações detalhadas para um outro tutorial, caso haja interesse por parte de nossos leitores. De qualquer forma, embora não explicadas aqui, as transições de estados 2G permanecem representadas na figura geral.

A princípio, somos levados entender o modo conectado simplesmente como o ‘contrário’ do modo Idle. Infelizmente, o cenário não é tão simples assim.

Hoje em dia, é cada vez maior a quantidade de smarphones disponíveis no mercado, cujo lado benéfico foi uma maior adoção (em massa) do uso de dados. Realmente este alcance foi muito grande, e está cada dia maior.

Entretanto, trouxe um grande desafio sobre como suportar esse ‘tsunami’ de sinalização que tal utilização massiva de dados requer.

Os agora inúmeros usuários querem todos estar conectados, ao mesmo tempo, nos mais diversos tipos de aplicação.

Por diversos motivos e mecanismos, cada um dos smartphones periodicamente ativa e desativa suas conexões.

Enquanto o objetivo é que o usuário tenha a percepção de sempre conectado, a quantidade de sinalização torna essa missão quase impossível.

Felizmente, para minimizar esse problema foram criados diferentes ‘estados’ no modo conectado! 

Embora neste tutorial estejamos buscando entender de forma geral os estados e modos de operação dos móveis uma rede, os modos UTRAN (3G UMTS) e E-UTRAN (4G LTE) tem alguns conceitos ou estados mais específicos. Então vamos prosseguir, mas falando separadamente sobre cada um deles.

 

Modo Conectado 3G

Quando um móvel 3G encontra-se no modo conectado, o seu nível de conexão com a UTRAN é determinado pelos requisitos de QoS do RAB ativo, e das características de tráfego dos mesmos.

Os desafios no UMTS de manter uma grande quantidade de usuários conectados levaram a mecanismos e implementações que buscassem minimizar esse cenário.

Como exemplo, algumas implementações buscam minimizar o consumo de bateria do móvel, e outras implementações buscam diminuir a sinalização. A funcionalidade Fast Dormancy (disponibilizada pelo 3GPP no Release 8) também tem mecanismo de atacar esse desafio. Outras funcionalidades ainda vem sido desenvolvidas e melhoradas até hoje.

Ironicamente, os sistemas UMTS foram desenvolvidos para suprir a crescente demanda de multimídia (dados) vista anos atrás. Como se pensava em um crescimento muito grande de dados, o sistema foi desenhado de maneira eficiente para o transporte dessas altas larguras de banda de bits, vídeos, etc. Mesmo com um pequeno atraso para iniciar, o sistema atendia bem, principalmente em casos de taxas altas.

Mas nos últimos anos, a explosão de dados vista foi maior que se imaginava. Smartphones cada vez mais baratos e acessíveis, planos de dados ilimitados estendidos até para usuários pré-pagos, explosão de aplicações de todos os tipos - principalmente aplicações usando pequenos volumes de dados periódicos, com atualizações frequentes.

Novas aplicações surgiram ou se tornaram mais usadas, como Redes Sociais e Mensagens (Whatsapp, Twitter, Facebook), Portfolios de Ações, Sincronismo de E-mail/Calendários/Contatos/RSS.

Embora o sistema UMTS permita, não foi desenvolvido para isso: enviar e receber quantidades muito pequenas de dados, muitas vezes menor que 1 kB.

Cada uma dessas mensagens necessita uma conexão com toda a carga de sinalização associada!

Muitas operadoras mantém os móveis num canal de potência maior, por um período de tempo maior, quando imaginam que ele vai transmitir ou receber mais dados num futuro próximo. Mas isso acaba gastando mais bateria, e ocupando recursos que poderiam estar sendo utilizados por outro usuário.

Para ajudar a melhorar esse problema do móvel 3G que encontra-se em modo conectado, existem os estados: cell_DCH, cell_FACH, cell_PCH e URA_PCH.

 

Vamos conhecer cada um deles, e para facilitar o entendimento, vamos fazer uma classificação de acordo com os itens:

  • Canal: os canais que o móvel utiliza neste estado são dedicados ou compartilhados?
  • Conhecimento pela rede: a rede sabe onde o móvel se encontra a nível de célula ou a nível de URA?
  • Transferências de Dados: o volume de dados a ser transmitido é grande ou pequeno?
  • Transições: quando termina de transferir, ou termina um determinado timer, para onde o móvel vai?

Das classificações acima, talvez a que você não tenha entendido plenamente seja a de canal dedicado ou compartilhado. Uma maneira de se entender essa diferença entre canal dedicado e compartilhado é fazendo uma analogia.

Pense nos canais dedicados como quartos em um hotel - atendimento individual e garantido para o usuário. O único problema é que, assim como num hotel, o número de canais - quartos - é limitado. De qualquer forma, o hotel sempre tenta prover o serviço da melhor forma possível – assim como a rede.

Seguindo a mesma analogia, canais compartilhados seriam um salão de conferências - atende muito mais gente, mas não da mesma forma como atende nos quartos.

Vamos então falar de cada um destes estados, buscando fazer as classificações mencionadas.

 

Estado cell_DCH (UTRAN)

Se existe um estado que representa o modo conectado 3G, esse estado é o cell_DCH.

 

Canal Dedicado. Como o próprio nome do estado sugere, o cell_DCH (DCH: Dedicated CHannel) utiliza um canal dedicado para o móvel no Uplink e no Downlink.

No estado cell_DCH o móvel está no modo conectado, e utiliza um canal dedicado R99, ou um compartilhamento do HS-DSCH (High Speed Downlink Shared Channel) e/ou E-DPCH (Enhanced Dedicated Physical Channel).

Conhecido a nível de Célula. Também podemos intuir do próprio nome que a rede sabe onde o móvel se encontra no nível de célula (de acordo com o Active Set atual).

Transferências de Grandes Volumes de Dados. Quando o móvel deve transferir grandes volumes de dados, esse é o estado ideal.

Mas como sabemos o cenário vem mudando, com a adoção de aplicações cada vez mais comuns que demandam pequenas transferências de dados periodicamente. E se formos utilizar os recursos limitados do cell_DCH para todos os estabelecimentos e reestabelecimentos, fatalmente o sistema entraria em colapso. Na nossa analogia de quartos de hotel, não haveria quartos para todos!

A solução é criar um estado auxiliar que suporte a demanda extra. E isso significa utilizar canais compartilhados, que definem o estado que vamos ver a seguir, o cell_FACH.

Transições para Idle ou cell_FACH (ou estados PCH, como veremos logo mais). Quando o móvel termina de transferir, ele pode retornar para o modo Idle (liberando a conexão RRC), ou mudar para o estado cell_FACH (se houver em um buffer uma quantidade de dados a serem transferidas menor que um determinado limiar configurado – ou em outras palavras, se houver pouco volume de dados a ser transferido).

 

Estado cell_FACH (UTRAN)

Canal Compartilhado. O estado cell_FACH mantém o móvel em modo Conectado, só que ao invés de canal físico dedicado, o móvel utiliza canais compartilhados.

 

Comparando com a analogia do canal dedicado como sendo quartos em um hotel, os canais compartilhados seriam o salão de convenções deste hotel.

Transferências de Pequenos Volumes de Dados. Isso torna esse estado ideal para transmissão e recepção de pacotes de dados pequenos:

  • No Uplink é utilizado o canal RACH (Random Access Channel): o móvel fica constantemente transmitindo mensagens RACH.
  • No Downlink é utilizado o canal FACH (Forward Access Channel): o móvel fica constantemente decodificando o canal FACH.

 

Conhecido a nível de Célula. No estado cell_FACH, a rede também sabe onde o móvel se encontra no nível de célula (a célula onde o móvel fez o último Cell Update).

Transições para Idle ou cell_DCH (ou estados PCH, como veremos logo mais). Quando o móvel termina de transferir no cell_FACH, ele pode retornar para o modo Idle (liberando a conexão RRC), ou mudar para o estado cell_DCH (se houver em um buffer uma quantidade de dados a serem transferidas maior que um determinado limiar configurado - ou em outras palavras, se houver grande volume de dados a ser transferido).

Mas mesmo com a ajuda do cell_DCH e do cell_FACH (quartos do hotel, mais o salão de conferências), a capacidade da rede pode não ser suficiente. Além disso, se as opções de saída desses estados, após o fim das transferências fosse apenas o modo Idle, agravaríamos o problema de aumento de sinalização (reestabelecer conexões).

Mas então qual seria a solução para esses casos, onde tudo já está ocupado? No caso do hotel: pegar o nome e dar uma senha a cada um dos usuários acima do limite, e chamar os mesmos assim que possível/necessário.

No caso da rede 3G, para minimizar esse problema, existem os estados PCH (cell_PCH e URA_PCH). São estados para onde os móveis podem ser transferidos, e não perdem a sua conexão RRC (deram o nome e pegaram uma senha).

Mas por enquanto, ainda não podem usufruir dos serviços do hotel (enviar ou receber dados). Apenas podem ficar atentos, e quando for necessário/oportuno, obter o serviço.

Vamos então conhecer os estados PCH?

 

Estado cell_PCH (UTRAN)

O estado cell_PCH é um dos estados PCH, um modo Conectado que o móvel pode assumir e que tem algumas características interessantes. A começar pelo nome: PCH refere-se a paging.

Embora não seja o mesmo que o estado Idle, esse estado lembra bastante o comportamento daquele modo, principalmente do ponto de vista do móvel. A grande diferença aqui é que conexão de controle (RRC) não é perdida (embora o móvel raramente a utiliza).

 

Sempre que o móvel acampa em uma nova célula o móvel informa à rede (‘cell update’). Lembre-se que no estado Idle, o móvel informa à rede apenas quando há mudança na LA – Location Area ou RA – Routing Area; ou seja, nesse estado temos mais atualizações, pois estamos a nível de célula.

Mas nesse estado, como no Idle, o móvel não transfere dados. E toda vez que o móvel precisa transmitir o ‘cell update’, o móvel precisa mudar temporariamente para o estado cell_FACH.

O móvel fica escutando os mesmos canais como no modo Idle - usa DRX para monitorar o canal PCH selecionado via PICH associado. O rádio permanece inativo na maior parte do tempo, e só acorda no ciclo DRX do estado cell_PCH (Importante: o ciclo DRX do estado cell_PCH é diferente do ciclo DRX do estado Idle).

Como mencionado, a conexão de controle é mantida, então qualquer nova transmissão de dados pode ser realizada de maneira muito mais rápida, e com muito menos sinalização, porque significa apenas enviar os dados presentes.

Nesse estado não há nenhuma atividade de downlink: sempre que o móvel precisa transmitir ou receber, ele vai para o estado cell_FACH.

Conhecido a nível de Célula. No estado cell_PCH, a rede sabe onde o móvel se encontra no nível de célula (a célula onde o móvel fez o último ‘cell update’). Lembrando: o ‘cell update’ é feito no estado cell_FACH.

Sem Transferências de Dados. Os únicos objetivos desse estado são:

  • Economizar energia (usando ciclo DRX similar ao modo Idle)
  • Permitir rápido acesso à rede, já que a rede sabe exatamente qual célula enviar o paging e também porque não há necessidade de setup de nova conexão RRC.

Transições para Idle ou cell_FACH. Se após um certo tempo, continuar sem dados a transferir, o móvel é liberado. Caso contrário, vai para o estado cell_FACH (há dados a serem transferidos).

 

Estado URA_PCH ​(UTRAN)

O quarto e último estado (URA_PCH) é praticamente idêntico ao estado cell_PCH. A única diferença é que os ‘cell updates’ são enviados apenas quando o móvel muda de URA (UTRAN Registration Area) ao invés da mudança de Cell.

Com isso o móvel transmite ainda menos frequentemente que no estado cell_PCH (lembrando que mantém a conexão de controle ativa).

 

Conhecido a nível de URA. A rede sabe onde o móvel se encontra no nível de URA (UTRAN Registration Area) de acordo com a URA assignada ao móvel durante o último ‘URA update’ – lembrando que o ‘URA update’, assim como vimos no estado cell_PCH, é feito somente no estado cell_FACH.

Sem Transferências de Dados. Pelo motivo acima, esse estado é recomendado para móveis que estão se movendo rápido. Mas continua com os objetivos similares do estado cell_PCH:

  • Economizar ainda mais energia;
  • Permitir rápido acesso à rede, já que a rede sabe a URA para qual enviar o paging e também porque não há necessidade de setup de nova conexão RRC.

Transições para Idle ou cell_FACH. Se após um certo tempo, continuar sem dados a transferir, o móvel é liberado. Caso contrário, vai para o estado cell_FACH (há dados a serem transferidos).

 

Comparação entre Modo Idle e Estados PCH (cell_PCH / URA_PCH)

Após conhecer os estados de paging conectados cell_PCH e URA_PCH, podemos dizer que são equivalentes ao modo Idle?

Não. Lembre-se que no modo Idle, não temos nenhuma conexão RRC estabelecida, ao contrário que nos estados cell_PCH e URA_PCH, onde essa conexão ainda existe.

É importante não confundir com o fato de que no modo Idle e estados cell_PCH e URA_PCH o móvel não possui nenhum recurso de radio alocado! Por essa razão, ele não pode iniciar nenhum tipo de transferência de dados nos canais dedicados e comuns. Isso é verdade.

Porém, existe uma diferença muito grande quando o móvel tenta iniciar a comunicação com a rede.

No modo Idle, o móvel precisa enviar uma solicitação de conexão RRC (via RACH). Já no estado cell_PCH ou URA_PCH o móvel se move para cell_FACH, já envia alguma mensagem como a 'cell update', e já está pronto para a comunicação - não tem que reestabelecer a conexão de sinalização, e depois a conexão RRC novamente.

Assim a obtenção do serviço da rede é mais eficiente.

 

Bateria e Sinalização

O consumo de bateria e o aumento de sinalização e interferência na rede estão diretamente relacionados a alguns fatores de configuração das transições de estado, como timers e outros ajustes.

Mas para entender bem como tudo isso funciona, precisamos conhecer algumas informações auxiliares.

Vamos então ver algum desses dados que influem na redução de consumo de bateria do móvel, e redução da sinalização.

Considerando os estados vistos até agora, podemos comparar o consumo de bateria em cada um deles através de unidades relativas. Assim, temos os consumos aproximado de cada estado RRC:

  • OFF = 0
  • Idle = 1
  • cell_DCH = 100 (ou seja, 100 x Idle)
  • cell_FACH = 40 (ou seja, 40 x Idle)
  • cell_PCH < 2 (nesse caso depende da razão do DRX com Idle e a mobilidade)
  • URA_PCH ≤ Cell_PCH ( em cenários de mobilidade é menor que o consume no estado cell_PCH; já em cenários estáticos é o mesmo).

Existe uma relação entre o consumo de energia e a eficiência da comunicação. A figura a seguir nos ajuda a entender melhor isso, pois mostra o workflow dos estados UMTS, onde o estado que apresenta maior consumo encontra-se mais alto na figura. Lembre-se porém que o consumo não deve ser a única variável a ser levada em conta: quanto maior a energia utilizada pelo móvel, mais imediatamente a comunicação acontece.

 

Se o móvel permanece no estado cell_DCH, ele tem conexão praticamente imediata, e um throuput bem alto. Só que consome a bateria 100 vezes mais que no modo Idle.

Se ele permanece no estado cell_FACH, tem um throuput menor, porém com um consumo 40% do cell_DCH.

Se ele permanece num dos estados de paging (cell_PCH ou URA_PCH), o consumo é praticamente o mesmo que no modo Idle. A vantagem é que ambos mantém a conexão de controle, ou seja, a comunicação é retomada de forma bem mais rápida que no modo Idle.

O que o modo Idle tem de bom em relação à essa relação (consumo de bateria versus eficiência de comunicação) é que o consumo de bateria é mínimo, e a carga produzida na rede também.

Assim, a rede sempre busca mover os móveis para os estados de energia mais alta quando é necessário transmitir ou receber, e o mais rápido possível, trazer os mesmos de volta para estados de menor energia quando não há previsão de novas transmissões.

Os algoritmos de gerenciamento de recursos de radio (RRM) que tomam tais decisões são implementados pela rede.

Importante: O móvel não pode mudar sozinho de um estado a outro, ele é sempre direcionado pela rede!

Importante: estamos falando sobre consumo de bateria e aumento de sinalização de acordo com as configurações de parâmetros na rede. Até aqui tivemos o resumo, e poderíamos tranquilamente passar para o próximo e último modo do nosso tutorial de hoje, o modo Conectado 4G. Entretanto, já que estamos com esse assunto bem recente em nossa mente, e também pela dificuldade em se encontrar documentação específica sobre este tema, vamos fazer um ‘extra’, e falar um pouco mais sobre isso, porém agora de uma forma mais detalhada. Se você quer apenas conhecer os modos e estados de maneira geral, pode pular para o último item (Modo Conectado 4G). Entretanto, se deseja aprofundar um pouco mais no tema de sinalização 3G, basta seguir lendo.

 

Bateria e Sinalização x Timers e Outros Ajustes

Vamos falar agora sobre os timers (temporizadores) e triggers (disparadores) que fazem com que o móvel vá de um estado para outro, no modo Conectado 3G.

Já vimos que quando o móvel está no estado cell_DCH, ele faz a transmissão/recepção de grandes volumes de dados. Em um determinado momento, não há mais o que se transmitir/receber, o móvel para de transmitir.

Mas a rede não retira imediatamente o móvel do estado cell_DCH, já que ele pode ter mais dados para receber/transmitir em breve.

Esse tempo em que a rede decide mover o móvel do estado cell_DCH para o estado cell_FACH é muito crítico (lembre-se que enquanto o móvel está no estado cell_DCH, ele mantém um canal dedicado, ou ocupa um lugar no algoritmo de scheduling HSDPA (High Speed Downlink Packet Access).

Esse tempo de inatividade é informalmente chamado de T1, uma vez que não é padronizado pelo 3GPP, mas é amplamente usado pelos fabricantes.

Somente após decorrido o tempo de inatividade configurado para cada estado, é que a rede coloca o móvel em outro estado mais adequado.

No caso do móvel que estava transmitindo no estado cell_DCH parar de transmitir, começa a contar um timer T1. Após decorrido este tempo o RNC envia o móvel para o estado cell_FACH ou cell_PCH.

Já quando o móvel está no estado cell_FACH, fazendo a transmissão/recepção de pequenos volumes de dados (ou simplesmente porque foi redirecionado do cell_DCH), um tempo parecido é usado pela rede para disparar o envio do móvel para um estado de menor energia. Também informalmente como o T1, este timer é chamado de T2. O estado de menor energia para onde a rede mandará o móvel pode ser o cell_PCH ou o URA_PCH, dependendo da disponibilidade desses estados na rede.

Para redes que suportam cell_PCH ou URA_PCH, temos ainda um terceiro timer, T3. Quando o móvel fica no estado cell_PCH durante um determinado tempo, o RNC dispara a transição para Idle.

O objetivo desses timers (tempos decorridos para o disparo da transição de estados) é bem fácil de ser entendido, se tentamos responder a seguinte pergunta: Em um conjunto de móveis, qual deles deverá voltar a enviar ou receber dados primeiro (qual a probabilidade)?

A resposta é que é mais provável que sejam aqueles móveis que estavam utilizando dados recentemente, por último.

Por esse motivo a rede mantém o móvel em um canal dedicado por alguns segundos T1 antes de enviar para os canais comuns do cell_FACH - pode ser que o mesmo venha a solicitar mais dados muito em breve.

Isso funciona bem para alguns tipos de aplicações, como um usuário navegando por páginas em um browser.

Porém, esse algoritmo vem se tornando cada vez mais inadequado, devido ao surgimento e utilização cada vez maior de aplicações que possuem agendamento de atualização periódica, como já exemplificamos no início deste tutorial, como Redes Sociais e Messengers (Whatsapp, Twitter, Facebook), Portfólios de Ações, Sincronismo de Email/Calendários/Contatos/RSS.

Esse tipo de atualização pode acontecer por exemplo a cada 2 ou 3 minutos.

E o que isso significa? Já deu tempo para o móvel voltar de cell_DCH para Idle! Novamente teremos que reestabelecer a conexão RRC em cada um desses updates; novamente obter um canal dedicado ou compartilhado. E tudo isso, muitas vezes para transmitir apenas 1 kB, com duração de 1 segundo ou menos!

O móvel ainda permanece alguns segundos ocupando um canal de alto consumo de energia, gastando bateria, desperdiçando recursos da rede e causando interferência para os outros móveis!

Como podemos ver, chegamos a um ponto de desafiante. Na verdade, um dilema.

Em relação ao consumo de bateria, é melhor que o móvel volte o mais rápido possível para o modo Idle, logo depois que termine de transmitir. Ou seja, fique o menor tempo possível ‘conectado’.

Em relação à experiência do usuário, é melhor que ele fique o maior tempo possível ‘conectado’.

O tempo de transição do modo Idle para cell_DCH (tempo de ativação do RAB) leva cerca de 2 segundos.

Quando a transição ocorre de um estado PCH para cell_FACH, esse tempo de ativação do RAB cai para 0.25 segundos. Nesse caso precisamos que a rede suporte algum dos estados PCH (cell_PCH e/ou URA_PCH).

Ou seja, temos uma equação com diversas variáveis (reduzir consumo de bateria, melhorar experiência usuário, reduzir sinalização e interferência) que depende de diversos fatores (se a rede dispõe de estados PCH, o valor dos tempos T1 e T2, o tempo de ativação do RAB do DRX).

Diversos tipos de otimização podem ser feitas na tentativa de se alcançar a melhor configuração de acordo com a rede.

Vamos tentar mostrar a seguir algumas dessas possíveis combinações de forma gráfica, considerando a transmissão de um pequeno pacote de dados (~ 1kB ), em um tempo muito curto ( ~ 1 s), em vermelho (1).

 

No eixo vertical temos o consumo relativo de bateria, comparado com o consumo no modo Idle. No eixo horizontal, temos o tempo em que o móvel fica em cada um dos estados, que por sua vez são identificados pelas cores. As respectivas áreas representam a energia usada.

 

Colocando as principais combinações juntas, temos o gráfico abaixo.

 

No primeiro exemplo (1) temos os tempos T1 e T2 altos (=10 segundos), em uma rede que não dispõe de estados PCH, e consequentemente sempre tem um tempo de ativação de RAB alto (=2 segundos).

 

No exemplo seguinte (2) temos o mesmo cenário, só que reduzindo os tempos T1 e T2 pela metade (=5 segundos). É nítido que a configuração dos timers T1 e T2 afeta diretamente a duração da bateria percebida pelo usuário – nesse caso, reduzida. Porém, o móvel volta muito mais cedo para o modo Idle. Isso significa que toda vez que o usuário for reiniciar a utilização de dados (como um novo clique em uma página da web, após algum tempo em que levou lendo a página anterior) ele deverá passar por todo o processo de ativação de RAB (Radio Access Bearer), esperando cerca de 2 segundos.

 

Além do tempo em que o usuário espera ser em si um inconveniente, temos ainda o problema da grande quantidade de sinalização envolvida nesse processo, adicionando ainda mais carga à rede (nesse caso, a RNC).

Tentando resolver esse problema, usamos os estados PCH, como no exemplo seguinte (3). Agora temos uma ativação do RAB (Radio Access Bearer) muito mais rápida (0.25 segundos), já que no estado PCH ainda mantemos a conexão de controle.

 

O único inconveniente nesse caso é que o consumo de bateria no estado PCH, embora também sendo baixo, ainda é o dobro que no modo Idle (menor consumo possível). Em longo prazo, esse consumo também faz diferença na duração da bateria.

Para tentar minimizar esse consumo de bateria no estado PCH, podemos ajustar o ciclo DRX de cada um desses estados. No exemplo anterior, a configuração estava como a recomendada, com o ciclo DRX do estado cell_PCH o dobro do tempo do ciclo DRX do modo Idle. Valores típicos são Idle DRX = 1280 ms e cell_PCH DRX = 640 ms, ou então Idle DRX = 640 ms e cell_PCH DRX = 320 ms.

Mas se ajustamos os ciclos para o mesmo valor, como no próximo exemplo na sequência do gráfico (4), o consumo de bateria no estado cell_PCH fica praticamente igual ao consumo no modo Idle.

 

Nota: Falaremos em outro tutorial sobre o DRX, mas por enquanto saiba que o mesmo influi na forma com que o móvel ‘escuta’ o paging. Quanto menor esse ciclo, mais responsivo é o móvel (mais atento, recebendo mais informação de page), porém maior o consumo da bateria. Quanto maior o ciclo DRX, menor consumo da bateria, porém menos responsivo o móvel fica para as chamadas iniciadas pela rede (pagings).

Se aumentamos o ciclo DRX do cell_PCH (para ficar igual ao do modo Idle) e consequentemente diminuir o consumo, temos a desvantagem de diminuir um pouco a probabilidade de resposta do móvel aos pagings.

Como último caso de exemplo (5), temos a participação dos fabricantes de terminais, que no passado, quando o problema de sinalização não era tão comum como mais recentemente, desenvolveram por sua própria conta mecanismos que economizassem bateria.

 

A ideia básica de todos era a óbvia: se o móvel não está necessitando transmitir mais, após algum tempo (de inatividade) ele deve retornar para o modo Idle. O móvel simplesmente decide sozinho quando liberar sua conexão (não a rede), através da mensagem SCRI (SIGNALLING CONNECTION RELEASE INDICATION), existente desde a Release 99, mas que não esperava nenhuma resposta da rede.

A seguir, novamente o gráficos com alguns exemplos de otimização que podem ser feitas através do ajuste de timers, utilização de estados PCH, configuração de ciclos DRX, etc.

 

Importante: Nos exemplos, sempre iniciamos a transmissão utilizando o estado cell_DCH, e em seguida o cell_FACH. O nosso objetivo foi ilustra as configurações dos tempos T1 e T2. Mas no nosso exemplo específico, consideramos um pequeno volume de dados, em um tempo muito curto.

Pelo que já vimos, essas são condições ideais para o estado cell_FACH. Ou seja, na prática, essa transmissão de pacotes do exemplo é configurada para acontecer no estado cell_FACH, ao invés do cell_DCH.

Mas independente disso, temos um fator comum a todos os exemplos: todas as transições do móvel até agora são comandadas pela rede, não há ‘diálogo’ com o mesmo. (Com exceção do último exemplo, com implementações proprietárias de tempo de inatividade – e mesmo assim é apenas uma ação arbitrária do móvel, que simplesmente decide voltar para o modo Idle).

Ou seja, não temos otimização de recursos. Mas ninguém mais que o móvel sabe exatamente o que está se passando, o que está ocorrendo. Quais aplicações estão sendo utilizadas, e o que provavelmente vão demandar da rede.

E melhor ainda: ninguém melhor do que o móvel para dizer que não precisa de mais nada – que a rede pode encerrar sua conexão!

Se estabelecemos esse diálogo, a rede pode imediatamente mover o móvel para um estado de energia mais conveniente no momento, e configurado pela operadora.

Essa conversa é excelente para ambos: o móvel economiza bateria, e a rede economiza recursos (canais) e reduz interferência!

Infelizmente, a importância desse diálogo foi percebida um pouco tarde (quando os fabricantes já seguiam sua própria implementação de liberar a conexão de sinalização, sempre para o modo Idle). Somente em 2008/2009, a Release 8 do 3GPP padronizou o mecanismo FD (Fast Dormancy), que definia que o móvel poderia se comunicar com a rede utilizando a mensagem já existente SCRI, agora com o IE (Information Element) "Signalling Connection Release Indication Cause" presente e configurado para "UE Requested PS Data session end".

Em outras palavras: com o FD, o móvel pode dizer para a rede que não quer mais nada, e a mesma pode imediatamente retirá-lo de um canal de alto consumo de energia, enviando para um estado mais apropriado.

O FD permite que o controle dos estados bypasse os timers de inatividade, após o móvel terminar de transferir todos os seus dados – ao receber a SCRI, a RNC pode enviar o móvel para o modo Idle.

Acabamos de ver então os principais cenários de configuração de timers relacionados às transições de estados, com um pouco mais de detalhes (e ainda podemos perceber que há muito o que ser visto e discutido!).

Mais uma vez, fugimos do objetivo de ser simples, porém esse entendimento pode ser bastante elucidativo, até mesmo para os mais experientes no assunto, e por isso decidimos abordá-lo.

Vamos voltar, e concluir nosso tutorial, falando um pouco sobre o modo conectado no 4G.

 

Modo Conectado 4G

Finalmente, chegamos ao último modo do tutorial de hoje. Não se preocupe, estamos quase acabando, e muito em breve você será capaz de entender a figura com visão geral que mostramos no início.

Da mesma fora que os móveis 3G, após ser ligado, o móvel LTE realiza uma série de ações, os procedimentos de acesso inicial. Isso inclui por exemplo ‘Cell Search’ e ‘Cell Selection’, recepção de informações do sistema e o procedimento de acesso aleatório. Novamente: estes conceitos não serão explicados aqui hoje, pois queremos apenas entender apenas como funcionam os modos, estados e transições de forma geral.

Comparado com 2G e 3G, os estados e transições de estados LTE (4G) são bem mais simples: Ou o móvel está no modo Idle, ou está no modo Conectado. Isso vale também para LTE-A (Advanced).

 

Um conceito que já deve ter ficado claro para você, a partir do que vimos até agora é a importância da melhoria da eficiência de economia de bateria e recursos da rede. E que isso está extremamente relacionado com os estados, como e quando ocorrem suas transições. Principalmente no cenário global cada vez maior de aplicações do tipo 'Always-on', com pequenas transmissões de dados muitas vezes imprevisíveis.

Já deve estar começando a imaginar como aplicar alguns conceitos em sua própria rede, mas ao mesmo tempo se preocupando porque não consegue vê uma solução tão eficiente, capaz de atender a tantas diferentes variáveis.

Mas temos uma boa e uma ótima notícia. A primeira, e boa notícia, é que não é apenas você que tem essas dúvidas. As redes 3G realmente não são as mais adequadas para esse cenário, uma vez que não foram construídas com essa finalidade. De qualquer forma, podem ser bastante melhoradas, com a aplicação de features como a 'Continuous Packet Connectivity'.

E a ótima notícia é que o LTE (4G) já foi criado pensando nesse tipo de problema desde a sua concepção!

Um exemplo disso é o DRX (Discontinuous Reception) no modo Conectado, que dá mais opções ao móvel: a possibilidade de desligar periodicamente o seu rádio. Esse tempo de liga-desliga pode ser configurado até a granularidade de 1 ms!

Sabemos porém que desligar o móvel pode trazer um impacto negativo em termos de latência. Para minimizar esse problema, foram definidos 2 estágios de DRX.

 

No primeiro estágio, a partir de um certo tempo decorrido sem que haja mais transferência de dados, o móvel utiliza o ciclo de DRX curto, ou seja, poderá 'dormir' (desligar o rádio) por períodos bem pequenos. O rádio fica 'dormindo' e 'acordando' mais frequentemente.

Quando estiver utilizando o ciclo DRX curto, podemos passar para o segundo o estágio (ou mesmo retornar para o estado de Recepção Contínua, caso existam dados a serem transferidos). O segundo estágio segue a mesma idéia anterior: passado um determinado tempo sem dados para transferir, o móvel utiliza um ciclo DRX longo, ou seja, agora vai 'dormir' (desligar o rádio) por períodos mais longos.

Por um lado economiza bateria, por outro, aumenta a latência.

Importante: cuidado para não confundir o ciclo DRX conectado do LTE com o DRX do modo Idle. No modo Idle, o DRX é mais relacionado ao paging, e por isso muitas vezes é chamado de paging DRX. Esse tempo do ciclo DRX do modo Idle é muito longo que o do LTE, podendo chegar a segundos!

De certa forma, podemos considerar esses estágios como ‘sub-estados’ do LTE no modo conectado.

Quando o móvel LTE está no modo Conectado, ele possui uma conexão RRC, e suas informações são guardadas (conhecidas) na eBN (e-NodeB). O móvel monitora os canais de controle associados com o canal de dados compartilhado, e verifica se há dados agendados para ele (ou não), informa o CQI (Channel Quality Feedback Information) após todas as medidas e também realiza medidas das vizinhas de todas as redes (2G/3G/4G).

Em relação ao seu conhecimento pela rede, no estado cell_FACH, a rede (eNodeB) sabe onde o móvel se encontra no nível de célula (a célula onde o móvel fez o último Cell Update).

Falando sobre transições, já sabemos que o LTE temos apenas 2 estados básicos: Idle e Conectado. Portanto o móvel no LTE vai de modo Idle para Conectado ou de Conectado para Idle.

Para entrar no modo Conectado, o móvel realiza o setup de conexão: setup de RRC, configurações/reconfigurações e segurança. E inicia uma nova conexão ou mantém as existentes.

Quando o móvel não solicita recursos nem de uplink nem de downlink da rede (eNodeB), e da mesma forma a rede (eNodeB) não recebe sinalização/tráfego destinadas ao móvel, o móvel reseta/libera todos os recursos de rádio (incluindo sinalização), informa à rede que está saindo do estado e o motivo. Em outras palavras, sempre que a conexão termina, o móvel é liberado.

Em relação ao consumo de bateria, quando o móvel está no modo conectado, o móvel tem um consumo variável. Se ele estiver ativamente transferindo dados dizemos que está no 'sub-estado' Continuous Reception.

Após um determinado tempo (t1) sem mais dados a serem transferidos, o móvel muda para o 'sub-estado' Short DRX - e fica esperando por mais dados, por outro determinado tempo (t2).

Se chegar mais dados, ele então retorna ao 'sub-estado' Continuous Reception, caso contrário, segue para o 'sub-estado' Long DRX.

 

Diferentemente do 3G, o dreno de energia no 4G LTE é variável, dependendo do throughput. Taxas baixas requerem menor energia, mas a medida que as taxas aumentam, o consumo de energia também aumenta.

Numa comparação grosseira com o 3G, o radio LTE consome mais energia porque os seus estados de finalização da comunicação (Short DRX e Long DRX) consomem a mesma alta energia, enquanto no 3G temos o cell_FACH, que consome menos da metade da energia base cell_DCH. Mas embora tenha o consumo um pouco maior, não podemos nos esquecer que o LTE é muito mais rápido que o 3G.

Todas essas comparações e algoritmos implementados podem ser vistos indiretamente nos diagramas de transição de modos e estados 2G/3G/4G, como o que temos abaixo.

 

É claro que este diagrama não está totalmente completo, mas tentamos agrupar pelo menos as principais informações necessárias para as explicações.

Esperamos que o objetivo de hoje tenha sido alcançado, e este resumo o ajude a entender melhor como é o funcionamento da rede do ponto de vista do móvel, principalmente o que isto representa em termos de consumo de bateria, aumento de sinalização, latência, interferência e outros fatores que afetam diretamente a qualidade da rede e consequentemente a experiência do usuário.

 

Conclusão

Todos os conceitos de modos, estados conectados e transições em redes móveis vistos no tutorial de hoje são bem mais amplos (e complexos) do que o que foi apresentado. Tentamos apresentar de o assunto de forma simplificada, porém a quantidade de detalhes (e conceitos auxiliares que precisam estar bem entendidos) torna essa tarefa muito difícil, devemos reconhecer.

Com o entendimento dos conceitos apresentados, é fácil perceber o grande espaço que temos para as técnicas e soluções que possam melhorar a eficiência da comunicação e acelerar o tráfego, ao mesmo tempo em que consigam economizar bateria do móvel e recursos da rede.

Afinal isto é sempre o que buscamos: ajudar você a entender um pouco de cenários complexos, tornando-os mais simples de serem entendidos, e assim dando subsídios para que você continue evoluindo em seus estudos e trabalhos.

Contamos com você, mantendo-se como fiel leitor, e principalmente, fazendo parte desse projeto junto conosco. Se você gostou desse tutorial (ou de outros do nosso site), compartilhe com sua rede de colegas e amigos.

O seu reconhecimento participando é o que nos motiva a seguir acompanhando a evolução das redes, e trazer sempre novos tutoriais, notícias e inovações.

Até o próximo tutorial.