Serviço de Voz sobre LTE

Transcrição

1 VII SRST SEMINÁRIO DE REDES E SISTEMAS DE TELECOMUNICAÇÕES INSTITUTO NACIONAL DE TELECOMUNICAÇÕES INATEL ISSN SETEMBRO DE 2017 Serviço de Voz sobre LTE Escórcio Luís Miguel 1, Daniel Andrade Nunes 2 Abstract This paper presents a study of techniques used nowadays to provide voice services over the LTE network. LTE is the fourth generation mobile broadband standard that emerges as the successor to 2G / 3G technology, has a core (All-IP) packet switching and does not support voice-switched circuit like technologies prior to it. In order for the 4G / LTE network to support voice services, operators needed to adapt it. The CSFB is one of alternative to support voice service in LTE networks when receiving or making a call, the connection move the mobile device back to the 2G / 3G network, the VoLGA is other alternative to voice service, that replace the WI-FI network for LTE to provide this service. These techniques are VoLTE alternative, considering that its needs a new infrastructures IMS in the network. Keywords CSFB, LTE, VoLTE, VoLGA Resumo Este artigo apresenta um estudo de técnicas utilizadas atualmente para prover serviços de voz sobre a rede LTE (Long Term Evolution). O LTE é a quarta geração do padrão de banda larga móvel que surge como o sucessor da tecnologia 2G/3G (Second Generation/Third Generation), possuindo um núcleo all-ip de comutação de pacotes que não oferece suporte a voz comutada a circuito como as tecnologias anteriores. Para que a rede LTE suporte serviços de voz, as operadoras dispõem de diversas soluções. O CSFB (Circuit Switched FallBack) é uma das alternativas para o suporte de serviço de voz na rede LTE, o VoLGA (Voice Over LTE Via Generic Access) é uma outra alternativa para o serviço de voz, que substitui o acesso WI-FI (Wireless Fidelity) pelo LTE para prover este serviço. Estas técnicas são alternativas ao VoLTE (Voice Over LTE) visto que o mesmo necessita de uma nova infraestrutura IMS (IP Multimedia Subsystem) na rede. Palavras chave CSFB, LTE, VoLTE, VoLGA I. INTRODUÇÃO As indústrias de comunicação sem fio celular testemunharam um grande crescimento nas últimas décadas com mais de 4 bilhões de usuários em todo mundo [1]. A primeira geração dos sistemas celulares analógicos suportou a comunicação de voz com roaming limitado. A segunda geração prometeu maior capacidade e melhor qualidade de voz do que os sistemas analógicos. Além disso, o roaming tornouse mais predominantes graças as normas e atribuições comuns de espectro entre países, especialmente na Europa. Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de Telecomunicações, como parte dos requisitos para a obtenção do Certificado de Pós-Graduação em Engenharia de Redes e Sistemas de Telecomunicações. Orientador: Prof. MsC. Daniel Andrade Nunes. Trabalho aprovado em 06/2017. Os dois sistemas celulares de segunda geração amplamente implantados foram o GSM (Global System For Mobile Communications) e o CDMA (Code Division Multiple Access). Os sistemas de primeira e segunda geração, foram basicamente projetados para suportar serviços de voz comutados a circuitos [1]. As redes de acesso celular evoluíram de uma tecnologia puramente comutada por circuitos para o 3G, que poderia suportar dados de alta velocidade, serviços de voz e multimídia na tecnologia de comutação de pacotes IP (Internet Protocol). As redes sem fio 3G foram definidas pelo 3GPP (Third Generation Partnership Project) de forma que a rede núcleo suporta comutação de circuitos baseado na rede GSM e comutação de pacotes baseado na rede GPRS (General Packet Radio Services) [2]. A arquitetura de rede LTE, também conhecida como 4G (Fourth Generation), foi projetada com o objetivo de suportar o tráfego comutado a pacotes com mobilidade contínua, QoS (Quality Of Service), altas taxas de transferências, permitindo taxas de transferências de até 100 Mbps de download e 50 Mbps de upload e latência mínima. O LTE é uma rede totalmente voltada para transmissão de pacotes, logo, não suporta a realização de chamadas de voz com CS (Circuit Switched) como por exemplo, a PSTN (Public Switch Telephony Network). Para estabelecer serviços de voz na rede LTE é preciso que exista uma infraestrutura que a suporte. Ou seja, é necessário que exista uma rede IMS [3]. A Figura 1 [4] ilustra as redes 2G/3G/4G e as interfaces que conectam os núcleos das redes, mostra também que o LTE não tem nenhuma interface ligada diretamente com a rede CS, neste caso, nenhuma chamada CS é suportada pelo MME (Mobility Management Entity). A tecnologia VoLTE, que será explorada este artigo, é uma das alternativas mais eficiente para o suporte de voz em redes LTE [2]. O objetivo deste artigo é apresentar uma visão geral das diferentes propostas para suporte de voz na rede LTE, descrevendo o funcionamento de cada uma delas para que possamos analisar a propostas mais eficiente para a transmissão de voz e SMS (Short Message Service) A Seção II apresenta soluções para o tráfego de voz na rede LTE, destacando-se as tecnologias que podem ser implantadas e uma solução de handover utilizada pelo VoLTE denominada SR-VCC (Single Radio Voice Call Continuity), enquanto que a Seção III apresenta as conclusões deste trabalho.

