WIT Communications Application Server Plataforma interoperável para a convergência das telecomunicações

Transcrição

1 WIT Communications Application Server Plataforma interoperável para a convergência das telecomunicações WIT Software 2010 / Luís Gonçalo Henriques de Matos Mestrado em Informática e Sistemas Ramo de Desenvolvimento de Software Setembro 2011 Orientador ISEC: Professor Doutor João Cunha Supervisor Externo: Engenheiro Frederico Lopes

2

3 Bem aventurado o homem que encontra a sabedoria, e o homem que adquire conhecimento, pois ela é mais proveitosa do que a prata, e dá mais lucro do que o ouro. Provérbios 3:13 e 14 v

4

5 À minha querida Mãe, Maria, em especial, que me tem encaminhado e acompanhado ao longo da vida e dos momentos, a quem devo tudo aquilo que hoje sou, pelos seus exemplos de coragem e perseverança, à minha namorada, Ilanna, pelo amor, paciência, compreensão, carinho e apoio durante esta jornada. A vocês, dedico vii

6

7 Agradecimentos À minha família, pelo amor incondicional, apoio e incentivo na realização deste projecto. À minha namorada Ilanna, pelo seu amor, compreensão e paciência durante essa jornada. Aos meus amigos, que durante todo este tempo me acompanharam e me transmitiram força e confiança. Ao Professor Doutor João Cunha, o meu especial agradecimento, pela orientação, acompanhamento e pelos excelentes conselhos que sempre me deu. Ao Bruno Carvalho e ao Nuno Campos, pela paciência e dedicação na passagem de conhecimento para que pudesse prosseguir com este projecto. Ao Frederico Lopes, pelas orientações de gestão e pelo acompanhamento dado ao longo de todo o projecto. Ao Pedro Pereira, pelas instruções técnico-estratégicas dadas nos momentos decisivos. À WIT Software, por ter aceitado, apostado e confiado no meu trabalho. E por último, mas não menos importante, a toda a família WIT que, de um modo geral, criou todas as condições para que este projecto fosse possível. ix

8

9 Resumo Este documento descreve o trabalho realizado por Luís Matos no âmbito do estágio do Mestrado em Informática e Sistemas, Ramo de Desenvolvimento de Software. O estágio decorreu na WIT Software e teve duração de 10 meses. O Rich Communication Suite (RCS) é uma iniciativa da GSM Association (GSMA) que conta com o esforço colaborativo da indústria de telecomunicações, com mais de 100 operadoras, fornecedores de equipamentos e empresas de telecomunicações, com o objectivo de facilitar a introdução no mercado de aplicações móveis e a prestação de serviços que forneçam uma experiência de comunicação avançada, interoperável e convergente. O RCS define serviços e aplicações que introduzem listas de contactos que mostram dinamicamente a mudança de status de presença e as possibilidades de comunicação, e dispõe de diferentes opções de conversação. A WIT Software desenvolveu o WIT Communications Application Server (WCAS), um servidor inserido no WIT Communications Suite (WCS), destinado a fornecer serviços tanto a aplicações cliente como outros servidores na rede de uma operadora de telecomunicações. Devido à sua flexibilidade e modos de funcionamento pode integrar-se com a rede de telecomunicações bem como com os serviços já existentes na rede, estabelecendo e garantindo todas as comunicações necessárias entre aplicações cliente e servidores. Para garantir a interoperabilidade do WCAS com clientes e servidores numa rede de telecomunicações que siga os standards do RCS, foi necessário desenvolver e evoluir diversos módulos do WCAS para que este fique dotado dos meios necessários para poder ser integrado com quaisquer servidores e clientes de outras empresas que respeitem os mesmos standards. Foram realizados os testes de interoperabilidade definidos pelo RCS com recurso a servidores externos que seguem o mesmo standard e a clientes tanto do WCS como de outras empresas. Palavras Chave (Tema): RCS, Telecomunicações Móveis, Interoperabilidade Palavras Chave (Tecnologias): Java, Spring, Netty, SailFin, OCCAS, Wowza xi

10

11 Abstract This document introduces the work done by Luís Matos within the scope of the Master in Informatics and Systems, Software Development Branch. The internship took place at WIT Software during the past 10 months. The Rich Communication Suite (RCS) is a GSM Association (GSMA) initiative, which relies on the collaborative effort of the telecommunications industry, with over 100 mobile operators, device manufacturers and telecommunications companies, which aims to facilitate the rapid adoption of mobile applications and services providing an interoperable, convergent and rich communication experience. RCS defines services and applications that introduce contact lists showing dynamically changing of status and on-line capabilities and offers different messaging options. WIT Software developed the WIT Communications Application Server (WCAS), a server platform included in the WIT Communications Suite (WCS), intended to provide services to both client applications and other servers on a network of a telecom operator. Due to its flexibility and operating modes, it can be integrated with the telecommunications network and with existing services, providing and ensuring all the necessary communications between clients and servers. To ensure WCAS interoperability with clients and servers in a telecommunications network that follows the RCS standards, it was necessary to develop and fit out various WCAS modules so that it is endowed to be integrated with any server and client from other companies that comply with the same standards. The interoperability tests defined by RCS were performed using external servers that follow the same standards, and by application clients both from WCS and from other companies. Keywords (Subject): RCS, Mobile Telecommunications, Interoperability Keywords (Technologies): Java, Spring, Netty, SailFin, OCCAS, Wowza xiii

12

13 Índice Agradecimentos... ix Resumo... xi Abstract...xiii Índice... xv Índice de Figuras... xix Índice de Tabelas... xxi Notação e Glossário...xxiii 1 Capítulo I - Introdução Enquadramento Objectivos Motivação Riscos Projecto Negócio Organização do relatório Capítulo II - Rich Communication Suite Introdução O que é o RCS A motivação Como está organizado Release Release RCS-e Empresas intervenientes xv

14 2.6 Concorrentes Capítulo III - Requisitos Módulo de Chat Enhanced Messaging File Transfer Image Share Módulo de Capabilities Outros requisitos High Availability Integração na plataforma existente Roadmap Capítulo IV - Metodologia de trabalho Processo Sprints Monitorização Planeamento Equipa de projecto Validação e Testes Gestão da Informação Capítulo V - Tecnologia e Protocolos Tecnologia Protocolos Capítulo VI - Arquitectura Capítulo VII - Resultados Capítulo VIII - Conclusões Objectivos realizados Trabalho futuro Lições aprendidas xvi

15 Bibliografia Anexo 1 Competitors Analysis Anexo 2 WCAS Detailed Design Anexo 3 WCAS Chat Protocol Anexo 4 WCAS Chat Module Performance Report xvii

16

17 Índice de Figuras Figura 1 - Cenário WWC WCAS WWC. 4 Figura 2 - Cenário WWC WCAS Servidor SIP Externo WPC. 5 Figura 3 - Cenário WWC WCAS WPC. 5 Figura 4 - Gráfico Hours Burndown with Cumulative Flow. 38 Figura 5 - Gráfico Workitem Cumulative Flow. 39 Figura 6 - Product Backlog. 40 Figura 7 - Sprint Backlog. 41 Figura 8 Branch, merge e tag (release) do projecto. 43 xix

18

19 Índice de Tabelas Tabela 1 - Concorrentes do WCAS. 26 Tabela 2 - Roadmap das etapas e iterações do projecto. 33 Tabela 3 - Features implementadas por release. 36 Tabela 4 - Equipa de projecto. 41 xxi

20

21 Notação e Glossário 3GPP API BANIF BCP CDMA CGD CPIM EAB EDP F2S GSMA HTTP I&D IDE IM IMS IP IPTV J2ME JAIN JDBC JSR LTS 3rd Generation Partnership Project Application Programming Interface Banco Internacional do Funchal Banco Comercial Português Code Division Multiple Access Caixa Geral de Depósitos Common Presence and Instant Messaging Enhanced Address Book Energias de Portugal Flash To SIP Global System for Mobile Communications Association Hypertext Transfer Protocol Investigação e Desenvolvimento Integrated Development Environment Instant Messaging IP Multimedia Subsystem Internet Protocol Internet Protocol Television Java Platform Micro Edition Java APIs for Integrated Networks Java DataBase Connectivity Java Specification Request Long Term Support xxiii

22 MMS MMSC MSISDN MSRP NAB NIO OCCAS OMA PC PSTN RCE RCS RDBMS RIA SDP SIMPLE SIP SMS SMSC SVN SWQ TCP TV UDP UMTS Multimedia Messaging Service Multimedia Messaging Service Center Mobile Subscriber Integrated Services Digital Network Number Message Session Relay Protocol Network Address Book New Input Output Oracle Communications Converged Application Server Open Mobile Alliance Personal Computer Public Switched Telephone Network Rich Communication Ecosystem Rich Communication Suite Relational DataBase Management System Rich Internet Application Session Description Protocol Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions Session Initiation Protocol Short Message Service Short Message Service Center Subversion Software Quality Transmission Control Protocol Television User Datagram Protocol Universal Mobile Telecommunications System xxiv

23 WCAS WCS WMC WPC WWC XCAP XDMS XML Z2M2 WIT Communications Application Server WIT Communications Suite WIT Mobile Communicator WIT PC Communicator WIT Web Communicator XML Configuration Access Protocol XML Document Management Server Extensible Markup Language Zero Bugs, Zero Delays, Maximum Productivity, Maximum Customer Satisfaction xxv

24

