O que é RRC e RAB?

Postado por leopedrini segunda-feira, 20 de maio de 2013 09:30:00 Categories: Curso
Rate this Content 6 Votes

Para trabalhar diariamente com modernas redes wireless como UMTS e LTE, é essencial que o profissional de telecom tenha pleno entendimento de seus conceitos mais básicos, como aqueles que controlam o estabelecimento e a manutenção de uma chamada, seja ela de Voz (CS) ou Dados (PS).

Nesse cenário, RAB e RRC são os dois dos conceitos mais importantes pois são responsáveis por toda a negociação envolvida nessas chamadas.

 

 

 

Além do RAB e RRC, temos ainda alguns outros termos diretamente envolvidos no contexto, como RB, SRB, TRB, AS, NAS entre outros. São conceitos igualmente importantes, uma vez que sem eles o RAB e RRC não poderiam existir.

Então vamos tentar hoje entender da forma mais simples possível o papel do RRC e RAB nas chamadas dessas redes móveis na prática. A medida que se tornar necessário, vamos também falar dos demais conceitos citados.

 

Introdução

Para começar, podemos dividir uma chamada em duas partes simples: a sinalização (ou controle) e os dados (ou informação). Já adiantando um dos principais conceitos, podemos entender o RRC como responsável pela parte de controle, e o RAB como responsável pela parte da informação.

Como mencionado, outros conceitos auxiliares são envolvidos nas chamadas, mas nosso objetivo hoje é fixar os conceitos mais básicos - RRC e RAB, permitindo que posteriormente consigamos evoluir em nossa aprendizagem.

Por incrível que pareça, até profissionais que já trabalham com redes UMTS – WCDMA e LTE tem alguma dificuldade na compreensão plena dos conceitos de RRC e RAB. E sem esse entendimento inicial, dificilmente os mesmos conseguem evoluir em com clareza ou eficiência em seu trabalho diário.

Sem mais introdução, vamos direto ao assunto e então tentar entender de uma vez por todas esses conceitos tão importantes.

 

Analogia

Como sempre, e já costume do telecomHall, vamos fazer uma analogia que nos auxilie a entender o funcionamento do RRC e RAB na prática.

Vamos começar imaginando o seguinte cenário real: duas pessoas estão isoladas por um penhasco. Do lado esquerdo, uma pessoa (1) deseja comprar alguns coisas que estão à venda numa loja (2) - ou depósito - do lado direito. Nesse lado direito, além do depósito, temos também uma vendedora (3), que ajudará o comprador a entrar em contato (negociação) com o depósito.

Como objetos adicionais ou auxiliares (4), temos algumas barras de ferro de diferente tamanhos, e alguns carrinhos – uns parecidos com vagões de trem, outros como carrinhos de controle remoto.

Resumindo, temos a situação esboçada na imagem abaixo.

 

E então, como essa situação pode ser resolvida?

Vamos prosseguir com uma solução possível: o comprador da esquerda anota o seu pedido, amarra em uma pequena pedra que encontra pelo chão, e joga (1) para o vendedor no outro lado. A pedra leva então a informação ou solicitação inicial.

 

A vendedora recebe a solicitação, mas precisa enviar a mesma para o depósito, a fim de serem enviadas as compras solicitadas. Ela envia a solicitação em um carrinho de controle remoto (1), que percorre um caminho previamente demarcado até o depósito.

 

Algum tempo depois, a resposta do depósito chega à vendedora (1), que então verifica se vai poder enviar os dados ou não.

 

Para podermos prosseguir com a nossa chamada, vamos considerar uma resposta positiva. Ou seja, o que o comprador está querendo, ou os ‘recursos’ estão disponíveis.

A vendedora percebe que para atender à solicitação, e poder enviar as compras, ele vai precisar construir um ‘caminho’ (1) entre as duas pontas do penhasco, para que os vagões possam transitar com os pedidos/recibos e as compras. Então, o vendedor utiliza algumas de suas barras de ferro e cria uma ligação entre os dois.

 