2 Fig.1. Topologia das redes móveis 2G/3G/4G. II. SOLUÇÕES TRÁFEGO DE VOZ SOBRE A REDE LTE A. Arquitetura CSFB Para que ocorra o CSFB, o dispositivo móvel deve ser dual mode, ou seja, deve ser capaz de operar tanto na rede LTE quanto na rede legada (GSM/CDMA). Esta arquitetura pode usar comutação de circuito, onde o terminal LTE é transferido através de handover para redes GSM, WCDMA (Wideband Code Division Multiple Access) ou CDMA [3] para prover os mesmos serviços existentes no domínio CS das redes legadas, por exemplo, chamadas de voz, chamada de vídeo e Serviços de localização [3]. A interface (SGs) entre o Servidor MSC (Mobile Switching Center) e o MME (Mobility Management Entity) permite que o dispositivo do usuário se registre tanto no domínio CS quanto no PS (Packet Switched) enquanto estiver na rede de acesso LTE. Esta interface também permite a entrega de SMS, sem que o dispositivo precise deixar a rede LTE [5]. A Figura 2 [5] ilustra a arquitetura CSFB com a interface SGs, que torna possível a comunicação entre o MME e a MSC/VLR. Fig. 2. Arquitetura CSFB. 1. Processos CSFB Registro e Localização Quando o UE (User Equipment) é ligado em uma rede que suporta CSFB, ele se registra na rede LTE e na rede legada (CS), para permitir a transferência (handover) do UE para a rede legada (2G ou 3G) quando for necessário. A rede LTE precisa saber a localização do UE, portanto, o MME rastreia a localização do UE na rede LTE, fornecendo continuamente as informações de localização para a MSC, usando a interface SGs [4]. Chamada Originada na rede LTE Assume-se neste caso 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. Este por sua vez, verifica se o UE é capaz de suportar o CSFB e notifica o enb (evolved Node-B) para transferir (executar o handover) do UE para uma célula da rede legada. Antes de fazer a transferência do UE, o enb instrui que o mesmo realize medidas de RF (Radio Frequency) nas células vizinhas 2G e/ou 3G [4]. O enb então decide a melhor célula para o UE, e realiza handover. Uma vez que o UE é transferido para a rede 2G/3G, o controle de chamada passa a ser realizada pela rede legada. Chamada Terminada na rede LTE Neste caso, uma chamada terminada chega à MSC/VLR onde o UE foi previamente registrado de acordo com o processo descrito anteriormente. A MSC/VLR então 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, uma mensagem SRM será enviada para o MME. O MME então notifica o enb para transferir o UE para uma célula da rede legada, como descrito anteriormente [4]. Chamada com conexão de dados LTE Quando há uma conexão de dados ativa, e o UE recebe ou efetua uma chamada, a conexão de dados é transferida para a rede legada ou é temporariamente suspensa até que o UE retorne para à rede LTE. Deve-se levar em consideração que

3 se a conexão de dados também for transferida, ela poderá operar com taxas de transmissão reduzidas, dependendo da rede legada empregada. 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 [4]. B. Arquitetura VoLGA O VoLGA é uma solução para o suporte de voz sobre a rede LTE que permite que os dispositivos móveis LTE acessem sistemas e serviços legados sem ter que deixar o domínio LTE. O VoLGA é baseado no padrão do 3GPP denominado GAN (Generic Access Network) [6]. GAN é um sistema de telecomunicações que é usado para voz, dados e multimídia por meio de redes IP. UMA (Unlicensed Mobile Access) é o nome comercial utilizado pelas operadoras de telefonia móvel para o acesso externo IP em suas redes principais, sendo que este sistema já foi chamado de Wi-Fi calling por vários fabricantes de aparelhos telefônicos, incluindo a apple e a Samsung [7]. O UMA foi desenvolvido por um grupo de operadoras e empresas fornecedoras, de forma que as suas especificações iniciais foram publicadas em 2 de setembro de As empresas contribuíram então com as especificações do 3GPP como parte do item de trabalho "Generic Access to A/Gb interfaces". Em 8 de abril de 2005, o 3GPP aprovou as especificações para Generic Access to A/Gb interfaces pelo release 6 e renomeou o sistema para GAN. No final de 2007, a especificação GAN foi aperfeiçoada para suportar interfaces 3G (Iu) através do GANC (Generic Access Network Controller) para a rede do núcleo móvel (MSC / GSN (GPRS Support Node)) [7]. O GAN requer dispositivos dual mode que têm interface de rádio GSM / UMTS e uma interface Wi-Fi. Tais dispositivos móveis estão disponíveis atualmente por vários fabricantes, como por exemplo, Samsung. Quando os dispositivos dual mode detectam a disponibilidade de uma rede Wi-Fi (em casa ou em hotspot público), eles registram-se com a rede central GSM / UMTS através do link Wi-Fi e a internet. Um gateway GAN conecta um assinante à infraestrutura de uma rede e chamadas de voz e outros serviços de comutação de circuitos, tais como SMS, são transportados entre o dispositivo móvel e o gateway através do link Wi-Fi e a rede de acesso à internet [6]. A Figura 3 [7] mostra o GANC presente na rede de acesso atuando como um ponto de acesso. Do ponto de vista do núcleo da rede, o GANC é visto como uma BSC (Base Station Controller) / RNC (Radio Network Controller) Fig. 3. Arquitetura GAN.

