Soluções IMS para aprovisionamento de serviços de telecomunicações em ambientes AD HOC

Departamento de Ciências e Tecnologia da Informação

Soluções IMS para Aprovisionamento de Serviços de

Telecomunica-ções em Ambientes AD HOC

Domingos Garcia da Silva

Dissertação submetida como requisito parcial para obtenção do grau de

Mestre em Engenharia Informática e de Telecomunicações

Orientador(a):

Professor Pedro Sebastião, PhD, ISCTE - Instituto Universitário de Lisboa

Co-orientador(a):

Professor Rui Jorge Lopes, PhD, ISCTE - Instituto Universitário de Lisboa

ii

iii

Dedicatória

Dedico este trabalho aos meus pais e irmãos por todo encorajamento e motivação para supor-tar à distância.

iv

v

Agradecimento

Aos meus orientadores, por todo o apoio e disponibilidade prestada ao longo do desenvolvi-mento do trabalho.

Quero também agradecer aos meus colegas de mestrado Márcio Santos, Adilson Ramos, Ed-valdo Segundo, Felisberto Monteiro, Cíntia Pinheiro, Ariel Freitas e Evódia Medina por todo apoio de forma incansável a todos os níveis “Irmãos”.

vi

vii

Resumo

Com o crescente desenvolvimento populacional e a sua necessidade de comunicação, as ope-radoras de telecomunicações têm sido impulsionadas a dispor de recursos tecnológicos1 _para atender à demanda dos utilizadores à medida que novas áreas habitacionais são criadas. Facto é que nem sempre estão disponíveis verbas quando observado os custos associados para insta-lar e manter sistemas de telecomunicações eficientes.

E como tal, o IP Multimedia Subsystem (IMS) afigura-se como sendo uma arquitetura capaz de atender a questão acima com serviços de telecomunicações e convergência total entre redes fixas e redes móveis baseada em protocolos comuns de Internet - Internet Protocol (IP). Por outro lado, prover suporte aos mais variados equipamentos de redes de telecomunicações, destacando-se os OpenHardware, consequentemente reduzindo a complexidade e os custos dos recursos tecnológico, por não necessitarem de licenciamentos.

No âmbito da dissertação os ensaios foram realizados no mais popular OpenHardware Raspberry Pi. Assim, esta dissertação tem por vista explorar soluções que permitam disponi-bilizar serviços de telecomunicações concretamente telefonia, recorrendo a recursos tecnoló-gicos com baixo custo operacional.

A dissertação adota uma abordagem metodológica de Design Science Research, guiada por uma revisão da literatura diligente e sistemática, resultando na identificação dos principais trabalhos relacionados, com os objetivos propostos da dissertação.

Espera-se que esta dissertação seja relevante para o contributo de conhecimento da arquitetura IMS.

Palavras-chave: Redes Convergentes, Redes de Nova Geração, IP Multimedia Subsystem.

viii

Abstract

With growing population growth and their need for communication, telecom operators have been driven to have the technological resources to meet the demand of users as new housing areas are created. Fact is that funds are not always available when observed the associated costs to install and maintain efficient telecommunications systems.

And as such, the IP Multimedia Subsystem (IMS) appears to be an architecture capable of addressing the above issue with telecommunications services and full convergence between fixed-line networks and mobile networks based on common Internet protocols). On the other hand, to provide support to a wide range of telecommunication network equipment, notably OpenHardware, thereby reducing the complexity and cost of technological resources.

Within the dissertation essays were held in the most popular OpenHardware Raspberry Pi. Thus, this dissertation aims to explore solutions that allow the provision of telecommunica-tion services specifically telephony, using technological resources with low operatelecommunica-tional costs.

The dissertation adopts a methodological approach of Design Science Reserach, guided by diligent and systematic literature review, resulting in the identification of the main papers and reports related to the proposed objectives of the dissertation.

It is expected that this dissertation will be relevant to the knowledge contribution of the IMS architecture.

ix

ÍNDICE

1. INTRODUÇÃO ... 1 1.1 CONTEXTO E MOTIVAÇÃO... 1 1.2 OBJETIVOS ... 2 1.3 ABORDAGEM METODOLÓGICA... 3 1.4 ORGANIZAÇÃO DO TRABALHO ... 3 2. FUNDAMENTAÇÃO TEÓRICA ... 5

2.1 REVISÃO DAS REDES DE TELECOMUNICAÇÕES ... 5

2.2 EVOLUÇÃO DAS REDES ... 6

2.3 REDES CONVERGENTES ... 8

2.4 REDES DE NOVA GERAÇÃO (NGN) ... 10

2.5 IP MULTIMEDIA SUBSYSTEM (IMS) ... 12

2.6 PROTOCOLOS ... 15

2.7 APLICAÇÕES IMS ... 19

3. DESENHO E IMPLEMENTAÇÃO DA SOLUÇÃO PROPOSTA ... 25

3.1 ARQUITETURA DA SOLUÇÃO PROPOSTA ... 25

3.2 REQUISITOS DE IMPLEMENTAÇÃO... 26

x

4. TESTE E ANALISE DE DESEMPENHO DA SOLUÇÃO ... 31

4.1 REGISTRO E INTEROPERABILIDADE SIP/IMS ... 31

4.2 INTEROPERABILIDADE IMS E PSTN ... 44

4.3 AVALIAÇÃO DE DESEMPENHO ... 45

5. CONCLUSÕES E TRABALHO FUTURO ... 53

5.1 CONCLUSÕES ... 53

5.2 TRABALHO FUTURO ... 54

REFERÊNCIAS ... 57

ANEXO A ... 61

A.1 INSTALAÇÃO DO OPENIMS CORE ... 61

A.2 BAIXAR O OPENIMS CORE ... 61

A.3 CONFIGURAÇÃO DA BASE DE DADOS ... 62

A.4 INSTALAÇÃO DO NÚCLEO IMS ... 62

A.5 COMPILAÇÃO DO FHOSS... 62

xi

Lista de Figuras

Figura 2.3.1 - Arquitetura de Redes Sobrepostas ... 8

Figura 2.3.2 - Arquitetura de Redes Convergentes ... 9

Figura 2.4.1 - Modelo funcional geral NGN ... 11

Figura 2.5.1 - Arquitetura IMS [7] ... 13

Figura 2.5.2 - Componentes e interfaces IMS ... 14

Figura 2.6.1 - SIP trapézio [30] ... 16

Figura 2.6.2 - SIP Server DHCP Option 120 ... 19

Figura 2.7.1 - Elementos da arquitetura IMS disponibilizado pela FOKUS [6] ... 20

Figura 2.7.2 - IMSDroid Client ... 22

Figura 2.7.3 - Boghe IMS Client ... 23

Figura 2.7.4 - X-Lite softphone ... 24

Figura 3.1.1 - Arquitetura da Solução Proposta ... 25

Figura 3.2.1 - Raspberry Pi 3 ... 27

Figura 3.3.1 - Utilizadores do FHoSS ... 29

Figura 3.3.2 - Perfil de utilizador ... 29

Figura 4.1.1 - Parâmetro de configuração do terminal IMS ... 32

Figura 4.1.2 - Registro IMS - fase do desafio ... 32

Figura 4.1.3 - Registro IMS - fase de validação de registro ... 33

Figura 4.1.4 - Procedimento de Sessão de Chamada IMS ... 34

Figura 4.1.5 - Teste real de chamada entre dois terminais IMS ... 35

Figura 4.1.6 - Jitter e Latência_Codec GSM (de cima para baixa) ... 36

Figura 4.1.7 - Jitter e Latência_Codec G.711 (de cima para baixa) ... 37

Figura 4.1.8 - 403 Forbidden - utilizador do HSS desconhecido ... 38

Figura 4.1.9 - Interoperabilidade entre utilizador IMS e SIP ... 39

Figura 4.1.10 - Jitter e Latência IMS para SIP_Codec G.711 ... 40

Figura 4.1.11 - Jitter e Latência IMS para SIP_Codec GSM ... 41

Figura 4.1.12 - Configuração de Rede Visitada ... 42

xii

Figura 4.1.14 - Jitter e Latência_GSM ... 43

Figura 4.1.15 - Jitter e Latência_G.711 ... 44

Figura 4.2.1 - Interoperabilidade IMS PSTN ... 45

Figura 4.3.1 - Fluxo de chamada do UAC e UAS... 46

Figura 4.3.2 - SIPp INVITE ... 47

Figura 4.3.3 - SIPp RTP ... 48

Figura 4.3.4 - SIPp UAC Xlite ... 49