Estabelecido todo o caminho entre os envolvidos, as solicitações podem ser enviadas de ambos os lados, bem como as compras ou quaisquer outras informações podem ser transferidas, pelos diferentes caminhos e vagões/carrinhos!

Se você conseguiu entender como foi resolvido o problema acima, parabéns, você acabou de entender como funciona a forma mais comum de comunicação UMTS – WCDMA e LTE!

Embora as analogias não sejam perfeitas, nos ajudam bastante a entender o complexo funcionamento dessas redes, principalmente em relação aos novos conceitos como RRC e RAB, mas também de um também muito usado, o ‘bearer’ – tanto que vale a pena falarmos um pouco sobre ele antes.

 

O que é Bearer?

Se procurarmos a palavra ‘bearer’ no dicionário, vamos encontrar algo do tipo Carregador, Portador ou Transportador. De forma simples: aquele que carrega ou transporta algo de algum ponto a outro ponto. Em um restaurante, podemos fazer a correspondência do ‘bearer’ com um Garçon.

 

Mas do ponto de vista de Telecomunicações, ‘bearer’ é melhor entendido como um ‘cano’ que conecta dois ou mais pontos em um sistema de comunicação, através dos quais os dados fluem.

 

Falando mais tecnicamente, é um canal que transporta Voz ou Dados, uma conexão lógica entre diferentes pontos (nós) que garante que os pacotes que estão trafegando tenham as mesma características de QoS. Explicando melhor: para cada ‘bearer’ temos diversos parâmetros associados, como por exemplo qual o atraso e perda de pacotes limite – e são esses atributos que fazem com que cada pacote que vai nesse mesmo canal tenha os mesmos parâmetros QoS.

 

Fluxograma Geral - RRC, RAB e Outros

Agora que sabemos o que é bearer, vamos voltar à analogia apresentada anteriormente, mas agora trazendo as mesmas para o lado real, mais técnico.

Tudo o que vamos falar vai ser resumido em um única figura, contemplando todos os conceitos vistos hoje, e que detalharemos a partir de agora.

Nota: Se você conseguir entender bem os conceitos que serão explicados na figura abaixo, você já estará com um ótima base tanto para redes WCDMA quanto para redes LTE. Isso porque para facilitar as nomenclaturas de referem ao WCDMA, mas o princípio é praticamente o mesmo no LTE. Basta apenas fazer as correspondências equivalentes, como trocar NodeB por eNB.

 

Naquele nosso cenário fictício, a vendedora é a UTRAN, a responsável por criar e manter a comunicação entre o UE (comprador) e o CN (depósito) a fim de que os requisitos de QoS de cada uma sejam atendidos.

  • UTRAN: UMTS Terrestrial Radio Access Network
    • NodeB
    • RNC
  • UE: User Equipment
  • CN: Core Network
    • MSC: para serviços de voz comutada
    • SGSN: para serviços de pacotes comutados

O penhasco é a Interface Uu, entre o UE e a UTRAN, e a estrada por onde passa o carrinho que vai até o depósito é a Interface Iu, entre a UTRAN e o CN.

O envio de solicitações e recibos é a parte de sinalização, ou o RRC. Já o envio das compras é a parte de dados, ou o RAB. No nosso cenário, o RRC são os trilhos, e RAB é o serviço completo do envio de dados entre o UE e o CN.

  • RRC: Radio Resource Control
  • RAB: Radio Access Bearer

Nota: O RRC se dá na Camada 3 do Plano de Controle, enquanto o RAB se dá entre o UE e o CN, no Plano de Usuário.

Os vagões de trem são os RBs, e transportam a informação no caminho rádio. Esses vagões definem que tipo de coisa será transportada, e em qual quantidade. Da mesma forma, os RBs definem que tipo de dados vão no RRC, podendo ser sinalização ou dados. Quando os atributos de QoS mudam, então os RBs associados com aquela conexão RRC precisam ser reconfigurados.

