O que é CSFB e SRVCC no LTE?

Postado por leopedrini quinta-feira, 21 de maio de 2015 04:00:00 Categories: CSFB Curso LTE SRVCC VoLTE
Rate this Content 6 Votes

Independente do ritmo de implantação das redes LTE ao redor do mundo (maior em algumas regiões, menor em outras), o número de usuários com dispositivos 4G vem crescendo de forma intensa.

Graças a fatores como a diminuição dos custos - devido ao ganho de produção em escala, e também pelo incentivo à migração para planos 4G - oferecidos pelas operadoras que já possuem uma rede disponível, cada vez mais e mais pessoas tem acesso aos novos serviços e benefícios que essa tecnologia oferece.

Entretanto, por mais que os serviços de dados atuais sejam aprimorados, e que os avanços na área levem à adoção de novos serviços, uma necessidade básica ainda deve continuar existindo pelo menos por um bom tempo: as chamadas de voz!

 

Embora a realização de uma chamada de voz possa parecer simples, depende muito do cenário em que se encontra o usuário, e as alternativas disponíveis para sua realização. Por isso é necessário entendermos bem quais são as possibilidades e conceitos mais importantes desses principais cenários.

Nas primeiras gerações de redes celulares a comunicação através de chamadas de voz era o objetivo principal, e baseava-se em uma topologia de circuitos comutados ou canais (CS Circuited Switched).

Com o tempo, a necessidade de outros serviços (dados!) foi surgindo. As chamadas de voz passaram a existir junto desses novos serviços. Como a demanda aumentou muito, esses novos serviços foram suportados por um novo domínio, o de pacotes comutados baseados em IP (PS Packet Switched).  Figura a seguir mostra como esses dois domínios funcionam.

 

E no sistema LTE (4G), tivemos mais uma grande mudança: o domínio CS foi extinto! As redes LTE se baseiam exclusivamente no domínio PS, e os serviços de voz devem ser realizados de outras maneiras (como veremos mais adiante).

Mas como já mencionamos, independente das topologias de rede, os serviços de voz continuam sendo necessários. (É claro que diminuíram um pouco, comparado há alguns anos, porém continuam expressivos, ou seja, sua demanda continua).

Com as redes LTE cada vez maiores, vamos então tentar entender um pouco mais os conceitos, alternativas e soluções para um usuário qualquer que realize uma chamada de voz em uma rede LTE?

 

 

 

Como, quando e onde?

Antes de mais nada, precisamos entender onde, quando e como podem ocorrer as chamadas de voz.

Nas redes legadas 2G, temos chamadas de voz praticamente apenas em circuitos - para cada chamada (domínio CS).

Nas redes legadas 3G, os serviços de voz podem utilizar o domínio CS, mas também podem ser realizadas através de soluções OTT (Over The Top), aplicações que encapsulam a voz e transportam via um domínio IP (PS), mas que não possuem os requisitos de QoS necessários para garantir uma boa comunicação - com serviços do tipo Non GBR (sem garantia de bit rate). Exemplo: Skype. Nota: é muito incomum, mas também é possível fazer chamadas de voz OTT nas redes 2G. Na verdade, soluções OTT podem ser existir em qualquer tecnologia - pode ser usado nas redes legadas, mas também em outras como WiFi - que já são comumente usadas para VoIP.

Já nas redes LTE, as chamadas de voz podem ser totalmente baseadas em IP, utilizar soluções OTT via 4G, ou ainda serem transferidas para as redes legadas 2G/3G.

 

Como começamos a ver, são muitas alternativas. Como de costume, vamos ver com calma cada uma delas.

Nota: nesse tutorial, vamos nos referir sempre a chamadas de voz (originadas e/ou terminadas); porém, serviços como SMS também estão incluídos.

 

Alternativas para chamadas de voz em uma topologia de rede genérica 2G-3G-4G

E a melhor forma de entender as alternativas ou possibilidades de realização de chamadas de voz na rede LTE (4G), é começar a partir de uma topologia de rede 2G-3G-4G bem simplificada - considerando apenas os principais elementos envolvidos.

Como podemos ver na figura a seguir, o LTE (EPC) não tem nenhuma ‘ligação’ direta com a rede CS – como já vimos, foi projetado para cuidar de chamadas puramente IP (PS). Não tem nenhuma Media Gateway diretamente conectada, portanto, nenhuma chamada CS é suportada pelo MME.

 

Em outras palavras, se o usuário ou UE (User Equipment) estiver numa rede LTE, como a mostrada na topologia acima, não podemos realizar uma chamada de voz.