Figura 4.3.5 - Utilização da CPU ... 50

Figura 4.3.6 - Utilização de memória ... 51

Figura 5.1.1 - Tela de login FHoSS ... 64

xiii

Lista de Tabelas

Tabela 1.2.1 Objetivos Específicos ... 2

Tabela 1.3.1 Abordagem Metodológica ... 3

Tabela 2.5.1 - Descrição das Interfaces IMS ... 15

Tabela 3.2.1 Especificação dos equipamentos utilizados ... 27

xiv

Lista de Acrónimos

1G First Generation

2G Second Generation

3G Third Generation

3GPP Third Generation Partnership Project 3GPP2 Third Generation Partnership Project 2

4G Fourth Generation

AAA Authentication, Authorization and Accounting ADSL Asymmetric Digital Subscriber Line

AS Application Server

CODEC Coder-Decoder

CPS Calls Per Second

CSCF Call Session Control Function

DNS Domain Name Service

FDMA Frequency Division Multiple Access FQDN Fully Qualified Domain Name

GSM Global System for Mobile communication

HLR Home Location Register

HSS Home Subscriber Service HTTP Hypertext Transfer Protocol IAX Inter-Asterisk eXchange

IC Integrated Circuit

I-CSCF Interrogating Call Session Control Function IETF Internet Engineering Task Force

iLBC Internet Low Bitrate Codec

IMS IP Multimedia Subsystem

IoT Internet of Things

IP Internet Protocol

ISDN Integrated Services Digital Network

LAN Local Area Network

xv MGCP Media Gateway Control Protocol

MOS Mean Opinion Score

ms milliseconds

MSC Mobile Station Center

NAT Network Address Translation

NGN Next-Generation Network

P-CSCF Proxy Call Session Control Function PDF Policy Decision Function

PLMN Public Land Mobile Network

PSTN Public Switched Telephone Network

QoS Quality of Service

ROI Return On Investment

RTCP Real Time Control Protocol

RTT Round Trip Time

S-CSCF Serving Call Session Control Function SIP Session Initiation Protocol

SIPp Simple Internet Protocol Plus

SMS Short Message Service

UA User Agent

UAC User Agent Client

UAS User Agent Server

UDP User Datagram Protocol

UE User Equipment

VoIP Voice over Internet Protoco VoLTE Voice over Long-Term Evolution

WAN Wide Area Network

1

1. Introdução

Neste capítulo definem-se o Contexto, Motivação, Objetivos, Metodologia bem como a Orga-nização da dissertação.

1.1 Contexto e Motivação

Com o crescente desenvolvimento populacional e a sua necessidade de comunicação, as ope-radoras de telecomunicações têm sido impulsionadas a dispor de recursos tecnológicos2 _para atender à demanda dos utilizadores [1] à medida que novas áreas habitacionais são criadas. Certo é que tais recursos tecnológicos carecem de investimentos financeiros e que nem sem-pre estão disponíveis quando observado os custos3 _{associados para instalar e manter sistemas} de telecomunicações eficientes nessas áreas desprovidas [2] de recursos tecnológicos, conse-quentemente, impossibilitando o acesso aos serviços de telecomunicações como a telefonia.

Daqui resulta a motivação deste trabalho de investigação, que pretende explorar soluções que permitam disponibilizar serviços de telecomunicações concretamente telefonia, recorrendo a recursos tecnológicos com baixo custo operacional [3].

Nos últimos anos, surgiram diversas iniciativas como OpenBTS [4] Mesh Potato [5] e Ope-nIMS Core [6] que têm sido tomadas como alternativa para permitir o acesso de serviços de telefonia a baixo custo. Porém, um dos grandes entraves do OpenBTS consiste na necessidade de obter uma licença de espetro para operar em rede Global System for Mobile communicati-on (GSM). Quanto ao Mesh Potato, refere-se à mobilidade limitada, no que diz respeito à acessibilidade para terminais móveis. Sendo que a mesma fora concebida para terminais fixos analógicos. Neste domínio, o OpenIMS Core afigura-se como uma solução particularmente

2 Entendidos como infraestrutura de acesso aos serviços dos operadores de telecomunicações.

3 TCO (Total Cost of Ownership) estimativa financeira projetada para associar custos diretos ao ciclo de vida de um sistema ou equipamento.

2 relevante devido ao seu impacto tecnológico baseado no núcleo IP Multimedia Subsystem (IMS) [7] que irá permitir a criação de serviços de telecomunicações – telefonia, utilizando os componentes de redes de próxima geração IMS e protocolos comuns da Internet.

Os próximos capítulos detalharão todo este processo da proposta da solução, desde a fase do desenho do modelo conceptual a implantação e realização dos testes. Cada um destes capítu-los serão abordados de forma objetiva ao contexto da dissertação não sendo relevante uma especificação mais aprofundada.

1.2 Objetivos

Dentro do contexto referido na secção anterior, a dissertação tem como principal objetivo propor, desenhar, implementar e testar uma solução para fornecer serviços de telefonia que se apresente como alternativa economicamente rentável e funcional para atender as necessidades de comunicação em áreas onde o acesso alternativo aos serviços de telecomunicações não existe ou é muito caro.

Contudo, esta solução deverá garantir interoperabilidade entre os diferentes domínios e a rede pública. Para tal foram definidas algumas fases que nos levarão a concretização da investiga-ção. Estas fases estão descritas na 1.2.1.

Tabela 1.2.1 Objetivos Específicos

Fase 1 Explorar as várias aplicações Open Source disponíveis no momento, que possam dar resposta aos requisitos de uma plataforma IP Multimedia Subsystem.

Fase 2 Desenhar e implementar uma solução que possa servir de base para a implementação de servi-ços de telefonia a baixo custo operacional.

3

1.3 Abordagem Metodológica

Para atingir os objetivos enumerados anteriormente, definiu-se uma abordagem metodológica de Design Science Research [8], [9]. No âmbito do objeto de investigação, é realizada uma revisão da literatura diligente e sistemática, utilizando os motores de busca científicos como Google Scholar [10] e bibliotecas digitais — IEEE Xplore [11], ACM Digital Library [12] pesquisando alguns termos referentes a telecomunicações, nomeadamente: evolução das redes de telecomunicações, redes convergentes, redes de nova geração, IP multimedia subsystem, Voz sobre IP (VoIP), Open IMS, OpenWRT. Resultando assim na identificação dos principais trabalhos relacionados com os objetivos propostos da dissertação atual.

Tabela 1.3.1 Abordagem Metodológica

Objetivos Específicos Métodos Instrumentos

Fase 1

Explorar as várias aplicações Open Source disponíveis no momento, que possam dar resposta aos requisitos de uma plataforma IP Multimedia Subsystem.

R. Literatura

Siste-mática Artigos científicos

Fase 2

Desenhar e implementar uma solução que possa servir de base para a im-plementação de serviços de telefonia a baixo custo operacional.

Analise de possíveis arquiteturas telefonia IP para diferentes propósitos

Draw - editor gráfico online, Open IMS, Kamailio IMS.

Fase 3 Testar a funcionalidade e desempe-nho da solução proposta.

Teste de operação e desempenho

Softphone, Wireshark, SIPp

1.4 Organização do Trabalho

A dissertação está estruturada em 5 capítulos. Inicia-se com uma breve contextualização, apresentando-se o seu enquadramento, objetivos e a metodologia que se insere nesta disserta-ção.

4 O segundo capítulo aborda a teoria necessária para a realização da dissertação. Esta revisão ajudou na validação do estado da arte, fazendo-se uma revisão dos principais marcos históri-cos das redes de telecomunicações e os fatores que levaram à transição de um modelo baseado em comutação de circuito para pacotes IP um modelo verdadeiramente convergente: NGN e IMS. E no seu final são apresentadas as principais soluções para desenvolvimento ou constru-ção do núcleo IMS.

No terceiro capítulo é feito o desenho e implementação da solução proposta de IMS basean-do-se do projeto OpenIMS Core e Kamailio IMS, terminando com a representação de alguns cenários básicos e intermédios de IMS.

No quarto capítulo é feita uma avaliação de desempenho da solução proposta, mediante a mé-todos de avaliação de requisitos funcionais e não-funcionais e avaliação da perspetiva do uti-lizador final através de testes aplicacionais.

No quinto capítulo são apresentadas as conclusões resultantes da confrontação da revisão bi-bliográfica com os resultados obtidos do trabalho, por fim o desfecho do trabalho e sugestões quanto a futuros trabalhos.

5

2. Fundamentação Teórica