25 1 Capítulo I - Introdução Este capítulo faz um enquadramento do estágio, apresentando os objectivos, a motivação para realizar este projecto e um breve resumo sobre a WIT Software, o Rich Communication Suite e o WIT Communications Application Server. 1.1 Enquadramento O estágio a que o presente relatório se refere foi realizado no WIT-Lab - departamento de I&D da WIT Software [1]. A WIT Software é uma empresa de software que desenvolve aplicações e serviços avançados na área das telecomunicações móveis. A empresa foi criada em 2001, tem Headquarters em Coimbra, dois centros de desenvolvimento, no Porto e Leiria, um escritório em Lisboa e uma filial em San Jose (California, US) para desenvolvimento de negócio. A empresa está organizada em 3 unidades de negócio: 1. Telco - Esta unidade faz desenvolvimento de software para operadoras de telecomunicações móveis e tem clientes na Europa, Estados Unidos e África. A unidade é ainda responsável pelo produto WIT Communications Suite, uma solução de software para convergência das comunicações móveis, comunicações fixas e da Internet; 2. Mobile - Esta unidade dedica-se ao desenvolvimento de aplicações para terminais móveis nas seguintes plataformas: iphone/ipad, Android, Blackberry, J2ME, Symbian. A unidade tem vários clientes na área da banca (BCP, CGD, BANIF), na área dos media (Impresa e Controlinveste) assim como alguns clientes internacionais, como é o caso da TomTom e da Real Networks; 3. Digital TV - Esta unidade é responsável pelo desenvolvimento de uma plataforma de widgets para TV cujo target são operadoras de cabo e IPTV. Tem clientes na Europa e Estados Unidos e tem expertise em desenvolvimento de software para Microsoft Mediaroom e OpenTV. A empresa tem uma forte ligação à Universidade de Coimbra e por este motivo é uma empresa com grande competência para actividades de I&D. O WIT-Lab é responsável Luís Gonçalo Henriques de Matos 1

26 por inovar, idealizar e exceder as expectativas para gerar novas soluções que possam trazer valor para o mercado. O WIT Communications Suite é um dos produtos desenvolvidos na empresa. Esta suite é composta por diferentes aplicações para diferentes plataformas: WIT PC Communicator; WIT Web Communicator; WIT Mobile Communicator; WIT Toolbar Communicator. As aplicações acima listadas são as aplicações clientes. A juntar a estas existe o WIT Communications Application Server (WCAS) que é um servidor de telecomunicações e é onde este estágio se foca. Este servidor é composto por um conjunto de módulos que permite fornecer serviços às aplicações do WIT Communications Suite (WCS) assim como a outras que sigam os mesmos standards. O desenvolvimento do servidor WCAS foi feito tendo em conta as normas existentes para que fosse possível integrá-lo com outros sistemas, como por exemplo, Short Message Service Center (SMSC), Multimedia Messaging Service Center (MMSC), Media Gateway, Authentication Server e Billing Systems. O Rich Communication Suite (RCS) é uma iniciativa da GSM Association (GSMA) que conta com o esforço colaborativo da indústria de telecomunicações, com mais de 100 operadoras, fornecedores de equipamentos e empresas de telecomunicações, com o objectivo de facilitar a introdução no mercado de aplicações móveis e a prestação de serviços que forneçam uma experiência de comunicação avançada, interoperável e convergente. O RCS define serviços e aplicações que introduzem listas de contactos que mostram dinamicamente a mudança de status de presença e as possibilidades de comunicação, e dispõe de diferentes opções de conversação. A GSMA baseia-se nas normas definidas pela Open Mobile Alliance (OMA), uma organização de normalização que desenvolve open standards para a indústria de telecomunicações móveis. A partir destes standards foram adoptadas um conjunto de features, simplificadas outras e excluídas as restantes, criando assim as várias versões do RCS. Com o aparecimento do RCS houve a intenção de tornar o WCAS compliant com este. Para isso foi necessário implementar novos módulos e adaptar alguns já Luís Gonçalo Henriques de Matos 2

27 existentes de modo a garantir a interoperabilidade do WCAS com clientes e servidores numa rede de telecomunicações que siga os standards descritos na iniciativa RCS. O WCAS ficou dotado dos meios necessários para poder ser integrado com quaisquer outros servidores e clientes de outras empresas que respeitem os mesmos standards. Foram realizados os testes de interoperabilidade definidos pelo RCS com recurso a servidores externos que seguem o mesmo standard e a clientes tanto do WCS como de outras empresas. 1.2 Objectivos O objectivo da WIT Software é tornar o WCAS compliant com o RCS, do mesmo modo que algumas aplicações do WCS já o são. Como para alcançar este objectivo era necessária a implementação de diversos módulos e a modificação de alguns já implementados, para este estágio foi definido como objectivo a implementação do Módulo de Chat. Este módulo representava uma importante meta a atingir pela WIT Software e já abrangia diversas features do RCS (Enhanced Messaging, File Transfer e Image Share), além de que permitia que o WCAS pudesse suportar mais um protocolo de media, o protocolo Message Session Relay Protocol (MSRP), que é um dos protocolos utilizados nas comunicações entre aplicações cliente e servidores RCS. No decorrer do estágio foi adicionado aos objectivos a implementação do Módulo de Capabilities. Este módulo, que é bastante mais simples que o Módulo de Chat, iria tratar uma feature que está definida no RCS-e (uma extensão ao RCS). Este objectivo foi introduzido dado o grande interesse da WIT em ser também compliant com o RCS-e e por as tendências das operadoras de telecomunicações estarem a convergir primeiro para RCS-e e só depois para RCS. O WCAS tem a capacidade de comunicar com todas as aplicações da WCS e de colocá-las a comunicar umas com as outras. Nem todas elas usam os mesmos protocolos, pelo que o fluxo de comunicação de uma aplicação até à outra passa por diversas camadas de tradução dentro do WCAS. A aplicação WIT Web Communicator (WWC) é um softphone 1 e o protocolo de comunicação é diferente dos restantes, neste caso proprietário da WIT, pois foi desenvolvido internamente (consultar Anexo 3-1 Um softphone é um software que permite fazer chamadas através da Internet, utilizando um computador em vez de utilizar hardware dedicado (telefone). Luís Gonçalo Henriques de Matos 3

28 WCAS Chat Protocol). Dado que esta aplicação é totalmente dependente do WCAS e sendo também intenção de torná-la compliant com o RCS, o protocolo de comunicação devia ser desenvolvido considerando os requisitos definidos pelo RCS. O WCAS tem dois modos de funcionamento: F2S - Flash-to-SIP, onde o WCAS funciona como uma gateway e permite que o WWC comunique com clientes SIP, nomeadamente clientes RCS. O WCAS assume o comportamento de um cliente para outros servidores SIP; Standalone - O WCAS assume o comportamento de um servidor independente, aceitando ligações de clientes RCS ou outro tipo de clientes que implementem as normas definidas no servidor. O grande módulo que faltava no WCAS e que devia ser implementado era o Módulo de Chat, que seguia a especificação OMA SIMPLE IM session mode. Este módulo foi o ponto central do estágio e devia ser implementado de modo a permitir a comunicação entre todas as aplicações do WCS. Isto implicava a implementação de várias camadas de tradução para que o WCAS pudesse operar tanto no modo F2S como Standalone. Dada a combinação destas possibilidades o trabalho foi dividido em três cenários: Comunicação WWC WCAS WWC - Desenvolvimento do Módulo de Chat apenas orientado para clientes WWC. Implementação da camada de tradução para clientes Flash e as funcionalidades necessárias no core do WCAS; WIT Software Domain RTMP WIT Web Communicator WCAS RTMP WIT Web Communicator Figura 1 - Cenário WWC WCAS WWC. Luís Gonçalo Henriques de Matos 4

29 Comunicação WWC WCAS Servidor SIP Externo WPC - Implementação de uma camada de tradução para o WCAS se poder comportar como cliente para um servidor SIP (modo WCAS F2S). Esta camada de tradução incluía SIP e MSRP; WIT Software Domain RTMP SIP MSRP WIT Web Communicator WCAS External SIP Server SIP MSRP WIT PC Communicator Figura 2 - Cenário WWC WCAS Servidor SIP Externo WPC. Comunicação WWC WCAS WPC - Implementação de uma camada de tradução para o WCAS poder aceitar ligações de clientes SIP directamente a ele (modo WCAS Standalone). WIT Software Domain RTMP WIT Web Communicator WCAS SIP MSRP WIT PC Communicator Figura 3 - Cenário WWC WCAS WPC. Este módulo devia ser preparado para funcionar tendo em conta um subsistema de High Availability, que iria permitir que o Módulo de Chat estivesse preparado para uma instalação numa rede onde estariam presentes outras instâncias do WCAS a funcionar em cluster. Isto iria tornar o WCAS mais robusto, escalável e tolerante a falhas. Luís Gonçalo Henriques de Matos 5

