O que é RRC e RAB?

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 todos 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 algumas
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

o NodeB
o RNC
 UE: User Equipment
 CN: Core Network
o MSC: para serviços de voz comutada
o 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).
o 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.

 
  
    
  
8
Post Anterior << >> Próximo Post

Mapa do site | Versão para impressão | © 2008 - 2020 telecomHall BR

Powered by mojoPortal | HTML 5 | CSS | Design by styleshout