4 O VoLGA emprega o mesmo princípio utilizado pelo GAN substituindo o acesso Wi-Fi pelo LTE. Do ponto de vista do dispositivo móvel, não há muita diferença entre os dois métodos de acesso, uma vez que ambas as redes são baseadas em IP [6]. A Figura 4 [6] ilustra a arquitetura VoLGA e o gateway VANC adicionado a rede LTE para prover serviços de voz para redes legadas via rede LTE. Fig. 4. Arquitetura VoLGA. 1. Processos VoLGA Registro na rede Quando um dispositivo móvel é ligado e detecta uma rede LTE, ele primeiro se registra no MME. O MME usa a interface S6a para conectar-se ao HLR/HSS (Home Location Register / Home Subscriber Server) e encontrar os dados do usuário necessários para a autenticação do mesmo. Depois de registar-se na rede LTE, o dispositivo móvel estabelece uma conexão com o VANC (VoLGA Access Network Controller). Este estabelecimento depende das informações de configuração específicas do VoLGA armazenadas no dispositivo móvel. O dispositivo móvel se registra no MSC através de um túnel seguro apartir do VANC. O protocolo DTAP (Direct Transfer Application Part) é usado para este propósito, sendo este já empregado no GSM e no UMTS. As mensagens são enviadas por um túnel estabelecido entre o dispositivo móvel e o MSC [6]. Chamadas de voz recebidas sobre LTE A descrição do procedimento neste item assume que o MS (Mobile Station) está no modo GAN A / Gb, isto é, registou com êxito com o VANC e o GA-CSR (Generic Access - Circuit Switched Resources) é a entidade RR (Radio Resources) de serviço para o MS [8]. 1. Uma chamada recebida pelo dispositivo móvel chega no MSC. O MSC envia uma mensagem de paging para o VANC, identificado através da última atualização de localização por ela recebida, incluindo TMSI (Temporary Mobile Subscriber Identity) do móvel se disponível. 2. O VANC identifica o contexto de registo do MS usando o IMSI (International Mobile Subscriber Identity) fornecidos pela MSC. Ele então busca (Paging) o MS usando a mensagem GA-CSRGA- CSR Paging Request. 3. O MS responde com um GA-CSR Paging Response incluindo o Classmark do MS e o número de sequência da chave de criptografia. O UE entra no modo dedicado e o estado do GA-CSR muda para GA-CSR dedicated. 4. O VANC estabelece uma conexão SCCP (Signalling Connection Control Part) com o MSC. O VANC então encaminha a paging response para o MSC usando a complete layer 3 information message. 5. A MSC pode, opcionalmente, autenticar o MS usando os procedimentos de autenticação do padrão GERAN (GSM EDGE Radio Access Network). 6. A MSC pode, também opcionalmente, atualizar a configuração de criptografia no MS, através do VANC. 7. A MSC inicia a configuração de chamadas utilizando a mensagem setup enviada ao MS via VANC. O VANC encaminha esta mensagem para a UE na mensagem GA-CSR DL direct transfer. 8. O MS responde com Call Confirmed usando o GA- CSR UL direct transfer depois de verificar a compatibilidade do serviço com o portador solicitado na configuração e modificação do serviço ao portador conforme necessário. Se o Setup incluiu o elemento de informação de sinal, o MS alerta o usuário usando o sinal indicado, senão o MS alerta o usuário após a configuração bem-sucedida do plano do usuário. O VANC encaminha a mensagem Call Confirmed à MSC. 9. O MSC inicia o assignment procedure com o VANC, que inicia a configuração do fluxo RTP (Real-time Transport Protocol) entre o VANC e o MS. 10. O MS indica que está alertando o usuário, através da mensagem alerting contida no GA-CSR UL DIRECT TRANSFERIR. O VANC encaminha a mensagem alerting para o MSC. O MSC envia uma mensagem alerting correspondente para a origem da chamada. 11. O MS indica que o destinatário respondeu, através da mensagem Connect contida no GA-CSR UL DIRECT TRANSFER. O VANC encaminha a mensagem de ligação para o MSC. O MSC envia a mensagem conenct correspondente para a origem da chamada 12. A MSC reconhece através da mensagem Connect Ack para o VANC. O VANC reencaminha esta mensagem para o MS como GA-CSR DL DIRECT TRANSFER. As duas partes da chamada estão conectadas ao canal de voz. 13. O tráfego bidirecional de voz flui entre o MS e o MSC através do VANC [8]. A Figura 5 [8] ilustra o processo descrito anteriormente.