O presente capítulo aborda os principais conceitos teóricos desta dissertação bem como os fatores que levaram à transição de uma modelo baseado em comutação de circuito para um modelo verdadeiramente convergente NGN. Também é explicado o protocolo SIP que é usado na sinalização das comunicações VoIP, e por fim, é apresentada toda a estrutura e compo-nentes de uma arquitetura IMS.

2.1 Revisão das Redes de Telecomunicações

A evolução das redes de telecomunicações marca o seu início com o surgimento do telégrafo como principal sistema de comunicação a longa distância nos séculos XIX e começo do sécu-lo XX. O sucesso do telégrafo foi tal que sécu-logo em 1866 foi instalado um cabo submarino tran-satlântico ligando o Reino Unido aos Estados Unidos. E por volta de 1875 [13] a rede de ca-bos de telégrafo já cobria todo o globo incluindo o Extremo Oriente e a Austrália.

Entretanto, a evolução ocorria de forma sistemática e contínua, gerando novas ideias. Foi quando precisamente no ano de 1876 Graham Bell inventara o telefone, transformando a voz em sinais elétricos, dando início ao período de comunicação de voz à distância [14]. Com os avanços apresentados pelo telefone, tornou-se uma questão de tempo até que começaram a surgir muitos outros sistemas, sem critérios de normalização, em que os países tecnologica-mente mais desenvolvidos tentavam fazer singrar os seus próprios sistemas. A evolução dos circuitos integrados (ICs), e seu baixo custo, demandaram a utilização desses componentes em aparelhos telefónicos.

Os princípios utilizados por Bell no seu aparelho telefónico continuam a ser ainda utilizados nos dias de hoje em uma boa parte dos aparelhos telefónicos analógicos. A invenção do tele-fone por Bell, suscitou a necessidade de comutação, pois a prática de interligar aparelhos dois a dois seria simplesmente impraticável, logo a solução encontrada para esta questão foi a

cria-6 ção de uma estrutura intermediária, uma central de comutação, na qual todos os telefones se-riam ligados [15].

A digitalização da rede telefónica teve seu início no final da década de 60, no segmento da transmissão, mas os princípios e a tecnologia para o aparelho telefónico digital só estiveram disponíveis na década de 70, devido ao seu elevado custo. A sua difusão começou somente na década de 90.

Com a rápida popularização da telefonia, passou haver necessidade de se interligar as diversas centrais de comutação posicionadas em áreas geograficamente distintas, de forma hierárquica para facilitar o seu crescimento e gerenciamento.

A estrutura hierárquica definia as centrais de comutação local, como sendo aquelas que ligari-am os utilizadores às estações telefónicas. E, as centrais de comutação de trânsito aquelas que interligariam as centrais locais. Este conceito hierárquico, permaneceu como base para as re-des de telefonia fixa comutada PSTN [13].

2.2 Evolução das Redes

Como referido acima, a evolução das telecomunicações teve o seu início com o surgimento do telégrafo, logo após as redes de telecomunicações tiveram uma evolução a ritmo exponencial

Com o passar dos anos as centrais de comutação e os aparelhos telefónicos evoluíram, e a dependência física de um aparelho telefónico ficar ligado ao cabo de rede da operadora deixa-va de ser crucial, assim surgia dos laboratórios de Bell, o novo conceito das redes de teleco-municações designado por redes móveis ou telefonia celular.

7

Redes de primeira geração (1G)

A primeira geração de redes móveis (1G) surgiu no início dos anos 80 [16] como um sistema totalmente analógico baseado em acesso múltiplo por divisão de frequência (FDMA). Desta forma tinha toda sua comunicação centralizada, e como consequência apresentava uma baixa capacidade de tráfego e sinais suscetíveis a interferências, tratando-se de um sistema pouco eficiente na utilização das frequências. Com a demanda de novos utilizadores, rapidamente este sistema foi esgotado e substituído pelos sistemas de segunda geração (2G) [17].

Redes de segunda geração (2G)

A 2G surge no início dos anos 90 [16] na Finlândia e baseava-se na tecnologia digital com objetivo de colmatar as limitações da 1G. Embora o seu sinal fosse transportado sobre a tec-nologia comutada por circuito, tal como a 1G, a 2G proporcionou algumas melhorias: melhor qualidade, maior capacidade de utilização na faixa de frequência, redes móveis sem fio - Glo-bal System for Mobile Communications (GSM) incluindo serviços de conferência e sistema de mensagens - Short Message Service (SMS) [18].

Redes de terceira geração (3G)

A 3G surgiu no sentido de oferecer maior capacidade, novas frequências e ritmos de transmis-são superiores para que o acesso à Internet fosse alcançado em alta velocidade. Com o sistema de alta velocidade viabilizado, diversos outros serviços passaram a oferecer maior qualidade ao clientes, como envio de imagens e a videoconferência, unindo os principais paradigmas das redes de telecomunicações, nomeadamente a telefonia móvel e Internet [18].

Foi a partir desta geração que se desenvolveu o conceito de rede IMS [7], objeto principal deste trabalho.

8

2.3 Redes Convergentes

O conceito de convergência, é um assunto que vem sendo discutido na indústria de redes de telecomunicações desde os anos 80, e quando nos referimos a redes convergentes, de uma maneira geral entendemos por uma infraestrutura de rede comum capaz de prover harmonio-samente serviços multimédia (voz, dados e aplicações) de maneira integrada, independente-mente da tecnologia de acesso [19].

No contexto dos avanços tecnológicos, surgiram diversos serviços destacando-se a telefonia móvel e a Internet. Contudo, identificaram-se algumas limitações para os operadores. As limi-tações consistiam na complexidade de gestão e no aprovisionamento dos serviços, uma vez que as operadoras tinham de implementar redes específicas para cada tipo de serviço, resul-tando em um grande número de redes sobrepostas [19]. como apresentado na figura 2.3.1.

Figura 2.3.1 - Arquitetura de Redes Sobrepostas

Estas limitações impulsionaram o surgimento da convergência, uma vez que as operadoras perceberam a necessidade de encontrar uma solução em que elas pudessem diversificar os serviços para manter e até mesmo atrair novos consumidores. O amadurecimento dessa ten-dência não foi de imediato, já que havia restrições tecnológicas significativas. Mas pode-se

9 considerar, que os primeiros passos em direção à convergência das redes de telecomunicações foram iniciados por ocasião da convergência das redes de voz e dados. Com base nisso, co-meçou-se pela digitalização da telefonia, que tipicamente era exclusivamente comutada por circuito, e passava a incorporar a possibilidade de transmissão de dados digitais, através da tecnologia ISDN permitindo uma série de melhorias em relação aos antigos sistemas analógi-cos.

A proposta da ISDN era de levar até ao utilizador final, uma extensão do canal de voz digital agregando na mesma linha recursos de dados até uma taxa de transmissão efetiva de 128 Kbps. A comunicação de dados até 128 Kbps na época já se via como um serviço revolucio-nário. A consolidação da Internet foi um passo fundamental para que os conceitos de conver-gência nas redes de telecomunicações se difundissem em maior escala, principalmente fora do segmento corporativo.

A figura 2.3.2 representa o cenário de uma única infraestrutura a prover serviços aos utiliza-dores com diferente tecnologia de acesso [19].

10

2.4 Redes de Nova Geração (NGN)

Segundo a norma Y.2001 [20] a NGN está relacionada com a ideia de uma infraestrutura co-mum de pacotes, sustentada pelo protocolo IP, com a capacidade de fornecer variadíssimos serviços e conteúdos de telecomunicações em tempo real (voz, vídeo e dados), e uso de múlti-plas tecnologias e transporte com QoS em banda larga de maneira independente. Tal conceito foi introduzido levando em consideração os desafios de um ambiente “desregulamentado” apresentados pelo setor das telecomunicações aos operadores de serviços, conectividade e conteúdo. Basicamente, este conceito eliminou as principais limitações das redes de teleco-municações existentes na época. O que antes era tratado como sendo voz, dados ou vídeo de forma autónoma e com fronteiras de atuação bem definidas, passaram a ser unificados dando forma e visão sobre o futuro das NGN garantindo maior capacidade de adaptação dos serviços prestados de acordo com a variação ou limitação de dispositivos e tecnologias de forma a atender o mercado no momento adequado, garantia de QoS das redes no que se refere a transmissão extremo-extremo, segurança, redução de custos, mobilidade generalizada entre os sistemas de redes fixas e móveis com a capacidade dos utilizadores poderem comunicar e terem acesso aos seus serviços assinados independentemente das mudanças geográficas ou de tecnologia de acesso.