30 1.3 Motivação A iniciativa RCS teve início a 16 Maio de 2007 e é apoiada pelos principais players da indústria de telecomunicações. Estes incluem operadoras de telecomunicações, fornecedores de serviços de rede e de dispositivos móveis (consultar capítulo Empresas intervenientes para ver a lista de empresas). Estando o mercado a convergir para esta iniciativa e tendo a WIT já uma linha de produtos que abrange as mais diversas opções de comunicação, isso representa a oportunidade de alargar e consolidar a sua presença no mercado das telecomunicações, tanto a nível nacional como internacional. Nesta linha de produtos está presente o WCAS que já cumpre alguns dos requisitos definidos pelo RCS, no entanto segue algumas especificações diferentes. Seguir as especificações definidas pelo RCS representa a oportunidade de estar de acordo com uma iniciativa a nível mundial e onde ainda existem poucas soluções a nível de servidores RCS. Ser compliant com o RCS permite que o WCAS possa servir não só qualquer aplicação cliente que siga a mesma norma, mas também representa a possibilidade de poder ser integrado numa rede IP Multimedia Subsystem (IMS) de uma operadora. O WCAS foi desenhado desde o início para poder funcionar tanto em standalone como numa rede IMS, que seguem protocolos específicos para que todos os sistemas presentes sejam interoperáveis. 1.4 Riscos Como qualquer projecto de software também este esteve sujeito a alguns riscos. Esta secção apresenta aquilo que representava um risco para o projecto e que, de certo modo, poderia afectar ou comprometer o seu desenrolar. São apresentadas também as estratégias adoptadas para gerir e lidar com cada um dos riscos. Os riscos foram divididos em duas categorias: Projecto e Negócio. No projecto serão considerados os riscos que estão directamente relacionados com o projecto e com o estágio. No negócio serão considerados os riscos que afectariam directamente os objectivos estratégicos da empresa. Luís Gonçalo Henriques de Matos 6

31 1.4.1 Projecto Área das telecomunicações A área das telecomunicações é relativamente complexa e lida com diversas situações para garantir o bom funcionamento do fluxo de uma comunicação. Como o projecto insidia directamente nesta área e como ela era praticamente desconhecida por mim, no início do projecto isto representou um risco considerável. Durante o projecto procurei aprender alguns temas e práticas relacionadas com o desenvolvimento deste tipo de servidores. À medida que o tempo passou e o projecto avançou este risco acabou por se dissipar. Definição de requisitos A especificação RCS é composta por uma documentação extensa e complexa de ler e compreender. Depreender os requisitos para os clientes já é uma tarefa difícil, deduzir o que é necessário para o servidor é ainda mais. É necessário além de perceber a comunicação com as aplicações cliente, perceber a implementação do requisito na arquitectura do servidor. No início do projecto foi de facto complicado e apenas com alguma ajuda de pessoas mais experientes foi possível perceber melhor os requisitos e assim defini-los claramente. Estimativas Estimar é uma tarefa difícil, estimar aquilo que ainda não se conhece, além de difícil está sujeito a uma taxa de erro muito grande. Mais uma vez esta foi uma tarefa difícil que se manteve durante grande parte do projecto. De modo a minimizar o erro, sempre procurei decompor uma tarefa em tudo aquilo que era necessário fazer para ela estar concluída, só que nem sempre isto era possível fazer sem antes começar a implementar algo, pois apenas aí era possível determinar as restantes tarefas que eram necessárias fazer. Apesar disso os prazos dados inicialmente não foram muito diferentes daquilo que foi estimado inicialmente, apesar de em determinadas alturas ocorrer algum overwork. Luís Gonçalo Henriques de Matos 7

32 1.4.2 Negócio Time-to-market O tempo que um software leva a ser introduzido no mercado pode ser determinante para o seu sucesso, pois se esse tempo for muito longo pode haver o risco de ser ultrapassado pela concorrência. No início dos projectos os concorrentes são poucos, mas com o passar do tempo o número de concorrentes tende a aumentar e torna-se mais complicado ganhar uma posição. Durante o projecto foi sempre partilhada muita informação entre a equipa WCS. Esta informação muitas vezes incluía novidades sobre o RCS e sobre os concorrentes. Isto foi muito útil, pois permitiu ter conhecimento de como estava a evoluir o mercado e a concorrência. Dinâmica do mercado Este risco acaba por afectar mais o estágio do que o próprio projecto. Os mercados são dinâmicos e a empresa onde foi feito o estágio também. Isto representa um risco porque nem sempre o objectivo que se tem agora é igual daqui a uns meses, fazendo com que a empresa ajuste o seu foco. Isto de facto verificou-se, no entanto, o foco da empresa não mudou radicalmente, apenas ficou mais direccionado, como foi o caso da inclusão do RCS-e no roadmap, que não estava previsto inicialmente. 1.5 Organização do relatório Este relatório encontra-se organizado em oito capítulos, focando cada um deles um assunto específico do estágio. O Capítulo I (o presente capítulo) faz uma introdução do âmbito do estágio e resume do que este se trata. No Capítulo II é feita a apresentação do RCS e da convergência das telecomunicações. No Capítulo III são apresentados os requisitos do RCS e do estágio e é apresentado o roadmap. O Capítulo IV detalha a metodologia e os processos seguidos ao longo do estágio. O Capítulo V fala sobre toda a tecnologia e protocolos que foram utilizados no estágio. No Capítulo VI é apresentada a arquitectura do WCAS, sendo apresentada não só uma visão de alto nível, mas também os detalhes de implementação. O Capítulo VII apresenta os testes de performance realizados ao WCAS. Por último, o Capítulo VIII apresenta as conclusões sobre o estágio. Luís Gonçalo Henriques de Matos 8

33 2 Capítulo II - Rich Communication Suite As informações apresentadas neste capítulo foram obtidas através de pesquisas efectuadas na Internet, leitura de notícias e artigos relacionadas com a convergência das telecomunicações e leitura da documentação disponível sobre o RCS. 2.1 Introdução A área das telecomunicações passou por diversas fases de evolução ao longo do tempo e nos últimos anos revolucionou principalmente com aquilo que oferecia [2]. No início das telecomunicações existia um número reduzido de dispositivos que permitia realizar comunicações simples, as comunicações eram apenas de voz e com uma qualidade reduzida [3]. Como tudo era feito com base na mesma feature, as normas e os standards utilizados eram reduzidos, o que permitia uma fácil interligação e entendimento entre os diversos dispositivos existentes. À medida que os dispositivos foram evoluindo a qualidade das features existentes foi sendo melhorada e foram aparecendo outras features [4]. Esta evolução trouxe a necessidade de interoperabilidade entre os diferentes tipos de dispositivos, com diferentes capacidades, para que pudessem ser utilizados em simultâneo e realizassem comunicações entre si. Esta evolução também tem feito com que a forma como se queira iniciar uma comunicação passe a ser de maneira diferente e a partir de algo diferente. Os utilizadores querem ser capazes de comunicar, aceder e partilhar informação em qualquer lugar, a qualquer hora e a partir de qualquer dispositivo ligado a uma rede de telecomunicações [2] [5]. Têm aparecido novos dispositivos ao longo de diversas gerações e muitos deles têm-se mantido até aos dias de hoje, permitindo a coexistência de várias tecnologias de comunicação. Isto obrigou a que houvesse um entendimento entre fornecedores de equipamentos e operadoras de telecomunicações para permitir o funcionamento em simultâneo de diversos dispositivos distintos. Com o passar do tempo e com a disponibilidade da banda larga móvel e a convergência das telecomunicações, surgiram dispositivos mais poderosos e com capacidade de executar funções como voz e vídeo de alta qualidade. Um conjunto de opções de comunicação que anteriormente estavam limitadas à interface de um computador estão agora disponíveis nos dispositivos móveis e em outros dispositivos Luís Gonçalo Henriques de Matos 9

34 de comunicação, como por exemplo, uma TV [4] [6]. Aplicações multimédia, troca de ficheiros, mensagens instantâneas, presença e redes sociais estão a tornar-se tão comuns nos dispositivos móveis como o SMS e o MMS. Estes dispositivos trouxeram novas formas de entendimento de modo a poderem interagir com os já existentes. A componente multimédia destes dispositivos fez com que a utilização das suas funcionalidades se expandisse para todos os dispositivos com ligação a uma rede de comunicações. O mercado das telecomunicações evoluiu para dimensões que vão para além das tradicionais comunicações com telefones e telemóveis. Hoje em dia as comunicações podem ser feitas tanto a partir de um telefone tradicional, um softphone ou mesmo uma TV [7]. Por detrás destas soluções está um circuito de servidores que, de segmento em segmento de rede, vai convertendo tecnologias de modo a tornar a comunicação possível. 2.2 O que é o RCS O Rich Communication Suite é uma iniciativa da GSMA que conta com o esforço de um grupo de players da indústria de telecomunicações com um objectivo comum: a rápida adopção de aplicações móveis e prestação de serviços que forneçam uma experiência de comunicação avançada, interoperável e convergente. A iniciativa RCS inclui operadoras de telecomunicações, fornecedores de serviços de rede e de dispositivos móveis. Esta iniciativa usa uma metodologia iterativa para disponibilizar um conjunto de features coerentes, normas de implementação, casos de uso, demonstrações e experimentações, tendo em conta as implementações de referência para a interoperabilidade, baseada nos actuais standards e especificações. Os resultados do RCS destinam-se a ser fornecidos como inputs para as entidades do sector, de forma a serem considerados como uma especificação de referência. O RCS define um conjunto de features avançadas que podem ser iniciadas a partir do Enhanced Address Book (EAB). O EAB (uma evolução do livro de endereços tradicional) permite saber as possibilidades de comunicação de um contacto e juntamente com a informação de presença que também está disponível no EAB consegue-se melhorar a experiência do utilizador e promover a utilização das features. A abordagem do RCS não comtempla a definição de novas features, mas sim a agregação e exploração de features standard de modo que possa ser feita uma oferta mais eficiente e equilibrada. Luís Gonçalo Henriques de Matos 10