5 Fig. 5. Fluxo de chamadas de voz recebidas. Chamadas de voz originadas sobre LTE. A Figura 6 [6] ilustra a troca de sinalização para estabelecer uma chamada de voz originada sobre a rede LTE empregando o VoLGA. Todas as mensagens de plano de sinalização e controle entre o UE e o VANC são transportadas por um túnel IPSec previamente estabelecido. Numa primeira etapa, o dispositivo móvel envia uma mensagem para o VANC anunciando que mudará a conexão de estado ocioso para estado dedicado (Connection Establishment). Posteriormente, uma mensagem (CM Service Request) é enviada para estabelecer uma conexão com o MSC (etapa 2 da Figura 5). Quando o VANC recebe a mensagem ele cria uma conexão com o MSC através da interface A (2G) ou Iu (3G) para este usuário e encaminha a mensagem (etapa 3). A MSC geralmente autentica o usuário e ativa a criptografia (etapas 4 e 5). Em seguida, o dispositivo móvel envia uma mensagem (setup) na etapa 6, que contém, entre outros parâmetros, o número de telefone do destinatário. A MSC reconhece a solicitação com uma mensagem Call Proceeding na etapa 7. Como o VANC é visto pelo MSC como BSC/RNC, a MSC então envia uma mensagem de solicitação de atribuição (Assignment Request) para o VANC (etapa 8) para estabelecimento de um canal portador comutado por circuitos. O VANC transforma esta mensagem em uma mensagem de ativação de canal (Activate Channel) para o dispositivo móvel na etapa 9 para prepará-lo para a troca de pacotes IP contendo dados de voz. Opcionalmente, a qualidade de serviço para os pacotes de voz pode ser assegurada pela ativação de um segundo portador na rede LTE (etapa 11). Uma vez que o dispositivo móvel é preparado para o fluxo de dados de voz, uma resposta de atribuição (Assignment Request) é enviada de volta para a MSC na etapa 13 para sinalizar o sucesso no estabelecimento de um canal de rádio. Assim, que a chamada tiver sido estabelecida com a outra parte, o MSC envia Mensagens (alerting and connect) na etapa 14 e 15 para o móvel. O caminho de voz é então estabelecido e a conversação pode começar. O sinal de voz é transmitido em um time slot TDM (Time Division Multiplexing) de 64 kbits na interface A no caso de uma MSC GSM ou através de um fluxo de dados baseado em ATM ou IP no caso de uma MSC UMTS [6]. O VANC traduz esse fluxo de dados em pacotes IP para transmissão através da rede LTE e vice-versa. O RTP é o protocolo usado para este propósito sendo que o mesmo também é usado por muitas outras soluções de voz sobre IP, tais como aqueles que utilizam SIP (Session Initiation Protocol) e IMS [6].

6 Fig. 6. Fluxo para uma chamada de voz móvel originada C. Arquitetura IMS O IMS é uma rede de aplicação, que opera em conjunto com redes 2G e 3G e LTE, tendo sido padronizado pelo release 5 do 3GPP [2]. O IMS foi introduzido pelas operadoras de telefonia móvel para oferecer acesso a serviços multimídia em redes de acesso móvel e outras redes wireless com garantia de QoS, cobrança e personalização de serviços que não eram possíveis com a internet [2]. O IMS reúne facilidades de voz como autenticação, autorização de serviço, controle de chamada, roteamento, interoperabilidade com PSTN, cobrança, serviços suplementares e VAS (Value Added Services). Nenhum desses serviços existe no EPC (Evolved Packet Core), sendo esta a razão pela qual o mesmo não pode processar uma chamada de voz sem o auxílio do IMS. Conforme a Figura 7 [9], o CSCF (Call State Control Function) é o elemento central de sinalização SIP entre o UE e o IMS, cuidando do registo do UE na rede IMS e da gestão da sessão de serviço. O CSCF é definido por três funcionalidades diferentes que podem residir no mesmo nó físico ou em nós separados conectados através da interface Mw. Todas estas funcionalidades estão envolvidas nas transações de sinalização SIP relacionadas com UE sendo elas: P-CSCF (Proxy CSCF) I-CSCF (Interrogating CSCF) S-CSCF (Serving CSCF) [3]. A Figura 7 [10] ilustra a arquitetura IMS e os elementos utilizados para o trafego de voz para redes externas.

7 Fig. 7. Diagrama da arquitetura IMS. O P-CSCF atua como o primeiro ponto de contato para sinalização de chamadas proveniente do usuário (UE) para a rede IMS. Do ponto de vista do SIP, o P-CSCF está agindo como um servidor proxy SIP de Entrada / Saída. Isto significa que todos os pedidos e / ou respostas iniciados pelo ou destinadas para o IMS passarão pelo P-CSCF. O P-CSCF é atribuído ao terminal IMS durante o registo e não se altera durante o período de registo (UE comunica-se com um único P-CSCF durante todo o tempo de registo) [2]. O I-CSCF fornece a funcionalidade de um servidor proxy SIP. Seu endereço IP é publicado no DNS (Domain Name System) do domínio, assim os servidores remotos podem encontrá-lo e usá-lo como um ponto de encaminhamento para pacotes SIP destinados a este domínio. I-CSCF consulta o HSS usando a interface DIAMETER Cx para recuperar a localização do usuário, e roteia então o SIP request a seu S-CSCF atribuído. Até a release 6, também pode ser usado para ocultar a rede interna das redes externas (criptografando parte da mensagem SIP), neste caso, é chamado de THIG (Topology Hiding Inter-network Gateway) [10]. O S-CSCF é um servidor SIP sempre localizado na rede doméstica. Utiliza as interfaces DIAMETER Cx e Dx para conectar-se ao HSS e fazer o download e upload do perfil do usuário. Não tem armazenamento local do usuário, todas as informações necessárias são carregadas a partir do HSS. Suas funções são as seguintes: Lidar com os registos SIP, o que permite ligar a localização do utilizador (por exemplo, o endereço IP do terminal) e o endereço SIP. Ficar no caminho de todas as mensagens de sinalização e pode inspecionar todas as mensagens. Decidir para quais servidores de aplicativos a mensagem SIP será encaminhada, a fim de fornecer Serviços. Reforçar a política do operador de rede. Podem haver múltiplos S-CSCFs na rede para distribuição de carga e por razões de garantia de alta disponibilidade. É o HSS que atribui o S-CSCF a um usuário, quando é consultado pelo I-CSCF [10]. O SLF (Subscription Locator Function) é necessário para mapear endereços de usuários quando vários HSSs são usados. O SLF é usado em uma rede IMS como mecanismo de resolução que permite que o I-CSCF, o S-CSCF e o AS (Application Servers) encontrem o endereço do HSS que contém os dados de assinante para um determinado usuário quando vários HSSs foram implantados pelo operador de rede. O SLF não executa qualquer lógica em suas interfaces, mas responde ao solicitante com uma mensagem REDIRECT especificando o endereço do HSS que é capaz de cumprir o pedido recebido. Tanto o HSS como o SLF comunicam-se através do protocolo DIAMETER [10]