Já os carrinhos de controle remoto são os Iu bearer, e transportam as informações na Interface Iu (entre a UTRAN e o CN), seja ela CS ou PS.

  • RB: Radio Bearer
  • Iu bearer: Interface Iu Bearer

Nota: RAB é a combinação de RB e Iu bearer.

Como alguns exemplos de RAB para diversos serviços e diferentes taxas temos:

 

O RAB Conversational e o RAB Interactive podem ser usados juntos, e nesse caso temos um caso de MultiRAB.

O RB é uma conexão de Camada 2 entre o UE e a RNC, e pode ser usado para controle de sinalização e dados de usuário. Quando é usado para sinalização ou mensagens de controle é chamado de SRB. E quando é usado para dados de usuário é chamado de TRB.

  • SRB: Signalling Radio Bearer (Control Plane)
  • TRB: Traffic Radio Bearer (User Plane)

Nota: em uma rede otimizada, podemos encontrar grande parte do tráfego sendo tratado por HSPA bearers, até mesmo MultiRAB. Essa opção libera recursos de CE (Channel Elements), aliviando assim a carga para o R99 (que somente pode utilizar tais recursos). Entretanto, a mesma deve ser feita com com atenção, pois se configurada de forma inadequada pode degradar os Indicadores de Performance com Bloqueios (Congestionamento) e Quedas.

Como você já deve ter percebido, estamos falando de diversos termos mais técnicos, porém são os termos que que você vai encontrar quando estiver por exemplo lendo fluxogramas de chamadas UMTS ou LTE, ou seja, é necessário. Mas se você conseguir entender pelo menos em parte os conceitos apresentados hoje, tudo fica mais fácil.

Vamos então vamos ver novamente a nossa figura, e continuar a nossa analogia.

 

Como sabemos, trabalhamos sempre com o conceito de camadas. E essa forma de enxergar a rede nos traz muitas vantagens, principalmente porque conseguimos ‘encapsular’ o acesso físico de rádio. Dessa forma, qualquer modificação ou substituição poderá ser feita de maneira menos complexa.

E não precisa dizer o quanto o caminho rádio é complexo, continuamente mudando, não é mesmo? Essa arquitetura de carregadores garante essa simplificação: o RNC e CN se preocupam com os requisitos de QoS no caminho entre eles (Interface Iu); e só o RNC precisa se preocupar em atender a QoS no complexo caminho rádio.

Certo, mas porque temos dois tipos de carregadores - vagões e carrinhos de controle remoto? A resposta para isso está na própria característica dos dois caminhos existentes. Sendo a Iu uma interface mais robusta, e também porque temos maiores alterações nos RABs durante as conexões, é normal que os carregadores desses caminhos também sejam diferentes. É como usar uma caminhonete 4x4 para subir uma montanha, e um carro de corrida para um pista de asfalto.

 

Independente dos transportadores, com o RAB os elementos do CN tem a impressão de um caminho físico para o UE, assim não precisa ficar se preocupando com os aspectos complexos da comunicação rádio.

Por exemplo, um UE pode ter 3 RABs entre ele e a RNC, e estes RABs podem estar sempre mudando, como no caso de soft handovers, enquanto a RNC tem apenas 1 Iu bearer para essa conexão.

Do ponto de vista dos transportadores, a principal tarefa da UTRAN é gerenciar esses serviços nessas interfaces. Ela controla a interface Uu, e junto com o CN, controla a provisão dos serviços na interface Iu.

Vale lembrar que numa comunicação entre o UE e o CN diversos outros elementos participam, principalmente para negociar os requisitos de QoS entre ambas as partes. Esses requisitos são mapeados nos RABs, que são visível a ambos (UE e CN), onde a UTRAN é a responsável por criar e manter esses RABs de forma que tudo isso seja atendido em todos os aspectos.

Detalhando um pouco mais...