35 O RCS utilizada a arquitectura IP Multimedia Subsystem para possibilitar a integração das features e para que estas sejam interoperável entre diferentes fornecedores de serviços. As features RCS podem ser utilizadas tanto em dispositivos móveis como fixos e são interoperáveis entre estes dois ambientes de rede. Das várias features existentes, a presença é aquela que desempenha o papel fundamental no RCS, pois é ela que permite determinar as possibilidades de comunicação de um contacto e isso é um factor essencial para despoletar o uso das restantes features. A interoperabilidade é vital para o RCS, pois sem features que funcionem transversalmente aos dispositivos e às redes os utilizadores terão pouco incentivo para as utilizar. A interoperabilidade comercial entre fornecedores e operadoras de telecomunicações é um dos objectivos a serem alcançados com esta iniciativa. Outro objectivo do RCS é proporcionar uma framework comum para um serviço que é interoperável entre operadoras de telecomunicações e dispositivos. O RCS não define as suas próprias especificações, mas explora as especificações standard existentes, por exemplo, a 3rd Generation Partnership Project (3GPP) e a Open Mobile Alliance (OMA). Desde o início que o RCS deu prioridade à interoperabilidade tanto entre dispositivos como entre redes. Somente com esta abordagem se consegue assegurar uma interoperabilidade plena de comunicação. Para acelerar e facilitar a introdução das features, os participantes da iniciativa RCS agiram das seguintes formas: Definiram um conjunto features, aproveitando os standards e normas de implementação existentes, criando assim um conjunto de comunicações interoperáveis baseadas em IMS. O IMS é uma arquitectura importante para trazer estas features para o consumidor de forma interoperável; Desenvolveram implementações de referência do RCS para dispositivos comerciais e validaram os requisitos base e as especificações técnicas para garantir a interoperabilidade de serviços; Criaram testes de interoperabilidade, realizados entre múltiplos fornecedores, para garantir e verificar a maturidade das features RCS. O RCS não especifica a implementação da interface dos dispositivos, apenas se centra nos requisitos de interconexão e interoperabilidade necessários de modo a definir as features para um conjunto de comunicações avançadas. Não é intenção do RCS criar Luís Gonçalo Henriques de Matos 11

36 novos standards, em vez disso pretende especificar um conjunto de features que podem ser implementadas utilizando standards já existentes. 2.3 A motivação Hoje em dia os utilizadores precisam de saber qual a plataforma de conversação que os seus contactos utilizam (Windows Live Messenger, Skype, etc.) e para estabelecer contacto com eles é necessário utilizar credenciais específicas da aplicação. O RCS permite conversações apenas com base na informação do número de telefone, que já está armazenada no livro de endereços e faz com que os utilizadores possam interligar-se de forma mais fácil. Serviços e aplicações que introduzem listas de contactos que mostram dinamicamente a mudança de status de presença e as possibilidades de comunicação, diferentes opções de conversação e a possibilidade de agregar conteúdos, são apenas alguns exemplos desta experiência de comunicação. Os consumidores podem ter a certeza de que estes recursos não estão disponíveis apenas num PC, mas também num dispositivo móvel e que existe uma comunicação plena entre dispositivos e redes. Com o RCS as operadoras de telecomunicações podem satisfazer as expectativas dos clientes e continuar a apresentar serviços cada vez mais evoluídos com base nas exigências dos consumidores. 2.4 Como está organizado O trabalho da iniciativa RCS está dividido numa sequência de esforços progressivamente publicados como releases. De seguida são apresentadas a release 1, a release 2 e uma evolução do RCS, o RCS-e (enhanced), Release 1 Na release 1 estão definidas as features base que fazem parte do RCS. Cada uma destas features dispõe de um conjunto de características que aprimoram a interacção com o utilizador. Esta release é composta pelas seguintes features: Enhanced Address Book; Content Sharing; o Video Share; Luís Gonçalo Henriques de Matos 12

37 o Image Share; File Transfer; Enhanced Messaging Enhanced Address Book O Enhanced Address Book (EAB) é uma evolução do livro de endereços tradicional. Com base na informação tradicional de um contacto (por exemplo, nome e MSISDN), fornece informação avançada sobre os contactos existentes. O EAB é um elemento fundamental do RCS e permite que os utilizadores façam uso das seguintes features: Saber informações das possibilidades de comunicação dos contactos; Iniciar comunicações; Efectuar chamadas de voz e vídeo; Efectuar transferência de ficheiros; Enviar mensagens; Publicar as informações de presença com atributos de texto e multimédia; Emitir um alerta de hyper-availability com tempo limitado aos contactos autorizados; Capacidade de incluir elementos multimédia, por exemplo, uma fotografia do contacto; Publicar informação de presença para contactos autorizados; Convidar e autorizar utilizadores a partilhar as informações de presença de forma recíproca; Permitir aos utilizadores adicionar um contacto a uma lista de contactos bloqueados (blacklist) para evitar a partilha de informações de presença com esses contactos e deixar de receber novos convites para a partilha de informações de presença; Permitir aos utilizadores aceder facilmente aos contactos avançados; Mostrar informações de presença e conteúdos relacionados a cada um dos contactos avançados; Luís Gonçalo Henriques de Matos 13

38 Ser notificado das actualizações das informações de presença e alertas de hyper-availability feitos pelos contactos avançados; Beneficiar de um histórico por contacto incluindo todos os tipos de comunicação; Permitir efectuar pesquisas tanto localmente no livro de endereços pessoal como em outros recursos externos; Assegurar o backup e sincronização do Address Book com o Network Address Book, que pode ser executada automaticamente, permitindo uma sincronização transparente em diferentes dispositivos do utilizador. O Network Address Book (NAB) é fundamental para oferecer as features do EAB, uma vez que oferece um repositório para armazenar os contactos do utilizador, que é acessível a partir de múltiplos dispositivos. O EAB dispõe das seguintes features: Presença; Enriched Contacts List; Service Capability Indication. Presença A presença é vista como um pedaço de informação para os contactos, para que eles possam saber o que o utilizador está a fazer, o seu estado de espírito, a disponibilidade, entre outras informações relacionadas com o utilizador. Ao utilizador é dada a possibilidade de publicar informações pessoais que formam a sua informação de presença. Como ilustração, o grupo de contactos com os quais foi estabelecida uma relação de presença pode ser visto como os contactos mais próximos de um determinado utilizador (amigos, familiares, colegas, etc.). A informação de presença não substitui o contacto vcard 2 do livro de endereços tradicional. O nome do contacto e outras informações não sofrerão qualquer impacto e toda a informação de presença é controlada pelo utilizador. 2 vcard é um formato standard para cartões de visita electrónicos. Costumam estar associados às mensagens de , mas podem ser enviados pela Internet ou através de IM. Contêm informações de Luís Gonçalo Henriques de Matos 14

39 Tendo sido estabelecida uma relação de presença com um determinado contacto, a informação de presença passará a ser visível a partir do EAB. Também é visível a partir de outros lugares do dispositivo, por exemplo, nos logs de comunicações efectuadas ou pastas de mensagens. Enriched Contacts List De modo a facilitar o controlo sobre os contactos que têm acesso à informação de presença do utilizador, é possível ter um acesso directo e diferenciado aos contactos com os quais foi estabelecida uma relação de presença. Há um acesso aprimorado no EAB que exibe tanto a presença dos contactos avançados como dos contactos tradicionais. Os contactos com presença são claramente identificados, por exemplo, apresentando alguns atributos da presença, como a fotografia, free text, etc. É possível ter uma visão detalhada de um contacto com presença, onde os atributos relevantes das informações de presença são exibidos. Service Capability Indication As possibilidades de comunicação que podem ser mostradas para o utilizador são: Video Call; Image Sharing; Video Sharing; File Transfer; Chat. A indicação das possibilidades de comunicação pode ser disponibilizada para todos os contactos no livro de endereços, sem a necessidade de estabelecer uma relação de presença. Por exemplo, um contacto no livro de endereços pode não ser de uma pessoa conhecida, mas se ele tiver um dispositivo RCS, as possibilidades de comunicação podem ser conhecidas de modo a poder estabelecer uma comunicação avançada com esse contacto. Esta informação também permite que os utilizadores saibam que contactos podem ser convidados a partilhar informações de presença. contacto como nome, morada, números de telefone, endereços de , URLs, logotipos, fotografias e clipes de áudio. Luís Gonçalo Henriques de Matos 15