8 O HSS é um elemento que existe também no EPC (embora exista no IMS há mais tempo) sendo a base de dados de todos os assinantes e serviços de dados. Suporta as entidades de rede IMS que lidam com as sessões de chamada com as seguintes informações: Informações relacionadas à assinatura (perfis de usuário), usadas pela camada de controle. Informações de subscrição usadas pela camada de serviço. Informações sobre a subutilização da camada de serviço. Informações sobre a localização física do usuário. O HSS também fornece as funções tradicionais do HLR e AUC (Authentication Center), permitindo que o usuário acesse os domínios de pacotes e circuitos da rede, através da autenticação IMSI. O perfil do usuário armazenado no HSS é composto por [10]: Identidade do usuário; Nome do S-CSCF atribuído; Informações de registro e perfil móvel; Parâmetros de autenticação; Informações de controle e serviço. O MRF (Media Resource Function) gerencia o fluxo de mídia na rede doméstica, oferecendo as seguintes funções: Reprodução de anúncios (áudio / vídeo); Conferência multimídia; Conversão de texto para fala e reconhecimento de fala; Transcodificarão em tempo real de dados multimídia (ou seja, conversão entre diferentes codecs). Cada MRF é ainda dividido em: MRFC (Media Resource Function Controller) é um nó no plano de sinalização que atua como um SIP User Agent para o S-CSCF e que controla o MRFP através de uma interface H.248. MRFP (Media Resource Function Processor) é um nó de plano de mídia que implementa todas as funções relacionadas à mídia. O BGCF (Breakout Gateway Control Function) é o elemento IMS que seleciona a rede na qual o breakout PSTN deve ocorrer, sendo usado para chamadas do IMS para um telefone em uma rede comutada a circuito, como a PSTN ou a PLMN (Public Land Mobile Network). O BGCF encaminha a sinalização para a rede PSTN / PLMN selecionada. Se o breakout ocorrer na mesma rede que o BGCF, então o BGCF seleciona um MGCF (Media Gateway Control Function), que será responsável pelo interfuncionamento com a PSTN, e encaminha a sinalização para MGCF. Caso contrário, encaminha a sinalização para o BCGF de outros operadores de rede. O MGCF recebe então a sinalização SIP do BGCF e gerencia o interfuncionamento com a rede PSTN [10]. O interfuncionamento entre a rede IMS e a rede de comutação de circuitos é realizado por vários componentes para sinalização, mídia e controle, sendo eles: O SGW (Signaling Gateway) é a interface com o plano de sinalização da rede de comutação de circuitos. Ele transforma protocolos de camada inferior como SCTP (Stream Control Transmission Protocol), MTP (Message Transfer Part) e ISUP (ISDN (Integrated Services Digital Network) User Part) do MGCF para a rede CS. O MGCF realiza conversão de protocolo de controle de chamada entre SIP e ISUP. Se comunica com o SGW através de uma interface SCTP e controla os recursos do MGW (Media Gateway) com uma interface H.248. O MGW controla as interfaces do plano de mídia com rede CS, convertendo entre RTP e PCM (Pulse Code Modulation). Também pode executar a transcodificação de mídia, quando os codecs usados não coincidem (Por exemplo, o IMS pode usar AMR (Adaptive Multi-Rate) enquanto a PSTN pode usar G.711). Servidores de aplicação (AS) Os servidores de aplicativos hospedam e executam os serviços e tem uma interface com o S-CSCF usando SIP. Exemplos de serviços são: - Serviços relacionados com a identificação de chamadas; - Call waiting, call hold, Call pick up; - Desvio de chamadas, transferência de chamadas; - Serviços de bloqueio de chamadas, identificação de chamadas maliciosas; - Intercepção legal; - Anúncios; - Serviços de teleconferência; - Serviços baseados em localização; - SMS, MMS (Multimedia Messaging Service); - Função VCC (Voice Call Continuity) ou convergência fixa móvel. O IM-SSF (IP Multimedia - Service Switching Function) é o nó no domínio IMS que fornece o interfuncionamento entre o controle de sessão SIP e as redes inteligentes tradicionais. Permite que as solicitações de serviços sejam encaminhadas para as plataformas legadas de entrega de serviços, tais como IN (Intelligent Networks) baseadas em SCPs (Service Control Point). O IM-SSF também permite acesso a informações de assinantes obtidas pelo HSS sobre a interface Si, usando o protocolo MAP (Mobile Application Part). D. Arquitetura VoLTE A terceira alternativa para serviços de voz sobre a rede LTE é um padrão conhecido como VoLTE, que se baseia em um conjunto mínimo de entidades e funcionalidades de rede IMS. O VoLTE foi criado para permitir que as operadoras LTE forneçam serviços de voz sem a necessidade de investir em um IMS completo e fazer mudanças radicais em suas redes[9]. A arquitetura VoLTE pretende substituir as soluções que utilizam Generic Access (VoLGA) e 2G/3G (CSFB) para a realização de chamadas de voz. Esse arranjo utiliza a infraestrutura totalmente baseada em IP para a realização de chamadas de voz [4]. A Figura 8 [11] mostra o trafego de voz da rede LTE para uma PSTN usando a rede IMS.