Observação: Como já mencionamos antes, e de acordo com a topologia acima, a única forma de realizar serviços de voz no LTE seria através de serviços OTT, como o Skype. Entretanto, esse tipo de solução não será abordada hoje.

Se entendemos isso, também é fácil percebermos que para haver serviços de voz no LTE, alterações precisam ser feitas. Existem algumas alternativas, e abaixo temos as principais delas:

  • VoLGA (Voice over LTE via Generic Access): utilizar as redes legadas 2G/3G como uma acesso genérico, ‘empacotando’ os serviços de voz, e entregando via LTE.
  • CSFB (CS Fall Back): sempre que o UE tiver a necessidade de realização de uma chamada, fazer com que ele reverta (‘fallback’) para a redes legadas.
  • VoLTE (Voice over LTE): realizar a voz sobre o LTE propriamente dito. Nesse caso, a voz puramente IP - VoIP LTE.
    • SRVCC (Single Radio Voice Call Continuity): garantir que as chamadas puramente LTE (VoLTE) sejam transferidas (via handover) para as redes legadas de uma forma transparente.

Nota: perceba que o SRVCC é uma opção quando a chamada de voz já foi estabelecida no LTE. Ou seja, é uma alternativa condicional - considerando que a opção de VoLTE tenha sido utilizada.

Mesmo sem conhecer ainda muito bem as opções apresentadas, é fácil imaginar que a ‘melhor’ solução seria realizar a voz sobre a própria rede LTE. Mas como tudo na vida, temos sempre o outro lado, os prós e os contras.

Para entregar serviços de voz na rede LTE é necessário que exista uma infraestrutura que a suporte. Em outras palavras, é necessário que exista um IMS (IP Multimedia Subsystem ou IP Multimedia Core Network Subsystem). Se o IMS estiver disponível, então a voz sobre LTE poderá ser fornecida desde que um conjunto mínimo de funcionalidades e entidades do IMS também estejam presente.

Nota: o IMS é muito mais completo, tem muito mais outras finalidades do que a voz. A voz é apenas mais uma aplicação do IMS.

Esse conjunto mínimo de funcionalidades e entidades do IMS (padronizado como VoLTE ou One Voice) foi padronizado para permitir que as operadoras LTE forneçam serviços de voz sem ter que fazer mudanças muito radicais na rede (sem ter que investir em um IMS completo, com todas as entidades e funcionalidades).

De qualquer forma, demanda investimento.

E por esse motivo tornam-se atrativas as duas primeiras alternativas, baseadas na infraestrutura CS da rede legada. Mas se por um lado tais alternativas requerem menor investimento na rede LTE, essas alternativas dependem das redes 3G/2G existentes.

Vamos falar um pouco mais sobre cada uma dessas possibilidades, mas sempre tentando manter uma visão geral, da forma mais simples possível de ser entendida. Lembre-se que o nosso objetivo é o aprendizado do conceito, a fim de permitir um aprofundamento no assunto, se desejado, com mais facilidade.

 

VoLGA

A primeira alternativa de implementação que surgiu foi o VoLGA (Voice over LTE via Generic Access), ou seja, tentar usar o que já havia disponível, com o mínimo de alterações necessárias.

Para usar a infraestrutura das redes legadas 2G/3G, o VoLGA introduz uma nova entidade de rede, o VNC (VoLGA Network Controller), que funciona basicamente como uma BSC 2G, comunicando-se com uma MSC (Mobile Switching Center) GSM e como uma RNC 3G comunicando-se com uma MSC (Mobile Switching Center) UMTS.

 

Quando temos uma nova chamada (seja ela originada ou terminada), a mesma é manejada pela MSC da rede legada. A VNC é quem faz a mediação do sinal de voz e suas mensagens relacionadas entre a MSC e a rede LTE.

Embora seja possível realizar a entrega de serviços de voz e SMS para usuários LTE, o VoLGA não teve sucesso. Isso porque, como vimos, necessita investimento exclusivos para esse fim. Em paralelo porém, os esforços globais em relação ao VoLTE aumentaram (como por exemplo investimentos no IMS), e assim essa alternativa acabou caindo em desuso.

 

CSFB

Mas se por um lado as operadoras seguem buscando uma infraestrutura LTE completa (com IMS completo) para atender serviços de multimídia e também de voz puramente LTE, essa não é uma topologia que está disponível a curto e até mesmo médio prazo.

Enquanto essa realidade não chega, é necessário utilizar a rede legada quando houver necessidade de entrega de serviços de voz e SMS aos usuários LTE.

E a alternativa mais comum para isso é o CSFB (CS Fall Back), uma solução provisória até o suporte completo de voz sobre LTE.