Uma conexão RRC existe quando um UE realiza o procedimento de estabelecimento da chamada, e obtem recursos da UTRAN. Quando uma conexão RRC é estabelecida, o UE também vai ter alguns SRBs. (Se por algum motivo a solicitação inicial não for aceita, o UE pode fazer uma nova solicitação depois de algum tempo configurado).

Uma vez que o SRB foi estabelecido ente o UE e o CN, o RNC verifica uma série de informações como a identidade do UE, qual o motivo da solicitação e se o UE tem capacidade do serviço solicitado.

É o RNC quem mapeia os RABs solicitados nos RBs, para tranferência entre o UE e a UTRAN. Além disso ele faz também as averiguações dos atributos dos RABs: se os mesmos podem ser atendidos pelos recursos disponíveis, e ainda se é preciso ativar ou reconfigurar canais de rádio (reconfiguração de serviços de camadas inferiores) baseado no número de conexões de sinalização e RABs a serem transferidos.

Dessa forma, ele cria a impressão de que existe um caminho físíco entre o UE e o CN. Lembrando novamente que não importa quantas conexões de sinalização e RABs existam entre o UE e o CN – só existe uma única conexão RRC usada pelo RNC para controle e transferência entre o UE e a UTRAN.

Agora que já vimos bastante sobre RRC e RAB, vamos conhecer apenas mais alguns conceitos hoje – afinal, já temos bastante informações apresentadas. Vamos falar de AS e NAS.

  • AS – Access Stratum é um grupo de protocolos específicos da rede de acesso
  • NAS – NON Access Stratum: de forma complementar, são os demais protocolos, ou aqueles que não são da rede de acesso

Nesse ponto de vista, o AS fornece o RAB para o NAS, ou o serviço de transferência de informação.

O UE e o CN precisam se comunicar (eventos/mensagens) um com o outro para realizar diversos procedimentos com inúmeros propósitos. E o ‘idioma’ dessa conversa entre eles é chamada de Protocolos.

Os Protocolos então são os responsáveis por permitir essa conversa entre o UE e o CN, e fazem com que o CN não se preocupe com o método de acesso (seja ele GSM/GPRS, UTRAN, LTE). No nosso caso a RNC atua como uma conversora de protocolos entre a UTRAN e o CN.

De acordo com o que aprendemos hoje, então o RAB é carregado:

  • Entre UE e a UTRAN: dentro da conexão RRC. O Protocolo RRC é responsável pela negociação dos canais (lógicos) das interfaces Uu e Iub, e pelo estabelecimento dos canais dedicados de sinalização como os SRBs e RBs entre nessas interfaces.
  • Entre o RNC e o CN: após ser negociado e mapeado, dentro da conexão do protocolo RANAP, pela interface Iu (CS/PS).
    • RANAP: Radio Access Network Application Part

Como já vimos acima, o RNC mapeia os RABs solicitados nos RBs utilizando a informação atual dos recursos de rádio da rede, e controla os serviços de camadas inferiores. Para otimizar o uso desses recursos de rádio, bem como o compartilhamento de banda e recurso físicos da rede entre diferentes entidades, a UTRAN pode também realizar a função de distribuição do CN para as mensagens NAS.

Para isso, o protocolo RRC transfere de forma transparente as mensagens do CN para a rede de acesso através de um procedimento de transferência direta. Quando isso ocorre, um indicador específico do CN é inserido nessas mensagens, e as entidades com a função de distribuição na RNC utilizam esse mesmo indicador para direcionar as mensagens para o CN apropriado, e vice-versa.

Mas agora o assunto começou a ficar muito mais complexo, e acreditamos já ter atingido nosso objetivo hoje, que era aprender os princípios básicos de RRC e RAB.

Tudo o que falamos acima pode ser visto novamente na mesma figura abaixo, a mesma do início das das explicações.

 

RRC e RAB no GSM?

Tudo bem, entendemos como funciona o RRC e RAB em redes UMTS – WCDMA e LTE. Mas e no GSM, temos esses conceitos também?