9 Fig. 8. Arquitetura VoLTE. Ao contrário dos serviços de dados nas redes 2G e 3G, onde os mesmos são tratados como first-come, first-served (o primeiro pacote que entra é o primeiro que sai), o LTE garante que cada serviço tenha o QoS necessário para otimizar a experiência dos assinantes, mesmo várias aplicações simultâneas. Por exemplo, uma perda significativa de pacotes em um vídeo em fluxo contínuo, como o YouTube, causa cintilação que será percebida pelo usuário. Para evitar este fenômeno, o streaming é armazenado temporariamente em segurança [12]. Em contraste, uma sessão de voz em tempo real (como VoLTE) pode tolerar uma perda maior de pacotes, uma vez que o ouvido humano é menos sensível a este fenômeno. No entanto, o atraso deve ser minimizado para evitar problemas de conversação encontrado em chamadas via satélite ou chamadas VoIP (Voice Over IP) com atraso e jitter excessivamente longos [12]. Para cada portador (bearer), a rede LTE atribui um nível de QCI (QoS Class Identifier). Cada QCI é caracterizado por um tipo de recurso GBR (Guaranteed Bit Rate) ou Non-GBR (Non-Guaranteed Bit Rate), com prioridade durante o congestionamento, orçamento de atraso de pacote e uma taxa de perda de pacote. Esses QCIs determinam como um portador é tratado pela rede durante a execução do serviço suportado pelo mesmo, a partir do UE até o PDN (Public Data Network Gateway), sendo o mesmo responsável por distribuir endereço IP ao usuário e também responsável pela comunicação entre a enb e os serviços non-3gpp como a internet. Os valores e parâmetros relativos a cada QCI são apresentados na Tabela I [12]. TABELA I VALORES PADRÃO DE QCI QCI Resource Type Priority Packet Delay Budget Packet Error Loss Rate Exemple Services 1 GBR ms 10-2 Conversational voice 2 GBR ms 10-3 Conversational voice (live streaming) 3 GBR 3 50 ms 10-3 Real time gaming 4 GBR ms 10-6 Non-conversational video (buffered streaming) 5 Non-GBR ms 10-6 IMS signalling 6 Non-GBR ms 10-6 Video (buffered streaming), TCP-based 7 Non-GBR ms 10-3 Voice, video (live streaming), interactive gaming 8 Non-GBR ms 10-6 Video (buffered streaming), TCP-based (e.g., www, , 9 Non-GBR ms 10-6 chat, ftp, p2p file sharing, progressive video, etc.) 1. chamada de voz para a PSTN na arquitetura VoLTE Para chamadas originadas pelo VoLTE para a rede CS, o S- CSCF de origem deve reconhecer que a terminação não está dentro do domínio VoLTE e recorre a uma BGCF para determinar a MGCF de destino [13]. O S-CSCF determina que o destinatário está dentro da rede CS de operadores e encaminha o SIP INVITE para o BGCF. O BGCF é responsável pela seleção de um MGCF apropriado para a rede CS. O BGCF pode usar DNS ou dados internos de configuração para analisar o URI (Uniform Resource Identifier) de solicitação para determinar o melhor MGCF a ser selecionado. O URI de pedido pode ser SIP, mas conterá um número E.164 (é uma recomendação, que define internacionalmente, a utilização da numeração na rede PSTN e em algumas outras redes de dados) ou um número de telefone qualificado por um parâmetro URI de contexto de telefone. O BGCF encaminha o INVITE para o MGCF selecionado. O MGCF é responsável pela interoperabilidade com a rede CS, tanto no plano de controle (IMS SIP para ISUP) quanto no plano de mídia via IMS-MGW. O MGCF seleciona a GMSC (Gateway Mobile Switching Center) de saída para a rede CS. A rota de saída para a rede CS pode ser baseada em TDM ou IP e utiliza ISUP ou SIP-I (SIP with encapsulated ISUP), respectivamente. A seleção de rotas no MGCF é baseada DNS ou dados de configuração.