Em termos estruturais, o modelo de rede NGN combina diferentes tipos de acesso: Local Area Network (LAN), Metropolitan Area Network (MAN) e Wide Area Network (WAN), PSTN/ISDN e Internet com interfaces abertas e padronizadas. A intenção de suportar os dife-rentes tipos de rede e interfaces, faz com que a NGN venha a suportar difedife-rentes dispositivos com diferentes capacidades, criando desta forma um sistema verdadeiramente ubíquo e unifi-cador. A capacidade de unificação dos serviços é suportada devido à sua estrutura de separa-ção formal entre as camadas de transporte, controle, serviços como mostra a figura 2.4.1 [21].

11

Figura 2.4.1 - Modelo funcional geral NGN

A camada de transporte tem a função de fornecer conectividade para os terminais da rede, ou seja, transferência de media, controlados diretamente por switch, roteador e media gateway responsáveis pelo tratamento do sinal entre a rede do utilizador para outras redes (PSTN/ISDN, Internet). Sendo que também, a camada de transporte e acesso endereçam as necessidades de QoS extremo-a-extremo desejáveis nas redes NGN. Nesta mesma camada, estão os media server responsáveis pelo processamento da media: gravação, texto para voz, etc.

A camada de controle tem a função de interpretar os números “discados” pelos utilizadores, acompanhar e controlar o estabelecimento de sessão/chamada, além de deter tarefas relacio-nadas com a tarifação e disparos de serviços.

A camada de serviço permite às operadoras ofertar novos e múltiplos serviços aos utilizadores (videoconferência, voz sobre IP, streaming entre outros) [22].

12

2.5 IP Multimedia Subsystem (IMS)

O IMS é uma arquitetura de controle de serviço e conectividade IP que permite a integração de diferentes tipos de serviços multimédia a utilizadores finais utilizando protocolos comuns da Internet [7].

O IMS foi originalmente concebida pelo organismo 3GPP [20] em 2005 e, desde então, tor-nou-se a arquitetura preferencial para suportar um conjunto de serviços de telecomunicações, fazendo convergência sobre diferentes acessos de forma eficiente, segura, fiável e com flexi-bilidade de taxação. Esta convergência, permite o desenvolvimento de serviços básicos e fun-cionalidades inovadoras que podem variar desde uma simples chamada de voz entre compu-tador e terminais móveis a uma vídeo conferência entre vários dispositivos com diferentes capacidades [23].

Para tal, utiliza extensivamente protocolos definidos pela Internet Engineering Task Force (IETF) [24], especificamente o SIP [25], para a gestão de sessão, e outros protocolos como Domain Name System (DNS) [26] e Diameter [27] para suportar serviços multimédia.

Neste contexto a arquitetura IMS surge com duas abordagens: tecnológica e comercial. Do ponto de vista tecnológico, apresenta-se como o elemento-chave da convergência tecnológica com suporte de QoS a novos serviços multimédia e com acesso ubíquo através da Internet. Do ponto de vista comercial, apresenta-se como a solução para gerar receitas às operadoras, atra-indo serviços providos por terceiros sem que se perca o controle da rede [7], como mostra a figura 2.5.1.

13

Figura 2.5.1 - Arquitetura IMS [7]

A arquitetura IMS tem um núcleo bem definido para suporte de ambientes fixos e móveis, estruturado para o fornecimento de diversos conteúdos e serviços a qualquer tipo de acesso e gestão de sessões baseadas em SIP. Esse gerenciamento de sessão é implementado pelas fun-ções controle de estado de chamada (CSCF) [28] e Home Subscriber Service (HSS) [29].

O HSS Possui a base de dados dos utilizadores. O HSS permite o acesso a outros servidores através das funções de autenticação, autorização e localização de utilizador. O CSCF funciona como um servidor SIP incumbido por controlar e garantir todas as mensagens SIP e registro dos terminais SIP – User Equipament (UE).

Importante ressaltar que o 3GPP não padroniza os nós, mas sim as funcionalidades. Isso signi-fica que a arquitetura IMS é uma coleção de componentes ligados por interfaces e normas abertas [12]. Podendo estes componentes estarem provisionados no mesmo servidor ou fica-rem distribuídos em diversos servidores, dependendo da carga e dimensão da rede. Como to-dos os componentes são baseato-dos em normas abertas, como Diameter e SIP, torna-se bastante fácil usar vários componentes de diferentes fornecedores. Esta possibilidade de várias combi-nações é um dos maiores atrativos da arquitetura IMS – a sua interoperabilidade.

14 A figura 2.5.2 fornece uma visão geral dos componentes e interface da arquitetura IMS. Não incluindo todos os componentes, mas tipicamente os mais relevantes [30], sendo os seus com-ponentes e interfaces (tabela 2.5.1) descritos em seguida.

Figura 2.5.2 - Componentes e interfaces IMS

Call Session Control Function (CSCF)

O CSCF é a parte fundamental da arquitetura IMS [7]. O componente CSCF é dividido em três componentes:

 Proxy CSCF (P-CSCF) – É primeiro ponto de contato entre um UE e uma rede IMS. As principais funções do P-CSCF são o encaminhamento de pedidos SIP, validação dos pedidos SIP, segurança e compressão de mensagens;

 Interrogation CSCF (I-CSCF) – Fica localizado na rede originária (home network) do UE. É o elemento de ligação entre P-CSCF e o S-CSCF, tendo como função funda-mental a consulta do HSS;

 Serving CSCF (S-CSCF) – Fica localizado na rede originária do UE. É responsável por gerir o controle de sessão, autenticação, disparos de serviços e chamadas SIP.

15

Tabela 2.5.1 - Descrição das Interfaces IMS

Interface IMS Protocolos

Gm UE, P-CSCF SIP Mw P-CSCF, I-CSCF, S-CSCF ISC S-CSCF, I-CSCF, AS Cx I-CSCF, S-SCF, HSS Diameter Sh SIP AS, HSS

2.6 Protocolos

Este subcapítulo não fornece uma descrição completa dos protocolos. Em vez disso, ele tenta apontar os aspetos importantes dos mesmos quando aplicados ao IMS.

Session Initiation Protocol (SIP)

O SIP [25] é um dos principais protocolos de sinalização e elemento permanente da arquitetu-ra IMS proposto paarquitetu-ra iniciar, modificar e encerarquitetu-rar uma sessão de utilizador intearquitetu-rativa que en-volve elementos multimédia, como vídeo, voz, mensagens instantâneas em uma rede IP. O SIP funciona complementarmente com outros protocolos tais como: Real-time Transport Pro-tocol (RTP) [31], Session Description ProPro-tocol (SDP) [32], entretanto não depende de ne-nhum deles para o seu funcionamento. Devido à sua simplicidade e extensibilidade, o SIP foi escolhido como o principal protocolo da arquitetura IMS.

A especificação do protocolo SIP define um conjunto de entidades: User Agents (UAs) e ser-vidores intermediários (Location Server, Proxy Server e Redirect Server).

 UA - são terminais SIP que podem atuar tanto como User Agent Client (UAC) quando inicia a comunicação com seu SIP Proxy enviando um pedido (INVITE), ou User Agent Server (UAS) quando recebe um pedido BYE;

 Location Server - é a entidade que recebe pedidos de registro de um UA e atualiza a base de dados de terminais com eles;

16  Proxy Server - é a entidade que recebe pedidos de ligação de um UA e transfere-o para outro servidor Proxy se a estação em particular não estiver no mesmo domínio de ad-ministração;

 Redirect Server - é entidade que recebe pedidos de ligação e envia-os de volta ao emissor incluindo os dados de destino em vez de enviá-los diretamente à parte chama-da.

Os servidores intermediários são meramente entidades lógicas, podendo perfeitamente estar disponíveis em um único servidor (Proxy Server). A figura 2.5.3 descreve uma configuração típica de rede, denominada "SIP trapézio". Por onde o SIP UA ou terminal é o ponto final dos diálogos: envia e recebe solicitações e respostas SIP, é o ponto final dos fluxos multimédia, e geralmente é o terminais do utilizador (UE), que é um aplicativo em um terminais ou um dis-positivo de hardware dedicado.

17

Session Description Protocol (SDP)

O SDP é um protocolo da camada de aplicação destinado a descrever sessões multimédia para efeitos de anúncio de sessão, convite à sessão e outras formas de iniciação da sessão multimé-dia. Foi definido na Request for Comments (RFC), RFC3264 [32].