No esquema CSFB, sempre que há uma demanda de uma nova chamada de voz, o usuário LTE é ‘recuado’ para uma rede CS legada, assumindo que esta fornece uma cobertura sobreposta. Em outras palavras: com o CSFB, a chamada de voz nunca está ativa no LTE, e sim nas redes legadas.

No final da chamada na rede legada, o UE pode se registrar novamente na rede LTE.

É mais ou menos assim: o UE está registrado (também) na rede legada. Quando ele tem uma chamada, ele diz à rede LTE: 'Eu tenho uma chamada para o UE, você pode pedir para ele vir para cá, e fazer a chamada?'

Para que ocorra o CSFB, os usuários devem estar usando dispositivos dual mode, ou seja, capazes de operar tanto na rede LTE quanto na rede legada.

Para suportar o CSFB, uma nova interface é introduzida: o SGs, conectando o MME à MSC legada.

 

Como o CSFB é a opção mais amplamente utilizada atualmente em diversas operadoras, vamos ver alguns cenários básicos do CSFB.

 

CSFB - Registro e Localização

Quando o UE CSFB é ligado, ele se registra nas duas redes: LTE e rede legada (CS).

E para permitir a transferência rápida para a rede legada (seja ela 2G ou 3G) quando for preciso, a rede LTE precisa saber a localização do UE.

Para isso o MME, que rastreia a localização do UE na rede LTE, fornece continuamente a informação de localização para a MSC legada, usando a nova interface SGs.

O conjunto de mensagens SGs suporta então o gerenciamento da Mobilidade, Paging e SMS.

 

CSFB - Chamada Originada

Vamos continuar, e assumir que o UE esteja inicialmente atendido pela rede LTE, e que existe uma conexão IP ativa.

Quando o UE decide originar uma chamada de voz, ele envia uma SRM (Service Request Message) para o MME (mais especificamente a ESR - Extended Service Request).

O MME verifica se o UE é capaz de suportar o CSFB, e notifica o eNodeB para  transferir o UE para a rede legada.

Antes de fazer a transferência do UE, o eNodeB pode pedir ao UE para realizar medidas de RF nas vizinhas da rede 2G/3G. O eNodeB então decide a melhor rede para o UE, e realiza o transferência.

Uma vez que o UE acampe na rede 2G/3G, ele inicia o procedimento de chamada como de costume - o UE inicia os procedimentos de controle de chamada na rede legada.

 

CSFB – Chamada + Conexão de dados LTE

E o que acontece se estou com uma conexão de dados IP ativa na rede LTE, e decido fazer uma chamada de voz?

Existem duas opções:

  • Os dados também são transferidos para a rede legada, ou
  • Os dados são temporariamente suspendidos, até que eu retorne para a rede LTE.

Embora a primeira opção pareça melhor, devemos levar em conta que se a transmissão de dados IP também for transferida, ela poderá operar em velocidades bem mais baixas (redes legadas). Além disso, pode ser que as redes legadas neguem a sessão IP, por falta de recursos ou por não ser capaz de processá-la.

A interface S3 é usada para realizar o handover da sessão PS para o 3G (nesse caso, o DTM - Dual Transfer Mode deve existir; porém esse detalhamento aqui hoje foge do nosso tema).

Não há suporte de handover de dados do 4G para o 2G - nesse caso, os dados são suspendidos.

Os eRABs 4G são liberados quando o UE faz o CSFB.

Uma informação importante é que a S3 é uma interface ‘nova’ entre MME e SGSN, sobre GTPCv2. E para suportá-la, o SGSN precisa ser atualizado (a maioria das operadoras não deseja fazer isso sem uma justificativa muito forte).

Já a interface Gn é sobre GTPCv1, que é a versão GTP nativa para redes 3G. Então nesse caso apenas o MME precisa ser atualizado, e como é um nó relativamente novo, é provavelmente mais fácil de ser feito. Isso sem falar que os novos SGSN podem ter suporte nativo para S3.

 

CSFB - Chamada Terminada

Por fim, temos o caso de uma chamada terminada para um usuário LTE.

A solicitação de chamada chega primeiro para a MSC onde o UE estava previamente registrado.

Quando a MSC recebe solicitação de chamada, ela envia mensagens de paging para o MME relacionado, via interface SGs.

Essa mensagem é encaminhada para o UE, que ainda está conectado à rede LTE.

Se o usuário aceita a chamada, ele envia uma SRM (Service Request Message) para o MME.

O MME então notifica o eNodeB para transferir o UE para a rede legada, e o eNodeB então decide a melhor rede para o UE realizar a chamada.

 