10 Após ter selecionado uma rota, o MGCF deve escolher um IMS-MGW para alocar e configurar recursos de mídia para a chamada. O MGCF envia um ISUP IAM (Initial Address Message) / SIP-I INVITE (IAM) para o GMSC que por sua vez, consulta o HLR para descobrir a localização da MSC (Mobile Switching Center) que o usuário está registrado no momento. Percebe-se que o MGCF pode ser co-localizado com um GMSC-S. O GMSC encaminha a solicitação para o MSC em que o usuário está registrado e o estabelecimento da chamada é executado. Para o ISUP / BICC (Bearer Independent Call Control), o MGCF enviará uma mensagem de 183 Progress contendo a resposta SDP (Session Description Protocol). Já para o SIP-I, o MGCF receberá uma mensagem de 183 Progress do MSC contendo a resposta SDP. Em ambos os casos, a resposta SDP contém um único codec de voz, indicando que pré-condições QoS também são desejadas, mas ainda não foram cumpridas no lado de terminação. Além disso, a resposta do SDP solicitará a confirmação das condições prévias de QoS que estão sendo atendidas no lado de origem. O Progress 183 (SDP) é enviado para a etapa de origem via BGCF / S-CSCF. O MGCF recebe um PRACK (Provisional Response Acknowledgement) do lado de origem da chamada e responde com um 200 OK (PRACK) para rotas BICC / ISUP. No caso das rotas SIP-I, o MGFCF deve passar PRACK e 200 OK (PRACK). O UE de origem enviará agora uma mensagem UPDATE com uma nova oferta SDP, confirmando o codec de voz selecionado e indicando que as pré-condições QoS foram satisfeitas pela origem. O MGCF recebe a mensagem UPDATE e responde com um 200 OK (UPDATE) para rotas BICC / ISUP e transita o UPDATE / 200 OK (UPDATE) para rotas SIP-I. O 200 OK (UPDATE) contém a resposta SDP indicando que pré-condições QoS também são atendidas no lado do término da chamada. Uma vez que as pré-condições QoS são agora cumpridas em ambas as extremidades, o MGCF deve enviar uma mensagem COT (Continuity) indicando "verificação de continuidade bem-sucedida". O usuário final na rede CS é agora alertado e o MGCF recebe uma mensagem ACM (Address Complete Message (alerting)) de ISUP / BICC ou uma mensagem SIP 180 Ringing (ACM) de SIP-I. O MGCF envia uma mensagem SIP 180 Ringing para a origem. É extremamente recomendável que o MGCF inclua o P-Early-Media header (Usado para indicar que os recursos são alocados) na mensagem SIP 180 (Ringing). Neste momento, o MGCF deve também assegurar que os meios de comunicação (por exemplo, tom de chamada, indicações de progresso) sejam transmitidos através do IMS- MGW. O SIP 180 Ringing é encaminhado para o VoLTE UE para indicar um tom de toque para o assinante. Quando a rede CS indica que a chamada foi atendida, o MGCF envia uma mensagem 200 OK (INVITE) para a rede IMS. Esta mensagem é encaminhada para o segmento de origem da chamada e para o VoLTE UE. O MGCF deve assegurar que os meios duplex possam ser transportados através do IMS-MGW neste ponto. O VoLTE UE recebe os 200 OK e envia uma mensagem SIP ACK para reconhecer que a chamada foi estabelecida. O ACK é propagado através da rede IMS para o MGCF. A mensagem ACK é encaminhada para a rede CS para rotas SIP- I. Nesta fase, a chamada é estabelecida com o tráfego de voz enviado através do portador dedicado entre o VoLTE UE e a rede CS através do IMS-MGW [13]. A Figura [13] ilustra uma chamada originada VoLTE (LTE/EPC/IMS) para uma rede PSTN Fig. 9. Chamada originada VoLTE para uma PSTN