40 Content Sharing É a capacidade que os utilizadores têm de trocar diferentes tipos de conteúdo durante uma sessão, normalmente uma chamada de voz, mas não exclusivamente. Os conteúdos partilhados durante uma chamada de voz podem ter um outro fluxo em transmissão ao mesmo tempo. Cada vez que uma chamada de voz for estabelecida o utilizador tem a possibilidade de partilhar conteúdos. Esta feature pode ser iniciada por ambas as partes, tanto quem iniciou como quem recebeu a chamada. Quando um utilizador inicia a partilha de conteúdos é enviado um convite para o outro contacto, que pode ser aceite ou rejeitado. Caso seja aceite, esta aceitação persistirá para todos os conteúdos partilhados durante a chamada. O receptor tem a possibilidade de guardar o conteúdo partilhado no dispositivo. Os conteúdos partilhados podem ser tanto de imagem como vídeo File Transfer É a capacidade que os utilizadores têm de trocar diferentes tipos de ficheiros, durante uma sessão em curso ou sem ter uma sessão em curso. As sessões podem ser chamadas de voz ou chat. Esta feature pode ser iniciada tanto por quem inicia como por quem recebe a chamada ou o pedido de chat. O receptor pode aceitar ou rejeitar os ficheiros oferecidos e, caso aceite, tem a possibilidade de guardar os ficheiros que são transferidos no dispositivo Enhanced Messaging O Enhanced Messaging tira partido dos números de identificação única (MSISDN), ao contrário dos serviços de mensagens típicos de Internet. Além de serviços de SMS e MMS um dispositivo RCS também oferece ao utilizador um serviço de chat. Os MMS e principalmente os SMS são serviços já muito bem estabelecidos e que existem no dia-a-dia dos utilizadores. O chat não é um substituto destes serviços de mensagens, mas sim um serviço paralelo com os seus próprios valores. Esses valores podem ser exemplificados por meio de conference chats, alertas vibratórios, conteúdos multimédia, informação de is typing e incorporando a transferência de ficheiros. Luís Gonçalo Henriques de Matos 16

41 Chat Um dispositivo compatível com RCS, além do suporte para os métodos de mensagens tradicionais, oferece ao utilizador um serviço de chat. O serviço de chat pode ser usado no modo um para um, em que apenas dois utilizadores estão em conversação, ou no modo de conference chat, com vários utilizadores ao mesmo tempo em conversação entre si. Em termos de RCS só é possível utilizar o chat com dispositivos RCS ou com outros dipositivos que suportem OMA SIMPLE IM session mode. As mensagens que são trocadas entre os utilizadores podem conter texto ou conteúdo multimédia Release 2 A release 2 explora e melhora as features da versão anterior, possibilitando a utilização das mesmas a partir de vários de dispositivos. Enquanto a release 1 definia apenas um dispositivo em utilização ao mesmo tempo, a release 2 define a utilização de vários dispositivos pelo mesmo utilizador ao mesmo tempo. Estes dispositivos podem ser, por exemplo, um telemóvel e um computador. As features que fazem parte da release 2 são: Broadband Access to RCS features; Multi-device environment; Network Address Book; Provisioning and configuration of RCS devices/clients Broadband Access to RCS features Os utilizadores RCS poderão utilizar as features de comunicação avançada em dispositivos que utilizem ligações de banda larga, por exemplo, um PC ou um portátil. Um utilizador poderá ter diferentes tipos de clientes RCS ligados simultaneamente e que utilizem diferentes tipos de acesso à rede (banda larga ou a rede da operadora) e pode iniciar uma feature RCS a partir de qualquer um deles. Clientes RCS de diferentes operadoras poderão comunicar entre si. Aqui é necessário que a infra-estrutura de rede das operadoras seja interoperável. Um cliente RCS release 1 também conseguirá realizar comunicações com um cliente RCS release 2. Luís Gonçalo Henriques de Matos 17

42 Multi-device environment Como a release 2 introduz o suporte para dispositivos de acesso através de banda larga, permite que os utilizadores usem as features RCS, por exemplo, a partir de um PC. A combinação habitual para utilizar as features RCS pode ser o cliente ter um dispositivo móvel e um dispositivo de acesso através de banda larga. Além desta combinação outras serão possíveis no futuro, como por exemplo, uma TV. O ambiente Multi-device permite ao utilizador: Atender uma chamada ou responder a uma mensagem a partir do dispositivo que melhor se adapte ao efeito; Ter uma única lista de contactos partilhada entre os vários dispositivos; Ser capaz de autorizar convites para partilhar informações de presença a partir de cada dispositivo; Ter uma única informação de presença que pode ser vista e mantida a partir de cada dispositivo que o utilizador tiver. O modo de funcionamento geral será quando um utilizador tiver vários dispositivos em utilização e for feita uma chamada ou enviada uma mensagem. Esta chamada ou mensagem será enviada para todos os dispositivos e cada um irá alertar para esse acontecimento. O utilizador poderá então responder a partir do dispositivo que melhor lhe convier. Quando o utilizador aceitar ou rejeitar num dos dispositivos, todos os restantes irão terminar o alerta Network Address Book O objectivo do Network Address Book (NAB) é fornecer um mecanismo centralizado e uniforme para os utilizadores administrarem as informações dos contactos numa rede RCS. No geral o NAB é um repositório de contactos que é implementado e administrado na rede da operadora. A partir do Enhanced Address Book os utilizadores podem criar informações de contactos nos dispositivos móveis RCS e depois fazer upload dos dados para o NAB. Estas informações são propriedade do utilizador, são mantidas por este e somente ele pode modificar ou apagar as informações dos contactos. Depois de um utilizador fazer Luís Gonçalo Henriques de Matos 18

43 upload destas informações para o NAB, pode mais tarde sincronizar com outro dispositivo RCS, como um PC ou outro dispositivo com acesso de banda larga Provisioning and configuration of RCS devices/clients Não se espera que o utilizador final tenha de configurar manualmente as definições para poder utilizar as features RCS num dispositivo. Assim que o dispositivo for ligado será registado na rede e todas as features RCS estarão disponíveis sem qualquer acção do utilizador. Isto aplica-se a dispositivos móveis e fixos, incluindo aqueles com acesso através de banda larga. Também se aplica tanto às features da release 1 como às da release 2. São transparentes para o utilizador as configurações relacionadas com a IMS, pontos de acesso, tamanho máximo permitido para File Transfer, etc. Na verdade, estes parâmetros devem ser configurados pela operadora e, geralmente, bloqueados a alterações por parte do utilizador final a fim de evitar erros de configuração indesejados nas features RCS. No entanto, deve haver a possibilidade de configurar algumas definições (SIP, XDMS) que podem ser necessárias para aceder a alguma feature quando, por exemplo, se mudar de operadora. De modo a permitir que as features RCS sejam de certa forma transparentes para o utilizador, as seguintes definições são configuradas no dispositivo: Definições de IMS Core/SIP para registo na rede e realização de comunicações básicas; Definições de XDMS; Definições de presença; Configurações do Network Address Book para efectuar backups, restauro e sincronização de contactos; Definições de IM para o chat; Configurações de File Transfer; Parâmetros RCS específicos, por exemplo, tamanho máximo permitido para File Transfer; Parâmetros específicos de dispositivos de acesso à rede através de banda larga, por exemplo, o MSISDN do utilizador. Luís Gonçalo Henriques de Matos 19

44 Algumas das configurações listadas acima têm uma influência directa na experiência do utilizador. Por exemplo, os parâmetros específicos de RCS incluem o número máximo de caracteres do free text nas informações de presença. Desta forma o utilizador irá ser sempre informado sobre esse limite ao digitar o conteúdo do free text, evitando assim que o texto seja truncado quando for entregue a outro contacto. Outros exemplos são o tamanho máximo permitido para o Portrait icon, também nas informações de presença, ou para um ficheiro a ser transferido. A interface do utilizador deve incluir informações sobre esse limite, fazendo com que o utilizador saiba que nem todo o conteúdo multimédia pode ser usado nesses contextos RCS-e O RCS-e (enhanced) é uma optimização das features de voz e texto da release 1 e 2, que permite aos utilizadores enviar mensagens instantâneas, efectuar chamadas, partilhar vídeo e fazer transferência de ficheiros em tempo real, de modo simples e interoperável. Apesar do desenvolvimento interessante do RCS, cinco das principais operadoras europeias, a Deutsche Telekom, a Orange, a Telecom Italia, a Telefonica e a Vodafone anunciaram no Mobile World Congress de Fevereiro de 2011, planos para lançar uma versão melhorada do RCS, conhecido como RCS-e, no final de 2011 ou início de Com base nos princípios de interoperabilidade estabelecidos dentro do ecossistema das operadoras móveis, a especificação RCS-e, chamada RCS-e Advanced Communications, proporciona uma optimização das especificações da release 1 e 2, de modo a acelerar o tempo de entrada no mercado e simplificar a oferta ao cliente. Resumidamente, o RCS-e proporciona uma simples e interoperável extensão para voz e texto hoje em dia" [8]. Este novo foco no RCS é baseado nos resultados dos testes com clientes em features RCS, de modo a compreender melhor onde as operadoras podem aumentar a sua oferta de serviços oferecendo assim mais valor aos clientes. O aparecimento do RCS-e trouxe consigo uma nova designação para toda a iniciativa RCS, que foi o RCE (Rich Communication Ecosystem), que pretende representar o RCS 2.0 e o RCS-e, e a interoperabilidade entre ambos. Luís Gonçalo Henriques de Matos 20

45 Princípios RCS-e O mecanismo fundamental do RCS-e é a feature Capability Discovery. Por exemplo, quando um utilizador percorre os seus contactos e selecciona um contacto RCS-e, a aplicação cliente realiza uma verificação das possibilidades de comunicação do contacto, sendo assim capaz de mostrar as features que estão disponíveis para comunicar. Este pedido é encaminhado para o destinatário e pode ter dois tipos de resposta: 1. O contacto está registado e as possibilidades de comunicação, no momento em que é efectuado o pedido, são guardadas pelo utilizador que efectuou o pedido; 2. O contacto não está registado ou não existe. Este mecanismo para determinar as possibilidades de comunicação é importante na medida em que permite que um utilizador saiba quais os serviços que estão disponíveis antes de serem utilizados Conformidade A conformidade do dispositivo com a especificação RCS-e pode resumir-se no seguinte: Suporte para registo na rede da operadora; Obtenção das possibilidades de comunicação de um utilizador através dos mecanismos de SIP OPTIONS e ANONYMOUS fetch; Suporte para chat; Suporte opcional para File Transfer, Image Share e Video Share. A razão para fazer do File Transfer, Image Share e Video Share opcionais é facilitar a penetração das features RCS-e em todos os tipos de dispositivos. Posteriormente um dispositivo RCS-e suportará todas as features RCS-e que sejam viáveis, tendo em conta as limitações de hardware e software. De qualquer modo uma operadora de rede que implemente a especificação RCS-e deve suportar File Transfer, Image Share e Video Share ao nível da rede. Luís Gonçalo Henriques de Matos 21