CSFB – O que ocorre após o fim da chamada CS?

Já vimos que os eRABs 4G são liberados quando o UE faz o CSFB. Mas o que acontece quando o UE termina a chamada CS?

Em relação ao que deve ocorrer em seguida (se o UE deve voltar ou não para o LTE tão logo termine a chamada CS), não há regra específica.

De qualquer forma, as principais possibilidades seriam:

  • As camadas superiores forçarem a ‘reseleção’ para o LTE assim que o UE entrar em modo Idle na rede legada.
  • A operadora enviar informação de ‘redirecionamento’ do LTE na mensagem de release da conexão RRC na rede legada 3G após a chamada ser terminada. Isso vai resultar novamente em reseleção para o LTE.
  • As camadas mais baixas (AS - Access Stratum, neste caso URRC ou GRR) reselecionarem para o LTE se o critério de reseleção for satisfeito. Na maioria dos casos, as operadoras tem seus parâmetros configurados de tal forma que a reseleção para o LTE aconteça se houver uma área com boa cobertura LTE sobreposta a rede legada.

 

VoLTE

Tudo o que vimos até agora baseia-se na realização da chamada de voz na rede legada. Mas como vimos são soluções ‘provisórias’, até que a solução ‘definitiva’ de voz em LTE esteja disponível.

E a solução de voz definitiva em LTE (Voz IP, ou mais especificamente VoLTE) utiliza o backbone IMS. Um exemplo de topologia de rede com suporte a VoLTE é mostrado na figura a seguir.

 

Para a realização de chamdas de voz, as redes LTE precisam ter o IMS. Quando as primeiras redes LTE surgiram, elas não possuiam o IMS, e sem o IMS, não era possível fazer nenhuma chamada com qualquer rede CS ou PSTN.

Já falamos do IMS anteriormente, mas vamos recordar.

 

IMS

IMS é um backbone (rede) no nível de aplicação, que trabalha no topo de outras redes wireless e não apenas o LTE (como 3G, 2G, WiFi entre outras).

O seu conceito é bastante amplo, e entendê-lo com todas as suas entidades, possibilidades, interfaces, protocolos, e possibilidades é uma tarefa extremamente difícil, até mesmo para os mais experientes no assunto.

O IMS não é recente: já existia bem antes do LTE (assim como outras entidades, como o PRCF do EPC, que também não é novidade!).

Sua especificação completa consiste de milhares e milhares de standards do 3GPP. Mas vamos tentar entender de uma maneira mais simples do que a encontrada lá.

Como o próprio nome sugere (IP Multimedia Services), o IMS oferece diversos serviços de multimedia IP, incluindo VoIP (Voz over IP). No IMS a voz é apenas ‘mais’ um serviço!

O IMS reúne features de voz como autenticação, autorização de serviço, controle de chamada, roteamento, interoperabilidade com PSTN, cobrança, serviços suplementares e VAS. Nenhum desses existe no EPC: esta é a razão pela qual o EPC puro sem o IMS não pode processar uma chamada de voz.

Em outras palavras: para VoLTE, o acesso é feito pelo SAE (EUTRAN + EPC), enquanto o serviço de voz reside no IMS.

Uma analogia que podemos fazer é o IMS sendo um automóvel. E a voz LTE, como sendo o nosso serviço de transporte (ir de um local ao outro).

  • Podemos comprar um carro extremamente básico - motor básico 1.0, rodas, volante e outras peças mínimas: conseguimos ir de um local a outro.

  • Ou podemos comprar um carro ‘conectado’ - ultra moderno, potente, tetra-fuel, com todos os itens de segurança, ABS, Air bag, conectado à Internet, etc: também vamos de um local a outro... mas podemos fazer várias outras coisas também.

É mais ou menos isso com o IMS. Ele é usado em conjunto com a rede LTE para suportar voz: tanto a implementação completa IMS, como a mínima sugerida pelo padrão Voice over LTE.

A indústria de telecomunicações porém preferia não investir num IMS completo, ou pelo menos não tinha motivos suficientes. E para a adoção da solução de voz IMS mais simples, surgiu a iniciativa VoLTE, que especifica um conjunto mínimo de features, e seleciona uma simples opção quando múltiplas opções existentes para determinadas funcionalidades.

Porém, nem todas essas funcionalidades são necessárias para entrega de serviços de voz básicos pela rede LTE.