O SDP fornece uma representação normalizada para tais informações, independentemente de como essas informações são transportadas. O SDP é apenas um formato para a descrição da sessão não incorpora um protocolo de transporte, e destina-se a usar diferentes protocolos de transporte, conforme apropriado, incluindo SIP e Hypertext Transfer Protocol (HTTP).

Uma mensagem SDP contém três níveis de informação:

 Session-level description – inclui o identificador de sessão, endereço IP, assunto, in-formações de contacto sobre a sessão e outros;

 Timing description – informa tempo de início e paragem, tempos de repetição, um ou mais níveis de media;

 Media type and format – informa sobre protocolo de transporte utilizado, informações de conexão, largura de banda, chave de criptografia, entre outros.

Real Time Protocol (RTP)

O RTP é um protocolo de transporte para aplicações em tempo real. Fornece funções de transporte de rede extremo-a-extremo adequadas para aplicações que transmitem dados em tempo real, como dados, áudio e vídeo. Definido na RFCs RC3550 [31]. Ele usa User Data-gram Protocol (UDP) como um protocolo de transporte, e o Real Time Control Protocol (RTCP) como protocolo auxiliar.

Basicamente o protocolo RTCP provê informação de retorno sobre a qualidade da receção como Round Trip Time (RTT), latência e perda de pacotes. É comummente usado para gerar relatórios da qualidade da ligação.

18

Diameter

O Diameter é um protocolo definido na RFC 6733 [27] e destina-se a fornecer serviços de Authentication, Authorization and Accounting (AAA) para aplicações tais como o acesso à rede, em situações locais ou mobilidade de utilizadores.

O protocolo Diameter está dividido em duas partes: o protocolo base (Diameter Base Proto-col) e as aplicações (Diameter Applications). As aplicações são especificadas separadamente. Algumas aplicações com especificação em curso buscam atender IP móvel (Diameter for Mo-bile IP), controle de tarifação pré-paga (Diameter Credit Control) e integração com o protoco-lo SIP (Diameter SIP Application). No contexto da arquitetura IMS, as duas extensões de in-teresse são a integração com o protocolo SIP e o controle de tarifação pré-paga [33].

Domain Name Server (DNS)

O DNS [34] é uma base de dados distribuída que contém os nomes alfanuméricos e seus cor-respondentes endereços IP de cada sistema registrado em uma rede (TCP/IP), como a Internet ou IMS. Os nomes alfanuméricos, mais conhecidos como nomes de domínio, são de natureza hierárquica, onde país, empresa, departamento e até mesmo um nome de nó podem ser identi-ficados. O DNS é um dos componentes essenciais para o funcionamento do IMS. Usualmente ele guarda informações do I-CSCF (usando NAPTR e tipo SRV de registros DNS), para que servidores remotos possam encontrá-lo e usá-lo como um ponto de encaminhamento (por exemplo, registrando) para pacotes SIP para este domínio [35].

SIP Server DHCP Option 120

O DHCP [36] é um protocolo de rede utilizado em redes IP para distribuir dinamicamente parâmetros de configuração de rede, como endereços IP para interfaces e serviços.

Especificado na RFC3361 [37], permite que terminais SIP localizem um servidor proxy SIP para se autenticarem. A opção 120 carrega uma lista de nomes de domínio ou IP do servidor

19 SIP, podendo conter vários nomes de domínio separados por ponto e virgula (;). Cada nome de domínio tem um registro de ponteiro de nomeação (NAPTR) que difere de qualquer outro. O UE tenta os registros na ordem listada, conforme especificado até descobrir o seu ponto de acesso SIP.

A figura 2.6.2 representa o parâmetro Option 120 a ser adicionado na configuração de um servidor DHCP Linux.

Figura 2.6.2 - SIP Server DHCP Option 120

2.7 Aplicações IMS

OpenIMS Core

O OpenIMS Core [6] consiste numa plataforma de código aberto, capaz de prover um ambi-ente de desenvolvimento e prototipagem de uma rede IMS, contemplando os principais com-ponentes da rede IMS - CSCFs e HSS. O OpenIMS Core em sua configuração, se assemelha a futuras redes IMS no nível de detalhe necessário e permite produzir os primeiros resultados de desempenho do IMS.

A principal motivação no desenvolvimento do OpenIMS Core, liderada pelo Instituto Fraunhofer FOKUS, foi fornecer um ambiente de referência básica do IMS adequada para testes de componentes para redes de próxima geração IMS, prototipagem de aplicativos IMS para fins de pesquisas. O OpenIMS Core é inteiramente baseado no software popular da co-munidade Open Source (SIP Express Route - (SER) ou MySQL).

20

Figura 2.7.1 - Elementos da arquitetura IMS disponibilizado pela FOKUS [6]

Kamailio IMS

O Kamailio (sucessor do antigo OpenSER e SER) [38] é um servidor SIP de código aberto lançado sob licença GPL, capaz de lidar com milhares de chamadas por segundo. O Kamailio pode ser usado para construir grandes plataformas para VoIP e comunicações em tempo real – presença, WebRTC, mensagens instantâneas e outras aplicações. Além disso, ele pode ser facilmente usado para escalar gateway SIP para PSTN, sistemas PBX ou servidores de media como Asterisk, FreeSWITCH ou SEMS.

Entre todos estes recursos poderosos está o seu suporte a extensões IMS para controle de ses-são de chamada P-CSCF, I-CSCF e S-CSCF.

21

Asterisk

O Asterisk é um software livre, de código aberto, que implementa em software os recursos encontrados num Private Branch eXchange (PBX) convencional, utilizando tecnologia de VoIP. Ele foi criado pelo Mark Spencer em 1999.

O Asterisk utiliza protocolos abertos tais como SIP, Media Gateway Control Protocol (MGCP) e Inter-Asterisk eXchange (IAX) para realizar a sinalização das chamadas telefôni-cas na rede TCP/IP.

É possível utilizar o Asterisk como:

 Media gateway - Entre a PSTN e a rede IP (fazendo uso de hardware especial).

 Media server - Tocando mensagens pré-programadas ou com interatividade via DTMF, como música de espera ou menu de atendimento.

 Correio de voz - Permitindo gravar recados

 PBX IP - Fazendo controle de encaminhamento de chamadas intra e inter-terminais.

Terminais IMS

Os terminais para IMS podem variar de terminais com suporte a um ou vários registros, su-porte a chamadas de voz, vídeo, mensagens e presença, IPTV. O UE IMS deve suportar AKAv1 / 2-MD5 autenticação, sinalização IMS SIP (PRACK, pré-condição) e chamadas de voz. Os terminais IMS avançados devem suportar chamadas de voz e vídeo, mensagens e pre-sença, livros de endereços, funcionalidades de segurança avançadas. Até agora, existem vários projetos de código aberto que estão trabalhando no desenvolvimento de clientes IMS.

IMSDroid

O IMSDroid [39] é o primeiro terminais IMS 3GPP de código aberto com suporte completo para dispositivos Android (1.5 e posterior). A versão atual do IMSDroid implementa

parcial-22 mente as especificações da versão 3 do GSMA Rich Communication [40] Suite e do One Voice profile V1.0.0 (LTE, também conhecido como GSMA VoLTE).

Figura 2.7.2 - IMSDroid Client

Boghe IMS Client

Boghe IMS Client [41], [42], é um terminal IMS projetado especialmente para usar em con-junto com o Fraunhofer FOKUS Open IMS Core. É executado no sistema operacional Win-dows e é muito fácil de configurar e utilizar. Suporta chamadas de voz, mensagens instantâ-neas, e vídeo chamada.

23

Figura 2.7.3 - Boghe IMS Client

X-Lite SIP Client

O X-Lite [43] é o terminais baseado em SIP distribuído de forma livre e comercial pelo Coun-terPath.

24

Figura 2.7.4 - X-Lite softphone

O X-Lite possui todos os recursos padrão do telefone, incluindo linhas, mute, não perturbe, áudio e videoconferência de seis linhas e assim por diante.

No entanto, ele também tem alguns recursos e funções aprimorados que tornam o X-Lite po-pular softphone no mercado.

 Mensagens instantâneas e presença usando o protocolo SIMPLE;  Configuração “Zero touch”;

 Deteção de "toque zero" para detetar a largura de banda que o computador de um utili-zador pode acessar;

25

3. Desenho e Implementação da Solução

Propos-ta

Uma vez analisado o panorama existente das tecnologias na área de IMS, e explorado as várias aplicações código aberto disponíveis no momento, que possam responder adequada-mente aos objetivos definidos da dissertação, é chegada a altura de definir a arquitetura da solução proposta e os seus requisitos de implementação.