46 Chat O chat permite aos utilizadores trocar mensagens entre um ou mais utilizadores instantaneamente. No RCS-e o chat é uma feature de referência, disponível para qualquer utilizador registado e usa o OMA SIMPLE IM session mode como especificação base. À medida que foram introduzidas novas features foram feitos alguns ajustes e modificações necessárias na especificação base do RCS. O RCS-e trouxe as seguintes alterações a nível de features relativamente às releases 1 e 2 do RCS: Remoção da Presença - Nas releases 1 e 2 do RCS as features só podiam ser utilizadas se fosse possível saber a presença de um contacto. Com o RCS-e esta feature foi retirada e passa a ser possível utilizar qualquer feature mesmo desconhecendo a presença do contacto; Capability discovery - É uma nova feature que permite determinar quais as possibilidades de comunicação de um contacto antes de iniciar qualquer tipo de comunicação. Na release 1 e 2 apenas era determinar as possibilidades de comunicação quando um contacto tinha presença; Store and Forward - É uma nova feature mas que a sua implementação é critério da operadora. Requer que o Chat Server tenha a capacidade de armazenar uma mensagem quando o utilizador de destino não está online e enviá-la para ele quando ele voltar a estar novamente online; Displayed Message Disposition - Esta nova feature permite que o remetente seja notificado quando uma mensagem que enviou for exibida no dispositivo do utilizador que a recebeu. Esta notificação não garante que a mensagem tenha sido lida pelo utilizador, apenas indica que a mensagem foi exibida no dispositivo do destinatário; Local Black List - Uma nova feature que define que o dispositivo deve permitir armazenar localmente uma lista de contactos bloqueados; Conversation History - Uma nova feature que define que o dispositivo deve permitir armazenar localmente o histórico de uma conversação; Luís Gonçalo Henriques de Matos 22

47 User Alias - É uma nova feature que permite que o utilizador defina um nome que pode ser enviado enquanto se estabelece uma comunicação com outro utilizador. 2.5 Empresas intervenientes A iniciativa RCS já conta com mais de 100 operadoras, fornecedores de equipamentos e empresas de telecomunicações. Abaixo encontra-se a lista de empresas que já aderiram a esta iniciativa. Mobile Operators AT&T Bell Mobility Bouygues Telecom China Mobile China Unicom China Telecom E-Mobile France Telecom/Orange KDDI KTF Mobilkom Austria NTT NTT DoCoMo Optus SingTel SFR SK Telecom Smart SoftBank Swisscom Telecom Italia Mobile Telecom New Zealand Telefonica O2 Telekom Srbija Telenor Tele2 Sweden TeliaSonera Telstra TMN T-Mobile Verizon Wireless Videotron Wind Messaging Operators Belgacom International Carrier Services Mach Sybase Syniverse Technologies Infrastructure suppliers Acision Aicent Acme Packet Airwide Solutions Alcatel-Lucent Almira Labs Aylus Broadsoft Cicero Networks Comverse Ericsson Fujitsu Gemalto Luís Gonçalo Henriques de Matos 23

48 Genband Huawei IBM IntelliNet Technologies Iwatsu Electric Mavenir Nable Communications NeuStart Nokia Siemens Networks OKI Electric Industry Openmind Networks OptiMobile Sonus Networks Starent Tatara Systems Tekelec ureach ZTE 724 Solutions Handset manufacters Hitachi LG Motorola NEC Nokia Sagem Wireless Samsung Sony Ericsson Toshiba Software developers Be Tomorrow Colibria CommuniGate Systems Comneon Ecrio Eyeball EyeP Media Genaker Inexbee Inspirit MailVision OnMobile (Voxmobili) NeuSoft Mobile Solutions Smith Micro Software Summit Tech Solaiemes Telcoware WIT Software Test laboratories Fraunhofer Institute Fokus Mera Networks Octopus Network Setcom Wireless Products Other Symbian Luís Gonçalo Henriques de Matos 24

49 2.6 Concorrentes As informações sobre este tipo de servidores não são de conhecimento público, principalmente quando são soluções comerciais. Estas são habitualmente transmitidas e negociadas directamente com as operadoras que pretendem adquirir um produto deste tipo, pelo que a informação pública é muito escassa. Como o WCAS se encontra inserido dentro do WCS não faria sentido analisar apenas os concorrentes do servidor, deste modo, foi conduzido um estudo inicial sobre os concorrentes dos principais produtos do WIT Communications Suite (WCS): WIT PC Communicator (WPC), WIT Web Communicator (WWC) e WIT Mobile Communicator (WMC), que facilitou a identificação dos concorrentes do WCAS. Os concorrentes foram identificados com base na solução apresentada e nas features que os produtos do WCS também têm ou que está previsto virem a ter. Com base nisto foram identificados dois tipos de concorrentes: Concorrentes directos - Empresas que têm objectivos comuns ou soluções que apresentam as mesmas features que os produtos do WCS e que concorrem no mesmo mercado; Concorrentes indirectos - Empresas ou soluções que não concorrem directamente com os produtos do WCS, pois têm um público-alvo diferente, mas que poderão concorrer quando os produtos do WCS forem integrados nas operadoras, estando a concorrer também com as operadoras. O facto de o WCAS poder operar tanto no modo F2S como no modo Standalone, faz com que encontre vários concorrentes distintos. Há empresas que desenvolveram soluções que operam de modo semelhante ao WCAS F2S e outras de modo semelhante ao WCAS Standalone. Há algumas que têm uma solução conjunta, agregando tudo num só produto, sendo estas fortes concorrentes do WCAS, pois também ele é uma solução conjunta. Apesar de existirem diversas soluções que possam de certo modo concorrer com o WCAS, pelo menos a nível de Web Softphones, nem todas elas estão vocacionadas para a incitava RCS, no entanto, são considerados concorrentes dado que apresentam soluções semelhantes. Na Tabela 1 encontram-se listadas, por ordem de importância, as soluções que devido às suas características se aproximam do objectivo do WCAS ou que estão de certo Luís Gonçalo Henriques de Matos 25

50 modo ligadas à iniciativa RCS. Para uma lista completa dos concorrentes do WCS deve ser consultado o Anexo 1 - Competitors Analysis. Tabela 1 - Concorrentes do WCAS. Empresa Solução Standalone F2S Ericsson IMS Multimedia Telephony Nokia Siemens Networks MSC Server System Alcatel Lucent 5400 IMS Application Server Huawei IP Telephony Solution Colibria RCS Application Servers Summit Summit Solaiemes RCS Thin Client Server Solaiemes RCS Solution Gateway Aylus Media Platform Microsoft Lync Telepo Business Communication Server CommuniGate Systems CommuniGate Pro Server British Telecom Ribbit De seguida é apresentada uma breve descrição de cada uma das soluções listadas na Tabela 1. Luís Gonçalo Henriques de Matos 26

51 Ericsson - IMS Multimedia Telephony [9] Solução IMS que oferece serviços tanto de telecomunicações tradicionais como de telecomunicações multimédia. Possui uma arquitectura escalável que permite adicionar novos serviços aos já existentes. Nokia Siemens Networks - MSC Server System [10] Solução que apresenta uma arquitectura distribuída e que faz o controlo de chamadas, sinalização e media. Permite que cada um dos serviços seja direccionado para entidades dedicadas e de alto débito optimizando assim o fluxo das comunicações. Alcatel Lucent IMS Application Server [11] Application Server que oferece um ambiente configurável para fornecer serviços de convergência entre as telecomunicações tradicionais e a Internet. Pode ser instalado tanto numa rede IMS como não IMS. Huawei - IP Telephony Solution [12] Solução unificada para voz, vídeo e dados numa rede IMS. Permite fazer a transição e agregação entre as telecomunicações tradicionais e as telecomunicações IP. Colibria - RCS Application Servers [13] Solução que dispõe de diversos serviços independentes, altamente escaláveis e modulares para Presence, Messaging e Address Book. Summit - Summit [14] Solução bastante completa que permite a integração com redes IMS e RCS e tem uma solução idêntica a cada um dos produtos do WCS. Compete com o WCAS nos dois modos de funcionamento. Solaiemes - RCS Thin Client Server [15] Plataforma RCS que permite a criação de clientes RCS em diferentes plataformas sem necessidade de implementar protocolos de telecomunicações específicos, utilizando apenas protocolos de Internet e API. Pode ser integrado com redes IMS e RCS. Solaiemes - RCS Solution Gateway [16] Plataforma de convergência entre soluções para a web e infra-estruturas de telecomunicações. É interoperável com redes IMS e RCS. Luís Gonçalo Henriques de Matos 27