Então vamos exemplificar com um diagrama (extremamente simples) de uma implementação de voz no IMS (VoLTE).

  • Vamos considerar que faremos uma chamada VoLTE com uma rede CS qualquer, por exemplo a PSTN (Public Switch Telephony Network).
  • E considerar no IMS apenas 2 elementos simples, uma para o plano de controle (com a sinalização) e outra para o plano de usuário (com a voz).
  • E a entrada sendo o SAE, ou a rede LTE.
  • No IMS, o elemento de controle seria um servidor SIP (logo mais vamos falar sobre SIP – por enquanto entenda apenas que quando temos uma requisição de chamada para esse servidor, ele configura a chamada.); e o elemento de usuário seria uma Media Gateway.

 

Fazendo uma comparação com as redes legadas, o Servidor SIP seria equivalente à MSC numa topologia de rede móvel, e a Media Gateway seria equivalente a uma Media Gateway típica em qualquer topologia de rede, que é comum em virtualmente qualquer rede de voz para realizarmos chamadas.

O conceito acima é válido, mas na prática o IMS consiste de muito mais entidades, como podemos ver a seguir. Nota: nem todas as entidades e interfaces estão mostradas na figura.

 

Vamos ver (rapidamente) um pouco sobre esses principais elementos.

Observação: Não se preocupe em entender tudo agora sobre esses elementos. Lembre-se que o nosso objetivo hoje aqui não é esse. De qualquer forma, vale a pena uma leitura.

O MGCF (Media Gateway Controller Function) é o elemento de controle que se comunica com outras redes PSTN. É significante porque tem função de inter- networking: é capaz de falar SIP, é capaz de falar ISUP, é capaz de falar outros Protocolos de Sinalização.

A IM-MGW (IM Media Gateway) é o elemento que cuida da voz, fazendo funções por exemplo de tradução de protocolos, requeridas para suportar a chamada. Mais especificamente entre o Real Time Transport Protocol (RTP) para formato analógico ou PCM básico, na rede CS e vice-versa.

O HSS (Home Subscriber Server) é um elemento que existe também no EPC LTE (embora exista no IMS há mais tempo), e as suas funções são similares.

O MRF (Media Resource Function) prove muitos serviços relacionados a voz, como conferências, anúncios, reconhecimento de voz entre outros. É sempre dividido em duas partes, o MRFP (Media Resource Function Processor), para os streams de mídia, e o MRFC (Media Resource Function Controller) que funciona basicamente como um ‘mixer’ RTP.

Um conceito importante, e que vale a pena destacarmos aqui é o de ‘Proxy’, por exemplo para fazer filtros, identificar de onde vem os usuários, casos de roaming, etc. Lembre-se que estamos falando de uma rede IP. Em vez dos usuários falarem direto com os servidor SIP, eles utilizam o proxy.

O CSCF (Call Session Control Function) tem algumas variações.

  • O P-CSCF (Proxy CSCF) entre outras tarefas, fornece informação de QoS relacionada à rede LTE. Acessa uma AF para o serviço de voz, e fornece ao PRCF funções de controle de 'policy' e 'charging'.
  • O I-CSCF (Proxy CSCF) é um interrogador.
  • E o S-CSCF (Serving CSCF), funciona como o servidor CSCF, um nó central.

O BGCF (Border Gateway Control Function) funciona como uma tabela de roteamento (ou tabela B) e atua ajudando o S-CSCF. Tem basicamente as decisões de roteamento.

Como falamos, no IMS a voz é um serviço - o IMS é um facilitador de serviços. Os serviços do IMS são fornecidos através de AS (Application Servers).

Uma dessas aplicações é a Voz. Serviços de vídeo, conferência, etc.

Inclusive, às vezes os AS não são considerados como parte de IMS (quando entendemos o IMS como um CORE).

E no IMS, o padrão AS para voz é o MMTEL (Multimedia Telephony Service), às vezes chamado de MTAS (Multimedia Telephony Application Server).

O SBC (Session Border Controller) é um elemento das bordas do IMS, para controle da sinalização e muitas vezes do streams de medias envolvidas nas chamadas.

O S-CSCF vai ser responsável pelo roteamento da chamada dependendo de onde o outro usuário (a outra parte) esteja:

  • Um SBG (Session Border Gateway) se o a outra parte estiver em domínio IP;
  • Uma MGC/MGW se a outra parte estiver no domínio CS (PSTN/PLMN).

IBCF e TrGW não estão mostrados na nossa figura, mas são respectivamente o plano de controle e de usuário para outras redes IMS, outras redes SIP em geral. São similares ao MGCF/IM-MGW - os requisitos para atingir um ou outro tipo de rede são diferentes, por isso, temos também partes separadas para realizar as mesmas funções, mas com redes diferentes.

 