3.1 Arquitetura da Solução Proposta

A figura 3.1.1, demostra a perspetiva global da solução da arquitetura proposta, tendo como ponto de atenção, o acesso com terminais de baixo custo, preferencialmente terminais com suporte ao sistema operativo Android por serem tipicamente os mais económicos [44], equi-pados com softphone – IMSDroid (podem ser utilizados diferentes tipos de terminais), e a interoperabilidade com outros domínios (IMS, SIP e PSTN).

26 Nesta arquitetura, os terminais são ligados através de uma Wi-Fi (porém, sem restrição para outras tenologias de acesso - e.g: Ethernet) ao ponto de acesso – P-CSCF (instalado no raspberry pi 3) mais próximo do utilizador. O P-CSCF por sua vez, estará ligado aos restantes elementos CSCF da arquitetura IMS que estabelecerá a ligação entre os vários domínios (IMS, SIP, PSTN).

3.2 Requisitos de Implementação

Para a implementação da solução proposta não serão necessários grandes requisitos em ter-mos de hardware. Neste sentido, no âmbito dos objetivos da dissertação considerou-se vanta-josa a utilização conjunta do OpenIMS Core e do Kamailio IMS. Esta opção deveu-se ao fac-to de ser uma solução implementada por software de código aberfac-to e economicamente viável, capazes de prover todos os elementos do núcleo da rede IMS nomeadamente o CSCF, HSS, SIP AS. Ambas plataformas, podem ser implementados em algumas variedades do sistema operativo GNU/Linux. Os seus pacotes “tarballs” podem ser encontrados no sitio de cada pro-jeto através de repositórios Subversion [45]. Como já mencionando anteriormente a 3GPP [20] não especifica um hardware mínimo. Normalmente, qualquer arquitetura x86_64 generic com 2.4GHz e 1GB de memória RAM deve ser o suficiente para compilar e instalar os módu-los adicionais e bibliotecas do IMS para ensaios mínimos de voz (registo, envio e receção de chamadas).

A distribuição GNU/Linux definida para a instalação do servidor foi a Debian8, esta seleção está relacionada com a estabilidade do sistema operacional e a familiaridade do desenvolve-dor do trabalho com o ambiente.

A implementação da solução proposta fora realizada, recorrendo-se à tecnologia de virtualiza-ção, utilizando-se para isso o VMWare Esxi [46].

Além das máquinas virtualizadas, utiliza-se um Raspberry Pi3 [47] com Kamailio IMS para o ponto de acesso à rede IMS como definido na arquitetura da solução proposta (figura 3.2.1).

27 O Raspberry Pi, é um dispositivo de pequeno porte com todo o hardware inserido numa única placa e todo o restante hardware é constituído com peças não muito evoluídas, mas que per-mitem o bom funcionamento do sistema.

O Raspberry Pi ganhou rapidamente popularidade devido a seu baixo custo, robustez para alguns projetos de Internet of Things (IoT) e facilidade de instalação abre possibilidades mui-to interessantes que poderá vir atender os nossos objetivos como ponmui-to de acesso de terminais moveis IMS/SIP, assegurando também a funcionalidade de um dispositivo P-CSCF, como indicado na Tabela 3.2.1.

Figura 3.2.1 - Raspberry Pi 3

Tabela 3.2.1 Especificação dos equipamentos utilizados

EQUIPAMENTO ESPECIFICAÇÃO FUNÇÃO S.O VM_DNS_Debian IntelR© Core 1CPU T6600, 2.4GHz, 1GB

RAM DNS, DHCP 120 Debian 8

VM_IMS_Debian IntelR© Core 1CPU T6600, 2.4GHz, 1GB

RAM S-CSCF, ICSCF, HSS Debian 8 Raspberry Pi 3 Broadcom 1.2GHz 64-bit quad-core ARMv8

CPU, 1 GB de RAM P-CSCF Raspbian PC_Windows 7 IntelR© Core 1CPU T6600, 2.4GHz, 1GB

RAM Boghe IMS / X-Lite Windows 7 Samsung S6 2100 MHz, Quad-core Cortex-A53 IMSDroid Android

28

3.3 Implementação da Solução Proposta

Uma vez definida a arquitetura da solução proposta e os requisitos, é chegada a vez da sua implementação. Será com esta implementação que serão efetuados os testes necessários de forma a avaliar a operação e desempenho da solução proposta.

Para se evitar perder a perspetiva, a implementação pormenorizada dos diversos componentes da solução proposta é toda referida nos anexos (Anexo A) que constam no final da disserta-ção. Na sequência também estarão algumas ferramentas para testes e análise de desempenho da solução proposta.

A implementação do OpenIMS Core e do Kamailio IMS levanta um certo nível complexida-de, mas, contudo, encontra-se muito bem documentada, quer nos seus sítios Web [38], [48] como em vários sítios da Internet.

Descrição Genérica da Instalação

Partindo do princípio que se tenha o sistema operativo Linux instalado, começa-se por obter-se o código para respetiva compilação do OpenIMS Core. O OpenIMS Core é pré-configurado para funcionar a partir de um caminho de arquivo padrão. A instalação é vista no anexo A.

Instalação terminada, e o núcleo IMS fica disponível pelo endereço web em http://localhost: 8080/hss.web.console.Com o login 'hssAdmin' e senha ‘hss’.

O OpenIMS Core vem provisionado com alguns utilizadores de amostra por padrão. Um utili-zador "alice", cuja identidade pública é: alice@iscte.test. E o outro é 'bob', cuja identidade pública é: bob@iscte.test. Contudo, adicionou-se um novo utilizador que cuja sua identidade pública é "dsilva", e estes utilizadores podem ser verificados na figura 3.3.1 do FHoSS.

29

Figura 3.3.1 - Utilizadores do FHoSS

A figura 3.3.2 mostra a interface web para configuração de utilizadores no FHoSS.

Figura 3.3.2 - Perfil de utilizador

Portanto, o capítulo que se segue, irá cobrir a parte dos testes de configuração dos terminais SIP/IMS e da plataforma o seu todo, para o nosso melhor entendimento.

31

4. Teste e Analise de Desempenho da Solução

Este capítulo será inteiramente dedicado ao processo de testes de funcionalidade e desempe-nho da solução proposta. como definido na fase 3 dos objetivos do trabalho. Desta forma, foram definidos dois cenários de testes. Primeiramente são apresentados testes de registro, chamada, interoperabilidade de serviço IMS/SIP e PSTN, incluindo os seus respetivos testes de qualidade de transmissão em todos os cenários. Por fim, a avaliação de desempenho, com atenção ao P-CSCF provisionado pelo Raspberry Pi.

4.1 Registro e Interoperabilidade SIP/IMS

O objetivo aqui é essencialmente verificar o comportamento do sistema fase a pedidos de re-gistos e realização de chamadas. Portanto, serão realizadas algumas experiências para nos certificarmos de que toda as funcionalidades necessárias encontram-se disponíveis, tanto para o cliente IMS ou Cliente SIP.

Neste caso, todas as funcionalidades devem ser cumpridas tendo em conta as seguintes etapas:  Etapa 1: Registro e ligação entre utilizadores do domínio IMS;

 Etapa 2: Interoperabilidade entre utilizadores SIP e IMS;  Etapa 3: Interoperabilidade com outros domínios IMS;

Etapa 1 - Registro e ligação entre utilizadores do

domínio IMS

Para o utilizador poder interagir com os serviços da rede tem de estar registado na rede. Dada a necessidade económica e mobilidade (transferência entre P-CSCF) identificada na motiva-ção do trabalho, é selecionado o terminal IMSDroid como preferencial por razões de que, facilmente um utilizador, teria em sua posse um dispositivo Android [44]. Dependendo da

32 preferência de cada utilizador, outros UEs podem ser configurados numa forma equivalente à explicação mais abaixo.

Figura 4.1.1 - Parâmetro de configuração do terminal IMS

O processo de registro começa pelo envio de um pedido SIP REGISTER (figura 4.1.2) do UE para a rede IMS, concretamente o P-CSCF, que por sua vez encaminha a solicitação para o I-CSCF que consulta o HSS para à indicação de possíveis S-I-CSCF. Com base a indicação rece-bida, o I-CSCF identifica o CSCF apropriado para as características do utilizador. Com o S-CSCF identificado, o I-S-CSCF encaminha o mesmo pedido para o S-S-CSCF, que responde com uma mensagem SIP 401 Unauthorized. Nesta altura, desencadeia-se um desafio digest para o UE, que reformula o seu pedido SIP REGISTER.