52 Aylus - Media Platform [17] Plataforma de media que é compatível com HTTP, SIP, IMS e RCS. Permite media transcoding em tempo real. Microsoft - Lync [18] Plataforma corporativa que permite a interligação transparente de diversas tecnologias e utiliza várias features e protocolos definidos pelo RCS. Telepo - Business Communication Server [19] Solução muito completa, apresentando uma solução idêntica a cada um dos produtos do WCS, quer a nível de clientes quer a nível de servidor. CommuniGate Systems - CommuniGate Pro Server [20] É uma gateway que direcciona os pedidos vindos de diversos tipos de clientes para servidores específicos. Suporta protocolos específicos do RCS. British Telecom - Ribbit [21] Solução que começou por ser apenas uma plataforma e neste momento oferece soluções tanto a nível de clientes como de servidor. Compete com o WCAS nos dois modos de funcionamento. Luís Gonçalo Henriques de Matos 28

53 3 Capítulo III - Requisitos Os requisitos deste projecto incidiram principalmente sobre as features da release 1 do RCS e um pouco sobre as do RCS-e. O objectivo de alto nível do projecto era a implementação de um novo módulo, o Módulo de Chat. Este módulo iria comtemplar a maioria das features que estão definidas na release 1, no entanto, tem alguns ajustes na release 2. No decorrer do estágio foi introduzindo nos objectivos a implementação do Módulo de Capabilities, que iria comtemplar algumas das features do RCS-e. Os requisitos detalhados do Módulo de Chat encontram-se na documentação oficial do RCS e da OMA. Esta documentação define tanto os requisitos funcionais como os técnicos. Neste capítulo será apresentado um resumo dos requisitos que faziam parte dos objectivos numa vertente mais funcional e um resumo do que foi necessário implementar no WCAS para desenvolver o Módulo de Chat e o Módulo de Capabilities. A documentação oficial do RCS e da OMA pode ser consultada nos seguintes endereços: RCS (RCS Release 1 Updates e RCS Release 2 Updates - February 2011) RCS-e OMA (Instant Messaging using SIMPLE) Luís Gonçalo Henriques de Matos 29

54 3.1 Módulo de Chat Dada a semelhança entre as features do Enhanced Messaging, File Transfer e Image Share, todas elas foram agregadas no Módulo de Chat Enhanced Messaging Este serviço implica a implementação de um novo módulo no WCAS, o Módulo de Chat. O serviço de chat deve poder ser usado tanto no modo de um para um, em que apenas dois utilizadores estão em conversação, como no modo de conference chat, com vários utilizadores em simultâneo. O RCS define a utilização do protocolo MSRP para a transferência de dados e para a sinalização define o protocolo SIP File Transfer Deve ser possível a transferência de ficheiros durante uma sessão de chat ou chamada ou mesmo sem ter uma sessão em curso, sendo também possível o envio de vários ficheiros em simultâneo entre os mesmos utilizadores. Também aqui devem ser usados os protocolos SIP e MSRP Image Share O serviço de Image Share permite que os utilizadores partilhem imagens durante uma chamada de voz ou vídeo que está em curso. Este requisito tem algumas semelhanças com o anterior, no entanto, apenas pode ser usado durante uma chamada. Usa os mesmos protocolos que o File Transfer. Para a implementação destas features no WCAS são necessários os seguintes desenvolvimentos: Definição de um protocolo de comunicação entre WWC e o WCAS e a sua implementação no WCAS; Implementação do core do serviço de Chat, File Transfer e Image Share; Implementação de uma camada de tradução para Flash; Implementação de extensões à camada de tradução SIP, no modo F2S (RFC 3261, 3265, 3515, 4028, 4353, 4488, 4566, 4575, 4579, 5366, 5368); Luís Gonçalo Henriques de Matos 30

55 Implementação de uma camada de tradução para SIP Servlets, no modo Standalone (RFC 3261, 3265, 3515, 4028, 4353, 4488, 4566, 4575, 4579, 5366, 5368); Implementação de uma stack de MSRP e do conceito de MSRP Switch para utilização tanto no modo F2S como no modo Standalone (RFC 3862, 4975, 4976); Implementação dos seguintes tipos de sinalização: o Local - Para utilização com clientes ligados directamente ao WCAS; o Proxied - Para utilização no modo F2S; o Conference - Para utilização em Conference Chats. Implementação dos seguintes tipos de media: o Flash para Flash - Para transferência de dados apenas entre clientes WWC; o Flash para MSRP e MSRP para Flash - Para transferência de dados entre clientes WWC e clientes WPC ou WMC; o MSRP para MSRP - Para transferência de dados apenas entre clientes WPC e WMC; o Bypass MSRP - Para permitir que os clientes WPC e WMC possam estabelecer sessões de transferência de dados em peer-to-peer, ou seja, sem utilizar o WCAS como intermediário; o Conference - Para utilização quando se estiver perante uma sessão de Conference Chat, entre qualquer tipos de cliente; o Flash para Flash em internode - Para permitir a transferências de dados entre clientes Flash que estejam ligados em nodes diferentes, quando estiver a ser utilizado o subsistema de High Availability. Luís Gonçalo Henriques de Matos 31

56 3.2 Módulo de Capabilities Este módulo é o responsável por gerir a feature Capability discovery, uma vez que determina as possibilidades de comunicação de um contacto independentemente de este ter presença ou não. Utiliza o protocolo SIP para a sua implementação e apenas deve ser usado entre cliente WPC e WMC. A implementação deste serviço implicou os seguintes desenvolvimentos no WCAS: Implementação do core do serviço de Capabilities; Implementação de uma camada de tradução para SIP Servlets, no modo Standalone (3261, 3265, 4028, 4566); Implementação de mecanismos de relay para determinação das possibilidades de comunicação. 3.3 Outros requisitos High Availability De modo a preparar o WCAS para um cenário de crescimento, mantendo a sua confiabilidade, este deve ser suficientemente escalável, tolerante a falhas e totalmente transparente para os utilizadores, ou seja, o módulo de chat deve estar preparado para ser instalado num cenário de High Availability. Para que este módulo esteja preparado para isso deve ser desenvolvido um subsistema que permita que uma instância do WCAS possa interagir com outras instâncias do WCAS. Para o seu funcionamento são necessários os seguintes desenvolvimentos: Implementação de um subsistema de High Availability para o módulo de chat; Implementação dos seguintes tipos de sinalização no módulo de chat; o Internode - Para sinalização entre servidores WCAS. Implementação dos seguintes tipos de media no módulo de chat; o Flash para Flash - Para transferência de dados apenas entre clientes WWC em nodes diferentes. Luís Gonçalo Henriques de Matos 32

57 3.3.2 Integração na plataforma existente Este projecto não ia ser desenvolvido de raiz, era a continuação de um projecto já existente. Devido a isso, os novos módulos implementados bem como todos os desenvolvimentos efectuados devem ser perfeitamente integráveis com o sistema já existente. O módulo de chat deve seguir a arquitectura existente nos restantes módulos e utilizar, sempre que possível, os mesmos protocolos, as mesmas tecnologias e as mesmas API já utilizadas no projecto. 3.4 Roadmap Este projecto culminou com a release 3 do WCAS e o seu desenvolvimento foi dividido em três grandes etapas, tendo cada etapa várias iterações. Estas etapas foram definidas de acordo com os objectivos estratégicos da empresa. Na Tabela 2 está o roadmap e as várias etapas e iterações do projecto. Tabela 2 - Roadmap das etapas e iterações do projecto. Etapa Iteração Comple xidade Data de Início e Fim # 1 - Análise Média WWC WCAS WWC Análise das features RCS, priorização e atribuição de estimativas. # 2 - Protótipo MSRP Criação de um protótipo MSRP standalone, segundo os RFC 4975 e # 3 - Conceito Chat Manager Definição da arquitectura do Módulo de Chat e dos interfaces de sinalização. # 4 - Comunicação Chat Alta Alta Média Implementação das interfaces de media para comunicação entre WWC Luís Gonçalo Henriques de Matos 33

58 # 5 - Sinalização Proxied Implementação da interface de sinalização proxied e de um SIP User Agent. # 6 - Inicialização da Stack MSRP Implementação dos mecanismos necessários para estabelecer uma sessão de media MSRP. # 7 - Integração da Stack MSRP Alta Alta Alta WWC WCAS Servidor SIP Externo WPC Integração do protótipo MSRP no WCAS e a sua ligação com a camada de media. # 8 - Comunicação chat 1-1 Implementação dos comandos necessários para inicialização de uma comunicação. # 9 - File Transfer Adaptação das interfaces de sinalização e media para suporte de File Transfer. # 10 - File Transfer Adaptação da camada de SIP e suporte para interpretação e criação do protocolo SDP (RFC 4566). # 11 - Image Share Adaptação das interfaces de sinalização e media e do SDP para suporte de Image Share Média Média Média Baixa # 12 - Conference Chat Adaptação das interfaces de sinalização para inicialização de um conference chat. # 13 - Conference Chat Implementação de comandos para actualização do estado do conference chat. Alta Alta Luís Gonçalo Henriques de Matos 34