SIP

Para suportar sinalização telefônica entre a rede LTE e as redes telefônicas, o IMS usa SIP (Session Initiation Protocol). O SIP é um protocolo padrão para o estabelecimento de chamadas de voz sobre redes IP.

O código é aberto, e utiliza o modelo ‘requisição-resposta’ para permitir sessões de comunicação.

Existe um conjunto de comandos padrão que podem ser usados para iniciar, gerenciar e terminar chamadas entre dois dispositivos SIP.

O SIP foi adotado pela padronização IMS como o protocolo para permitir a sinalização entre redes telefônicas e redes VoIP.

O SIP é baseado em texto, e foi desenvolvido - na década de 90 - com o objetivo de ser simples e eficiente, assim como o protocolo HTTP (na verdade, foi inspirado no HTTP e outros protocolos como SMTP).

Uma boa analogia é compararmos o SIP com o HTTP.

Você consegue entender bem o princípio de interação do HTTP, que permite conexão de áudio, texto, vídeo e outros elementos numa página WEB. Com o SIP é praticamente a mesma coisa: ele permite o estabelecimento, gerenciamento e términos de chamadas (ou sessões) de multiusuários IP sem necessidade de conhecer o conteúdo da chamada. Uma sessão pode ser uma simples chamada telefonica entre dois usuários, ou uma conferência multimedia multiusuário.

Ambos (SIP e HTTP) levam o controle da aplicação para o usuário final, independente do protocolo de transporte (o SIP é um protocolo de controle, na camada de aplicação), não havendo portanto necessidade de centrais de comutação.

O SIP entretanto não é um protocolo de reserva de recursos, e também não tem nada a ver com QoS.

Uma pequena pausa: nosso tutorial de hoje já está bem extenso, mas vamos continuar um pouco mais com esse assunto, pois esses conceitos são muito importantes, e você ainda vai ouvir falar muito deles.

Para tentar entender melhor, vamos ver um exemplo simplificado para o processo de estabelecimento de uma chamada voz usando a plataforma IMS e sinalização SIP.

 

  • Inicialmente, o UE envia uma mensagem SIP do tipo 'Invite', contendo a descrição de uma ou mais medidas para a sessão de voz (Initial SDP - Session Description Protocol - Offer).
  • Em seguida, o P-CSCF encaminha essa mesma mensagem para o S-CSCF (que já foi previamente identificado durante o processo de registro).
  • Tudo transcorrendo bem, a rede de terminação terá enviado uma mensagem do tipo ‘offer response’ para o S-CSCF, e este encaminha esta mensagem para o P-CSCF, autorizando a alocação de recursos necessários para esta sessão.
  • Finalmente, o P-CSCF encaminha a mensagem 'offer response' de volta para o UE, que confirma recebimento da mensagem 'offer response’  e a reserva de recursos é iniciada.

Esse é um exemplo bem simplificado de como pode ser a obtenção (originação) de um serviço de voz pelo UE, via IMS.

Diversos outros diagramas existem, com cenários bem mais complexos, porém a ideia básica pode ser entendida acima, e estendida caso seja necessária.

Vamos concluir o tutorial de hoje, vendo agora o caso onde uma chamada inicialmente estabelecida no IMS tenha que ser ‘transferida’.

 

SRVCC

Finalmente chegamos à nossa última alternativa enumerada no início deste tutorial: SRVCC (Single Radio Voice Call Continuity).

O SRVCC entretanto não é uma alternativa para entrega, e sim um processo de handover de chamada de voz de uma chamada previamente iniciada no LTE (seja ela One Voice VoLTE ou Full IMS LTE Voice).

É um método de transferência de chamada (handover), de maneira mais simplificada e confiável, quando um usuário LTE se encontra em uma sessão de voz ativa no IMS, e se movimenta para áreas sem cobertura LTE, mas com cobertura das redes legadas 2G/3G.

A principal vantagem é que a chamada não vai cair – apenas será transferida para o domínio CS das redes legadas.

Se no caso acima o UE sai da área de cobertura LTE com uma chamada em curso (mas vai para uma área de cobertura legada 3G/2G), devemos manter a continuidade dessa chamada de voz ativa. Nesse caso, o SRVCC é utilizado: o procedimento onde o contexto de uma chamada de voz ativa no IMS é transferida para o CS da rede legada (por exemplo, transferência de contexto do nó IMS para a MSC).

 

O desafio com o SRVCC é realizar o handover enquanto o UE está conectado a apenas um único rádio, em um determinado instante.