33 O UE envia um novo pedido SIP REGISTE (figura 4.1.3) dessa vez incluindo o parâmetro de identidade privada (e.g credenciais). Com este novo dado, o S-CSCF faz uma correlação de parâmetros, dentre o pedido recebido pelo I-CSCF com as informações do perfil do utilizador existente no HSS. O S-CSCF verifica a resposta digest e responde com um SIP 200 OK quan-do a verificação for bem-sucedida, informanquan-do para o I-CSCF que por sua vez informa o P-CSSF, que o utilizador está registado.

Figura 4.1.3 - Registro IMS - fase de validação de registro

Etapa 1.1 - Chamada entre utilizadores do mesmo

domínio IMS

Neste momento, com o utilizador registado, outro teste semelhante é efetuado para testar liga-ções entre os UE. O utilizador convidará outro utilizador da rede IMS para uma chamada com o envio de um pedido SIP INVITE.

Na figura que se segue (figura 4.1.4), podemos observar o procedimento de sessão de chama-da entre dois utilizadores do mesmo domínio IMS, onde o utilizador <sip:dsilva@iscte.test> origina a chamada com o envio do pedido INVITE para o utilizador <sip:alice@iscte.test> usando a sua identidade pública. Neste momento é disparado uma sequência de métodos (mensagens de sinalização SIP). Como o pedido é encaminhado para o mesmo domínio IMS

34 “iscte.test”, logo o P-CSCF já sabe quem é o S-CSCF para os utilizadores. O S-CSCF para os utilizadores fora obtido na ocasião do pedido SIP REGISTE (ver a fase 14,15,16 da figura 4.1.3). Assim sendo, o P-CSCF encaminha a mensagem para o S-CSCF, que por sua vez pro-cessa o pedido com base no destino do Request-URI definido por <sip:alice@iscte.test>, co-mo o S-CSCF é o servidor SIP da rede local, tanto para o chamador e o chamado, responde ao pedido INVITE sem a necessidade de participação de outros elementos IMS (I-CSCF e HSS).

35

Figura 4.1.5 - Teste real de chamada entre dois terminais IMS

A ligação entre os dois utilizadores foi testada com sucesso, a partir do IMSDroid e Boghe IMS. Como isso tem-se o primeiro requisito da dissertação cumprido. De forma a testar a qua-lidade de comunicação entre os UE, recorreu-se ao Wireshark para analise dos pacotes RTP mediante ao uso dos codecs GSM e G.711.

O uso do GSM chegou a “33,37” milissegundos (ms) de Jitter (variação do atraso entre paco-tes sucessivos de dados), e “162.92” ms de latência, porém sem registro de perda de pacopaco-tes (figura 4.1.6).

Ao nível dos fluxos RTP, o codec G.711 apresentou um Jitter de “8,38” ms e uma latência de “83,42” ms sem perdas de pacotes (figura 4.1.7).

Segundo a recomendação G.114 da ITU-T [49], para que possamos obter uma boa qualidade de voz, a transferência de pacotes RTP não deveria ultrapassar os 150 ms de latência, possuir

36 o Jitter abaixo dos 20 ms e uma perda de pacotes inferior a 3%. Pelo que então, o codec G.711 afigurou-se o mais indicado.

37

Figura 4.1.7 - Jitter e Latência_Codec G.711 (de cima para baixa)

Etapa 2 - Interoperabilidade IMS e SIP

A segunda etapa foi projetada de forma a testar a interoperabilidade entre utilizadores em terminais IMS e SIP. Neste contexto, acredita-se que em algum momento seja necessário o uso de um terminal ou até mesmo a interoperabilidade entre outros domínios IMS e SIP. Nes-te caso, para realização dos Nes-tesNes-tes e inNes-tegração IMS e SIP, utilizou-se o Nes-terminal VoIP não IMS X-lite e modificou-se o S-CSCF (scscf.cfg) e o HSS para suportar o algoritmo de auten-ticação MD5 no cabeçalho Authorization do pedido REGISTER.

38 Antes de alterar. #modparam("scscf","registration_default_algorithm","MD5") #modparam("scscf","registration_default_algorithm","AKAv2-MD5") modparam("scscf","registration_default_algorithm","AKAv1-MD5") Depois de alterar. modparam("scscf","registration_default_algorithm","MD5") #modparam("scscf","registration_default_algorithm","AKAv2-MD5") #modparam("scscf","registration_default_algorithm","AKAv1-MD5")

Em todo caso, o método de funcionamento é em tudo semelhante ao descrito no processo de registro de utilizador IMS como visto na etapa 1, ficando apenas a diferença de que, em caso de não haver mudança de algoritmo, o HSS responderá para o S-CSCF diante da solicitação de autenticação para posterior desafio digest ao utilizador IMS (processo 5 – 8 da figura 4.1.2) com uma mensagem de erro 403 forbidden hss user unknown (figura 4.1.8), indicando que por agora não é somente uma questão de credências (401 Unauthorized) mas do esquema de autenticação não suportado.

Figura 4.1.8 - 403 Forbidden - utilizador do HSS desconhecido

Portanto, a partir da mudança de autenticação ao S-CSCF e o HSS a sessão passa a ser estabe-lecida com sucesso entre os utilizadores de IMS e SIP (figura 4.1.9).

39

Figura 4.1.9 - Interoperabilidade entre utilizador IMS e SIP

Portanto, para verificar a qualidade na comunicação entre terminais IMS e SIP, utilizou-se o mecanismo descrito anteriormente. Recorreu-se ao Wireshark para analise dos pacotes RTP mediante o uso dos codecs G.711 e GSM. A figura 4.1.10 apresenta o resultado da comunica-ção utilizando-se o codec G.711 nos terminais. Foi verificado neste caso, uma variacomunica-ção do jitter de “37,10” ms com “225,93” ms de latência e perdas de pacotes de 0,3%.

40

Figura 4.1.10 - Jitter e Latência IMS para SIP_Codec G.711

Quanto ao uso do codec GSM representado na figura 4.1.11, verificaram-se variações superio-res tanto pelo jitter “58,73” ms, latência “674,34” ms e em perdas de pacotes 0,16%.

41

Figura 4.1.11 - Jitter e Latência IMS para SIP_Codec GSM

Etapa 3 - Interoperabilidade entre domínios IMS

Neste caso foi testada a interoperabilidade entre domínios, sendo projetados dois domínios IMS de forma a provar o correto funcionamento entre utilizadores de domínios IMS diferen-tes. Portanto todo o processo de registro é semelhante ao anteriormente descrito. ficando ape-nas a diferença de que agora tem-se o problema de Network Address Translation (NAT) por resolver. NAT é a técnica pelo qual os endereços IP são mapeados de um domínio para outro em uma tentativa de fornecer roteamento transparente para terminais.

No cenário em questão (figura 4.1.13), os terminais do domínio IMS “iscte.test” não podem contatar o terminal do domínio IMS “net1.test” e vice-versa. Para tal, colocou-se uma

fi-42 rewall/SBC que fornecesse serviços de demarcação, segurança e interoperabilidade entre os domínios. De seguida, adicionou-se em cada HSS o domínio remoto como rede visitada.

Figura 4.1.12 - Configuração de Rede Visitada

Assim sendo, as mensagens enviadas de um domínio passaram a alcançar o destinatário pre-tendido.

Figura 4.1.13 - Interoperabilidade entre domínios IMS

Portanto, para verificar a qualidade na comunicação entre diferentes domínios IMS, utilizou-se o mecanismo descrito anteriormente. A partir da utilização do codec GSM, pode-utilizou-se verifi-car na figura 4.14, uma variação do jitter de “32,85” ms, uma latência “318715,79” ms e per-das de pacotes de 74,84%.

43

Figura 4.1.14 - Jitter e Latência_GSM

Neste cenário (figura 4.1.15) o uso do codec G.711, apresentou-se ligeiramente mais baixo que o anterior cenário (figura 4.1.14), com jitter de “156.30” ms com “12,68” ms de latência e sem perdas de pacotes.

44

Figura 4.1.15 - Jitter e Latência_G.711

4.2 Interoperabilidade IMS e PSTN

Para realização dos testes com a rede PSTN, foi adicionado ao cenário um servidor Asterisk como Application Server (AS) para garantir a interoperabilidade da rede IMS com a PSTN (figura 4.1.16).

45

Figura 4.2.1 - Interoperabilidade IMS PSTN