59 # 14 - RCS-e compliance Definição da arquitectura do Módulo de Capabilities e da camada de tradução de SIP Servlets. # 15 - MSRP Switch Implementação da camada de tradução de SIP Servlets para o Módulo de Chat e adaptação da camada de media e MSRP para funcionamento como um MSRP Switch. # 16 - High Availability Alta Baixa Alta WWC WCAS WPC Preparação do Módulo de Chat para suportar o subsistema de High Availability. # 17 - Testes e estabilização Revisão de todos os desenvolvimentos efectuados, realização de testes e correcção de bugs. # 18 - Testes de Performance Preparação de cenários e realização de testes de performance à camada de media do WCAS Baixa Média # 19 - Testes de Performance Realização de testes de performance à camada de sinalização do WCAS. # 20 - Conference Chat Adaptação da arquitectura para suportar múltiplos participantes. # 21 - Conference Chat Adaptação das interfaces de media para estabelecer um sessão de conference chat. Baixa Média Baixa Luís Gonçalo Henriques de Matos 35

60 Na Tabela 3 encontram-se as várias features da release 1 e 2 do RCS e do RCS-e. Para cada feature encontra-se indicada a participação efectuada neste projecto. Tabela 3 - Features implementadas por release. Release Feature Desenvolvimento Enhanced Address Book (XDMS) Já desenvolvido Release 1 Content Sharing Video Share Image Share Não desenvolvido Desenvolvido File Transfer Enhanced Messaging Desenvolvido Desenvolvido Release 2 Broadband Access to RCS features Multi-device environment Network Address Book Não aplicável Desenvolvido Já desenvolvido Provisioning and configuration of RCS devices/clients Remoção da Presença Capabilities Discovery Não aplicável Não aplicável Desenvolvido RCS-e Store and Forward Displayed Message Disposition Participação no desenvolvimento Participação no desenvolvimento Local Black List Conversation History User Alias Não aplicável Não aplicável Participação no desenvolvimento Luís Gonçalo Henriques de Matos 36

61 4 Capítulo IV - Metodologia de trabalho Este capítulo descreve a metodologia, os processos, as práticas e a organização seguida durante todo o projecto, mostrando as interacções e divisão de responsabilidades entre a equipa de gestão e a equipa de desenvolvimento. 4.1 Processo As características do projecto e o facto de, tanto o projecto como a área das telecomunicações serem totalmente novas para mim, cedo permitiram perceber que muitas das tarefas apenas conseguiam ser determinadas ao longo do tempo e depois de realizar algum trabalho. Apesar dos requisitos funcionais serem claros, a sua definição em termos técnicos era relativamente complexa e por vezes estava dependente da realização de outros requisitos, o que dificultava a determinação e previsão antecipada de um roadmap detalhado. Deste modo, as fases de architecture design não eram tão formais e por vezes ocorriam após as fases de development. Dadas estas particularidades, foi usada a metodologia Scrum. Esta abordagem ágil é uma prática comum na WIT Software, nomeadamente no departamento de I&D, pois permite que o projecto esteja actualizado não só com as tecnologias mas também com os propósitos estratégicos da empresa e do mercado. 4.2 Sprints Os Sprints tiveram a duração de 15 dias e no último dia de cada Sprint eram realizadas as actividades comuns do Scrum: Review; Demo; Planning; Retrospective. Era feito um overview sobre os objectivos do Sprint e apresentado o trabalho concretizado, realizando demonstrações práticas. Após isso eram definidos os objectivos do Sprint seguinte e por fim, e apenas com os developers, eram discutidos pormenores técnicos de implementação. Durante cada Sprint eram realizadas as tarefas planeadas no Sprint Backlog e eram registadas as horas dedicadas a cada tarefa. 4.3 Monitorização O projecto era monitorizado utilizando duas ferramentas, o Timetracker [22] e o próprio Sprint Backlog. Para o registo das horas de trabalho diárias era utilizada a ferramenta Timetracker e semanalmente eram submetidas para a plataforma Weekly Luís Gonçalo Henriques de Matos 37

62 Reports para serem posteriormente analisadas e aprovadas. Durante o Sprint eram também registadas no Sprint Backlog as horas dedicadas a cada tarefa, sendo para isto utilizado um ficheiro Excel. A granularidade deste ficheiro era maior do que a do Timetracker, oferecendo a possibilidade de fazer uma análise de como evoluiu o trabalho ao longo do Sprint, através dos seguintes gráficos: Hours Burndown with Cumulative Flow - Este gráfico permite efectuar duas análises: a típica de um Burndown Chart (progresso do trabalho realizado e o tempo restante para o fim do Sprint); e a de um Cumulative Flow, que permite apurar como as tarefas estão a evoluir através dos vários estados (Pending e In Progress) até estarem terminadas (Complete); Workitem Cumulative Flow - Este gráfico permite fazer a mesma análise de um Cumulative Flow, mas é mais específico, focando-se apenas no número de tarefas terminadas tendo em conta o número que estava inicialmente previsto. Durante o Sprint Review estes gráficos eram analisados para procurar compreender como correu o Sprint. As horas de esforço diárias eram calculadas para 7 horas por dia em vez de 8 horas, o que perfazia 70 horas por Sprint (considerando 10 dias úteis de trabalho). Esta prática permitia ter uma margem de segurança de 10 horas para eventuais deslizes nas tarefas previstas e outras tarefas rotineiras (reuniões, demos pontuais, etc.). Na Figura 4 pode ser observado um exemplo do gráfico Hours Burndown with Cumulative Flow de um Sprint com 10 dias úteis de trabalho. Figura 4 - Gráfico Hours Burndown with Cumulative Flow. Luís Gonçalo Henriques de Matos 38

63 Ao observarmos o gráfico da Figura 4 é possível perceber a evolução do trabalho realizado ao longo dos dias. Do ponto de vista do Burndown Chart o trabalho restante andou sempre muito perto do linear, ocorrendo apenas pequenas oscilações, no entanto, o trabalho não ficou todo terminado. Podemos também verificar que o número de horas inicialmente previstas não foram as mesmas que as finais, isto deve-se ao facto de algumas tarefas terem demorado mais tempo do que o estimado e de terem aparecido novas tarefas que não estavam inicialmente previstas. Na perspectiva do Cumulative Flow pode-se observar que durante a maior parte do Sprint houve uma considerável percentagem de tarefas em curso (amarelo) e apenas ficaram terminadas mais para o fim do Sprint, embora com algum overwork. Esta quantidade de tarefas em curso, deve-se ao facto de algumas tarefas poderem ser iniciadas isoladamente, mas para serem terminadas já necessitavam de outras serem terminadas primeiro. Apesar de o Sprint ter terminado sem nenhuma tarefa em curso, houve tarefas que não foram sequer iniciadas (cinzento), pelo que transitaram para o Sprint seguinte. Podemos observar também que o esforço (linha azul) não foi linear ao longo do Sprint, tendo ocorrido ligeiras oscilações principalmente nos últimos dias. Na Figura 5 pode ser observado um exemplo do gráfico Workitem Cumulative Flow, do mesmo Sprint. Figura 5 - Gráfico Workitem Cumulative Flow. Observando o gráfico da Figura 5, tem-se uma visão rápida e simples do número de tarefas Pending (cinzento), In Progress (amarelo) e Complete (verde). Neste Sprint em particular, houve uma pequena percentagem de tarefas que ficou terminada logo Luís Gonçalo Henriques de Matos 39

64 no início do Sprint, no entanto houve algumas que ficaram em curso durante grande parte do Sprint, ficando apenas concluídas nos últimos dias. Apesar de não haver nenhuma tarefa que ficou a meio, houve um pequeno número de tarefas que não foram realizadas e que transitaram para o Sprint seguinte. 4.4 Planeamento O planeamento do projecto era feito por duas fases. Na primeira fase os membros da equipa de gestão definiam as features ao nível do roadmap geral, com um nível de detalhe muito reduzido e mais orientadas para objectivos estratégicos e de negócio. Aqui era dada uma estimativa inicial (no Sprint Planning Meeting) para avaliar a viabilidade das features que se pretendiam realizar. A segunda etapa era mais isolada e pertencia apenas a quem ia desenvolver. As features eram analisadas em maior detalhe, sendo divididas em tarefas mais pequenas e mais técnicas. Por vezes era redefinida a estimativa dada na primeira etapa. O roadmap geral consistia num ficheiro Microsoft Project, que era acessível a toda a equipa do WCS. Para analisar as features em maior detalhe era consultado Product Backlog e o Sprint Backlog. O Microsoft Project era mantido pela equipa de gestão, o Product Backlog pela equipa de desenvolvimento, mas sob a orientação do Scrum Master e do Product Owner e o Sprint Backlog era apenas mantido pela equipa de desenvolvimento. Na Figura 6 e na Figura 7 encontram-se um exemplo do Product Backlog e do Sprint Backlog, respectivamente. Figura 6 - Product Backlog. Luís Gonçalo Henriques de Matos 40

65 Figura 7 - Sprint Backlog. 4.5 Equipa de projecto Por se tratar de um estágio este projecto funcionou de certo modo isolado (para não afectar os projectos já em produção) e apenas existiu um developer. Apesar disso, existiu um conjunto de pessoas que fizeram parte da equipa do projecto, conforme se pode observar na Tabela 4. Tabela 4 - Equipa de projecto. Alias Nome Função Responsabilidades LM Luís Matos Developer Planeamento de baixo nível e implementação das features pretendidas. NC Nuno Campos Tutor Técnico Orientações de modo a garantir que o projecto alcançava os objectivos. FL Frederico WCS Product Proprietário dos produtos do WCS e Lopes Owner responsável por priorizar as features a serem implementadas. PP Pedro Pereira CTO Orientações estratégicas de modo a alcançar os objectivos de negócio. Luís Gonçalo Henriques de Matos 41