Existem duas versões de SRVCC.

  • SRVCC Handover para redes GSM ou para UMTS, definidas pelo 3GPP.
  • SRVCC Handover para redes 1xRTT definidas pelo 3GPP2.

Para permitir SRVCC, tanto o UE quanto as redes LTE e também as legadas, devem suportar SRVCC. Para isso, uma nova interface especial SV é introduzida entre o MME e a MSC, que roda sobre o protocolo GTPv2.

 

Para suportar SRVCC, a rede IMS deve também incluir um servidor de aplicações, chamado de SCC AS (Server Centralization and Continuity Application Server).

Este servidor de aplicações é quem gerencia a sinalização requerida para o processo.

Vamos ver um exemplo simplificado de alguns procedimentos do SRVCC LTE para o GSM.

  • Quando um UE que suporta VoLTE encontra-se em uma área de cobertura LTE, ele inicia sessões de voz através da rede IMS, que vai abrigar a sessão e fornecer aplicações e controle de sessão baseado em SIP.
  • Quando o UE se move de uma área de cobertura LTE para uma área de cobertura CS 3G/2G com a sessão IMS em curso, o IMS alterna a sessão para o domínio CS, mantendo ambas as partes da sessão cientes do handover.

 

Exemplo de Handover SRVCC

Ao perceber que o seu nível de sinal LTE começa a diminuir, o UE com uma sessão de voz IMS ativa, sinaliza para a eNodeB, dando início ao handover SRVCC.

O eNodeB então identifica a melhor rede disponível receber o serviço, e envia a solicitação de handover (especificando que é do tipo SRVCC) para o MME.

A nova solicitação de chamada de voz é então enviada para o IMS, usando um STN SR (Session Transfer Number for SRVCC) - um número único que é gerado por cada UE, e é armazenado no HSS.

Este número único é enviado pelo MME para o HSS quando o UE entra em contato pela primeira vez com a rede.

Ao receber o número STN SR, o SCC AS entende que a chamada correspondente deve ser transferida para uma rede diferente rede, e inicia o processo de redirecionamente para o ponto de transferência (handover) com a rede legada.

Depois que a preparação de recursos é completada, o MME confirma a solicitação de handover, fornecida anteriormente pelo eNodeB.

O eNodeB então transmite essa confirmação para o UE, e ainda fornece a informação requerida sobre a rede alvo.

Nas etapas finais, o UE é detectado nas redes legadas, e a chamada é reestabelecida no UE.

Assim, temos o completamento do SRVCC handover.

Pacotes de voz, e também pacotes que não são de voz podem ser transferidos utilizando esse método, porém as taxas de dados vão ser limitadas pelas capacidades das redes legadas.

Uma vez que o SRVCC é um procedimento de handover inter-RAT baseado em IMS da rede LTE para o CS da rede legada 3G/2G, é muito mais complexo que aquele handovers das redes legadas 3G/2G. A questão é como manter uma performance de handover comparável, ou melhor aceitável.

De forma a melhorar a performance do handover SRVCC, um WI (Work Item) chamado eSRVCC (SRVCC enhancement) foi estabelecido no 3GPP SA2 na Release 10. A solução é baseada em ancoragem no IMS, e introduz novas entidades ATCF (Access Transfer Control Function) e ATGW (Access Transfer Gateway).

Novamente, o aprofundamento deste assunto foge do nosso objetivo hoje.

Para concluir, vamos enumerar algumas das principais vantagens e desvantagens (ou prós e contras) de cada alternativa.

 

Vantagens e Desvantagens de cada alternativa

Tempo de configuração de chamada: Quando as operadoras utilizam CSFB, um dos maiores problemas enfrentados (e uma das grandes desvantagens do CSFB) é o aumento no tempo de configuração de chamada, devido aos procedimentos de resintonia nos rádios 3G/2G. 

Uma solução eficiente de CSFB requer o mapeamento TAC -> LAC de forma que o recuo para um LAC/MSC externa seja evitado, já que isso vai aumentar ainda mais o tempo de configuração de chamada.

Qualidade da chamada: a qualidade da chamada LTE é melhor, quando comparamos a mesma com aplicações de terceiros (OTT). Isto é devido ao QoS específico alocado para a chamada IMS, que pode não estar presente em aplicações de dados comuns.

Limitações de recursos para VoLTE: o AMR-NW do LTE necessita muito menos recursos e datarate que o GSM, e assim teremos muito mais usuários numa mesma largura de banda (eficiência espectral).

Investimento x Rede Atual: se tudo está 'funcionando bem', qual seria a justificativa para investimentos, uma vez que com certeza tais investimentos geram resistências das áreas comerciais e de negócios?