Começou-se por registar um utilizador no Asterisk de forma a testar o correto funcionamento. Após o utilizador estar registado, foi possível iniciar uma chamada para um utilizador do mínio IMS. Outro teste semelhante foi efetuado para testar chamadas de um utilizador do do-mínio IMS para o utilizador do Asterisk. No entanto, esta tentativa não teve o resultado dese-jado devido a inconsistências de roteamento e registro SIP [50] do OpenIMS Core. Embora tenham sido tomadas medidas para minimizar esse problema na Etapa 2 (Interoperabilidade IMS e SIP), não foi suficiente para garantir a compatibilidade atual entre IMS e PSTN, as chamadas foram testadas sem sucesso, sendo que a solicitação INVITE não alcançava o desti-no retornando a mensagem 402 Bad extension.

4.3 Avaliação de Desempenho

A tarefa neste subcapítulo consiste em avaliar a capacidade e o desempenho do Raspberry Pi enquanto terminal P-CSCF, de modo a saber-se o número máximo suportados de chamadas ponto a ponto. Para tal, escolheu-se o SIPp [51] como sendo a ferramenta para testes, pois é muito poderosa, flexível e livre, para que possamos enviar todos os tipos de mensagem RFC3261 [25].

O SIPp possui internamente um User Agent Client (UAC) e um User Agent Server (UAS) incorporado que serão executadas no Raspberry Pi para testar o P-CSCF em condições de

46 carga. O UAC é o agente cliente que inicia a sinalização para o UAS, e o UAS é o agente ser-vidor que responde a sinalização SIP.

Figura 4.3.1 - Fluxo de chamada do UAC e UAS

Teste SIPp sem media

Portanto, por tratar-se de um ambiente controlado, deu-se início aos testes já com taxas eleva-das. Como tal, decidiu-se começar com o envio de 100 chamadas por 10 segundos do UAC (192.168.1.12:5061) ao UAS (192.168.1.12:5067). Uma vez que as funções de UAC e UAS estão a ser executados no Raspberry Pi, atribuiu-se para o UAC a porta 5061 para sinalização SIP e para o UAS a porta 5067 para a sinalização SIP.

sipp -sn uac 192.168.1.12:5067 -r 100 -rp 10000 -i 192.168.1.12 -p 5061 sipp -sn uas -i 192.168.1.12 -p 5067

47

Figura 4.3.2 - SIPp INVITE

O teste efetuado teve a duração aproximadamente de 21 minuto (min). A variável utilizada para testar a carga do sistema foi o número máximo de chamadas em simultâneo por segundo (call rate) igual a 100 cps, especificado na linha de comando “sipp” após o parâmetro -r, com tempo de chamada igual a 10000 ms, sendo também especificado na linha de comando “sipp” após o parâmetro -rp.

Portanto o valor encontrado como o número máximo de chamadas em simultâneo que o Raspberry Pi enquanto P-CSCF suporta, são tidos apenas com os valores “estáveis” máximos antes da saturação (Peak) de chamada. Assim sendo, o número de chamadas bem-sucedidas ou a caga máxima suportada encontrada foi de 30 cps. Sendo que foram enviadas ou proces-sadas 10 chamadas por segundo como pode ser observado na figura 4.3.2.

Importa referir, que neste primeiro teste de chamadas simultâneas, não é estabelecido real-mente uma conexão RTP e, portanto, o Raspberry Pi não é exposto a carga total no sistema.

48

Teste SIPp com media - RTP

Com base a experiência anterior, iniciou-se o teste em troca de media logo com uma taxa de chamada igual a 30 cps por 10 segundos para o utilizador dsilva.

sipp -sn uac -d 10000 -s dsilva@iscte.test 192.168.1.12 -l 30 -mp 5606

A figura 4.3.3 exibe o fluxo de chamadas, bem como algumas informações.

Figura 4.3.3 - SIPp RTP

49

Figura 4.3.4 - SIPp UAC Xlite

Os resultados dos testes de sinalização RTP utilizando o codec GSM e G.711 pode ser obser-vado na tabela 4.3.1 que se segue.

Tabela 4.3.1 - Taxa máxima de chamada suportada por codec

Codec Taxa Chamadas (cps) Taxa de tempo (ms) Taxa suportada (cps)

GSM 100 10000 8

G.711 100 10000 12

O que se percebeu, portanto, é que, com a sinalização de RTP o Raspberry Pi, teve como chamadas bem-sucedidas ou a carga máxima suportada em 12 cps, isso utilizando o codec G.711.

Portanto, foram considerados apenas os valores estáveis máximos antes da saturação (Peak) de chamada, para os quais não há retransmissão ou timeout de mensagens SIP. No entanto, pode haver perdas ao nível de pacotes RTP, devido à carga elevada do sistema. Entretanto, o

50 SIPp somente verifica se uma conexão RTP está estabelecida, mas não verifica a qualidade da mesma, sendo assim é prudente que seja feita uma chamada normal para verificar se a quali-dade é aceitável.

Desempenho do Raspberry Pi – P-CSCF

Os resultados obtidos através do Nagios demostram em termos gerais um pico de utilização do processador e da memória ao longo do estabelecimento de sessão.

A partir da figura 4.3.5 e 4.3.6, conclui-se que a utilização da CPU e memória aumentava consideravelmente quando se verificam pedidos INVITE. Após a sessão estar estabelecida, a utilização da CPU era reduzida, mas verificava-se uma ocupação total de memória aproxima-damente constante.

51

Figura 4.3.6 - Utilização de memória

Conclusões de Testes

Os testes da solução permitiram efetuar a sua caracterização em termos das funcionalidades dos componentes IMS, desempenho e capacidade do Raspberry PI. Foram testadas todas as funcionalidades da solução, comprovando-se o seu correto funcionamento. Embora condicio-nados pela dificuldade ou limitação de encaminhar as chamadas do IMS para a PSTN.

Em termos de taxa máxima de chamada suportada, os resultados obtidos indicam (ver tabela 4.1 se necessário) maior capacidade de processamento de chamada quando utilizado o codec G.711. Cada codec possui uma aplicação e ganho diferente, por isso, saber escolher pode fa-zer uma grande diferença. Em redes locais geralmente temos banda passante em abundância, de forma que o nível de compressão tem um peso pequeno na escolha do codec a ser utiliza-do. Nesse caso a melhor escolha passou a ser o G.711, que ocuparia cerca de 100kbps (inclu-indo o cabeçalho).

Contudo, a utilização do codec G.711 permitiu a realização de até 3 cps e ao Raspbery Pi uma taxa máxima de ligação igual a 12 cps, sendo que a taxa máxima de chamadas suportada fora atingida num período aproximado de 4 minutos de ligação.

52

53

5. Conclusões e Trabalho Futuro

5.1 Conclusões

Esta dissertação enquadrou-se na temática do IMS implementado em equipamentos de baixo custo, concretamente OpenIMS Core em Raspberry Pi.

Foram apresentados inicialmente os conceitos e tecnologias inerentes ao IMS, nomeadamente a sua arquitetura, os protocolos envolventes e projetos existentes como OpenIMS Core.

Foi com base neste projeto que se desenvolveu a arquitetura proposta para o fornecimento de serviços de telefonia utilizando componentes IMS, numa perspetiva de integração completa com as demais redes (SIP, Móvel e Fixa). Desta forma, deu-se início ao desenvolvimento da solução propriamente dita, utilizando o OpenIMS Core que por sua vez, não trouxe totais re-sultados a quando da sua instalação ao Raspberry Pi. Obrigando-nos a recorrer ao seu fork, Kamailio IMS para suprir incompatibilidade identificada do OpenIMS Core para Raspberry Pi na altura das primeiras experiências (2017). Com isso obtivemos o primeiro resultado do tra-balho, que consistia em prover serviços de telefonia utilizando recursos tecnológicos de baixo custo operacional, e para tal, recorreu-se ao Raspberry Pi como ponto de acesso P-CSCF.

Outra questão que se viu a cumprir no trabalho, foi à interoperabilidade entre utilizadores IMS e SIP. Portanto, esperava-se pela interoperabilidade com a rede publica – PSTN, mas infeliz-mente esta tentativa não teve o resultado desejado devido a inconsistências de roteamento e registro SIP do OpenIMS Core com a PSTN. Nos testes de interoperabilidade com a PSTN foi incorporado, um servidor Asterisk como Gateway, para facilitar o roteamento de chamadas IMS-PSTN. Chamadas vinda do Gateway para a rede IMS eram bem-sucedidas, mas o inver-so não foi possível garantir.