11 E. SR-VCC O SR-VCC não é uma alternativa para entrega de voz, e sim um processo de handover de chamadas previamente iniciadas na rede LTE (IMS LTE Voice) para as redes legadas. Uma vez que a chamada VoLTE é suportada pela rede LTE, pode haver a necessidade de fazer uma transferência da mesma para uma rede GSM, WCDMA ou CDMA no caso de não haver mais cobertura LTE [3]. A funcionalidade do handover de uma chamada VoIP apartir da rede LTE para o domínio CS das redes legadas é designado como SR-VCC e não necessita que o UE sinalize simultaneamente com duas tecnologias de rádio acesso diferentes [3]. A MSC servidora da conexão usa a interface Sv baseada em GTP (GPRS Tunneling Protocol) para o MME no domínio LTE no acionamento do procedimento de SR-VCC. A S-IWF atua semelhante a um servidor MSC âncora para domínio CS alvo e também é responsável pela preparação dos recursos necessários da rede de rádio acesso alvo. Para que ocorra o SR-VCC apartir da E-UTRAN (Evolved- UTRAN) para o UTRAN/GERAN, O MME primeiro recebe o pedido de handover da E-UTRAN com a indicação de que isso é para tratamento SR VCC e, em seguida, ativa o procedimento SR VCC com o S-IWF através da interface Sv, se o MME tiver informações STN-SR (Session Transfer Number for SR-VCC) para este UE. O S-IWF inicia o procedimento de transferência de sessão para IMS, e coordena com o procedimento de handover de CS para a célula alvo [15]. A Figura 10 [3] ilustra o método de handover SR-VCC usando o VoLTE. Fig. 10. Handover SR-VCC. III. CONCLUSÕES Há muitos desafios para o LTE. Enquanto o 3GPP padronizou o VoLTE baseado em IMS para voz sobre LTE e o SR-VCC para continuidade das chamadas, a adoção do IMS tem sido muito lenta principalmente por causa dos problemas de custo [14]. Entre as técnicas não-ims, o CSFB requer alto investimento porque exige que todos as MSCs sejam atualizadas para suportar a interface SGs. O CSFB introduz latência na execução de chamadas de voz quando as chamadas são entregues do LTE para as redes 2G / 3G legadas [14]. Em comparação com o CSFB, o VoLGA tem um custo menor, e se conecta ao PCRF para fornecer o QoS necessário e não há atraso na execução da chamada. Entretanto, o VoLGA não foi padronizado pelo 3GPP. Os operadores que utilizam o VoLGA enfrentam a perspectiva de incompatibilidade entre RAT (Radio Access Technology) e possíveis obstáculos na migração para o VoLTE [14]. A migração para o LTE é inevitável. O GSMA (GSM Association) padronizou o VoLTE baseado no 3GPP IMS como a melhor solução para voz e SMS em redes LTE. Como esta solução é complexa e dispendiosa, os operadores estão considerando CSFB e o VoLGA, pelo menos temporariamente. REFERÊNCIAS [1] KHAN, Farooq., "LTE for 4G Mobile Broadband.," Air interface technologies and performance,2009. [2] Al-Begain. Khalid, Balakrishna. Chitra, Galindo. A. Luis, Fernández M. David. IMS: A Development and Deployment Perspective, 1st ed, [3] HOLMA. Harri, TOSKALA. Antti., "LTE for UMTS OFDMA and sc- FDMA Based Radio Access", 1st ed., John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom, [4] P. Z. Leonardo. (2008). O que é CSFB e SRVCC no LTE. Telecomhall. [online]. Disponível: http: // [5] Qualcomm The first phase of voice evolution for mobile LTE devices [online] Disponivel: ution_for_mobile_lte_devices.pdf. [6] SAUTER, M. Voice over LTE via Generic Access (VoLGA). White paper, August [7] BATHI. Simran, TAYAL. Vandana, GULIA. Pooja, Generic Access Network(GAN). IJRD-Jornal of Computer Science and Engineering, April [online] Disponivel: Journal-of-Research-&-Development-Organisation-pdf/International- Journal-Of-Computer-Science-Engineering/Journal-Of-Computer- Science-Engg-April-15/April-Cse-19.pdf. [8] 3GPP Generic Access Network: 3GPP TS43.318, Mobile Broadcasting with Wimax ; Amitabh Kumar, [9] Holtzman. Yehuda. (2013), Voice Service Alternatives for LTE Networks.Exploregate[online] Disponível: [10] IMS Architecture overview [online] Disponível: [11] Kulkarni. Vijay, Yost. Bruce. (1986). Testing LTE, and VoLTE. GL Communications [online] Disponível: [12] Voice over LTE: The new mobile voice [online] Disponível: voice-over-lte-new-mobile-voice-inspire-new.pdf.

12 [13] GSMA (1982). VoLTE Service Description and Implementation Guidelines [online] Disponível: [14] GUPTA, Lav. Voice over LTE: Status and Migration Trends withe paper, April [online] Disponivel: [15] 3GPP Technical Specifi cations Single Radio Voice Call Continuity (SRVCC), V [online] Disponivel: pdf. Escórcio Luís Miguel nasceu em Luanda-Angola, em 11 de outubro de Possui os títulos: Técnico em Eletricidade Eletrônica e Telecomunicações no ITEL - Instituto Nacional de Telecomunicações em 2008 e graduado em Engenharia de Telecomunicações em agosto de 2014 pelo UNIFIEO- Universidade Instituto Fundação Para Osasco. Desde setembro de 2016 é técnico de suporte, onde atua na área de telefonia VOIP e NGN. Tem interesse nas áreas de Antenas, Sistemas de Comunicações Móveis de 5ª Geração, Comunicações Ópticas, Sistemas de Comunicação Digital, Sistemas de Comunicações Móveis celular. Daniel Andrade Nunes nasceu em Santa Rita do Sapucaí em 1973, formado como Técnico em Eletrônica na Escola Técnica de Eletrônica Francisco Moreira da Costa em 1992 e graduado em Engenharia elétrica em 1998 pelo INATEL Instituto Nacional de Telecomunicações. Trabalhou 5 anos na multinacional Ericsson como instrutor técnico e gerente de projetos principalmente na área de sistemas celular no planejamento, otimização e desenvolvimento de cursos para sistemas AMPS, DAMS, CDMA e GSM em 13 países da América latina, Estados Unidos, Europa e África. Obteve o grau de Mestre em Telecomunicações, também pelo INATEL em agosto de É professor dos programas de Graduação e Pós Graduação em matérias relativas a comunicações móveis e transmissão digital no INATEL além de já ter ministrado cursos nas áreas de planejamento e otimização para sistemas GSM, WCDMA, LTE, WiFI e WiMAX pelo ICC Inatel Competence Center. Atualmente integra o corpo de pesquisadores do Centro de Referência em Radiocomunicações (CRR) do Inatel.