A comparação então deve ser feita é: Investimento versus Benefícios do IMS/MGW/BGCF.

Futuro: De qualquer forma todas essa discussão futuramente terá mais significância. Atualmente ainda dispomos de extensas redes legadas, com capacidade para suportar essas chamadas de voz.

Nesse caso, não é problema continuar utilizando essa infraestrutura disponível. A resistência somente começará a diminuir quando tal capacidade também diminuir. Mas em uma rede LTE, se o IMS é suportado podemos fazer uma chamada VoIP. Então porque precisamos fazer uma chamada de Voz CS?

CSFB x SRVCC:

  • Não é necessário implementar ambas as soluções (CSFB e SRVCC) ao mesmo tempo, se a rede tem uma cobertura total ampla e um backbone IMS.
    • Se implementamos o CSFB, significa que não vamos fazer a configuração de chamadas no Core IMS existente, e que poderia cuidar dessa chamada no LTE.
    • Em respeito ao SRVCC: assumindo que o Backbone IMS esteja disponível. Neste caso, se o registro no IMS é bem sucedido, o usuário não necessita fazer o CSFB - A chamada de voz pode ser iniciada na própria rede LTE, usando IMS.
  • CSFB é um procedimento de handover por serviço, enquanto SRVCC é um procedimento de handover por cobertura.

 

Casos Práticos e Analogias

Com tudo o que vimos hoje, vamos imaginar alguns cenários.

Primeiro, imagine que você está em uma rede LTE que não possui IMS. Então, a única maneira de ocorrer uma chamada de voz, seja ela originada ou terminada, é através do recuo para as redes legadas 2G/3G.

Você precisa ser redirecionado/liberado para a rede legada 2G/3G, partindo do LTE, para realizar uma chamada de voz. Como uma ‘reseleção’ de célula do LTE para o 2G/3G. Uma vez na rede legada, você realiza a chamada normalmente, como já está acostumado.

E assim, você acabou de ver o CSFB na prática!

Agora suponha que você esteja vendo um stream de vídeo na rede 4G, e receba uma chamada de voz. Nesse caso, você precisa ir para a rede 3G (em modo idle), e obter os recursos para a realização dessa chamada no 3G.

Assim que você termina a chamada de voz, você continua assistindo o stream de vídeo, só que agora na rede 3G (o handover 3G para 4G ainda não está definido).

Você acabou de ver o CSFB com uma chamada de dados ativa!

Agora vamos imaginar que você está em outra rede LTE, dessa vez com IMS. Nesse caso, você pode fazer uma chamada de voz por pacotes IP.

Acabamos de ver uma chamada VoLTE!

Continuando, imagine que você está em uma dessas chamadas de voz por pacotes no 4G. Suponha ainda que você alcança a borda de cobertura de sua célula 4G. Então, a única opção de manter a sua chamada é fazer o handover da mesma para o 3G (supondo ser esta a cobertura existente). Sua chamada vai continuar então na rede 3G, só que agora uma chamada de voz CS. SRVCC!

Se o SRVCC não é suportado, a chamada deve cair assim que o mesmo saia da área de cobertura LTE.

Caso o SRVCC seja suportado, um conjunto de mensagens são trocadas e a chamada de voz é transferida (handover) do IMS LTE para o domínio CS da rede 2G/3G.

E assim, acabamos de ver um exemplo de handover SRVCC!

Por hoje é isso. Esperamos que o tutorial tenha conseguido ser util para você que de alguma forma tem interesse por voz em redes LTE.

 

Conclusão

Vimos no tutorial de hoje, de uma maneira bem geral, as principais maneiras de realizar chamadas de voz (e SMS) em redes LTE.

As opções ou alternativas dependem de diversos fatores, como a topologia de rede disponível e a estratégia da operadora.

Dependendo da situação, a chamada pode ser originada no LTE através de aplicações de dados (VoIP OTT), ser originada puramente no IMS do LTE (VoLTE), ser redirecionadas para ser realizada em outras redes, através de mecanismos desenvolvidos para esse fim (CSFB) ou ainda transferida via handover - no caso de chamada em curso VoLTE – para uma rede legada (SRVCC).

Então, para um usuário que está numa área de cobertura LTE, uma série de considerações devem ser verificadas, como o tipo de dispositivo que o mesmo utiliza (suporta CSFB?), se a rede LTE possui um IMS que permita a realização de chamadas, se as células suportam SRVCC, etc.

A partir dos conceitos visto aqui hoje, esperamos que você tenha condições de entender bem o que ocorre quando um usuário realiza uma chamada de voz a partir de uma rede LTE.