A princípio, a resposta é não. Porém, com o que aprendemos hoje, podemos fazer uma comparação com alguns parâmetros ‘equivalentes’ do GSM.

Podemos comparar a fase SDCCH e a fase TCH de uma chamada no GSM com RRC e RAB no UMTS.

RRC é o Controle dos Recursos de Rádio que trabalha como Plano de Controle na camada 3. É usado basicamente para sinalização no UMTS. Então podemos comparar com a parte sinalização no GSM, como o processo de designação imediata para alocação dos recursos de SDCCH.

RAB é o ‘Carregador’ de Acesso Rádio que trabalha como o Plano de Usuário para prover Dados para os serviços solicitados pelo usuário. Então podemos comparar com a parte do usuário no GSM, como a designação de TCH dos usuários.

Para cada serviço solicitado pelo usuário temos apenas 1 RAB. Por exemplo, se o serviço solicitado for uma chamada de Voz (CS-AMR), então 1 CS RAB vai ser gerado e fornecido para o usuário. O mesmo ocorre para Chamadas PS.

Assim a nossa tabela de equivalência seria:

 

UMTS / LTE

GSM

Control

RRC Connection

Immediate Assignment

User

RAB Assignment (RNC-CN)

Assignment (BSC-MSC)

 

 

Exemplo de Conexão RRC e RAB

Para concluir por hoje, vamos ver (sempre de forma simplificada) como acontece uma conexão usando RRC e RAB.

Sempre que o UE precisa de recursos da UTRAN, ele solicita à mesma. Para que esses recursos sejam alocados, a mesma estabelece uma conexão RRC, com alguns SRBs.

Nesse caso, uma conexão RAB é criada para permitir a transferência de dados no plano de usuário. Lembramos que o RAB é formado por RB + Iu bearer. O RAB é criado pelo CN, com uma requisição de QoS específica.

Para um único UE, podem existir múltiplos RAB por serviço NAS (CS ou PS).

Mas vamos nos ater apenas ao procedimento inicial, ou seja, como é realizado o procedimento ‘RRC Setup’, a partir da solicitação do UE.

A figura a seguir mostra isso de forma mais direta.

 

A conexão RRC envolve então sempre 3 passos:

  1. O UE solicita uma nova conexão no Uplink (‘RRC CONNECTION REQUEST’);
  2. Havendo recursos suficientes, é enviada no Downlink a mensagem ‘RRC CONNECTION SETUP’, incluindo o motivo, com a configuração do SRB; (Nota: caso contrário, se a conexão RRC não puder ser estabelecida, a mensagem enviada é ‘RRC CONNECTION SETUP REJECT’).
  3. Se tudo correr bem, o UE envia a mensagem no Uplink: ‘RRC RRC CONNECTION SETUP COMPLETE’.

E depois as informações de ‘MEASUREMENT CONTROL’ ficam sendo enviadas no Downlink, para a continuidade da comunicação.

Após a conexão RRC ser estabelecida, a UTRAN faz a ligação entre o CN e o UE, realizando por exemplo as operações de Autenticação e Segurança.

E então, o CN informa o RAB para a UTRAN de acordo com requisitos do serviço solicitado pelo UE. Como vimos, o estabelecimento RAB ocorre depois do RRC, e sem uma conexão RRC nenhum RAB pode ser estabelecido.

 

Conclusão

Vimos hoje uma explicação simplificada abrangendo de inúmeros conceitos envolvidos na comunicação das mais modernas redes móveis existentes, principalmente relacionados a RRC e RAB.

Com essa base conceitual, vamos prosseguir evoluindo nos próximos tutoriais com exemplos que tornam a assimilação desses complexos conceitos em uma tarefa bem menos exaustiva que o normal.

Esperamos que você tenha gostado, e contamos com a sua participação, que pode ser por exemplo sugerindo novos tópicos, ou também compartilhando o nosso site com os seus amigos. Se possível, deixe também logo abaixo os seus comentários.

Até o próximo tutorial.