Shipnet®, IMS,Application server, Service enablers ... · Gestão de identidades,Redes convergentes, Multicast, Redes de acesso ... as noções de ... tam o contacto entre pessoas

3

Web 2.0, IPTV, Telemedicina, Sociedade da informação, Mobile TV, Shipnet®, IMS, Application server, Service enablers, ContextAwareness, Gestão de identidades, Redes convergentes, Multicast, Redes de acesso heterogéneas, IEEE 802.21, Mobilidade transparente, DVBH, Network activator, Autonomic networks, SOA, BPEL, Virtualização de redes, MBMS, SAE, LTE, PBT, TMPLS, Avaliação de projectos, Métricas, Formação.

4 Saber & Fazer Telecomunicações

Título

Saber & Fazer Telecomunicações Revista Técnica da PT Inovação

Edição

PT Inovação 2008

Design

www.dreamlab.pt

Impressão

Litografia Coimbra, S.A.

Tiragem

1 000 exemplares ISSN 1645-8710 Depósito Legal 251344/06

apresentação 5

A difusão do conhecimento adquirido é um dos compromissos que a PT Inovação tem mantido com os seus stakeholders, sendo a revista Saber&Fazer um dos mecanismos utilizados para esse fim.

Muito desse conhecimento é obtido e criado na participação em projectos de experimentação tecnológica, em desenvolvimento de produtos e também na experiência obtida em casos reais de utilização.

Uma das características diferenciadoras da PT Inovação é a co-exis- tência de uma grande diversidade de áreas de trabalho num mesmo Cam- pus, resultando na identificação de áreas de intersecção potenciando a inovação de elevado valor.

Este número da revista Saber & Fazer espelha essa diversidade, contendo art igos nas áreas de plataformas de serviço, sistemas de suporte às operações, evolução de redes, tecnologias de televisão e vídeo, Internet do futuro e Web2.0, formação, telemedicina e ferra-

mentas de apoio à gestão. O con- teúdo reflecte o momento que se vive hoje numa sociedade com cada vez mais necessidade de estar sempre ligado , com acesso imediato a informação suportada na mobilidade e convergência com sobre- posição de tecnologias, intersecção das plataformas de internet e televi- são, tudo num ritmo cada vez mais tempo-real, impondo aplicações de gestão e aprovisionamento flexíveis e de alto desempenho, plataformas de serviço convergentes em redes de alto débito para o suporte de ser- viços ubíquos orientados ao negó- cio, à saúde, ao lazer e segurança.

A todos aqueles que tornaram possível a edição de mais este número da revista, principalmente os autores dos artigos, o nosso agra- decido reconhecimento.

6 Saber & Fazer Telecomunicações

O lançamento do sexto número da "Saber e Fazer Telecomunicações" representa para nós a consolidação de um projecto de difusão de conhecimento da PT Inovação para os seus stakeholders, através de uma revista de Telecomunicações em português, que nos permita dar a conhecer os desenvolvimentos tecnológicos relevantes nesta área, bem como o que se faz no grupo PT. Nesse sentido, este número apresenta um conjunto de artigos com participação de colegas e de parceiros que, em conjunto com a PT Inovação, trabalham na procura de melhores soluções para o grupo.

À semelhança dos números anteriores, incluem-se artigos sobre temas diversos, mantendo a opção, definida desde o primeiro número, de ir ao encontro de uma parte significativa da população que desenvolve a sua actividade profissional no sector das telecomunicações. Nesse sentido, enquanto que alguns dos artigos apresentam uma complexidade técnica significativa, outros são acessíveis a um grupo mais alargado de leitores. Neste nú- mero, os artigos foram agrupados em 6 secções.

O conjunto de artigos sobre Apli- cações e Serviços apresenta os resultados de projectos como a recomendação de conteúdos, uma abordagem Web 2.0, a aplicação da Telemedicina ao Serviço da Pe- diatria, um caso em Angola, e um serviço da acção social da Funda- ção PT e da PT Inovação, PT Tele- aula.

A passagem para os novos modelos de arquitecturas de rede e consequente alteração na dispo- nibilização de serviços é tratada na área de Desenvolvimento de Ser- viços com seis artigos, que vão desde a apresentação de plataformas de desenvolvimento de ser- viços móveis, a plataformas de fornecimento de serviços, sistemas orquestração de serviços, sistemas de filtragem de conteúdos em e-

-mail, e novos paradigmas de ser- viços

A crescente integração de redes e serviços coloca questões de Con- trolo sobre a Rede, que exigem novas abordagens, que permitam não só a convivência de serviços, como também a procura de mobilidade desses serviços. Nesta sec- ção são apresentados artigos de controlo de acesso, soluções de mobilidade e MobileTV.

Os operadores continuam a investir nas plataformas e aplicações de Gestão de Redes e Serviços, como um meio fundamental de dar resposta à necessidade de optimizar processos e monitorar permanentemente a rede. Apresentam- -se, nesta secção, três artigos, dois na área da gestão de redes e um na área da provisão.

O sector das telecomunicações apresenta um dinamismo impar na indústria, o que obriga a uma constante procura de novas soluções; a revista apresenta uma secção sobre Evolução e Desafios, que pretende alargar horizontes, com um artigo sobre Internet de futuro, dois artigos sobre redes móveis e um sobre novas tecnologias de rede de acesso.

Por último, a a secção caracterizada por artigos com foco na Inovação de Processos, aspecto crítico na eficiência de funcionamento das organizações, com um artigo sobre a avaliação de projectos de Ino- vação, um artigo sobre métricas em desenvolvimento de software, e um artigo sobre o processo de con- cepção de formação no âmbito do projecto ATENA.

Em nome de todos os que colabo- raram nesta edição, fazemos votos para que todos os leitores encontrem motivos de interesse neste nú- mero da "Saber e Fazer Telecomu- nicações".

índice 7

Recomendação de Conteúdos: uma Abordagem Web 2.0

A Telemedicina ao Serviço da Pediatria

PT Teleaula Um Serviço da Acção Social da Fundação PT e da PT Inovação

Introdução às Plataformas de Desenvolvimento em Ambientes Móveis

Shipnet ® Service Delivery Framework (SDF)

Plataforma ip-Jib ® : Shipnet ® SIP/IMS Application Server

Exemplo Comercial de uma Solução de Controlo de Serviços de Dados

UPCASE (User Programmable Context-Aware Services)

Filtragem de Conteúdos de E-mail Open-source

Gestão de Identidade e Privacidade em Redes Convergentes: Uma Análise de Potencial

Gestão de Sessões Multicast sobre Redes de Acesso Heterogéneas

Optimização dos Mecanismos de Mobilidade em Redes de Próxima Geração

DVB-H, DVB-SH e DVB-IPDC: Tecnologias DVB para o Mobile TV

Recolha de Desempenho de Equipamentos de Rede no Âmbito do cluster NetB@nd

Gestão Autonómica em Redes de Próxima Geração

Agilização dos Processos de Provisão

O Impasse da Internet

Arquitectura IMS e MBMS Integrada

A Evolução da 3ª Geração Móvel, a Visão do 3GPP

Evolução de Tecnologias de Transporte em Redes de Agregação/Metro

AVALORE Avaliação e Acompanhamento de Projectos de Desenvolvimento de Novas Tecnologias

Pontos de Função e sua Aplicação na PT Inovação

Os Desafios à Formação do Projecto ATENA

Siglas & Acrónimos

8

15

23

28

36

45

52

59

65

72

79

87

94

101

106

111

117

123

130

137

144

152

158

164

Norma Magalhães(Dreamlab)

01

8Saber & Fazer Telecomunicações

palavras-chave:Web 2.0, redes sociais, long tail,

conteúdos, recomendação,IPTV, MEO, SAPO Vídeos, PÉTALA

Este artigo apresenta a Recomenda-ção de Conteúdos Vídeo/TV combase em redes sociais, fazendo oseu enquadramento nos conceitosWeb 2.0 e introduzindo algumas dascaracterísticas mais relevantes desteparadigma Internet: as noções de“User-Generated Content” e de “LongTail”.

Recomendação de Conteúdos:uma Abordagem Web 2.0

Paulo Reis Fausto de Carvalho

Hugo Dias Bernardo Cardoso

As questões associadas à Recomen-dação de Conteúdos são discutidas econcretizadas na abordagem emutilização no projecto PÉTALA, umprotótipo para IPTV/ MEO que a PTInovação está a desenvolver emarticulação com o Laboratório SAPOna Universidade de Aveiro.

Recomendação de Conteúdos:uma Abordagem Web 2.0

9

1. IntroduçãoExplorar, intervir, interagir, criar, personalizar. O internauta de hoje assume indiferenciadamente todos ospapéis e exige ser, cada vez mais, oactor principal na sua interacção noespaço Web. O fluxo tradicional daInternet deixou de ser unidireccional,de armazenamento e recolha deinformação, passando a ser bidireccional: o utilizador pesquisa e obtém,mas também gera, publica, altera epartilha.

Esta alteração marcante é actualmente associada ao conceito Web2.0, termo introduzido em 2003 nasequência de uma sessão de brainstorming entre Tim O'Reilly e DaleDougherty, em que constataram queexistia uma florescente nova geraçãode serviços e comunidades basea-das na Web. A mudança de para-digma da Internet trouxe uma Webque evoluiu para plataforma globalde serviços, com muito maior controlo do conteúdo por parte dos utilizadores e dotada de uma arquitectura claramente orientada para aparticipação. De facto, os serviçosWeb 2.0 aproveitam o efeito multipli

cativo da rede para se tornarem tantomelhores quanto mais usados, tirando partido da inteligência colectivapara oferecer informação com maisqualidade, riqueza e diversidade.

Esta evolução da Internet tem tidoum impacto crescente e significativono modo como as pessoas pensam,aprendem, comunicam e colaboram,ao nível profissional e pessoal. Muitopara além dos aspectos tecnológicosque lhe estão associados, a Web 2.0potencia novas formas de publicação, partilha e organização dainformação e do conhecimento, paraalém de ampliar os espaços de inte-racção entre os participantes no processo. Tecnologias como AJAX,RSS e os microformatos Web 2.0são afinal ingredientes e ferramentaspara novas estratégias, processos emodelos de negócio.

Este artigo enquadra uma área ondeo potencial social da Web 2.0 trazvalor acrescentado tangível para umaárea classicamente disjunta daprópria Internet: a Recomendaçãode Conteúdos Vídeo/TV baseada naopinião colectiva de redes de pes

soas afins, redes sociais onde o utilizador se insere.

Com forte tradição no domínio dosdesenvolvimentos para IPTV/MEO,a PT Inovação tem vindo a investirna criação de capital intelectual nestaárea de conhecimento e está actualmente a desenvolver um protótipodeste sistema de recomendaçõesatravés do projecto PÉTALA, em arti-culação com a actividade do La-boratório SAPO na Universidade deAveiro.

2. Criação informal de conteúdo2.1. Blogs e Redes SociaisActualmente o blog, inicialmente denominado Weblog (“Web log”), é aforma mais popular de publicaçãopessoal na Internet. Diariamente,milhões de pessoas por todo omundo publicam pequenos artigosmultimédia (posts) partilhando infor-malmente vivências, anseios, imagens, notícias, opiniões, assuntosprofissionais, conhecimentos, nor-malmente permitindo que outros utilizadores deixem comentários edando assim origem a sequênciasde mensagens temáticas (threads).

As ferramentas disponíveis para acriação e manutenção de blogs,através de um vulgar browser Internet, são muitas e de fácil utilização,não exigindo conhecimentos técni-cos de grande profundidade. Essaé certamente uma das razões dasua elevada popularidade e a suautilização por pessoas de todos ossectores de actividade acaba porainda contribuir mais para a suadivulgação — o efeito multiplicador.

A necessidade de automatizar apesquisa de actualizações (posts ecomentários) em blogs levou à cria-ção de um mecanismo designadopor Really Simple Syndication (RSS),através do qual é efectuado o download de todos os novos conteúdosa partir dos sítios subscritos. Apesarde “mesmo simples”, o RSS é defacto um poderoso protocolo quepossibilitou a criação de teias deblogs, organizadas por miríades deassuntos e tópicos, numa verdadeira versão peer-to-peer da antigamente tão popular Usenet (news).

A utilização do software dito socialestá igualmente em alta. Há inú-meros serviços na Web que facilitam o contacto entre pessoas e oestabelecimento de redes combase nas relações interpessoais (osamigos dos meus amigos), tanto aonível pessoal como profissional:SAPO Spot, Orkut, Friendster, Facebook, Hi5, LinkedIn e MySpacesão apenas alguns exemplos entreos mais populares.

A dinâmica destas redes sociais assenta fortemente em mecanismosassociados à reputação e populari-dade de cada indivíduo no seio darede a que pertence, gerando consequentemente conteúdo informalabundante em torno de tendênciase opiniões relativas a interessespartilhados pelas comunidades,logo relevante para a temática daRecomendação de Conteúdos endereçada neste artigo.

Em alternativa às rígidas taxonomiasclássicas, a classificação dos con-

teúdos é normalmente feita recorrendo a tags, palavras-chave a partirdas quais é possível organizar informalmente, com base na seme-lhança tal como é percebida pelopróprio utilizador/produtor.

As redes sociais estão de facto a terum impacto cada vez mais significativo na sociedade actual, esbatendo-se as fronteiras entre consumidores e produtores de conteúdo,ócio e trabalho. Mais do que a simples comunicação ou o acto de visi-tar uma página Web, hoje é naturalgerar-se conteúdo a cada momento, seja informalmente em posts oucomentários de blogs, ou mais formalmente em artigos de wikis (informação temática estruturada, deedição colaborativa), consolidandocomunidades fortes congregadas àvolta de interesses comuns que extravasam os limites geográficos, alimentando uma gigantesca rede decomunicação global interactiva eparticipativa que está a redefinir omodo como criamos, trabalhamos,colaboramos e vivemos.

2.2. User-Generated ContentPor oposição ao conteúdo criado porprodutores profissionais especializados, o termo User-Generated Content (Conteúdo Gerado pelo Utilizador) refere-se a todo o conteúdo,seja uma mera visualização ou comentário numa página Web, umpost, uma fotografia ou até um clipde vídeo, gerado por alguém que seinsere no grupo dos utilizadores finaise não no dos produtores. O conceitoendereça assim o esbater da fronteiraentre o produtor e o consumidor, quefaz desaparecer o cariz unidireccionaltão característico dos media maistradicionais, dando lugar a um espaço comum onde os intervenientesconsomem e produzem conteúdo,constroem colaborativamente e seaproximam de um modelo mais democratizado dos media [1].

Apesar de não ser novo, este fenómeno ganhou especial notoriedade


nos últimos anos, impulsionado pela consolidação da arquitectura participativa da Web 2.0. Segundo aAlexa (companhia de análise detráfego na Web), uma significativafatia do tráfego gerado actualmentena Internet (15% dos page viewsdiários [2]) está relacionada com apli-cações centradas ou, pelo menos,potenciadas por User-GeneratedContent, não sendo por isso de estranhar o emergir de novos modelosde negócio em domínios onde tradicionalmente apenas existia conteúdocom origem em produtores especia-lizados.

É o que se passa no caso do IPTV,em que conteúdo gerado pelos utilizadores pode enriquecer as actuais ofertas comerciais, criandodiferenciação e vantagens compe-titivas. Esta oportunidade é particu-larmente interessante no caso dosconteúdos audiovisuais, através deserviços que explorem o vídeo noseu habitat natural — a televisão. Nocontexto do evento SAPO Codebits2007, a PT Inovação apresentouuma aplicação “prova de conceito”da exequibilidade de um serviço departilha de vídeos, similar ao popularYouTube, num cenário de televisãointeractiva. A aplicação MEO Vídeosconsiste num frontend adaptadopara as especificidades do meiotelevisivo (maior distância de visualização, input menos flexível com ocontrolo remoto, etc.), onde o utilizador pode explorar os clips devídeo do portal SAPO Vídeos utilizando uma Set-Top Box e middlewareem tudo semelhantes ao serviçocomercial MEO.

2.3. A importância do Long TailA lógica do conteúdo gerado porutilizadores está associada a umfenómeno interessante que possi-bilita a introdução de modelos denegócio sustentáveis onde, à parti-da, parecia não haver oportunida-des a explorar.

O Long Tail (cauda longa) está associado à procura reduzida para um

11

conjunto elevado de produtos denicho, por oposição à procura elevada para um conjunto pequeno deprodutos mainstream (Short Head).Apesar do seu baixo valor, constata-se que o conjunto dos (muitos)produtos que existem na zona da“cauda longa” tem um valor comercial equivalente aos (poucos) produtos mais populares. Este facto éparticularmente interessante paraconteúdos online, pois a oferta podeser praticamente ilimitada uma vezque os custos de armazenamentoe distribuição são extremamentebaixos [3].

Os consumidores, que anteriormente tinham acesso a um númeroreduzido de conteúdos, passarama ter uma variedade muito alargadade novas opções e, consequentemente, experimentam mais e aca-bam por consumir produtos que atéentão desconheciam, alterando assim os tradicionais padrões de consumo. O que antes constituía ummercado ignorado pelos fornecedores, passou agora a ser economi-camente atractivo e diferenciador.

A abundância de produtos e denichos de mercado torna mais complexa a pesquisa e releva a impor-tância da Recomendação enquantoforma de facilitar e tornar expeditaa opção certa. Em que opiniõesconfiamos? Que recomendaçõesvamos aceitar? Claramente vamosprocurar o que pensam os indivíduos com melhor reputação, com opi-niões mais conceituadas. As redessociais vão assim fornecer as reco-mendações que servem como atalhos no emaranhado de informaçõese que incentivam os utilizadores aexperimentar produtos até entãodesconhecidos — eis de novo oefeito multiplicador Web 2.0.

3. Recomendação de ConteúdosOs intensos fluxos de informação aque estamos expostos diariamente,fruto da digitalização de conteúdos,do aumento dos canais de comunicação e da ubiquidade nas formas

de acesso, faz com que estejamoscada vez mais expostos a um fenómeno que dá pelo nome de “Infor-mation Overload”. Este fenómeno,que se define por estarmos expostos a mais informação do que aquela que poderíamos facilmente assimilar, ainda que associado a algoinequivocamente positivo como ademocratização e facilidade de acesso à informação, levanta algumasquestões problemáticas:

> A informação é fidedigna? E imparcial?

> Como a poderemos filtrar? Comopoderei aceder à informação queme interessa em particular?

> Como reagir perante informaçõescontraditórias?

> Em suma, como adequar a dimensão quase infinita (conteúdos)à dimensão parca e limitada, onosso tempo disponível?

Esta última questão faz com que asmetodologias de acesso aos con-teúdos sejam uma temática extre-mamente debatida actualmente.Particularmente no caso da Web,surge a necessidade de explorarmetodologias de acesso mais inteligentes, adequadas ao que o utilizador deseja e procura, em suma,mais personalizadas. Paralelamente,também faz algum sentido que essas metodologias actuem comopontos de contacto entre o utilizador e a informação “desconhecida”que poderá ser do seu interesse.

Uma destas metodologias de filtragem de informação é precisamentea Recomendação de Conteúdos:utilizando dados fornecidos implícitaou explicitamente pelo utilizador(p.ex. avaliar positivamente um livroou filme vs. simplesmente consultarinformações sobre o mesmo), umsistema tratará de fornecer / reco-mendar ao utilizador uma série deitens que potencialmente serão doseu interesse. Esses itens são infe-

ridos através de comparações entreas características do utilizador — oseu perfil, definido através da informação obtida — e, tipicamente, ascaracterísticas dos itens/ conteúdos.

A Amazon destaca-se como umdos exemplos mais emblemáticosde operacionalização de um sistema de recomendação de conteú-dos com elevado sucesso. Existedesde 1994, tendo-se estabeleci-do como uma loja de livros online.Hoje em dia a Amazon regista umamédia de 615 milhões de visitantespor ano e comercializa um espec-tro muito mais largo de produtos,desde roupa a electrónica de consumo [4]. O seu sistema de reco-mendações, muitas vezes citadoem literatura relativa à filtragem deinformação e recomendação deconteúdos, marca presença na experiência de qualquer utilizador dasua loja online. De facto, desde apágina principal até aos detalhes deum produto em particular, a Amazon destaca itens que poderão suscitar interesse ao utilizador. Essesitens são mostrados com várioscontextos, consoante a secção dosite, podendo ser citados os se-guintes exemplos:

> Recomendação de itens conso-ante o histórico de compras / ava-liações do utilizador (“Top Picksfor You”);

> Recomendação de itens consoante o item que está a ser consultado (“Customers Who BoughtThis Item Also Bought”);

> Recomendação de itens que po-derão complementar o item queestá a ser consultado / adquirido(“Frequently Bought Together”);

> Recomendação de itens que normalmente são adquiridos pelosutilizadores após consultarem oitem que está a ser consultado(“What Do Customers Buy AfterViewing This Item?”).

Recomendaçã de Conteúdos:uma Abordagem Web 2.0


Outro exemplo clássico da recomendação de conteúdos é o sistema Cinematch da Netflix. A Netflix,existente desde 1997, é uma empresa de aluguer de DVD online: osseus cerca de 8 milhões de clientesregistados acedem a uma base dedados de 100 000 títulos e solicitama entrega, em sua casa e por correio, do conteúdo escolhido. Esteconteúdo poderá ser mantido emcasa do cliente por um período detempo mais alargado que o dosvideoclubes tradicionais, devendoo cliente devolvê-lo à Netflix atravésde um envelope de retorno já incluído no aluguer. O sistema de reco-mendações da Netflix (Cinematch)funciona como uma secção do siteonde o utilizador aluga os con-teúdos. O utilizador começa por escolher os seus géneros favoritos evai construindo o seu perfil, alimen-tando o sistema à medida que ava-lia (de uma a cinco estrelas) os con-teúdos que conhece e vê. Essasecção tem o nome de “Movies You'llLove” e, actualmente, é utilizada por60% dos utilizadores na escolha dosconteúdos a alugar [5].

3.1. Abordagens à filtragem deinformaçãoA Recomendação de Conteúdos implica que, através de informação co-nhecida (o perfil do utilizador e umasérie de itens), se obtenha informa-ção previamente desconhecida (itensque potencialmente serão do seuinteresse). Os sistemas responsáveispor este tipo de processo são essencialmente sistemas de filtragem deinformação, cuja finalidade é filtrar osresultados relevantes, partindo deum catálogo extenso de itens e tendoem conta o perfil do utilizador. Esteprocesso de acrescentar informaçãoque não existia previamente, atravésde métodos lógicos e dedutivos, édenominado Inferência e, no casoparticular da recomendação deconteúdos, pode ser abordado atra-vés de duas perspectivas bastantediferentes: a filtragem colaborativa ea filtragem baseada em conteúdo.

A filtragem colaborativa define-sepor ser uma abordagem “social” àrecomendação de conteúdos. O sistema avalia a similaridade entre utilizadores — quer através de um perfil/interesses, quer através de umhistórico de interesse em itens específicos — e recomenda a um dadoutilizador A os conteúdos preferidospelo utilizador similar B.

Por sua vez, a filtragem baseada emconteúdo é uma abordagem maiscentrada no perfil do utilizador e nositens que este já definiu como interes-santes (através de ratings, aquisiçõesou comentários). É uma aproximaçãoque necessita de taxonomias e deum esforço adicional para classificaros itens [6].

Podemos referir os exemplos deduas plataformas de recomendaçãode música actuais, cada uma com asua perspectiva sobre a recomenda-ção de conteúdos: Last.fm, sistemasocial de recomendação de con-teúdos, com uma abordagem assen-te na filtragem colaborativa, e Pandora, sistema de recomendação maisbaseado nos conteúdos propriamen-te ditos e nas suas características.

O serviço Last.fm baseia as suasrecomendações na informação queobtém dos seus utilizadores, enquanto o serviço Pandora, aindaque necessite de algum input, émuito mais centrado nas caracte-rísticas mais ou menos concretasdos itens (as músicas catalogadasno sistema). Esta diferença na abor-dagem faz com que a origem dasrecomendações seja bastante divergente: de um dos lados temos umasérie de itens catalogados por pro-fissionais, do outro temos essencialmente a mesma série de itens, masrelacionada em proximidade peloshábitos de consumo dos seus utilizadores. Estas formas distintas deobter a informação necessária parafiltrar os itens resultam em vanta-gens e desvantagens para cadauma das abordagens à filtragem deinformação:

> A filtragem colaborativa ganha nofacto de não necessitar do esforço/custo de catalogação deitens, pois o feedback implícito eexplícito dos utilizadores é suficiente. Por oposição, os sistemasbaseados na caracterização doconteúdo necessitam de algoritmos ou entidades que sistema-tizem os itens do seu catálogo;

> Por depender do feedback dosutilizadores, a classificação deitens novos de um sistema baseado em filtragem colaborativaé mais difícil. Neste aspecto parti-cular, dado que a metodologia derecolha de informação é maisindependente dos utilizadores eda informação por eles fornecida,os sistemas baseados em con-teúdo conseguem mais facilmen-te ser “iniciados” e classificarnovos itens;

> A filtragem baseada em conteú-dos é demasiado “especializada”,i.e. as recomendações tendem aser mais “previsíveis” e com pou-ca variação. Contrariamente, nossistemas mais sociais é expectá-vel um certo efeito “surpresa”. Nocaso particular dos sistemas derecomendação de música baseados em conteúdo, é provável queo utilizador fique “preso” a um determinado círculo de artistas (dada a sua proximidade na taxonomia predefinida pelo sistema).Num serviço como o Last.fm, énormal (e acontece de forma muito frequente) que um determinado artista A (bastante diferente deB) seja recomendado a um utilizador que goste do artista B — dada a independência do sistema emrelação à proximidade taxonómica.

4. Protótipo PÉTALAA proliferação e a abundância decanais e de conteúdos televisivosdifundidos torna oportuna a ofertaao utilizador final de sistemas que oajudem a mais facilmente identificaros conteúdos que serão potencial-mente do seu interesse. Com base

Figura 1 – Output do protótipo PÉTALA

13 Recomendação de Conteúdos:uma Abordagem Web 2.0

nas características tecnológicas associadas à televisão interactiva (nomeadamente os EPG — guias electrónicos de programação) e apro-veitando a actual dinâmica em tornodos conceitos Web 2.0, a PT Ino-vação idealizou um sistema de reco-mendação de conteúdos televisivosbaseado em filtragem colaborativa,cujo protótipo está a ser criado noâmbito do projecto PÉTALA.

Neste protótipo estabelece-se assim uma ponte entre a recomen-dação de conteúdos baseada emredes sociais, marcadamente Web2.0, e o ambiente TV, exemplo para-digmático da distribuição clássicaprodutor-consumidor, no sentido daobtenção de uma vantagem clara,com adição de valor tangível e facilmente perceptível pelo utilizador final.

O protótipo PÉTALA apresenta umsistema de recomendação idealizado para explorar as vantagens dosmais recentes desenvolvimentostecnológicos (IPTV/MEO) e da receptividade do próprio utilizador anovas metodologias/fontes de co-municação. É um sistema arquitec-tado em termos de interacção parao ambiente típico de TV:

> o output do sistema é integradono EPG/Guia de Programação;

> o output é de consulta fácil e imediata (a título de exemplo, umametáfora “thumbs up/thumbsdown” associada aos conteúdos(ver Figura 1);

> a metodologia de input é igualmente simples, pois o utilizadordá a sua opinião sobre um determinado conteúdo, recomendandoou não à comunidade, através damesma metáfora “thumbs up/thumbs down”.

Trata-se assim de um sistema quepretende ser transparente e nãointrusivo, funcionando em comple-mentaridade com os serviços deEPG, tendo como objectivo fazer

convergir os conceitos da recomen-dação de conteúdos e das redessociais, num cenário de filtragemcolaborativa associado a ambientesTV, onde a proliferação de conteú-dos se faz notar e os métodos defiltragem actualmente disponíveissão ainda incipientes e com largoespaço de melhoria.

5. ConclusõesPelo que foi exposto ao longo desteartigo, fica claramente estabelecidoque a área da Recomendação deConteúdos associada ao potencialdas redes sociais Web 2.0, abreperspectivas interessantes para aintrodução de novos serviços e funcionalidades que irão acrescentarvalor às ofertas comerciais tradicio-nais de Vídeo / TV digital.

É nesse sentido que surge agoraesta aposta da PT Inovação, sustentada pelas actividades de inves-tigação aplicada e experimentaçãoque têm vindo a decorrer ao longodos últimos anos e possibilitada pe-las suas reconhecidas competências no domínio do desenvolvimentode aplicações para IPTV, nomeadamente na família de produtos MEO.

O projecto PÉTALA, desenvolvidopela PT Inovação em articulaçãocom o Laboratório SAPO na Universidade de Aveiro, irá certamentecontribuir para a criação de novas

oportunidades e para a disponi-bilização de funcionalidades atractivas, que tornarão ainda mais agra-dável e interactiva a experiência dosutilizadores de IPTV.


Referências[1] REIS, Paulo; DIAS, Hugo; CARVALHO, Faustode; CARDOSO, Bernardo. reTubing Video Con-tent, NEM Summit 2008, Saint-Malo, França,2008[2] ALEXA. Alexa Top 500 Sites [on-line]. SanFrancisco - USA: Alexa - Amazon Company, 2008[Visitado a 15 Set. 2008]http://www.alexa.com/site/company/contact[3] ANDERSON, Chris, The Long Tail [on-line]Wired, Out. 2004, [Visitado a 15 Set. 2008]http://www.changethis.com/10.LongTail[4] WIKIPEDIA (Contribuintes Diversos). Amazon.Com [on-line]. San Francisco - USA: Wikimedia Foundation, 2008 [Visitado a 15 Set. 2008]http://en.wikipedia.org/wiki/Amazon.com[5] NETFLIX. Netflix Consumer Presskit [on-line].Los Gatos - USA: Netflix Inc., 2008 [Visitado a 15Set. 2008 http://cdn0.nflximg.com/us/pdf/Consumer_Press_Kit.pdf[6] LORENZI, Fabiana. Sistemas de Recomenda-ção [apresentação, on-line] - Brasil [Visitado a 15Set. 2008]htp://www.slideshare.net/renato_shira/sistemas-de recomendao/

Paulo Reis, licenciado em Novas Tecnologias daComunicação pela Universidade de Aveiro. Iniciouo seu percurso profissional na PT Inovação comum estágio curricular subordinado ao tema“Aplicações para Televisão Interactiva”, seguidode estágio profissional com a temática “IPTV: In-terfaces e Interacção”. Actualmente é colaboradorda PT Inovação, no departamento IAD - In-vestigação Aplicada e Difusão do Conhecimento,onde investiga novos cenários na área das apli-cações colaborativas, novos paradigmas deinteracção e televisão interactiva, sendo de desta-car o seu forte envolvimento no desenvolvimentode aplicações e na customização de User Interface da plataforma comercial MEO.

Fausto de Carvalho, licenciado em EngenhariaElectrónica e Telecomunicações pela Universidadede Aveiro. O seu percurso no CET e PT Inovaçãoestá especialmente ligado à área dos serviçosmultimédia interactivos, nomeadamente atravésda participação em múltiplos projectos de I&Dnacionais e internacionais, no âmbito de IPTV eTV Digital Interactiva. Mais recentemente, esteveprofundamente envolvido na introdução do ser-viço Meo. É actualmente responsável pela divisãode Aplicações Colaborativas e Serviços Web 2.0,área de Investigação Aplicada e Difusão de Conhe-cimento, olhando o futuro da Televisão e da Inter-net na perspectiva de novas tecnologias, con-teúdos e modelos de negócio emergentes, nosmais diversos contextos de convergência, interac-tividade e interacção, individualmente e em rede.

Hugo Dias, licenciado em Engenharia Informáticapela Faculdade de Ciências e Tecnologia da Uni-versidade de Coimbra. Iniciou a sua actividade naPT Inovação em 2004, com um estágio curricularsubordinado ao tema “Sistema de Aprendizagemde Base Semântica”, fazendo posteriormente umestágio profissional com o tema “Sistemas deBase Semântica para Gestão e Acesso a Con-teúdos”. Participou no desenvolvimento do “Sis-tema de Gestão de Formação” da plataforma deeLearning “Formare”, estando actualmente atrabalhar na plataforma de IPTV MEO, mais con-cretamente no desenvolvimento de aplicaçõespara a sua integração na oferta de serviços IPTV.Paralelamente, tem participado em iniciativasligadas à Web 2.0 e redes sociais.

Bernardo Cardoso, licenciado em Auditoria Con-tabilística e Mestre em Gestão da Informação pelaUniversidade de Aveiro. Na sua actividade na PTInovação tem estado envolvido em vários pro-jectos relacionados com televisão e vídeo digital,com particular enfoque em sistemas baseadosem MPEG e DVB, nomeadamente sistemas detransmissão de televisão digital e interactividade.Esteve fortemente envolvido no projecto de Tele-visão Digital Interactiva da TV Cabo, ao nível dodesenvolvimento de aplicações, conteúdos, testese análise de desempenho. Mais recentemente, ecomo responsável pela Divisão de Televisão Digitale Serviços IPTV, tem estado ligado às tecnologiasassociadas ao IPTV e contribuído ao nível dacustomização e do desenvolvimento de aplicaçõesno serviço MEO.

Norma Magalhães, licenciada em Tecnologiasde Informação e Comunicação pela Universidadede Aveiro. Fez um estágio curricular na PT Inovaçãono âmbito das Comunidades de AprendizagemDistribuída, acolhido pela equipa Formare. Pos-teriormente, prosseguiu em estágio profissionalorientado ao tema Personalização no LMS Formare.Ensino a Distância, Comunidades de Aprendizagem,eLearning e Web 2.0 constituíram as áreas de in-vestigação e de orientação na concepção doprojecto mencionado. Actualmente, colabora coma PT Inovação no desenvolvimento de aplicaçõesde natureza colaborativa, no âmbito da Web 2.0.

palavras-chave:Telemedicina, Teleconsulta, Telemonitorização,

eSaúde, Tele-ecocardiografia, Sinais vitais

Este artigo apresenta o trabalho de-senvolvido no âmbito de dois projectos: o PEDITEL e o LifeStream. Oprimeiro é um projecto-piloto pio-neiro de eSaúde, centrado na áreada Pediatria, que envolve instituiçõesde saúde de Angola e de Portugal.O segundo é um projecto de desenvolvimento, que visa dotar a solução

Fernando Santiago Manuel Dinis

Paulo de Carvalho(DEI/UC)

António Pena Leandro Vale(DEI/UC))

Jorge Henriques(DEI/UC)

A Telemedicina ao Serviço da Pediatria15

de Teleconsulta Medigraf de valências de aquisição, transmissão e vi-sualização remota de sinais vitais,para apoio no processo de decisãode transferência de pacientes entreunidades de cuidados intensivospediátricos.


1. IntroduçãoA Telemedicina é habitualmente de-finida como a integração das tele-comunicações, informática e ciências médicas, com o objectivo demelhoria global da prestação doscuidados de saúde. São comummente apontadas como vantagensda Telemedicina, a melhoria da quali-dade média dos serviços prestados,a prestação de mais e melhores ser-viços com menos recursos, a disseminação de conhecimentos e competências, a maior satisfação dosutentes, a redução de deslocaçõesmorosas e o aumento da acessibilidade aos serviços especializados,entre outras.

A PT Inovação participa em projec-tos de eSaúde há mais de 10 anos,tendo uma experiência acumuladasignificativa e contando com a colaboração de parceiros de reconhecida idoneidade e competência naárea da saúde. Em 2000, iniciou odesenvolvimento da Solução Medigraf, uma plataforma de suporte aserviços remotos de medicina, ondeo trabalho cooperativo se conjugacom a videotelefonia, partilha de

formação clínica e imagem médica,permitindo aos profissionais de saú-de a colaboração em torno da ob-tenção do diagnóstico clínico, independentemente da distância que ossepara. Actualmente, esta Soluçãoencontra-se instalada em cerca de50 instituições de saúde em Portugal, sendo utilizada por um significativo número de profissionais, em diversas especialidades clínicas.

Na área da Pediatria, a Solução Me-digraf suporta tecnologicamentedesde 2000, a Rede de Teleconsulta em Cardiologia Pediátrica e Fetal,envolvendo o Hospital Pediátrico deCoimbra, o Hospital Santo André(Leiria), o Centro Hospitalar da Covada Beira (Covilhã), o Hospital SousaMartins (Guarda), o Hospital InfanteDom Pedro (Aveiro), o Hospital SãoSebastião (Santa Maria da Feira), oHospital Amato Lusitano (CasteloBranco) e o Hospital São Pedro (VilaReal). Desde então, são realizadasTeleconsultas regulares, programadas e em situações de urgência,com transmissão em tempo real deexames de ecocardiografia. Até àdata, foram realizadas nesta Rede

mais de 6000 sessões de Teleconsulta, com claros benefícios para osPacientes e para as instituições envolvidas.

Fruto da experiência obtida em Portugal, a PT Inovação em conjuntocom parceiros Portugueses e Ango-lanos, lançou o projecto PEDITEL,um projecto de Telemedicina centrado na pediatria, envolvendo insti-tuições de saúde dos dois países.

Na vertente tecnológica, a SoluçãoMedigraf tem vindo a incorporar novas funcionalidades, que a valorizam e a diferenciam face ao mercadopara a qual está direccionada. É dissoum exemplo, o projecto LifeStream,um projecto do Plano de Inovação,co-financiado pela PT Inovação epela TMN, que visa adaptar a Solu-ção a contextos de utilização em unidades de cuidados intensivos pediátricos, embora generalizável aoutros cenários.

Este projecto abre também a possibilidade futura de extensão da utilização da solução a contextos demobilidade.

2. Projecto-Piloto PEDITEL2.1. ObjectivosNo âmbito do Plano de Acção paraa Sociedade da Informação (PASI),o Governo de Angola definiu a áreada saúde como um dos pilares estruturantes. No pilar “Assegurar Saú-de para Todos”, estão definidos alguns projectos segundo um conjuntode eixos, dos quais o desenvolvimento de um programa de Telemedicinase apresenta como uma das prioridades para melhorar o acesso aoServiço Nacional de Saúde de Angola, com as seguintes metas:

> 1 Unidade Móvel de Telemedicinapor província, até 2009;

> 50% das unidades de saúde a utilizar o sistema de Telemedicina,até 2012.

Neste contexto, a PT Inovação naaltura do lançamento em Angola daempresa INOVETEL (empresa dedireito Angolano participada doGrupo PT para o sector do I&D emTelecomunicações e Sociedade deInformação), em colaboração comdiferentes entidades portuguesas eangolanas, decidiu configurar um

projecto-piloto, que designou porPEDITEL, para a implementaçãode uma solução integrada de Telemedicina em Angola. Este projectopretende assim demonstrar a utilidade da Telemedicina num país comas características geográficas de Angola e contribuir para a redução damortalidade infantil, que é das maiselevadas no continente africano.

Para a execução do projecto, queteve início em Novembro de 2007,foram envolvidos diversos parceirosestratégicos nas suas diferentes vertentes de actuação, nomeadamenteo Hospital Pediátrico de Luanda, oHospital Provincial de Benguela, oHospital Pediátrico de Coimbra, aAngola Telecom, a Multitel, a Unitel,a HemoPortugal / HemoAngola ea PT Inovação / INOVETEL.

2.2. Descrição técnica do projectoA implementação do projecto foiidealizada para duas fases distintas,correspondendo a primeira à efectivação da ligação de Coimbra a Luanda e a segunda à expansão àprovíncia de Benguela.

O projecto contemplou a instalação

17

dos terminais específicos necessários para a prática de Teleconsulta(Sistemas Medigraf) e a implementação da rede de interligação entreas instituições de saúde, na qualparticiparam os operadores de tele-comunicações envolvidos. A solução implementada (Figura 1) possibilita a realização de sessões deTeleconsulta em tempo real entre asunidades de saúde envolvidas noprojecto e permite o acesso externo, via internet, para avaliação emdiferido de casos clínicos.

2.3. ResultadosO projecto PEDITEL encontra-se nafase final de implementação, tendosido já realizadas e contabilizadascerca de duas centenas de Teleconsultas de Cardiologia e Oncologia Pediátrica. Foram ainda identificadas outras especialidades clínicasque podem também beneficiar dainfra-estrutura instalada, nomeadamente: Anatomia Patológica, Oftalmologia, Nutrição e Infecciologia.Tirando partido da capacidade detransmissão disponibilizada pelo circuito internacional (512 Kbps), e dacomponente de videoconferência

A Telemedicina ao Serviço da Pediatria

Figura 1 – Diagrama da solução

Hospital Pediátrico de Coimbra Hospital Provincial de Benguela

Lisboa Luanda

Acesso InternetBanda Larga

Hospital Pediátrico de Luanda

ServidorInternetMedigraf

PlataformaMedigraf SE

ADSL / XDSLUplink 512Kbps+

PC Portátilc/ softwareMedigraf AR
















Link IP512Kbps c/ QOS




Internet

PlataformaMedigraf SEPlataforma

Medigraf SE


da plataforma de Telemedicina, foitambém possível realizar cursos àdistância em várias áreas clínicas ede enfermagem, com grande aceitação por parte dos profissionais desaúde angolanos. Na continuidadedestas acções, estão previstas novas iniciativas na área da Nutriçãoe Oftalmologia, assim como a repe-tição dos telecursos para o HospitalProvincial de Benguela.

A realização de sessões de tele-for-mação de Portugal para Angola evice-versa permite uma “fertilizaçãocruzada” de grande potencial paraambos os países, permitindo ummelhor conhecimento das suas reali-dades e a consequente aceleraçãodos níveis de desenvolvimento naárea da saúde. Esta actividade po-de ser complementada com arealização de estágios ou mesmomissões de intercâmbio dos profissionais de saúde.

Apoiado no sucesso do projectoPEDITEL, o Ministério da Saúde deAngola pondera a expansão doserviço de Telemedicina para outroshospitais centrais de Luanda e ou-tras províncias do país. A implementação de uma rede nacional deTelemedicina é uma das ambiçõesdo governo angolano, no sentidode disponibilizar às populaçõesmais distantes de Luanda serviços

médicos especializados, permitindouma gestão mais efectiva do transporte dos doentes e uma detecçãomais precoce de patologias graves.

Também a colaboração entre asinstituições de saúde angolanas eportuguesas poderá ser fortementealavancada pela utilização da Telemedicina. O contacto permanenteentre os profissionais de saúde permite que se extravase o âmbito dasTeleconsultas para contemplar a formação em Portugal dos médicos oua implementação de infra-estruturascirúrgicas ou laboratoriais ainda nãodisponíveis no território angolano.

3. Projecto LifeStream3.1. ObjectivosDiariamente, a transferência de do-entes para os hospitais centrais envolve um processo de decisão queé efectuado, regra geral, com baseem informação coligida em conversas telefónicas entre profissionaisde saúde. Idealmente, a tomada dedecisão deveria ser baseada numaanálise objectiva do estado do doente, o que, para além da observaçãodos exames imagiológicos e de ou-tros dados clínicos recolhidos (análises, antecedentes clínicos, etc.),requer a monitorização e avaliaçãodos sinais vitais do paciente no momento da tomada de decisão. Oprocedimento actualmente aplicadoinduz com frequência transferênciasdesnecessárias ou contra-indicadasde doentes para os hospitais centrais. O projecto LifeStream visa a-poiar os profissionais de saúde noprocesso de decisão de transferên-cia, disponibilizando funcionalidadesde monitorização remota dos sinaisvitais do paciente.

A integração na Solução Medigraf,de protocolos e mecanismos específicos para a aquisição/interfacecom monitores de sinais vitais e asua codificação e transmissão, permitirá dar resposta efectiva a necessidades actuais de serviços deunidades de cuidados intensivos,bem como a contextos de emer-

gência médica, saúde preventiva eapoio domiciliário de equipas clínicas geriátricas ou outras.

O projecto LifeStream tem comoprincipais objectivos:

> O desenvolvimento de interfacespara a interligação e comunica-ção transparente com os monitores de sinais vitais;

> O desenvolvimento e avaliaçãode CODEC (codificação e descodificação) específicos para a transmissão de sinais vitais;

> O desenvolvimento de módulospara a visualização e análise (porexemplo segmentação de ECG edetecção de arritmias, etc.) deséries temporais relativas aos sinais vitais;

> Integração dos módulos desenvolvidos na Solução Medigraf;

> A realização de ensaios de ava-liação da solução em contextomóvel.

3.2. Abordagem técnicaA Figura 3 ilustra um cenário possí-vel de utilização, previsto no âmbitodo Projecto LifeStream.

A configuração desta solução passa pela interligação de duas es-tações Medigraf, emissora ou central e receptora ou distrital, atravésde uma rede de comutação de pacotes. A estação emissora encontra-se conectada a um ou váriosequipamentos de monitorização clí-nica (por exemplo, um monitor desinais vitais, equipamento móvel deECG, SpO2, etc.), a partir dos quaissão adquiridos sinais vitais. Uma vezobtidos, os sinais vitais são processados e transmitidos, em tempo realou em modo diferido, para a estaçãoremota.

Atendendo às funcionalidades jádisponibilizadas pelo Medigraf,assume particular relevância a

Figura 2 - Sessão de Teleconsulta entre osHospitais Pediátricos de Luanda (cima) eCoimbra (baixo).

19 A Telemedicina ao Serviço da Pediatria

integração na plataforma de capacidades de gestão de aquisição, dearmazenamento e de tratamento debio-sinais para transmissão (incluindo compressão e descompressão)e o diagnóstico automático dosmesmos. Relativamente ao desenvolvimento de CODEC que possibilitem a transmissão eficiente dainformação, (situação que terá particular relevância num cenário mó-vel), refere-se o desenvolvimento dealgoritmos de compressão semperdas e com perdas, em particularpara o sinal ECG. Os primeiros, baseados em modelos de regressãoe de predição, permitem taxas decompressão na ordem dos 3:1; ossegundos, usando técnicas de dicionário e representação por cur-vas de Bézier permitem atingir taxasde compressão na ordem dos 24:1com taxas de erro na ordem dos 7%.

No que diz respeito ao desenvolvimento de soluções para a visualiza-ção e análise de séries temporaisrelativas aos sinais vitais, refere-sea detecção de alguns tipos pertinentes de arritmias, nomeadamentea detecção de ritmo cardíaco, extrasístoles ventriculares e fibrilhaçõesauriculares.

3.2.1. MódulosDe forma a conferir flexibilidade àsolução face aos requisitos, agrupou-se a implementação em três

módulos principais: módulo de aqui-sição, módulo de comunicação emódulo de visualização.

O módulo de comunicação é res-ponsável pela gestão dos canais decomunicação entre as duas esta-ções. Disponibiliza canais TCP, paraa transferência de informação decontrolo com garantia de entrega ecanais RTP / RTCP para transmissão em tempo real de informaçãode sinais vitais. Disponibiliza aos ou-tros módulos informação sobre estado dos canais estabelecidos (taxade erros, jitter, etc.), permitindo aestes adaptarem-se às condiçõesde transmissão.

O módulo de aquisição tem por funcionalidade principal servir demiddleware das redes de sensoresconectadas à plataforma, assumin-do, em particular, a responsabilidade pela gestão da aquisição dossinais provenientes de equipamentos clínicos, pelo respectivo processamento, pela preparação dos dados para transmissão e pelo seuarmazenamento (logging).

O módulo de visualização é responsável por apresentar visualmente aos profissionais de saúde osdados provenientes do módulo deAquisição. Esta solução faculta umdesacoplamento entre as duas funcionalidades de recolha e reprodu-

ção de dados clínicos, aumentandoa capacidade de adaptação dasolução e também a segurança.

A concepção e implementação dosmódulos de aquisição e visualização, bem como CODEC são efectuadas pelo DEI/UC (Departamentode Engª Informática da Universidadede Coimbra). A integração dos mó-dulos na Solução Medigraf é realizada pela equipa de desenvolvimentoda solução, na PT Inovação.

3.2.2. ArquitecturaA Figura 4 apresenta a arquitecturada solução implementada.

A solução foi desenhada numa lógica multi-camada, sendo compostapelas seguintes camadas:

> Data sources: camada é responsável pela aquisição de informa-ção. Por aquisição entende-senão só a interacção directa comequipamento de aquisição de sinais vitais, mas também a obten-ção de dados de outras fontes deinformação, por exemplo dadosarmazenados previamente emlogger;

> Parsing: camada responsável pelatradução / conversão dos váriostipos de dados (numérico, sinaistemporais e alertas) para o formato XML e respectivo encami

Figura 3 - Cenário de Utilização

PacketSwitchedNetwork

Estação clienteresponsável pela

visualização dosinal transmitido

EstaçãoMedigraf

EstaçãoMedigraf

Estação responsável pelaaquisição do sinal do

monitor e consequentetransmissão

Bluetooth

Balança

802.15.4

Monitor clínicode sinais vitais

USB/ RS 232 / Ethernet

PressãoArterial


nhamento para os vários canaisde processos;

> Processamento: camada que integra os vários dynamic layer container (DLC), que definem as etapas de processamento a seremimplementadas aos dados. Sãoexemplos de sub-camadas possíveis: compressão, segurança,reamostragem de sinal, detecçãode ruído, etc.;

> Data Sync: camada que comportaos módulos consumidores dasetapas de processamento anteriores. Engloba os componentesde comunicação, logger e visualização.

O componente de comunicação éresponsável pelo envio de dados,interagindo portanto directamentecom o software Medigraf.

O logger, tal como implementado,funciona simultaneamente comoconsumidor e como produtor de dados. Integra-se de forma transpa-rente no middleware, permitindo,em particular, que funcione de forma distribuída, uma vez que os dados armazenados numa instân-cia do middleware podem ser acedidos por outras instâncias de formatransparente. Deu-se ainda particular atenção aos mecanismos detolerância a falhas e de recuperaçãode dados, bem como o acesso ale-atório de leitura e a transparênciano acesso simultâneo de escrita eleitura. Diversos mecanismos decaching foram também integradosde forma a aumentar a escalabili-dade da solução.

O componente de visualização éresponsável por apresentar visualmente a informação. É a partir destecomponente que se processa ainterface com o software Medigraf,permitindo a visualização/interacçãocom o utilizador de uma forma integrada. Esta camada deverá aindaintegrar a visualização dos resultados dos algoritmos de processa

mento e análise de sinais vitais (emespecial ECG) que permitam detectar automaticamente diversas patologias, tais como arritmias e permitira geração de alertas. Esta camadadisponibiliza ainda funcionalidadesde configuração dos dados a adquirirdo equipamento de monitorização.É suportado o uso de templates deforma a armazenar perfis de visuali-zação predefinidos, sendo ainda permitida a configuração específica dosdiversos parâmetros (cor, tipo de tra-ço, etc.) de cada canal.

3.2.3. AdaptabilidadeDe forma a permitir que o middleware possa responder não só aosrequisitos imediatos da aplicaçãoclínica identificada, mas também às

exigências futuras expectáveis (porexemplo, sistemas distribuídos deaquisição de sinais vitais, novos e-quipamentos e protocolos, redes he-terogéneas de sensores, etc.), omiddleware recorre ao conceito deentidades abstractas de fonte de dados e de consumidor de dados, aolongo das diversas camadas quecompõem a arquitectura. Na últimacamada, é aplicada uma abstracçãobaseada em serviços, expondo-seos dados recolhidos ou transformadoscomo serviços ao consumidor final.

Pelo uso desta filosofia, todos oscomponentes expansíveis comuni-cam usando o mecanismo de plug--in descrito, permitindo que os protocolos de comunicação e dos dis

Figura 4 - Arquitectura da Solução

Serviço A

Serviço B

Comunicação

Dat

aSou

rce

Dat

aSyn

csP

roce

ssam

ento

Par

sing

Dat

aSou

rce

Visualização

DLC

Equipamento deAquisição

Equipamento deAquisição

Interpretação e Encaminhamento (XML)

Life

Str

eam

Comunicação Logger

Análise

Sampler

...

Compressão

Sampler

...

DLC

Dad

os R

AW

Dad

os R

AW

Estação Medigraf® (Receptora)

Estação Medigraf® (Emissora)

21 A Telemedicina ao Serviço da Pediatria

positivos clínicos possam ser carregados e incorporados de formadinâmica e em runtime (se necessá-rio) recorrendo a abstracções apro-priadas por forma a garantir o encapsulamento. Deste modo, omiddleware prepara o Medigrafpara operar em ambientes clínicosheterogéneos e desconhecidos apriori, facultando-lhe os mecanismos base para que possam ser incorporados serviços de detecção eauto-configuração de sensores(plug&play de novos sensores eprotocolos, de novas redes de sensores como 802.15.4, Zigbee, etc.),manutenção automática ou ainda amanutenção remota.

Outra mais-valia decorrente da abs-tracção produtor/consumidor dedados prende-se com o facto depoderem coexistir múltiplas instâncias do middleware de forma distribuída com capacidade de relayingde dados entre dispositivos, o queaumenta a mobilidade da solução.Isto poderá ainda facultar a ligaçãotransparente entre módulos distri-buídos em ambiente hospitalar(por exemplo, servindo de gatewayquando um equipamento fica distante da estação Medigraf), preparando ainda o ambiente para novoscontextos de aplicação como, porexemplo, em contextos de pHealthem que poderão coexistir múltiplosequipamentos terminais (PDA, set-top-box, etc.) e onde poderá sernecessário que o middleware operecomo gateway entre redes de sensores distintas (por exemplo, redesBluetooth, redes 801.15.4, etc.) ouainda entre estas e o nó Medigrafcentral.

A filosofia de design aplicada na camada de processamento recorreaos mesmos princípios de flexibilidade (Figura 4). Nesta camada umapilha de processamento é definidapela ligação de um ou mais blocosde processamento com funções e-lementares (por exemplo, compres-são de dados, detecção de ruído,especialização de operações de

diagnóstico clínico, encriptação, etc.),cada um servindo como consumidordos dados do bloco anterior e comoprodutor de dados para o bloco queo sucede. Também nesta situação odesign facilita que uma dada pilha deprocessamento seja alterada de forma dinâmica, permitido que a plataforma adapte on-the-fly o processamento que se encontra a realizarsobre os dados. Deste modo, é possível que o middleware altere dinamicamente o CODEC (por exemplo, emfunção das características e condi-ções da rede), incorpore novas tare-fas de análise de dados ou personalize processamentos (por exemplo,a extracção de uma nova tendênciade um sinal fisiológico para uma aplicação clínica) de forma dinâmica esem requerer intervenção directa dasequipas técnicas, na medida em queestes blocos de processamento po-derão ser descarregados remotamente.

3.3. ResultadosActualmente o projecto LifeStreamencontra-se em fase final de integra-ção dos módulos desenvolvidos nosoftware Medigraf. A Figura 5 apresenta imagens respeitantes à visualização de sinais vitais no Medigraf.No sentido de se avaliar e validar,em ambiente real, a solução desenvolvida, está prevista a realização deum piloto, que decorrerá a partir deOutubro, envolvendo o Hospital Pe-diátrico de Coimbra e o Hospital Santo André-Leiria.

Está igualmente prevista a realização de alguns ensaios de campoem cenário de mobilidade, utilizandoa rede móvel como infra-estruturade comunicação.

4. Importância para negócios dogrupo PTO projecto PEDITEL tem sido umpoderoso instrumento para a divulgação da empresa INOVETEL emAngola, confirmando o sucesso daestratégia adoptada pela administração da empresa. A forte divulga-ção pelos meios de comunicaçãosocial desta iniciativa contribuiu paraque muitos angolanos e portugueses ficassem a conhecer as capa-cidades e benefícios da Telemedi-cina e associar esse potencial aoGrupo PT / PT Inovação / INOVETEL.

Sendo a área da saúde, e particularmente a Pediatria, uma área emforte desenvolvimento e muito importante para Angola, existe um potencial de colaboração internacionale de negócio que a INOVETEL po-derá captar e facilitar. Por outro la-do, Angola é um dos países membros da SDAC (Southern AfricanDevelopment Community), pelo quea solução aí implementada, poderátambém vir a ser estendida a outrospaíses da região. A disponibilizaçãopor parte da União Europeia de fundos especificamente para paísesafricanos poderá ser uma importan-te oportunidade a explorar futuramente.

O projecto LifeStream potencia aexpansão da utilização da SoluçãoMedigraf a novos cenários e contextos de utilização, abrindo cami-nho para a implementação futurade uma solução de Telemedicinaespecificamente desenhada paraambientes de mobilidade, com umâmbito de utilização alargado, incluindo emergência médica, saúdepreventiva e apoio domiciliário.

Figura 5 - Visualização de Sinais Vitais

5. ConclusõesA utilização de Telemedicina permitea disponibilização de mais e melho-res serviços junto das populaçõesque se encontram distantes dosgrandes centros, sem que tal implique necessariamente um aumentodo número de profissionais de saú-de. Este facto contribui para o aumento da satisfação dos utentes,evitando deslocações desnecessá-rias, morosas, incómodas e caras.Os utentes passam a ter acesso aserviços especializados que de outraforma não estariam ao seu alcance,ou pelo menos de forma tão rápida.

Por outro lado, a prática de Telemedicina envolve vários profissionaisde diferentes unidades de saúde,tendo como consequência directaa melhoria da comunicação entreesses profissionais e a formaçãoon the job sem necessidade de seausentarem do local de trabalho,potenciando também a realizaçãode outras actividades profissionaisque extravasam o âmbito da Telemedicina.

O projecto PEDITEL pretende ser oembrião de uma solução global deTelemedicina a implementar em todo o território angolano, permitindoestender os benefícios desta actividade a toda a população. Angolatem actualmente limitações em termos de meios de comunicação terrestres, bem como uma grande faltade profissionais de saúde especialistas em várias províncias. As vantagens do recurso à Telemedicinasão assim evidentes e principalmente para os utentes da rede de saúdepública, que habitualmente têm me-nos recursos, não lhes permitindoprocurar outras alternativas. Espera--se que a generalização da Telemedicina neste país africano tenha umimpacto muito positivo na taxa demortalidade e consequentementeno aumento da esperança de vidadas populações.

O projecto LifeStream, por seu lado,potencia a extensão das capacida-

des da Solução Medigraf a novoscontextos e cenários de utilização,contribuindo para a consolidaçãodesta, como solução abrangente deTelemedicina, quer para a área daPediatria, quer para outras áreasclínicas.

Referências[1] Manuel DINIS, Fernando SANTIAGO, EduardoFRAUSTO, Rosalina GONÇALVES, Nicolau NETTO, Eduardo CASTELA, Luís BERNARDINO e Alfredo CAETANO, PEDITEL Project: a Step for aTelemedicine Network Solution in Angola Exportable to other African Countries, IST África 2008,Maio 2008, Windhoek, Namíbia.[2] Brito, M. and Henriques, J.and Carvalho, P.and Ribeiro, B. and Antunes, M. , An ECG compression approach based on a segment dictionaryand Bezier approximations, 15th European SignalProcessing Conference (EUSIPCO-2007), 2007[3] Brito, M. and Henriques, J. and Carvalho, P.d. and Ribeiro, B. and Antunes, M. , ECG Compression through segment matching and progressive error encoding, EMBC -2007, 29th AnnualInternational Conference of the IEEE Engineeringin Medicine and Biology Society,2007[4] R. Couceiro, P. Carvalho, J. Henriques, M.Antunes†, M. Harris, J. Habetha, Detection ofAtrial Fibrillation Using Model-based ECG Analysis,Int. Conf. On Pattern Recognition, 2008.[5] R. Couceiro, P. Carvalho, J. Henriques, M.Antunes, On the Detection of Premature Ventricular Contractions, EMBC -2008, 30th Annual International Conference of the IEEE Engineering inMedicine and Biology Society, 2008

Fernando Santiago, licenciado em EngenhariaElectrónica e Telecomunicações pela Universi-dade de Aveiro. Ingressou na empresa AutorTecnologias Multimédia Lda em 1994, ondedesenvolveu actividades como analista pro-gramador e de coordenação de desenvolvi-mento de soluções multimédia. Ingressou noCentro de Estudos de Telecomunicações em1998, na área de Desenvolvimento de Serviçose Aplicações, onde participou no desenvolvi-mento de aplicações Web corporativas, para aintranet da PT. Desde 2000, coordena odesenvolvimento da Solução de TelemedicinaMedigraf.

Manuel Dinis, doutorado em Engenharia Electro-técnica e Licenciado em Engenharia Electrónicae Telecomunicações pela Universidade de Aveiro.Em 1996 ingressou nos quadros da PT Co-municações S.A., encontrando-se cedido à PTInovação S.A. Desde Outubro de 2007 trabalhano projecto de criação da empresa INOVETEL -INOVAÇÃO E SISTEMAS DE COMUNICAÇÃO,SA em Angola onde é responsável pela áreada Sociedade de Informação e colabora naárea dos sistemas NETBAND. Foi Vogal doConselho Directivo da Agência para a Moder-nização Administrativa (AMA). Colaborou com oInstituto de Telecomunicações em Aveiro e foiAssistente Convidado no Departamento de

Electrónica, Telecomunicações e Informática daUniversidade de Aveiro. Desde 1994 esteveenvolvido em diversos projectos de I&D nacio-nais e internacionais tendo sido gestor de váriosprojectos europeus na área das comunica-ções móveis nomeadamente SEACORN, B-BONEe C-MOBILE. É especialista em planeamentocelular e redes móveis de banda larga. Publi-cou mais de 60 artigos técnicos em revistas econferências nacionais e internacionais.

António Pena, licenciado em Engenharia Infor-mática e de Sistemas pelo Instituto Superior deEngenharia de Coimbra. Trabalhou durante trêsanos como Analista e Programador para a CriticalSoftware, no desenvolvimento de aplicações paraa área das Telecomunicações. Ingressou na PTInovação em 2005 onde tem trabalhado comoAnalista e Programador em projectos para a áreada Médica, Medigraf, LifeStream, etc.

Leandro Vale, licenciado em Engenharia Infor-mática pela Universidade de Coimbra em 2007.Integra desde essa altura o CISUC - Centro deInformática e Sistemas da Universidade deCoimbra, exercendo actividades de investigaçãono grupo de Computação Adaptativa, com espe-cial enfoque na área clínica.

Jorge Henriques, doutorado em EngenhariaInformática pela Universidade de Coimbra em2001. É actualmente Professor Auxiliar noDepartamento de Engenharia Informática daFCTUC. Foi fundador e integra, desde a suaformação em 1991, o CISUC - Centro de Infor-mática e Sistemas da Universidade de Coimbra,exercendo act iv idades de invest igaçãono grupo de Computação Adaptativa. Foico-fundador do laboratório de Informática Clínicado CISUC. Os seus interesses centram-se nainvestigação de metodologias de InteligênciaComputacional e suas aplicações a problemasde modelização, diagnóstico e decisão, emsistemas complexos e não lineares, em particu-lar na área clínica. Desempenhou o cargo deDirector Executivo do Laboratório de Informáticae Sistemas do Instituto Pedro Nunes de 2001 a2004. É actualmente vogal do colégio deEngenharia Informática da Ordem dos Engenheiros.

Paulo de Carvalho, doutorado em EngenhariaInformática pela Universidade de Coimbra em2002. É actualmente Professor Auxiliar noDepartamento de Engenharia Informática daFCTUC. Foi fundador e integra, desde a suaformação em 1991, o CISUC - Centro de Informá-tica e Sistemas da Universidade de Coimbra,exercendo act iv idades de invest igaçãono grupo de Computação Adaptativa. Foi co--fundador do laboratório de Informática Clínica doCISUC. Os seus interesses centram-se nainvestigação em informática médica com particu-lar relevância no processamento e análise desinal/imagem e de metodologias de reconhe-cimento de padrões aplicados a problemasde diagnóstico e decisão. Desempenhou o cargode Vice-presidente do Instituto de InvestigaçãoInterdisciplinar da Universidade de Coimbra.É actualmente Vice-Presidente da ComissãoCientífica do Departamento de EngenhariaInformática.


palavras-chave:Educação; eLearning; Acção Social; Ensino aDistância; Aplicações; Sociedade da Informação;

O Grupo PT tem procurado, ao longo dos últimos 20 anos, dar respostaàs necessidades de telecomunica-ções dos cidadãos com deficiênciase incapacidades, participando emprojectos inovadores que visam asua inclusão social, no âmbito dosquais tem desenvolvido um conjuntode produtos e serviços de telecomu-nicações facilitadores da desejadainclusão escolar e profissional.

De acordo com a especificação efectuada pela Fundação PT, e no âmbito da parceria estabelecida com aDirecção Geral de Inovação e Desenvolvimento do Ministério da Edu-cação intitulada Projecto ASTRO, aPT Inovação desenvolveu uma solu-ção tecnológica inovadora de alta performance, possibilitando a um alunoassistir remotamente, e em temporeal, às aulas que decorrem na salade aula da escola que frequenta.

PT Teleaula — Um Serviço da AcçãoSocial da Fundação PT e da PT Inovação

Clara Cidade(Fundação PT)

Arnaldo Santos

Paulo Garcez(Fundação PT)

Artur Neves

Instalada em várias escolas nacionais, a solução PT Teleaula destina--se essencialmente a crianças do ensino básico e secundário com defi-ciências graves ou doenças crónicase prolongadas, que estão impedidasde se deslocar à escola para assistiràs suas aulas.

Este artigo tem como principal objectivo apresentar a solução PT Tele-aula, os locais onde está instalada eo impacto que tem na comunidadeescolar, nomeadamente, nas crian-ças que, por motivos diversos, estãoimpedidas de se deslolar à Escola paraassistir, presencialmente, às aulas.

23

03PT Teleaula — Um Serviço da Acção

Social da Fundação PT e da PT Inovação


1. IntroduçãoA solução PT Teleaula é um projectoda PT Inovação em parceria com aFundação PT, que consiste na cria-ção de soluções educacionais e re-creativas de forma a promover a in-tegração escolar de crianças quenão podem deslocar-se à Escola,através da utilização das Tecnolo-gias de Informação e Comunicação(Figura 1). Para garantir os objecti-vos do PT Teleaula, a PT Inovaçãodesenvolveu uma solução tecnoló-gica inovadora que consiste numambiente colaborativo integrado,possibilitando a um aluno assistirremotamente, e em tempo real, àsaulas, que decorrem na sala de aulada escola que frequenta (Figura 2).

Esta solução possibilita a comunica-ção remota entre a Escola e a Casado Aluno com acesso a um conjun-to de serviços e funcionalidades, no-meadamente: Videoconferência (áu-dio e vídeo); Envio e recepção demensagens escritas (chat); Envio erecepção de ficheiros; Trabalhocooperativo (partilha de aplicações);Selecção da câmara activa (remotae localmente); Controlo da posiçãoe nível de zoom da câmara PTZ(pan-tilt-zoom); Acesso à Internet eEducação a distância e eLearning.

2. Solução técnicaEsta solução apresenta uma confi-guração diferenciada para cada umdos dois ambientes de utilização (Fi-gura 3): em casa do aluno e na sala

de aula (escola). Para cada um des-tes ambientes foi criado um kit, coma seguinte diferenciação:

> O Kit Aluno permitir visualizar ecomutar à distância entre as duascâmaras da sala de aula (fixa ePTZ), bem como estabelecer ocontacto audiovisual com a salade aula, possibilitando uma intervenção activa na aula;

> O Kit Escola cria os meios paraque o aluno, remotamente, sepossa sentir completamente integrado na aula.

A Figura 2 ilustra os principais componentes presentes na solução Teleaula sendo garantida uma largura

Figura 1 - Exemplo de um aluno Teleaula

de banda de 128Kbps entre a escola e o aluno.

O PT Teleaula é uma aplicação de-senhada e desenvolvida numa arquitectura.NET Miscrosoft (Framework 2.0) que permite aceder a umconjunto de funcionalidades, ilustradas na Tabela 1.

Das funcionalidades referidas, osserviços de áudio e de vídeo, e ocontrolo remoto das câmaras, apresentam-se como os mais utilizadose os que diferenciam a solução PTTeleaula de aplicações semelhantes,existentes no mercado. O serviçode Videoconferência permite ver eouvir a outra parte em tempo real,através de um sistema de uma oumais câmaras (num máximo de três)e um ou mais microfones instaladosna escola, e uma câmara e um

sistema microfone / auscultadoresinstalados no aluno.

A solução PT Teleaula disponibilizauma câmara de vídeo PTZ (Pan-Tilt-Zoom), que permite controlar aposição horizontal e vertical, assimcomo o nível de zoom. O aluno (e aescola localmente) poderá escolheruma de seis posições pré-definidaspela Escola, e/ou controlar totalmente a posição e o nível de zoomda câmara.

A configuração das posições pré--definidas fica inteiramente a cargoda escola, assim como a permissãoou não, do controlo da câmara peloaluno.

3. ResultadosInstalada em várias escolas em Portugal, a Solução encontra-se dis

PT Teleaula — Um Serviço da AcçãoSocial da Fundação PT e da PT Inovação

25

ponível num total de 20 escolas / alu-nos, dispersas por vários distritos(Figura 5):

Aveiro - 2Viseu - 3Guarda - 1Castelo Branco - 1Leiria - 2Lisboa - 3Setúbal - 2Bragança - 1Faro - 5

Tendo como base o protocolo estabelecido entre o Grupo PT e o Mi-nistério da Educação, prevê-se ainstalação de mais 10 soluções Teleaula para 2009.

4. ConclusõesO impacto deste projecto no desenvolvimento individual e curricular des-

Figura 2 - Solução técnica da PT Teleaula

Figura 3 - Kit Aluno e Kit Escola

Web Cam

Auscultador c/ Microfone/Headphones w/ Microphone

RouterPC Multimédia

/ Multimedia PC

Câmara PTZ/ PTZ Camera

Câmara Fixa/ Fixed CameraAuricular Bluetooth

/ Headset Bluetooth

Placa de Aquisição de Vídeo/ Video Capture Board

Kit Aluno / Student Kit Kit Escola / School Kit

RouterPC Multimédia

/ Multimedia PC

Internet(ADSL)

Hospital/ Hospital

Casa do Aluno/ Student’s Home

Escola/ School


Figura 5 - Mapa de instalações por Distrito

Figura 4 - Janela de videoconferência

tes alunos é reconhecido pelo sectorda educação, havendo a expectativade poder ser alargado às regiõesautónomas da Madeira e Açores.

As crianças destas escolas, algumas delas com deficiências gravesou doenças crónicas e prolongadas, que estão impedidas de sedeslocar à escola para assistir àssuas aulas, passaram a usufruir dosmesmos direitos e a ter acesso àeducação ao longo da vida.

Verifica-se, com agrado, que algumas delas, apresentam resultadospedagógicos muito satisfatórios euma alegria imensa pelo facto depoder, remotamente, estar na suasala de aula ao lado dos seus amigos de turma, dando-lhes uma sensação de igualdade e conforto.

Estes valores humanos, associadosà utilização da tecnologia que oGrupo PT desenvolve, representamum dos principais pilares que orientam a Fundação PT e a PT Inova-ção, criando valor e aplicações paraa Sociedade da Informação e doConhecimento.

Tabela 1 - botões da barra de ferramentas da PT Teleaula

11

1

1

3

3

2

2

2

5

Açores

Madeira Portugal

Botão Descrição

Este botão permite iniciar ou terminar uma sessão com um sistema remoto.Dependendo da configuração do outro sistema, a sessão pode começarautomaticamente ou apenas depois de ser aceite pelo outro sistema.

Depois de iniciar uma sessão, a videoconferência é seleccionadaautomaticamente.

Este botão permite aceder à funcionalidade de chat. É possível enviar e recebermensagens de texto. As conversas são guardadas automaticamente no localindicado no programa de configuração.

Este botão permite enviar um ficheiro para o outro sistema. Se já estiver aenviar ou a receber um ficheiro, ao clicar neste botão poderá ver-se oprogresso da transferência.

Este botão permite aceder à partilha de aplicações. É possível partilhar maisdo que uma aplicação ao mesmo tempo, se desejado, assim como permitiro controlo das mesmas remotamente.

Permite o acesso ao ambiente de eLearning Formare, onde poderá acederao ambiente criado para a comunidade virtual do aluno Teleaula.

A qualquer momento é possível aceder à ajuda clicando neste botão. Poderátambém fazê-lo pressionado a tecla F1 no teclado.

27 PT Teleaula — Um Serviço da AcçãoSocial da Fundação PT e da PT Inovação

Artur Neves, técnico de desenvolvimento infor-mático, ligado à analise e desenvolvimento deaplicações desde 1995, ingressou na PT Inovaçãoem Outubro de 2001, no departamento de For-mação Tecnológica e de Serviços, exercendoactualmente funções no departamento deInvestigação Aplicada e Difusão do Conhecimento.Participa na concepção e desenvolvimento deaplicações Web corporativas e colaborativas,nomeadamente na plataforma Formare, e nosuporte aos seus utilizadores.Colabora e acompanha a Implementação,Metodologias e Aplicação prática de proces-sos e projectos de eLearning/bLearning dos clientese parceiros da PT Inovação, bem como nodesenvolvimento de Conteúdos MultimédiaNormalizados para as referidas metodologias deaprendizagem.Responsável pela execução do projecto Teleaulana PT Inovação.

Referências[1] Manuais Teleaula Versão 1.2www.formare.ptPanfleto PT TeleaulaApresentações do PT Teleaula em váriasconferências e exposições

Clara Cidade Lains, 49 anos, licenciada emEngenharia Electrotécnica - Ramo Telecomunica-ções pelo IST em 1982, Directora de Info-Exclusãoe Necessidades Especiais da Fundação PortugalTelecom, desde 2004.Desde 1991 que se dedicaem exclusividade ao estudo e desenvolvimentode soluções telecom na reabilitação e integraçãode pessoas com deficiências e incapacidades,alguns deles no âmbito de projectos transnacionais,é igualmente responsável pela criação edesenvolvimento do primeiro Departamento paraPessoas com Necessidades Especiais da PortugalTelecom e dos que lhe sucederam, sendoresponsável pela criação de diversos projectos,destacando-se: Recrear, ProNota, Urano, Astro,Estrela, Mão-na-Mão, Abrigo, PORCIDE/THINK(http://www.fundacao.telecom.pt). Membroconvidado do Conselho Municipal de Lisboa paraa Integração da Pessoa com Deficiência; Membrodo Conselho Consultivo da Fundação AFIDDiferença - Associação de Famílias para aIntegração das Pessoas com Deficiência; Membrodo Conselho Nacional de Promoção doVoluntariado; Membro do Conselho Editorial daImpactus; Consultora em projectos de integraçãode pessoas com deficiência e incapacidades notrabalho e nas escolas; bem como projectos paraa Cidadania Empresarial e o VoluntariadoEmpresarial.

Arnaldo Santos, doutorando em Ciências eTecnologias da Comunicação na Universidade deAveiro, Mestre em Engenharia Informática naárea do eLearning pela Faculdade de Ciên-cias e Tecnologia da Universidade de Coimbra(2000). Licenciado em Engenharia Electrónica ede Telecomunicações na Universidade deAveiro (1990). Pertence à estrutura de Gestão daPT Inovação, onde desempenha o cargo de res-ponsável pelo Departamento de “Formação eeLearning”. Gestor e orientador de vários estágiosde investigação e de desenvolvimento na área daformação, gestão de conhecimento, comunidadesde aprendizagem distribuídas e de conteúdos edu-cacionais multimédia. Docente convidado doDepartamento de Comunicação e Arte daUniversidade de Aveiro. Autor e co-autor de várioslivros e de numerosos artigos e comunicações naárea da gestão da formação, do ensino a distância,do bLearning e do eLearning.

Paulo Garcez, coordenador do grupo de Inova-ção e Gestão da Direcção de Info-Exclusão eNecessidades Especiais da Fundação PortugalTelecom, onde é feito o portfolio de Produtos eServiços para as Necessidades Especiais que oGrupo PT disponibiliza, e a operacionalização dosdiversos projectos de Responsabilidade Social.Cedido à Fundação PT pela TMN, anteriormentefoi responsável pela implementação e exploraçãodos serviços complementares da rede móvel erede IP. Licenciatura em Física Tecnológica,Faculdade de Ciências da Universidade Clássicade Lisboa.

01


palavras-chave:Java Micro Edition (Java ME), MIDP, JTWI,

MSA, Flash Lite, Java FX Mobile, Android, MExE,fragmentação de dispositivos, DiNO, MWiPEP,

vídeo, Mobile TV, Mithril

O sector das telecomunicações temassistido, nos últimos anos, a umaevolução notável no panorama móvelem termos tecnológicos. Actualmente,qualquer telemóvel de média gamajá disponibiliza acesso à Internet,bem como suporte para diversosconteúdos multimédia nos mais va-riados formatos.

A chegada das plataformas runtime-based aos terminais móveis fomentou o desenvolvimento de aplicaçõesque aproveitam todo o potencial dosmesmos, mantendo elevados níveisde portabilidade e compatibilidadecom uma vasta gama de terminaisde diferentes fabricantes.

Este artigo contém uma breve intro-dução ao panorama actual em maté-ria de ambientes de execução móvel

Introdução às Plataformas deDesenvolvimento em Ambientes Móveis

Filipe Azevedo Bruno Cabral

e plataformas de desenvolvimento,com especial foco na plataforma Java Micro Edition (Java ME). Para oefeito serão abordados vários aspectos, nomeadamente a nível de arquitectura, portabilidade e suporte dosterminais existentes no mercado.

Por fim, será feita referência a outraplataforma actualmente em crescimento, Adobe FlashLite, e abordadasalgumas futuras tecnologias emergentes que poderão, a médio prazo,substituir as actuais plataformas:versão 3 do FlashLite, Java FX Mobilee Android.


29

1. ContextualizaçãoAo longo dos últimos nove anos, aindústria de comunicações móveistem assistido a uma contínua evolu-ção no campo tecnológico, tanto anível das características dos equipamentos móveis (telemóveis, smartphones, PDAs, etc.) como tambémem novas técnicas e protocolos detransmissão de dados over-the-air.

O conjunto de especificações e stan-dards hoje conhecido como "3G",ou redes de terceira geração, veiocolmatar as limitações de largu-ra de banda do sistema GSM, estabelecendo o suporte físico neces-sário ao fornecimento de serviços econteúdos multimédia especificamente direccionados para a utiliza-ção em telemóveis e outros dispositivos portáteis.

Também os operadores móveis de-sempenharam o seu papel nesteprocesso, adaptando as suas infra--estruturas de comunicação e intro-duzindo novos serviços de dadoscomo as mensagens multimédia,chamadas de vídeo, televisão móvel,catálogos de conteúdos online

(download de imagens, toques, mú-sica, jogos, etc.).

Do outro lado da equação, os fabricantes de equipamentos concentraram esforços no sentido de introdu-zir novas capacidades multimédianos seus equipamentos: câmaras fotográficas, maior conectividade (Wi--Fi, Bluetooth), acesso Internet, integração com os desktops, etc., o quenaturalmente exigia também que tanto o hardware, como os sistemas ope-rativos, fossem substancialmentemelhorados.

O aparecimento de plataformas dedesenvolvimento baseadas em máquinas virtuais especialmente dimensionadas para a sua utilização emterminais móveis, como a Java MicroEdition (Java ME), veio reintroduzir ametodologia já existente no mundodos desktops — "write once, runeverywhere" — no panorama móvel.Com efeito, nos últimos anos temhavido um interesse acrescido porparte dos principais players daindústria (fabricantes, operadorasmóveis, programadores) neste tipode plataformas.

Esta tendência é justificada pelosaltos níveis de portabilidade e flexibilidade das aplicações que, destaforma, podem ser facilmente "trans-portáveis" para diferentes arquitecturas e sistemas operativos, caracte-rística que é inerente às máquinasvirtuais. Em termos práticos, istopermite reduzir substancialmente otime-to-market e custos de manu-tenção e distribuição das aplicações,o que já não acontece no cenáriode desenvolvimento nativo por nãoser possível transportar o mesmobinário para outras plataformas, sendo necessário reescrever o códigofonte, recompilar e redistribuir a aplicação. Existe também um problemaconhecido como binary breakage —os binários poderão ficar obsoletosaquando de uma nova versão dosistema operativo.

Não é surpresa, portanto, que estasplataformas sejam preferidas emambientes empresariais, extremamente competitivos e onde a rapidez de execução e eficiente gestãode recursos humanos marcam a di-ferença.

Este artigo visa introduzir o leitor àsplataformas de desenvolvimento mó-vel actualmente disponíveis, comincidência no suporte a nível de API,base de terminais suportados e SDKdisponíveis. Será ainda abordadoaquele que é considerado um dosmaiores desafios durante o processode desenvolvimento de uma aplica-ção móvel: a enorme diversidade determinais e perfis de hardware / soft-ware actualmente no mercado, pro-blema denominado por fragmenta-ção (device fragmentation). Parafinalizar serão indicadas algumas dasfuturas plataformas ou evoluçõesdas plataformas existentes que deverão a curto/médio prazo substituirou revelarem-se como concorrentesàs plataformas actuais.

2. Introdução às plataformas dedesenvolvimento móvel [1]Actualmente existem duas plataformas runtime based já com bastantepeso no mercado e com uma basesubstancial de terminais suportados: Java Micro Edition (Java ME)da Sun Microsystems, conhecidoanteriormente por J2ME, e o FlashLite da Adobe. Ambas as soluçõessão compostas por máquinas virtuais baseadas nas vertentes desktop (Java SE e Flash), mas tecnicamente redesenhadas e direccio-nadas para equipamentos limitadosem termos de hardware, como é ocaso dos telemóveis. Além do runti-me, estas plataformas incluem umconjunto de componentes neces-sários ao desenvolvimento: API paratodo o tipo de funcionalidades,ferramentas de authoring, compiladores, debuggers, emuladores determinais e documentação.

2.1.Plataforma Java ME [1][3][4]A página oficial:http://java.sun.com/javame/

A plataforma Java ME (Java Platform Micro Edition) engloba umconjunto de bibliotecas, ferramentas e especificações de máquinasvirtuais simplificadas baseadas namáquina virtual original do Java SE,

especificamente desenhadas parapequenos equipamentos com váriaslimitações a nível de hardware (CPUmodestos, pouca memória RAM,ecrãs de pequenas dimensões...).

A plataforma Java ME contém umapanóplia de API das mais completasna comunidade wireless, desde osuporte de um stack Bluetooth, passando por componentes 2D de altoe baixo nível, manipulação de con-teúdos multimédia (áudio e vídeo),manipulação de ficheiros e contactos telefónicos, envio e recepção deSMS/MMS, gráficos 3D, SVG (Sca-lable Vector Graphics), web services,conexões via sockets TCP e UDPou via HTTP/HTTPS, persistência dedados, extensões de segurança ponto-a-ponto e criptografia para pro-tecção de dados, tracking GPS, etc.

Mas a vantagem mais significativadesta plataforma passa pela suaposição sólida no mercado: mais de700 modelos diferentes de terminais incluem uma implementação doJava ME, que continua activamentesuportada pelos principais fabricantese operadores móveis, bem como poruma vasta comunidade de programadores de todo o mundo. O sentidode developer community está bas-tante presente, sendo muito fácil aentrada no mundo do desenvolvimento móvel devido aos inúmerostutoriais, papers, artigos técnicos ede opinião presentes nos sites dosprincipais fabricantes, nomeadamente o developer hub da Nokia,Sony Ericsson e Motorola, bem como o site da Sun, inteiramente dedicado à plataforma onde podem serencontradas todas as especifica-ções e documentação relevantes.

A tecnologia Java ME está conceptualmente dividida em três componentes distintos: configurações(CONFIGURATIONS), perfis (PROFILES) e bibliotecas adicionais (OPTIONAL PACKAGES) que, quandocombinadas, asseguram um ambiente de desenvolvimento robusto eflexível.


Uma configuração consiste numconjunto de especificações e requi-sitos que definem a implementaçãode uma máquina virtual direccionada para equipamentos portáteis ede características limitadas, associado a um leque de API Java básicas que formam a funcionalidadecore para que seja possível correruma aplicação Java ME. Existemduas configurações disponíveis:CLDC (Connected Limited DeviceConfiguration) e CDC (ConnectedDevice Configuration).

A diferença entre estas configura-ções reside essencialmente nas ca-racterísticas do target — a CLDC édireccionada para dispositivos muito limitados em termos de processamento, memória e autonomia, nomeadamente telemóveis, enquantoque a CDC aponta para dispositivosmais potentes.

Uma configuração apenas defineos requisitos da VM e um pequenosubset de API que formam o coreda plataforma. Deverá ser complementada com um conjunto de APIde alto nível que proporcionam onível de funcionalidade que se espera de uma plataforma de desenvol-vimento. Este conjunto de API é denominado por perfil e engloba asbibliotecas responsáveis pela criação de interfaces de utilizador,conectividade, persistência de dados, controlo de fluxo da aplicação,manipulação de eventos, etc. A cada configuração corresponde umou mais perfis. No caso da CLDC,o perfil disponível é o MIDP (MobileInformation Device Profile). No casoda CDC existem 3 perfis - Foundation Profile, Personal Basis Profile ePersonal Profile.

No entanto, é a combinação CLDC/MIDP que é considerada a plataforma Java ME preferencial, tanto paratelemóveis, como smartphones, de-vido principalmente às limitaçõesque persistem nestes equipamentos e também ao contínuo desenvolvimento nestes componentes.

31

Existem ainda API opcionais que,contrariamente a um perfil, não defi-nem um ambiente de desenvolvimento por si só, mas servem sim co-mo extensão às capacidades daplataforma, como por exemplo, àcombinação CLDC/MIDP. Estasbibliotecas, ou pacotes opcionais,são responsáveis por uma série defuncionalidades adicionais, tais como conectividade Bluetooth, mani-pulação de conteúdo multimédia (vi-sualização, gravação e streamingde vídeos e áudio), envio e recepçãode SMS/MMS, funções de PIM (Personal Information Manager), suportepara SVG, web services, acesso aosistema de ficheiros, etc. O carácteropcional destas bibliotecas prende--se com o facto de nem todos osterminais suportarem as mesmasfuncionalidades, sendo que estasestão dependentes de características técnicas tanto a nível de hardware, como de software. Por estarazão, não seria viável incluir estasAPI num perfil como o MIDP, vistoque isso iria restringir a plataformade suportar o maior número possívelde terminais e, assim, reduzir a portabilidade da mesma.

A Figura 1 contém uma representa-ção do stack que compõe a plataforma Java ME, onde podemos vera disposição dos componentes porordem hierárquica, bem como algu

mas das API opcionais mais relevantes.

Na plataforma Java ME, é comumver a designação JSR (Java Specification Request) normalmente associada a uma biblioteca. Uma JSRcontém um identificador que desig-na o documento de especificaçãoda API. Estes documentos podemser consultados no site da JavaCommunity Process, uma organização composta pelos principaisplayers do mercado wireless (Nokia,Sony Ericsson, Vodafone, Spring,Motorola, etc.) com mais de 1200participantes corporativos e indivi-duais, cujo objectivo passa por estabelecer um processo de engenhariade software que permita monitorizare contribuir activamente para o desenvolvimento da plataforma Java, oque naturalmente engloba a vertenteMicro Edition.

2.1.1. O problema da fragmenta-ção da plataforma — quais as causas e como minimizar o problema[4][5][6]O sucesso galopante da plataformaCLDC/MIDP projectou o aparecimento de diversas API opcionais nosentido de proporcionar aos programadores as ferramentas neces-sárias para que tirassem o máximopartido dos terminais. Este factor,agravado pela segmentação do

mercado de telemóveis em baixa,média e alta gama, fez com que setornasse cada vez mais complicadaa tarefa dos programadores em determinar um target que lhes propor-cionasse um ambiente de desenvolvimento “previsível”, ou seja,saber quais são as API suportadasnos terminais onde se pretende ins-talar a aplicação. Este problema éconhecido por fragmentação daplataforma, que ocorre devido àenorme diversidade tanto no hardware dos telemóveis (diferentesresoluções de ecrãs, diferentes aspect ratios, capacidades multimédia, opções de conectividade, RAMdisponível, velocidade de CPU), como na qualidade da própria implementação do runtime de Java ME.

Esta situação obrigava os programadores a optar pela distribuiçãode diferentes binários, um para cadasegmento ou grupo de terminaisque partilhassem características semelhantes. No entanto, esta práticaleva a gastos exagerados tanto nodesenvolvimento do código, comotambém na sua distribuição e posterior manutenção (novas versões epatches), não sendo por isso a so-lução ideal para o problema. Na verdade, perdia-se grande parte daportabilidade e, portanto, grandeparte da vantagem em usar a pla-taforma JavaME.

No sentido de minimizar este pro-blema, a JCP (Java CommunityProcess), juntamente com algunsdos maiores fabricantes de equipamentos e empresas licenciadas pelaSun para produzir máquinas virtuaisbaseadas em CLDC/MIDP, iniciaram um processo de criação de umstandard que definisse em concretouma única plataforma baseada emJava ME e unificasse o ambiente dedesenvolvimento.

Esta plataforma devia combinar umconjunto pré-definido de API, comespecificações de uma máquina virtual, que respeitasse um determinado vector de requisitos mínimos.


Figura 1 - Pacotes Opcionais Java ME

Application Profile

Configuration (VM)

JSR 75File & PIM

JSR 120WMA 1.0/1.1

JSR 226SVG

JSR 82Bluetooth

JSR 205WMA 2.0

OptionalPackages

JSR 135Mobile Media

JSR 1843D Graphics

JSR 172Web Services


Surge assim em 2003 a primeira especificação de uma plataforma ouapplication environment stack, o JT-WI (Java Technology for the WirelessIndustry). Actualmente, este standardestá a ser substituído progressivamente por um novo que admite já umlargo leque de API capazes de tirarpartido do potencial da última gera-ção de telemóveis, o MSA (MobileService Architecture) (Figura 2).

2.1.2. Aplicação JAVA ME desenvolvida in-house, nome de código:MITHRILNeste momento, está em fase de de-senvolvimento uma aplicação base-ada na tecnologia Java ME no depar-tamento de Plataformas e Produtosda PT Inovação em Aveiro. Trata-sedo Mithril (Figura 3), uma aplicaçãocliente direccionada para a utilizaçãoem telemóveis, cujo objectivo é unificar os dois principais serviços multi

média de valor acrescentado disponibilizados pelas plataformas DiNO e M-WiPEP, facultando:

a) Um módulo semelhante a umaonline store onde o utilizador po-derá fazer browsing pelos con-teúdos multimédia actualmentedisponíveis na plataforma DiNO,como toques, imagens, músicas,vídeos ou jogos, fazer a compra eposteriormente efectuar o download para o seu telemóvel;

b) Um cliente de Mobile TV, com su-porte para subscrição de pacotesde canais, seamless channelswitching — zapping rápido de ca-nais — e visualização full screen.

A principal razão da escolha da pla-taforma Java ME para este projectoprende-se com o seu maior desafio,que é o de suportar o maior númerode terminais multimédia actualmen-te no mercado e proporcionar nes-tes uma experiência de visualizaçãosemelhante. Estima-se um targetbastante elevado de mercado (cerca de 95% da plataforma NokiaS60, 70% Sony Ericsson e qualqueroutro terminal que corresponda aos

Figura 2 - Arquitectura MSA, cortesia Sun Microsystems

Figura 3 - Aplicação Mithril

Security andCommerce

Graphics Comms PersonalInformation

ApplicationConnectivity

ApplicationEnvironment

JSR 234Mobile MediaSupplement

JSR 117Security and Trust

Services

VirtualMachine

JSR 229Payment

JSR 226SVG

JSR 1843D Graphics

JSR 135Mobile Media

JSR 118MIDP 2.0

JSR 180SIP

JSR 205MMS

Messaging

JSR 82Bluetooth

JSR 120SMS

Messaging

JSRMIDP 2.0

Clarifications

JSR 139CLDC 1.1

JSR 179Location

JSR 75PIM and File

JSR 248MSA

Clarifications

JSR 238Mobile / 18N

JSR 211ContentHandler

JSR 172Web Services

MSA Subset Conditionally Mandatory APIs

33 Introdução às Plataformas deDesenvolvimento em Ambientes Móveis

requisitos mínimos CLDC/MIDP/JTWI). A aplicação Mithril leva a por-tabilidade do Java ME ao limite, sendo que seria praticamente impossí-vel utilizar outra plataforma dentrodo enquadramento pretendido emtermos de requisitos de mercado.

2.1.3. Ferramentas necessáriaspara o desenvolvimento em ambientes JAVA ME [7]A ferramenta indicada para o iníciodo desenvolvimento em Java ME éo Netbeans 6.x com Mobility Pack,para verificação do código, compila-ção, ofuscação e emulação (debug).São também disponibilizadas nosfóruns de desenvolvimento dosmaiores fabricantes, como a Nokia,Sony Ericsson e Motorola, diversasSDK que permitem testar o compor

tamento geral da aplicação.

2.2. Plataforma Flash Lite [2]Página Oficial:http://www.adobe.com/products/flashlite/

O Adobe Flash Lite é outra plataforma de desenvolvimento móvel combastante projecção de momento.Tal como a plataforma Java ME,também o ambiente Flash Lite é baseado num runtime que é fundamentalmente uma versão simplificada da versão Flash dos desktops.Dado que o cenário de desenvolvimento é semelhante à versão original, a curva de aprendizagem é bas-tante curta para programadores queestejam familiarizados com as ferramentas de authoring, ou IDE.

A plataforma Flash Lite pode ser usa-da para criar vários tipos de aplica-ções móveis, desde wallpapers escreensavers a jogos e outras apli-cações ricas em conteúdos. Exis-tem 3 versões principais (1.x, 2.x,3), embora apenas a partir da segunda versão se possa consideraresta plataforma como uma alternativa viável ao Java ME (as primeirasversões eram bastante limitadas emtermos de API). A versão 2 do FlashLite é baseada na versão desktop doFlash 7 e suporta algumas opçõesinteressantes como parsing de XMLcom interpretador de DOM embutido, suporte para TCP/IP, playbackde vídeo e áudio (de acordo com ascapacidades do terminal), renderingavançado de texto, etc. Adicionalmente, a versão 2 introduz suporte

Figura 4 - Arquitectura do Android, Cortesia OpenAlliance / Google

APPLICATIONS

APPLICATION FRAMEWORK

ActivityManager

WindowManager

ContentManager

ViewSystem

PackageManager

TelephonyManager

ResourceManager

LocationManager

NotificationManager

Core Libraries

Dalvik VirtualMachine

ANDROID RUNTIME

SurfaceManager

OpenGL | ES

SGL

MediaFramework

FreeType

SSL

SQLite

WebKit

Iibc

LIBRARIES

DisplayDriver

KeypadDriver

CameraDriver

WiFIDriver

FlashMemory Driver

AudioDrivers

Binder (IPC)Driver

PowerManagement

LINUX KERNEL

Contacts Phone Browser ...Home


à linguagem de scripting ActionScript 2.0, proporcionando ao programador uma poderosa ferramentaadicional no acesso às caracterís-ticas intrínsecas ao terminal.

A terceira versão do Flash Lite está,até à data da conclusão deste artigo, a começar o seu processo dedistribuição no mercado de terminais, sendo que já se encontra disponível nalguns terminais de topoda Nokia.

Esta nova versão traz inúmerosajustes e melhoramentos, além denovas features, destacando-se osuporte de conteúdo FLV, o formatomais popular de vídeo da Internet,fortemente utilizado em sites comoo YouTube e o MySpace, bem comoa capacidade de reproduzir conteú-dos Flash 8, aproximando cada vezmais a experiência de visualizaçãoentre o que é possível esperar nodesktop e no telemóvel.

2.2.1. Base de suporteEm termos de suporte no mercado,a versão 1 é ainda aquela com maiornúmero de terminais suportados, oque é um entrave à afirmação daplataforma, embora as versões maisrecentes estejam gradualmente asubstituir a primeira versão, conso-ante a disponibilidade de novos terminais e actualizações de firmwareaos equipamentos existentes. Emtermos de share do mercado, a pla-taforma Flash Lite continua atrás doJava ME, com uma base de terminais substancialmente menor.

Uma desvantagem bastante forte éque toda esta tecnologia é fecha-da, proprietária, limitada a apenasalguns sistemas operativos móveis(S60, S40, Windows Mobile e BR-EW), estando a utilização das suitesde desenvolvimento dependente daaquisição de licenças. O que contrasta com a plataforma Java ME,uma tecnologia aberta onde os pró-prios fabricantes disponibilizam osseus emuladores e ambientes dedesenvolvimento de forma gratuita.

2.2.2. Ferramentas necessáriaspara o desenvolvimento naplataforma Flash LiteTodos os estágios de desenvolvimento de uma aplicação baseadana plataforma Flash Lite, desde odesign até à fase de testes e distri-buição, estão integrados num únicoambiente, Adobe Flash CS3 + Adobe Device Central CS3 (conjunto deemuladores para testes).

3. Tecnologias e plataformas emer-gentes3.1. Plataforma JAVA FX MOBILE [8]Ainda em fase de desenvolvimento,o projecto Java FX Mobile propõeuma solução diferente. Em vez deser mais um runtime a correr sobreo sistema operativo nativo, consistenum stack de aplicações integradocom uma camada middleware deJava e respectivas API, em cima deum sistema operativo Linux optimizado e, portanto, desenhado comtecnologias 100% abertas.

Sendo baseado na versão 6 da pla-taforma Java SE, o objectivo principal é conseguir um sistema que sejacapaz de assegurar um ambienteconsistente numa gama de terminais, reduzindo assim o risco defragmentação ao mínimo e assegu-rando um target com características comuns, a nível de hardware esoftware, no qual os programadoresse possam basear para correr assuas aplicações. De notar que oprojecto Java FX Mobile é community-driven, o que significa que éaberto a qualquer pessoa que pretenda participar no projecto.

3.2. Plataforma ANDROID [9]Página Oficial:http://code.google.com/android/

O Android surge como outra alternativa ao futuro panorama dos ambientes integrados de desenvolvimento móvel. Tal como o projectoJava FX Mobile, também o Androidse baseia num stack de software incluindo um sistema operativo Linux,

middleware (bibliotecas, interpretadores, máquinas virtuais) e aplica-ções de topo (as aplicações acessí-veis ao utilizador final e que lhepermitem tirar partido das funcio-nalidades básicas do terminal, comofazer chamadas, enviar mensagens,etc.).

O projecto Android está a ser de-senvolvido pela Open Handset Alliance, um grupo de 30 experts emtecnologia móvel incluindo a HTC,LG, Motorola, Google, NVIDIA emuitos mais. É uma tecnologia a-berta, sendo que já se encontra disponível uma SDK para download napágina oficial do projecto para osearly adopters que podem começara desenvolver e testar as suas apli-cações para esta nova plataforma.

A linguagem utilizada no desenvolvimento de aplicações para a pla-taforma Android é Java puro, o quelhe garante para já uma enorme comunidade de programadores quese poderão sentir tentados a expe-rimentar pela primeira vez desenvol-ver para terminais móveis.

Desde que a SDK foi disponibilizadaque a plataforma Android tem gerado bastante expectativa por partedos entusiastas da comunidade etambém suscitado interesse porparte de programadores que nun-ca se iniciaram na indústria móvel,no que diz respeito ao que virá a sero produto final. Como qualquer tecnologia emergente, o Android aindatem um longo caminho a percorrer.Existem já alguns terminais em fasede testes, no entanto, o derradeirofactor de sucesso estará, como é deprever, na base de terminais suportados e na forma como a plataformalidará com o risco de fragmentação,aquando de uma eventual expansãopara vários equipamentos.


palavras-chave:

Shipnet®, SDF, IMS, BSS, OSS,OCS, SLEE, OMA, eTOM

Um Service Delivery Framework(SDF) disponibiliza um ambiente pa-ra a criação, instalação e execuçãode serviços, de uma forma rápida eeficiente, permitindo uma integraçãocom infra-estruturas de rede heterogéneas, sistemas OSS/BSS e terceiras entidades, de acordo com osprincípios arquitecturais SOA (Service Oriented Architecture), em consonância com a arquitectura OMAOSE (Open Mobile Alliance — OpenServices Environment) e em perfeitasintonia com os processos e modelos de informação promovidos peloTMForum.

A PT Inovação, empresa de referência no fornecimento de serviçose aplicações, no âmbito do programa Shipnet® (Service Handling onIP networks), está a desenvolver umSDF convergente, capaz de integrar

Nuno Silva Vitor Santos

com redes / ambientes legados(NGIN, SS#7, etc.) e redes de novageração (IMS/TISPAN, IPTV, etc.).

Este artigo descreve o estado daarte e os aspectos tecnológicos associados às novas plataformas deserviços, bem como a solução preconizada pela PT Inovação para aevolução das suas plataformas deserviços para um SDF convergente,em conformidade com os standardse as melhores práticas de mercado.

Cláudio Lobo Mário Rui Costa

Shipnet® Service Delivery Framework (SDF)

Shipnet® Service Delivery Framework(SDF)

37

1. IntroduçãoUm Service Delivery Framework(SDF) define uma base arquitecturalde referência que permite a criação,instalação, execução, orquestraçãoe gestão de serviços de uma formaágil, eficiente e integrada, num ambiente de convergência entre redes,recursos e serviços.

O SDF surgiu como uma consequência da própria evolução da redee dos sistemas de informação,substituindo um conjunto de plata-formas verticais silo-based (geralmente designadas por SDP — Service Delivery Platforms) por umaarquitectura comum e estratificada,endereçando as redes e sistemasde informação legados e de novageração.

O SDF — por vezes designado porSDP 2.0 — é construído tendo como base os conceitos SOA (ServiceOriented Architecture), sugerindo esustentando a integração, a reutilização e a orquestração eficientesdos vários componentes, tendo associado igualmente todos os aspectos de gestão do ciclo de vida dos

serviços e a sua migração para redes all-IP, baseadas nos standards3GPP IMS e ETSI TISPAN (IMS/TISPAN, wireless, wireline, etc.).

Um SDF, para além de utilizar standards IT e Telco, deve definir claramente um conjunto de camadas funcionais para a execução e exposiçãode serviços, utilizando componentes(enablers) que disponibilizam interfaces para outros componentes,abstraindo aspectos de implementação e a complexidade, específicosdas redes ou dos protocolos.

Os serviços e/ou aplicações queexecutam no SDF devem partilharum ambiente comum, ou seja, devem utilizar um conjunto de enablersstandard, um repositório central ecomum de serviços, de perfis eidentidades, de SLA, de conteúdos,de gestão integrada dos ciclos devida dos serviços, de interfaces comuns para OSS/BSS, etc.

Um SDF promete assim agilidadeno delivering de novos serviços eaplicações, potenciando a reutilização de capacidades, facilitando

a integração com os sistemas envolventes, baseados em interfacesstandards, e criando um nível deabstracção superior.

A PT Inovação, no âmbito do programa Shipnet®, tem vindo a desenvol-ver um SDF convergente de novageração, peça fundamental para acamada de serviços de qualquerfornecedor de serviços.

A Figura 1 representa conceptualmente o SDF convergente da PTInovação, residente no Service Layerda arquitectura Shipnet®.

Na Figura 1 é possível identificar asplataformas de execução de serviços (SDP) e um conjunto de enablers (Unibox, DiNO, Loc@Cel, XAF,Presença, etc.) que disponibilizamum conjunto de funcionalidades específicas, e que podem ser utilizados pelos vários serviços para darmaior valor aos mesmos.

2. Descrição do sistema ousoluçãoO Shipnet® SDF está devidamentealinhado com o grupo de trabalho

Service Delivery Framework do TMForum, que descreve um modelode referência para a gestão e execução de serviços convergentes depróxima geração, independente dastecnologias de rede suportadas para a implementação dos serviços(Figura 2).

A área de SDF Managed Resourcessubdivide-se nas áreas de ServiceLifeCycle Operation Support e Service Enabler & Application.

2.1. Ambiente de execução deserviçosDo ponto de vista de execução dosserviços (Service LifeCycle Operation Support), o shipnet® SDF devedisponibilizar os seguintes componentes:

> Servidores aplicacionais, ospróprios ambientes de execuçãode serviços (SLEE - Service Logic


Costumer, Suppliers, Partner Services

Integration Infrastructure

SDF managed resources

Service Enabler& Application

Service LifecycleOperation Support

Network & IT Resources

End-user Services

BSS/OSS

SDFManagement

Figura 1 - Shipnet® Service Delivery Framework (SDF)

Figura 2 - TMForum SDF

Conference &Collaboration

Services And Applications

ResidentialVoIP/Class 5

NumberTranslation

CRBT

IP-SM-GW

IM

VPN

ip-Centrex

VCC

XDMS

Service Delivery PlatformsService Enablers

SIP AS

ip-Jib®

SCIM

ip-Jib®

CDP

M-WIPEP

Presence

CamelSE

NGIN ®

Lawful CallInterception

SDF

Parlay-X

Prepaid

MVPN

Session Control

Transport Control

Transfer Functions

CTF

Real TimeBilling

B/OSS

OCS

O2CS

Execution Environment), dedicados a domínios de negócio específicos, baseados em tecnologiasstandards, por exemplo em JavaSLEE — Java Service Logic Execution Environment (event-driven)e/ou SIP-Servlets, com requisitosde elevado desempenho, elevadainteroperabilidade, mecanismosde alta fiabilidade e elevada tole-rância a falhas. Alguns exemplosde SLEE: CSE — Camel ServiceEnvironment para serviços CAMEL; Application Server — SIP paraserviços tipicamente IMS; IPTV;Portais Web;

> Serviços comuns, como componentes auto contidos, que ex-põem e disponibilizam funcionalidades bem definidas e reutilizáveis no contexto de uma oumais áreas de negócio;

> Um conjunto de Service Enablers, módulos reutilizáveis queabstraem recursos e sistemas a-plicacionais (por exemplo, Presença, Localização, Messaging,Charging, VCC, etc.), expondofuncionalidades bem definidaspara o acesso aos sistemas;

> Um conjunto de Resource Adapters, módulos reutilizáveis quefornecem abstracção para diálogocom os recursos de rede (interfaceSDF southbound), expondo funcionalidades bem definidas;

> Um conjunto de aplicações/serviços especializadas para umdado domínio funcional (por e-xemplo, IP Centrex, VPN, VCC,Classe 5, VoIP Residencial, IPTrunking,Conferência e Colaboração, etc., incluindo os serviçostradicionais de Voz e Dados);

> Um nível de exposição e controlo das funcionalidades dos Servi-ços e Service Enablers para terceiras entidades (interface SDFnorthbound);

> Um orquestrador de serviços detempo real, que combina e co

39

ordena a execução de múltiplosService Enablers, Resource A-dapters e Serviços, de forma acriar Serviços de valor acrescentado (por exemplo, ip-Centrex integrado com VCC e mVPN);

> Mecanismos para a execução deregras de controlo de serviçospor forma a garantir SLA definidoscom clientes e garantir os SLA def inidos com prestadores deserviços externos;

> Mecanismos uniformizados de A-daptação e Entrega de Con-teúdos, com suporte multicanal,com identificação da rede e terminal de acesso, com adaptaçãodos conteúdos ao meio e terminal,com integração com componentes de Gestão Centralizada deConteúdos e com componentesde gestão de direitos de autor;

> Mecanismos de Gestão Federada de Identidade que, numaperspectiva user-centric, permitaa ubiquidade, a convergência e aprivacidade no acesso aos serviços e a própria personalizaçãodestes pelos utilizadores, eliminando a fragmentação de múlti-plos identificadores e simplificando os métodos de autenticação.Potencia-se assim a utilização deum mesmo identificador paramúltiplos serviços “entregues” sobre diferentes redes estratificadase federadas, interligando múltiplosoperadores, services providers,content providers, etc., incluindomesmo os próprios utilizadorescomo providers.

2.2. Gestão do ciclo de vida dosserviçosDo ponto de vista de gestão do ciclode vida dos serviços (Service Life-cycle Management and Support), oshipnet® SDF deve dar respostaaos seguintes requisitos:

> Disponibilizar um ambiente decriação de serviços (SCE) capazde gerar os artefactos necessá-rios para a instalação e execução

dos serviços, e que forneça mecanismos para a gestão integradado portfolio de serviços, e que potencie o desenvolvimento de ser-viços pelo próprio operador;

> Disponibilizar um ambiente deinstalação dos serviços (ServiceDeployment) nos ambientes deexecução, que permita gerir aspectos como a distribuição dosartefactos pelos ambientes físicos,a interacção com mecanismoscentralizados de registry e localização de serviços e com mecanismos de gestão e controlo daexposição de funcionalidades;

> Disponibilizar um ambiente de Gestão dos serviços instalados no ambiente de execução dos serviços(Service Management), que disponibilize mecanismos para a efectivagestão do estado administrativo eoperacional dos serviços, bem como de aspectos infra-estruturaisrelativos aos ambientes de excuçãoque suportam os serviços (Infra-structure Management).

2.3. Business and OperationsSupport SystemA área de “SDF Management” corresponde às funções tradicionais deOSS - Operations Support Systemse BSS - Business Support Systems,onde as entidades funcionais existentes devem seguir a referência deagregação funcional sugerida pelomapa de operações eTOM (enhanced Telecom Operations Map),definido pelo TMForum.

No entanto, para que estes sistemas ajudem um operador a enfrentar adequadamente os novos desafios, devem disponibilizar umamaior flexibilidade, agilidade e capacidade para uma eficiente resposta em três vertentes:

1 - aos requisitos de marketing;2 - ao desenvolvimento de novosserviços e aplicações;3 - ao aparecimento de novos mo-delos de negócio.

Shipnet® Service Delivery Framework(SDF)


O SDF assim caracterizado sugerenão só aspectos de evolução arquitectural e tecnológica, mas subentende acima de tudo uma mudançade paradigma na área de SI, ondea construção e manutenção de produtos, de serviços e dos processosde negócio que os suportam é crucial para a sobrevivência de umoperador.

O Shipnet® SDF destaca assim, nesta área, como aspecto chave da mu-dança de paradigma, a uniformi-zação dos processos de negócio, asua ágil manutenção e a sua integra-ção em tempo real e online com osambientes de execução de serviços(SDP).

Para além disso, os princípios deorientação ao serviço, de distribui-ção, elevada interoperabilidade ede flexibilidade na construção deprocessos de negócio promovem oaparecimento de novas equipashorizontais com responsabilidades

bem definidas (Figura 3), por oposição à organização clássica verticali-zada por áreas de negócio, principalfactor do surgimento dos famosossilos verticais.

Assim sendo, a área de SDF Management deve compreender mecanismos para o suporte à criação,distribuição e manutenção de processos de negócio.

Nesse sentido, o Shipnet® SDF deve dar resposta aos seguintes requisitos:

> Disponibilizar um ambiente decriação de processos de negócio,capaz de criar e modelizar processos pelo uso, eventualmenteorquestrado, de serviços disponibilizados pelos ambientes deexecução constituintes do SDFManaged Resources;

> Disponibilizar um ambiente deGestão dos processos de negó-

cio, que faculte mecanismos verdadeiramente flexíveis para a suamanutenção e evolução, no sentido do não constrangimento dadinâmica do negócio;

> Os dois ambientes acima referidos devem suportar um modelode informação de negócio corporativo como linguagem comumde integração funcional de sistemas — modelo canónico empresarial tendo o SID como referência;

> Os mesmos ambientes referidosdevem estar assentes sobre umESB (Enterprise Service Bus) comum onde, respeitando o modelocanónico, todos os sistemas ex-põem funcionalidades.

Tendo como referência o modeloeTOM, o Shipnet® SDF posiciona--se nesta área de B/OSS cobrindoas principais funções que se destacam na Figura 4.

Manage Infrastructure & Services Life Cycle

Manage Security , Access Control, Identity Mng.

Manage Service Catalog ManageBusinessCatalog

Develop

Deploy

EvolveManage

ServiceCreationFramework

ServiceManagementFrameworks

BusinessProcessCreationFramework

BusinessManagementFramework

InfrastructureManagementFramework

SEE SEE

SDF

ServiceDevelopmentTeams

EnterpriseArchitectsTeam

BusinessDevelopmentTeam

SDFInfrastructureTeam

Service

Service BusinessProcess

Config

BusinessProcess Develop

Deploy

Config

Figura 3 - SDF e organização empresarial

41 Shipnet® Service Delivery Framework(SDF)

2.3.1. Sistema de charging e billingOutra vertente, com equivalente importância nesta área de B/OSS,prende-se com os aspectos de charging e de billing onde tradicionalmente os operadores possuem diversos sistemas de rating e de billingverticais.

Numa mudança global de paradigma, em que os operadores devempassar de uma perspectiva service-centric para user-centric, faz sentidoque passe a existir um mecanismocentralizado de rating e charging, defacturação e de cobranças, para todos os clientes e serviços, independentemente das redes e sistemasutilizados.

Nesse sentido, o Shipnet® SDF defende a adopção do conceito de RealTime Convergent Billing, disponibilizando um sistema único de rating echarging, o O2CS - Online/OfflineCharging System - e um sistema debilling convergente, ambos integrados, assentes nos princípios SOA,

e dotados de extrema agilidade nadefinição e disponibilização de novascampanhas e promoções de novosserviços e modelos de negócio.

O O2CS deve alinhar simultaneamente com a normalização OCS do3GPP (release 8) e com o EnablerCharging do OMA, respondendo aosprincipais aspectos de:

> Convergência, aplicado a qual-quer tipo de cliente e de serviço,integrando diferentes modelos denegócio tais como Pré-Pago ePós-Pago;

> Capacidade para influenciar, onlinee em tempo real, o acesso e a uti-lização (credit authorization) e con-tabilização continuada (accounting)da prestação de serviços. Dispo-nibiliza também charging offlineapenas com a diferença funcionalque não influencia a prestação doserviço no momento da sua utili-zação;

> Flexibilidade e rapidez na criaçãode novas estratégias de promo-ções personalizadas, assim comoa configuração eficiente de novasregras de tarifação;

> Abertura através do suporte deinterfaces normalizadas, funcionando como um Service Enablerpara qualquer SDP ou outro sistema, e tecnologicamente evoluídoatravés de uma arquitectura mo-dular e assente em tecnologiaságeis que facilitam a sua manu-tenção e evolução.

3. Alinhamento com o OMAO grupo OMA (Open Mobile Alliance) definiu o ambiente OSE (OMAService Environment), que serve como base de referência para o Service Layer de qualquer fornecedorde serviços.

O principal propósito do OSE é o depromover um conjunto de princípiosarquitecturais que justifica a especificação e desenvolvimento de Ser

Figura 4 - Cobertura Shipnet® do modelo eTOM

Strategy I&P

Infrastructure& ProductLifeCycleManagement

MartBusinessTools

NetworkPlanning Inventory

Management

Work ForceManagement

AccessControlManagement

BusinessConfigurationManagement

OS&R Fulfilment

Order Entry /Customer Care

CampaignSalesManagement

Order Handling

Assurance

Customer Interface Management

CustomerProblem Handling

Collection (Debt)Settlement

Billing

Bit InquiryHandling

Bit InvoiceManagement

On/OfflineChargingSystem

PromotionExecutionManager

ServiceQualityManagement

NetworkPerformanceManagement

ProblemManagement

Test & QosMonitoring

Alarm & FaultManagement

Mediation & Data Collection

ServiceActivation

ResourceAdapters(HLRs, VMs,...)

Order Management

SM CardManagement

VoucherManagement

NumberingManagement

Enterprise Service Bus

Enterprise Management

S/P Setlements & PaymentsManagement

Probes & RobotsPlatformsNet DomainNet Domain

Network & Platforms

Operations


vice Enablers, componentes funcionais normalizados, peças comunsde base para a construção deserviços.

A especificação de Enablers é o trabalho de fundo da OMA, sendo estes vistos como as entidades quetrazem para um Service Environment os seguintes aspectos:

> São componentes nativa e uniformemente inter-operáveis, quepromovem a integração entreserviços e sistemas desenvolvidos por diferentes fornecedores;

> Promovem a reutilização, na medida em que permitem que fun-ções comuns sejam agrupadasem componentes normalizadosdisponíveis para todos os ser-viços;

> Como consequência dos anteriores, reduzem o esforço de desenvolvimento de novos serviços.

Em resumo, a grande motivaçãopara a especificação de ServiceEnablers é a redução de complexidade no desenvolvimento, distribui-ção e integração de sistemas quesuportam o negócio dos operado-res, combatendo os silos verticais.

Pela importância dos princípios aquiexpostos como potenciadores deuma construção adequada de umambiente de execução de serviçosconvergentes de nova geração, oShipnet® SDF considera-os comofundamentos da sua arquitectura.

4. Relação com IMSO IP Multimedia Subsystem (IMS),idealizado originalmente para a áreamóvel e normalizado pelo 3rd Generation Partnership Project (3GPP),defende uma arquitectura para oferta global de serviços multimédia.

O IMS pressupõe a criação de váriascamadas horizontais baseada numainfra-estrutura IP global para suportarconvergência fixo/móvel, potenciando a construção de serviços complexos e agregados que podem serdisponibilizados sobre qualquer tipode rede.

No entanto, não desenvolve aindacom o devido detalhe, ou mesmonão refere como um todo, aspectosrelacionados, por exemplo, com acriação e gestão integrada do ciclode vida dos serviços, com a expo-sição e controlo de funcionalidadesmesmo para entidades terceiras,com a própria reutilização dessasfuncionalidades, com abstracção dasredes e protocolos, com gestão deidentidades, com orquestração deprocessos de negócio. Estes e ou-tros aspectos são considerados pe-ças chave na definição do conceitoSDF, complementando assim a arquitectura IMS.

Noutra perspectiva, o SDF pode servisto sem o IMS, gerindo a entregae orquestrando serviços sobre redespré-IMS. Ou seja, as duas arquitecturas/tecnologias podem coexistircomo peças vitais de um ecossistema onde, de forma colaborativa, são

construídos e geridos serviços convergentes de nova geração.

Em suma, e nesta perspectiva derelação com o IMS, o SDF é umanova camada de integração e ges-tão de serviços e aplicações sobreredes puras IMS e não IMS, promo-vendo a ponte entre elas para aconstrução de serviços de valoracrescentado. Com o ganhar domomentum do IMS nos próximosanos, as redes legadas irão reduzira sua expressão. No entanto, o SDFcontinuará integralmente válido como princípio fundador de uma verdadeira integração entre os domíniosTI vs Telco.

5. Importância para os negóciosdo grupo PTAs diversas operações de teleco-municações do grupo enfrentamhoje os mais diversos desafios, maisou menos intensos, dependendo doseu enquadramento geográfico e daenvolvente comercial, desde o combate à forte concorrência, vinda atéde novos players (em número elevado, ágeis e com soluções inovadorase tecnologicamente avançadas),passando pelas mudanças comportamentais da sociedade, traduzindo--se em clientes mais sofisticados eexigentes (mais facilidade, maior in-tegração, maior disponibilidade emobilidade, mais context aware), terminando nas dificuldades internasque sentem ao enfrentarem estes eoutros desafios.

A solução Shipnet® SDF é assimum meio para que as operações dogrupo possam enfrentar adequadamente os principais desafios atravésda resolução das principais dificuldades, nomeadamente:

> Eliminar a existência de silos verti-cais, difíceis de integrar e de manter e dependentes de fornecedores;

> Eliminar soluções baseadas emarquitecturas monolíticas levandoos fornecedores a alinharem asFigura 5 - Enquadramento O2CS

Busin...

43 Shipnet® Service Delivery Framework(SDF)

do negócio das empresas do grupoPT, onde um dos seus eixos fundamentais assenta no desenvolvimento de Serviços, Soluções e Sistemas, é natural que se continue aposicionar como líder, mas agorade uma nova visão sistémica e ope-racional, aplicável a qualquer umadas operações de (tele) comunica-ções do grupo.

Para além de detentora de uma vi-são estratégica global de evolução,materializada no Shipnet® SDF, aPT Inovação acredita estar na possede “potentes ferramentas” arquitecturais e tecnológicas que potenciemde forma efectiva os negócios dogrupo através da prestação de ser-viços de consultoria e do fornecimento de produtos e soluções adequados tendo estes como base osseguintes fundamentos e princípios:

> Evolução não disruptiva de produtos e soluções, rentabilizando o in-vestimento feito, seja em soluções

da PT Inovação ou de terceiros;

> Disponibilização de produtos esoluções tecnologicamente evo-luídos, permitindo a construçãode novos serviços de forma:

> Mais eficiente, melhorando aforma como se faz;

> Mais eficaz, melhorando aqualidade do que se faz;

> Mais flexível, alterando a formacomo se faz;

> Disponibilização de produtos esoluções alinhados com standards e modelos de referência,potenciando uma maior e melhorintegração entre produtos PTINsem descurar a integração comterceiros;

> Os produtos e soluções PTIN nãodevem impor constrangimentosde integração e/ou funcionais,mas sim serem escolhidos emantidos em operação pela suaexcelência operacional e funcional e não pela sua “amarração”funcional.

Em suma, com o Shipnet® SDF, aPT Inovação garante a evoluçãonão disruptiva das suas plataformas de serviço, tendo como panode fundo as redes convergentes depróxima geração, em conformidadecom os standards promovidos pelo3GPP, ETSI e OMA, com umaintegração entre os vários componentes, de acordo com os princípios da arquitectura SOA e as me-lhores práticas de mercado.

suas soluções cada vez mais porfunções baseadas em modelosde referência;

> Reduzir os custos de investimentos e operacionais no desenvolvimento de novos serviços e na suamanutenção;

> Controlar e gerir melhor, e de forma integrada, o portfolio de ser-viços que cada vez mais são emmaior número e com ciclos de vidamais curtos;

> Responder num time to marketadequado na introdução de novosserviços, mas agora numa pers-pectiva de user-centric e não deservice-centric;

> Manter clientes e cativar novos.

6. Conclusões e resultadosSendo a PT Inovação líder nativanas áreas de conhecimento estratégicas para o desenvolvimento

Figura 6 - Perspectiva SDF vs IMS

3rd-party Applications

App1 App2

App3 App4

IT Systems (OSS/BSS)

BillingCRM

OM Assurance

IMS network Legacy network

Unt

rust

edD

omai

nTr

uste

dD

omai

n

SOA

SDF


José Claudio Lobo, licenciado em EngenhariaInformática pelo Instituto Superior PolitécnicoGaya. Desempenhou funções na PT Inovação naárea dos sistemas de informação, nomeadamenteem projectos de desenvolvimento de sistemaspara o mercado fixo de circuitos alugados e degestão de serviços móveis. Participou igualmenteem vários estudos do Eurescom. Nos últimosanos tem trabalhado em funções de arquitectode sistemas, colaborando actualmente no Núcleode Enterprise Architecture do programa dereestruturação de sistemas de informação da Portugal Telecom.

Mário Rui da Costa, licenciado em EngenhariaElectrónica e Telecomunicações pela Universidadede Aveiro e pós-graduado em TecnologiasAeroespaciais pelo Instituto Nacional de Enge-nharia, Tecnologia e Inovação (INETI). Desempe-nhou funções na C.P.R.Marconi na área dastelecomunicações via satélite e na gestão da redede transporte. Desempenhou funções na PTInovação na área de serviços de gestão de redese na área das plataformas de rede inteligente,onde coordenou a equipa de desenvolvimento daplataforma de OM&C. Actualmente desempenhafunções na direcção de Coordenação Tecnológicae Desenho de Soluções, nomeadamente nadefinição do Service Delivery Framework da PTInovação.

Referências[1] OMA Service Environment Architecture Do-cument, Open Mobile Alliance.[2] Service Delivery framework Overwiew, Release 2.0, TM Forum[3] SDF - Industry Groups Positioning Document,Version 2.0, TM Forum.[4] Enhanced Telecom Operations Map®(eTOM), Business Process Framework Release7.0, TM Forum.[5] TS 32.296 V8.2.0, Online Charging System(OCS) : Applications and Interfaces Release 8,3GPP.[6] TS 32.240 V8.3.0, Charging Architecturesand Principles Release 8, 3GPP.OMA Charging Architecture, Open Mobile Alliance[7] OMA Online Charging Interface, Open MobileAlliance[8] 3GPP/3GPP2 Charging in OMA, Open Mobile Alliance[9] Descrição da Solução Convergente IP Multimedia Subsystem (IMS) da PT Inovação, Compromisso shipnet v1, PT Inovação[10] IMS and the Converging Media, IMS 2.0World Forum, Nuno Silva, April 2008[11] Mashing up SOA, Web 2.0 and IMS Technologies, 4th SDP Global Summit, Nuno Silva,Prague, September 2008[12] SOA and SaaS Approach - Transformingthe Legacy, Nuno Silva & Mário Rui Costa, SOAand Web Services Forum — Marcus Evans, london, November 2008[13] SOA in Practice, Nicolai M. Josuttis[14] Shipnet® - Arquitectura de serviços e redesde próxima geração, Nuno Silva, João Plácido,Luís Filipe Silva, Marco Monteiro, José CarlosAmorim, Revista Saber e FazerTelecomunicações 2007

Nuno Silva, licenciado em Engenharia Electrónicae Telecomunicações pela Universidade de Aveiroe mestre em Telecomunicações pela UniversityCollege of London (UCL). Desempenhou funçõesna PT Inovação no desenvolvimento de produtosRDIS e X.25, tendo trabalhado posteriormente nogrupo de Gestão de Redes e Serviços na área deSDH, tendo sido igualmente formador na Gestãode SDH. Exerceu igualmente acções de consultoria em Gestão de Redes e Serviços na PrimeSys(Brasil) e na PT Prime. Participou na elaboraçãode várias propostas para projectos do IST (Information Society Technologies) e estudos do Eurescom, assumindo a liderança dos mesmos.Nos últimos anos tem trabalhado em Redes dePróxima Geração (IMS/TISPAN), tendo liderado ogrupo “Redes e Serviços IMS” no departamentode “Serviços e Redes Móveis”, tendo sido um dosprincipais responsáveis pela definição e imple-mentação do Programa Shipnet®da PT Inovação(Fase 1 : 2005-2007). Desde Março 2008, desempenha funções na PT Inovação na área de “NovasPlataformas e Produtos”, com especial enfâse natemática da convergência fixo-móvel no “ServiceLayer” (plataformas IMS e IN), participando nafase de definição e concepção de serviçosIMS/TISPAN sobre a plataforma ip-Jib® (SIP Application Server), nomeadamente na linha dosprodutos ipCentrex, Classe 5 (VoIP residencial),SIP Trunking, VCC e VPN/ipCentrex Fixo-Móvelconvergente. É formador da PT Inovação na áreade RPG (IMS/TISPAN), sendo habitual orador convidado em várias conferências relacionadas comIMS, SDP, SOA e OSS/BSS (Informa, IIR, TMForum, Marcus Evans, etc). Participa no grupo SA –Service Aspects do 3GPP. É professor convidadoda Universidade de Aveiro, na área de InformationSystems Modeling.

Vitor Jorge Rodrigues dos Santos, licenciadoem Engenharia Informática, ramo de InteligênciaArtificial, pela Faculdade de Ciência da Universidade de Coimbra. Na PT Inovação desde 1994,tendo desempenhado diversos papéis naconstrução e evolução da actual solução NGIN,inicialmente como programador de software emais tarde como responsável pela evolução daplataforma infraestrutural NGIN. Participou nosmais diversos projectos de start-up e manutençãoda solução NGIN nas várias operações do grupoPT, destacando-se na PT Comunicações, naTMN, na Telesp Celular, na Unitel, na Meditel e,por último, na Vivo com o projecto Apolo. Participou também em estudos europeus do Eurescome do ITU-T. Actualmente é o Solution ArchitectNGIN e encontra-se a liderar a equipa de Arquitecturas e Evoluções de Plataformas da PTIN.

Plataforma ip-Jib®: Shipnet® SIP/IMSApplication Server

45

Com o advento das tecnologias eserviços baseados em tecnologia IP,as plataformas de serviços evoluíramnaturalmente no sentido de suportaros principais protocolos das redes denova geração.

No âmbito da iniciativa Shipnet® (Service Handling on IP Networks), a pla-taforma ip-Jib® representa o produtoda PT Inovação de servidor aplicacional SIP/IMS para serviços de temporeal, baseado em tecnologia JAVA,dando suporte a um leque diversificado de Facilitadores de Serviço (Service Enablers) e aplicações, sendoassim uma peça essencial no posicionamento da PT Inovação na área dasredes e serviços de próxima geração.

Dada a referência da PT Inovação nofornecimento de serviços baseadosem plataformas de rede inteligente(NGIN), a necessidade de interoperarcom serviços que executam nestasplataformas é fundamental, dando oip-Jib® igualmente suporte a estasituação, constituindo assim uma pla-taforma de serviços multimédia, numcontexto de convergência fixo-móvel.

palavras-chave:

SIP/IMS Application Server, JAINSLEE, SIP Servlets, SOA, OMA OSE,Service Enablers, JEE, IMS, TISPAN

Nuno Silva Marco Monteiro

Paulo Chainho Pedro Braz

João Baltazar



1. IntroduçãoOs operadores de comunicaçõesenfrentam grandes desafios colocados pelos emergentes fornecedoresde conteúdos e serviços da Internet— e.g., Skype, Google, Yahoo,MSN, etc. — que funcionam nummodelo OTT (Over The Top)1. Umaatitude passiva perante esta evo-lução do mercado tornará a PortugalTelecom num mero fornecedor de“pipelines” — em vias de se tornarum serviço commodity — correndoo grande risco de perder o acessoao cliente final. Para contrariar estatendência, o Grupo PT terá que sercapaz de criar um novo ecossistemade serviços capaz de satisfazer emtempo útil as necessidades de segmentos de mercado cada vez maisrestritos e exigentes. A iniciativaShipnet® [1] da PT Inovação pro-cura responder a esta necessidade.

No âmbito da iniciativa Shipnet®,que tem como base de referênciaos standards 3GPP IP Multimedia

Subsystem (IMS) [2] e ETSI TISPAN[3], a PT Inovação definiu uma arquitectura estratificada, composta poruma camada relacionada com osaspectos de controlo de sessões edo transporte, designada por Control Transport Framework (CTF), epor outra camada relacionada comos aspectos de serviços e aplica-ções, designada por Service Deli-very Framework (SDF) [4].

O ip-Jib® é um dos componentesbase do Shipnet® SDF, disponibilizando para além de um ambientede execução de tempo real (SLEE)baseado em tecnologia Java, umconjunto de Service Enablers, quedisponibilizam funcionalidades àsaplicações/serviços abstraindo asquestões particulares das redes edos protocolos, bem como um conjunto de conectores para redes denova geração (Resource Adapters).

É de salientar que o ip-Jib® dá resposta a situações em que a rede é

all-IP, contemplando arquitecturas3GPP IMS e ETSI TISPAN, ou redesVoIP/Softswitch.

Este artigo descreve os aspectostecnológicos e arquitecturais associados à plataforma ip-Jib®, e a suacontextualização na iniciativa Ship-net®, bem como os resultados e aimportância para o negócio globaldo Grupo PT.

2. Descrição do sistema ousoluçãoA plataforma ip-Jib® é uma plataforma de serviços carrier-grade eaberta, baseada nos standards do3GPP IMS e ETSI TISPAN, disponibilizando um conjunto de interfacespara integração com redes de novageração IMS/TISPAN ou com sistemas legados, bem como um conjunto de interfaces para terceirospara desenvolvimento de serviçospersonalizados.

O ip-Jib® pode ser configurado

1Estes actores disponibilizam os seus serviços através da Internet sem terem qualquer relação com os Operadores de Telecomunicações da rede de acessode Banda-Larga.

como um SCIM - Service CapabilityInteraction Manager, permitindo assim a orquestração de serviços distribuídos por várias plataformas deserviços.

O ip-Jib® disponibiliza todas as funcionalidades necessárias para geriro ciclo de vida dos diferentes componentes constituintes dos serviçose aplicações, sendo baseado nostandard JAIN SLEE (JSR22 [5] /JSR240 [6]), tendo actualmente como base computacional o SIP/IMSRhino Application Server [7].

É de referir no entanto que, de futuro, em função da maturidade deoutras soluções e tecnologias, podem ser consideradas alternativas àsolução actual, nomeadamente ou-tros servidores de aplicações JAINSLEE ou, inclusive, a utilização deservidores compatíveis com a tecnologia SIP Servlets 1.1 (JSR 289) [8].

Uma das características diferenciadoras do ip-Jib®, em relação a ou-tros produtos do mercado, é a suaintegração efectiva com as plataformas de Rede Inteligente, em parti-cular com a solução NGIN da PTInovação. Esta integração permitepotenciar as plataformas de servi-ços existentes e mais rapidamenteexplorar novas fontes de receitasproporcionados pelos novos servi-ços das Redes SIP/IMS para osmais de 80 milhões de clientes daplataforma NGIN.

Conceptualmente, o ip-Jib® é composto pelas camadas de ServiceEnablers e Resource Adapters, indoao encontro da arquitectura OMAService Environment (OSE) definidapelo OMA (Open Mobile Alliance) [9].

A Figura 1 apresenta uma versãosimplificada da arquitectura lógicado ip-Jib®, na qual são apresentados alguns Service Enablers e Resource Adapters.

47 Plataforma ip-Jib®: Shipnet® SIP/IMSApplication Server

Figura 1 - Arquitectura da plataforma ip-Jib®

JAIN SLEE

Enablers

B2BUA Charging

Proxy SMINT

Estatísticas Alarmes

Resource Adapters

SIP/ISC InoAPI

Diameter Framework

Sh Ro

httpJEE

2.1. Service EnablersOs Service Enablers são componentes para disponibilização de funcionalidades de mais alto nível, comabstracção sobre as componentesResource Adapters. Os ServiceEnablers disponíveis são:

> Session Enabler - funcionalidadesde controlo de Sessão Multimédia (chamadas) incluindo Proxy,B2BUA, Forward, early-mediacontrol, transferência de chamada, etc.;

> Presence Enabler com suporte aoprotocolo SIMPLE (IMS) e XMPP,permite às aplicações consultar,publicar e gerir estados de presen-ça entre entidades de presençaexternas e internas, desempe-nhando o papel de PresenceWatcher e/ou Presence Source;

> Messaging com suporte a mensagens instantâneas (SIMPLE eXMPP) e correio electrónico (SM-TP, POP3, IMAP4);

> Offline Charging para a geraçãode registos de chamadas (CDR);

> Online Charging com suportea pré-pagos por tempo ou porevento;

> Group Enabler disponibiliza funcionalidades para gerir grupos elistas de contactos;

> Enabler de Estatísticas, que temcomo funções o registo de deta-lhes de chamadas e de utilizaçãode serviços;

> Enabler de Alarmística, utilizadopara reportar erros graves e críticos no funcionamento do ip-Jib®e dos serviços de alto nível. A suafunção é providenciar uma interface mais simplificada para oenvio de alarmes, utilizando umainterface JMX.


2.2. Resource AdaptersO ip-Jib® disponibiliza igualmenteum conjunto de Resource Adapters(RA), que são componentes quepermitem a interligação a recursosexternos (redes ou outros componentes). Os RA disponíveis são osseguintes:

> IP IETF (RFC3261) e ISC SIP(3GPP);

> Diameter, nomeadamente:

> Diameter CCA - Suporte paraIETF RFC 4006;

> Diameter Base GA - Suportepara IETF-RFC 3588 excluindoaccounting;

> Diameter Ro - Suporte paraIETF-RFC 4006, 3GPP TS32.240 (v6.3.0), 3GPP TS32.240 (v7.0.0), 3GPP TS32.299 (v7.3.0);

> Diameter Rf - Suporte para3GPP TS 32.240, 32.299;

> Diameter Sh.

> Conector JEE disponibiliza interfaces Web (HTTP) para interacti-vidade do utilizador com serviçosSLEE;

> HTTP 1.1;

> SS#7, incluindo CAP V2, INAPCS1, MAP, TCAP;

> SMPP v5.0;

> MM7, baseado no 3GPP TS23.140 v5.3.0.

Para além dos RA que são disponibilizados nativamente pela plata-forma ip-Jib®, é possível aindadesenvolver outros RA, utilizandoa ferramenta Resource AdapterFramework. No contexto actual foram desenvolvidos, pela PT Inovação, os seguintes RA:

> RA InoAPI é uma interface proprie-tária, e complementar ao SIP, parausar todas as funcionalidadesavançadas do MRF ip-Windless®

da PT Inovação;

> RA RTDAP, que disponibiliza todas as funcionalidades avançadas de charging em tempo realda plataforma NGIN;

> RA XMPP para interligar a servidores de presença e mensagensinstantâneas XMPP;

> RA JDBC / Hibernate para ligaçãoaos repositórios de dados com osperfis de utilizadores e serviços;

> RA Rule Engine para ligação amotores de regras, permitindocriar novos e inovadores serviçosque tenham na sua lógica de ne-gócio um comportamento basea-do em regras;

> RA Javamail (SMTP, IMAP4,POP3) para ligação a servidoresde e-mail;

> RA X C A P / X D M C p e r m i t eligações servidores XCAP Ser-vers, como é o caso dos servidores XDM (XML Document Ma-nagement) normalizados pelaOMA;

> RA LDAP;

> RA LIF.

2.3. ClusteringRelativamente a questões de robus-tez, a plataforma ip-Jib® possibilitaa aplicação de técnicas de tolerânciaa falhas e alta disponibilidade, querao nível da plataforma em si, quer aonível dos seus componentes.

Devido ao seu funcionamento emcluster, permite que qualquer falhaque ocorra ao nível de um nó não setorne impeditiva do funcionamentodos restantes nós e, portanto, do ip-Jib® em si.

2 http://www.xmpp.org/

49

Isto permite uma taxa de utilizaçãona ordem dos 99,999%, estandoindisponível no máximo durante 5minutos por ano.

Poderá adicionalmente ser configu-rado um mecanismo de replicaçãode actividades, permitindo que oestado dos serviços e/ou RA, presentes num determinado nó, sejamreplicados através de todos os nósdo cluster. Em caso de falha doprimeiro nó, qualquer um dos ou-tros poderá assumir as suas actividades, sem que a falha seja perceptível ao utilizador.

Num cluster que possua N nós, osvalores para desempenho serãoaproximadamente Nx125 chamadaspor segundo. Em caso de se usar ojá referido mecanismo de replicação,haverá uma ligeira quebra de de-sempenho devido à constante sincronização obrigatória entre os nós.

Em suma, a plataforma ip-Jib® disponibiliza:

> Uma arquitectura em softwarecom tolerância a falhas compostapor N nós simétricos em modoactivo-activo (desta forma umasessão/chamada não falha quando um membro do cluster falha);

> Um uso escalável, eficiente eexemplar de todo o hardware disponível devido à arquitectura daplataforma (os nós estão em modo activo-activo);

> Uma única representação dosistema para administração apesar da arquitectura em cluster;

> Upgrade online para a plataformae para os serviços;

> Auto monitorização e auto recuperação em caso de falhas parase obter um sistema previsível efiável.

2.4. DesempenhoOs valores de desempenho do ip-Jib®

são, em grande parte, definidos pelascaracterísticas físicas do servidoraplicacional, variando assim de sistema para sistema. Como valor de re-ferência, para um servidor com QuadIntel Xeon @ 3Ghz e 4Gb de memó-ria RAM é possível obter valores dedesempenho na ordem dos 760eventos por segundo.

3. ResultadosFoi definida uma arquitectura deconstrução de serviços/enablers deforma a obter uma metodologia detrabalho comum na construção decomponentes, permitindo uma me-lhor articulação entre as diferentesequipas de desenvolvimento.

No presente, a versão da plataformaé a v1.0 dando resposta a requisitosde clustering, alta disponibilidade etolerância a falhas.

Os componentes actualmente existentes são:

> O Session Enabler v1.1 com su-porte das funcionalidades deB2BUA, early-media control, for-king, entre outros;

> O Charging Enabler v1.0, comsuporte de taxação baseada poreventos;

> O Enabler de Estatísticas v1.0,com funções de registo de deta-lhes de chamadas e de utilizaçãode serviços, podendo ser igualmente usado como a tarifaçãopós-paga;

> O Enabler de Alarmística v1.0,com funções de reporte de errosgraves e críticos no funcionamento do ip-Jib® e dos serviços dealto nível;

> O RA InoAPI v1.1.2, para controlodo MRF ip-Windless® da PTInovação;

> O RA de SIP/ISC v1.5.10, parainterligação com redes SIP/IMS;

> O RA de Diameter v1.1, para interligação com componentes em


redes IMS, suportando DiameterBase, CCA, Sh, Ro e Rf;

> O RA de HTTP v1.1, para recep-ção de pedidos HTTP;

> O RA de SOAP v1.0, para recep-ção de pedidos SOAP;

> O RA de CDR v1.4.5, para escritaem ficheiro local de Call DetailRecords.

A solução actual do ip-Jib® utiliza atecnologia JAIN SLEE 1.0, estandono entanto prevista a migração paraJAIN SLEE 1.1.

É de salientar que todos estes componentes do ip-Jib® (Service Enablers e RA) permitem uma constru-ção de serviços de uma forma maiságil e mais eficiente. A título deexemplo, refira-se a construção dosseguintes serviços, tal como apresentado na Figura 2:

> ipCentrex;

> VoIP Residencial (Classe 5);

> SIP Trunking;

> VCC (Voice Call Continuity), emarticulação com a plataformaNGIN;

> Coloured Ring Back Tone (CRBT);

> Multimedia Web Conference.

4. Importância para os negóciosdo grupo PTA disponibilização de serviços devalor acrescentado, sobre uma redeque está num processo de migra-ção para uma rede all-IP, é de fundamental importância para um ope-rador de excelência, num mercadocada vez mais global e competitivo.

Assim, a implementação de novosserviços, tais como ipCentrex, VoIPResidencial (Classe 5), SIP Trunking,Coloured Ring Back Tones (CRBT),Multimedia Web Conference, etc.apenas é possível tendo como baseuma plataforma baseada nas tecnologias mais recentes dos mundos

Figura 2 - Serviços/Aplicações sobre plataforma ip-Jib®

IT e Telco (Java, SIP, JAIN SLEE,SIP Servlets, etc).

Não deve ser esquecida, igualmentede extrema importância, a necessá-ria interoperabilidade entre as plata-formas de serviços legadas (NGIN)e o ip-Jib®, garantia essencial paraa transição suave dos serviços e res-pectivos clientes.

A título de exemplo, refira-se a convergência de serviços corporativosde voz para o mercado corporativo,em que soluções de VPN Fixo-Mó-vel (com extensões fixas e móveiscom plano de numeração privado ecom controlo de custos diferencia-do) têm de ser integradas com asextensões VoIP de um serviço ipCentrex, a executar sobre o ip-Jib®num ambiente de rede Softswitchou IMS, indo assim de encontro auma solução integrada e convergente de ipCentrex Fixo-Móvel.

Um outro exemplo, e que reflecteigualmente um cenário de conver-gência Fixo-Móvel tirando partidode ambas as plataformas, está rela

cionado com os aspectos de continuidade de sessão entre redes Wi--Fi e GSM, tal como especificado pelo serviço Voice Call Continuity (VCC)[10] (ou mais recentemente pelo ser-viço Multimedia Session Continuity(MSC) [11], em que a interacção en-tre as 2 plataformas permite a imple-mentação destes serviços.

Igualmente importante será habilitaras plataformas de serviços (NGIN)a tirar proveito dos novos ServiceEnablers das redes de próxima ge-ração (Presença, XDMS/Group ListManagement, etc.).

É de referir que os serviços anteriormente descritos são demonstráveisna rede SALINA da PT Inovação, queimplementa uma infra-estrutura derede de próxima geração, de acordocom as arquitecturas IMS e TISPAN.

Em suma, com a flexibilidade e robustez da plataforma ip-Jib®, quedisponibiliza um ambiente de exe-cução de tempo real para serviçosall-IP, bem como um conjunto deService Enablers, que permitem um


rápido desenvolvimento de serviçose aplicações, o grupo PT encontra--se numa posição privilegiada parafazer face aos requisitos exigentesdos vários clientes, com o time tomarket exigido.

5. ConclusõesA PT Inovação, empresa de refe-rência no fornecimento de serviçosde rede inteligente (NGIN) para ambientes tradicionais Circuit Switched(CS) e Packet Switched (PS), acompanha as várias actividades de normalização de redes e serviços, tendoem vista a evolução das suas plataformas para um cenário all-IP (IMS/TISPAN).

Como tal, a oferta de serviços, tendocomo pano de fundo a convergênciafixo-móvel, é um factor crítico paraa diferenciação e conquista de novosmercados e negócios.

A resposta da PT Inovação aos desafios de convergência fixo-móvelque se aproximam é baseada na de-finição de um Framework para a cria-ção, instalação, execução e gestão

Services and Applications

NumberTranslation

CRBT

IP-SM-GW

IM

VPN

Parlay-X

Prepaid

Conference &Collaboration

ip-Centrex

ResidentialVoIP/Class5

VCC

XDMS

Service Delivery Platforms

SIP AS

ip-Jib®

SCIM

ip-Jib®

IM-SSF

ip-Sail®

Service Enablers

Presence

ágil e eficiente de serviços (Shipnet®Service Delivery Framework), deacordo com os requisitos dos váriosclientes.

O ip-Jib®, disponibilizando porexcelência o ambiente de execuçãoserviços multimedia de tempo realdo Shipnet® SDF é uma peça fundamental para atingir os objectivosde excelência na prestação deserviços ao cliente.

Referências[1] “Shipnet® - Arquitectura de serviços e redesde próxima geração”, Nuno Silva, João Plácido,Luis Filipe Silva, Marco Monteiro, José CarlosAmorim, Revista Saber e Fazer Telecomuni-cações 2007.[2] - 3GPP IMS - IP Multimedia Subsystem,www.3gpp.org[3] - ETSI TISPAN, www.etsi.org/TISPAN[4] “Shipnet® Service Delivery Framework (SDF)”,Nuno Silva, Vitor Santos, Cláudio Lobo, MárioRui Costa, Revista Saber & Fazer Telecomuni-cações 2008.[5] - JSR 22, JAIN SLEE 1.0,http://jcp.org/en/jsr/detail?id=22[6] - JSR 240, JAIN SLEE 1.1,http://jcp.org/en/jsr/detail?id=240[7] - Rhino SIP/IMS AS,http://www.opencloud.com[8] - JSR 289, SIP Servlets 1.1,http://jcp.org/en/jsr/detail?id=289[9] OMA - Open Mobile Alliance,http://www.openmobilealliance.org/[10] - 3GPP VCC, Voice Call Continuity,http://www.3gpp.org/ftp/Specs/html-info/23507.htm[11] - 3GPP MSC, Multimedia Session Continuity,http://www.3gpp.org/ftp/Specs/html-info/23893.htm

Nuno Silva, licenciado em Engenharia Electrónicae Telecomunicações pela Universidade de Aveiroe mestre em Telecomunicações pela UniversityCollege of London (UCL). Desempenhou funçõesna PT Inovação no desenvolvimento de produtosRDIS e X.25, tendo trabalhado posteriormente nogrupo de Gestão de Redes e Serviços na área deSDH, tendo sido formador na Gestão de SDH.Exerceu igualmente acções de consultoria emGestão de Redes e Serviços na PrimeSys (Brasil)e na PT Prime. Participou na elaboração de váriaspropostas para projectos do IST (Information Society Technologies) e estudos do Eurescom, assumindo a liderança dos mesmos. Nos últimosanos tem trabalhado em Redes de PróximaGeração (IMS/TISPAN), tendo liderado o grupo“Redes e Serviços IMS” no departamento de“Serviços e Redes Móveis”, tendo sido um dosprincipais responsáveis pela def in ição eimplementação do Programa Shipnet®da PTInovação (Fase 1 : 2005-2007). Desde Março2008, desempenha funções na PT Inovação naárea de “Novas Plataformas e Produtos”, comespecial enfâse na temática da convergência fixo-móvel no “Service Layer” (plataformas IMS e IN),participando na fase de definição e concepçãode serviços IMS/TISPAN sobre a plataforma ip-Jib® (SIP Application Server), nomeadamente nalinha dos produtos ipCentrex, Classe 5 (VoIP residencial), SIP Trunking, VCC e VPN/ipCentrexFixo-Móvel convergente. É formador da PTInovação na área de RPG (IMS/TISPAN), sendohabitual orador convidado em várias conferênciasrelacionadas com IMS, SDP, SOA e OSS/BSS(Informa, IIR, TMForum, Marcus Evans, etc.). Participa no grupo SA - Service Aspects do 3GPP.Éprofessor convidado da Universidade de Aveiro,na área de Information Systems Modeling.

Marco Filipe Monteiro, licenciou-se em Enge-nharia Electrónica e Telecomunicações, pela Universidade de Aveiro, em 2004. Ingressou nesseano na PT Inovação encontrando-se actualmenteno departamento de Desenvolvimento de Plataformas e Produtos. Possui conhecimentos sobrevárias tecnologias/protocolos para desenvolvimento de serviços em Redes de Próxima Geração(IMS/TISPAN), destacando-se a tecnologia JainSLEE, SIP Servlets, J2EE e o protocolo SIP. Noprograma Shipnet® da PT Inovação é um dosresponsáveis pela plataforma ip-Jib®, quer aonível do desenvolvimento de conectores, serviçose service enablers, quer ao nível de especificaçãodesses mesmos componentes. Relativamente aosserviços e aplicações Shipnet® é actualmente umdos responsáveis pela especificação e desenvolvimento da aplicação IP Centrex.

Paulo Chainho, mestrado em Telecomunicaçõespelo IST da Universidade Técnica de Lisboa.Gestor de Projectos. Actualmente responsávelpelo Desenvolvimento de Plataformas de Presença e Serviços Colaborativos no departamentoDPP4 (Desenvolvimento de Novas Plataformas eProdutos). Entusiasta do "Open Source". Grandeexperiência em projectos Internacionais deInvestigação e Desenvolvimento incluindo Eurescom, ETSIN SPAN e EU IST. Consultoria naintrodução de plataformas de serviços RPG e IMSno Grupo PT.

Pedro Elói Braz, licenciou-se em EngenhariaElectrónica e Telecomunicações, pela Universidade de Aveiro, em 2007. Ingressou nesse anona PT Inovação como estagiário, tendo passadopelo departamento de Serviços e Redes Móveis.Actualmente encontra-se no departamento deDesenvolvimento de Plataformas e Produtos. Nasua actividade adquiriu conhecimentos sobrevárias tecnologias/protocolos para desenvolvimento de serviços em Redes de Próxima Geração(IMS/TISPAN), destacando-se a tecnologia JainSLEE e o protocolo SIP. No período de estágioteve como principal função o desenvolvimento deaplicações/serviços SIP/IMS convergentes noApplication Server ip-Jib®, sendo um dos principais dinamizadores da aplicação IP Centrex e doVCC (Voice Call Continuity). Em Outubro de 2008tornou-se um colaborador efectivo da PT Inovação,assumindo responsabil idades na área daespecificação de requisitos. Actualmente possuiconhecimentos de Jain SLEE, SIP e redes IMS,tendo alguns conhecimentos de redes inteligentes.

João Vítor Rico Baltazar é Mestre em Engenha-ria Informática pela Universidade de Coimbra. Em2007 ingressou como estagiário na PT Inovação,no departamento de Serviços e Redes Móveis,estando presentemente no departamento de Desenvolvimento de Plataformas e Produtos.Noâmbito da sua actividade desenvolveu compe-tências em redes IMS de próxima geração, comdestaque para a tecnologia Jain SLEE, protocolosSIP e Diameter e mecanismos de Charging. Esteveenvolvido no desenvolvimento da solução de servidor aplicacional IMS da PT Inovação, ip-Jib®, nasáreas de Charging e Clustering. Actualmente encontra-se a trabalhar na área de Clustering ip-Jib®dando especial ênfase às questões de alta Disponibilidade/Tolerância a Falhas e desempenho.

51 Plataforma ip-Jib®: Shipnet® SIP/IMSApplication Server


palavras-chave:

Serviços de dados, conteúdos dedados, sessões de dados, ipRaft

Com o aumento de utilização dasredes de dados nos últimos anos,suportado nas melhorias verificadasao nível das redes de acesso (fixas emóveis) e dos terminais, surgiramtambém os mais diversos tipos deserviços. Actualmente, podemos usaras redes de dados para aceder à internet, fazer download de jogos,toques ou imagens entre muitas outras aplicações.

Assim, tornou-se necessário a cria-ção de novos modelos de negócio,por parte dos operadores, para tirarpartido deste novo mercado que seencontra ainda em crescimento e segundo as estimativas de vários ana-listas continuará a crescer nos próxi-mos anos.

Para fazer face a estas novas solici-tações, a PT Inovação desenvolveuuma solução para controlo em tempo real, constituída por dois sistemas. O primeiro destina-se a disponibilizar uma interface com as redesde comutação de pacotes para sinalização e controlo em tempo real deacessos às redes de dados e a serviços de valor acrescentado numoperador; enquanto que o segundo

Miguel Santos Rui Quaresma

integra todas as funções de tarifaçãoe taxação dos acessos dos clientese implementa os modelos de negó-cios pedidos pelo operador para cada tipo de acesso e serviço.

Esta solução permitiu a evolução domodelo de tarifação e controlo deserviços de dados, onde o controloem tempo real do acesso aos servi-ços se tem mostrado um garante dadiminuição da fraude, permitindo ainda uma transparência relativamenteao número de clientes e de plata-formas de serviços em exploraçãona sua rede. Neste momento, a so-lução ipRaft encontra-se em explo-ração comercial nos 6 maiores ope-radores clientes da PT Inovaçãocontrolando mais de 30 milhões deutilizadores.

O artigo pretende demonstrar a capacidade e versatilidade da soluçãoipRaft e a sua importância para osoperadores e para o negócio da PTInovação. Será demonstrado atravésde exemplo de uma possível soluçãocomercial que integrará os serviçosque são actualmente controlados eoutros que se prevêem vir a ser controlados nos diversos operadores.

Exemplo Comercial de uma Solução deControlo de Serviços de Dados

53

1. IntroduçãoA crescente utilização das redes dedados, aliada a uma saturação dosserviços sobre as redes legadas devoz, tem pressionado os operadores de telecomunicações a redireccionarem o foco da evolução dassuas redes para as redes de dadose redes convergentes.

As redes de telecomunicações sofreram nos últimos anos diversasevoluções e melhorias que permitiram a disponibilização de uma vastagama de novos serviços baseadosnas comunicações de dados. O aparecimento de várias solicitações sobre redes IP, de onde se destaca cla-ramente a Internet, levou a que o quehá uma década era usado quase exclusivamente para conversação passasse (e com mais intensidade nosúltimos anos) a ser também utilizadoem grande escala para acessos dedados.

Actualmente, a ligação às redes dedados são uma necessidade “bási-ca” de uma grande fatia da população mundial para que esta possadesempenhar diariamente o seu

trabalho. Mesmo fora do ambienteempresarial, as comunicações dedados deixaram de ser uma comodidade só para algumas franjas dasociedade para passarem a serconsideradas uma necessidade.

Tem-se verificado que esta evolu-ção não se restringe a uma dadaregião geográfica ou económica, éantes uma tendência mundial. Hojeem dia é possível perceber que apopularidade e importância dos serviços de dados são entendidas deigual modo seja em Portugal, noBrasil, em Marrocos, em Angola ouem Timor.

Esta evolução das redes de tele-comunicações, e a procura crescente pelos serviços de dados conduziu por sua vez a uma revoluçãonos terminais móveis e nos dispositivos de acesso nas redes fixas. Estecrescimento sofreu novo impulsocom o advento da banda larga, primeiro a banda larga fixa e depois amóvel.

No que respeita às operações deredes móveis, os telemóveis dispo

nibilizam hoje em dia um número defuncionalidades muito superior àsexistentes nas gerações anteriores,nomeadamente no acesso a diversos tipos de serviços e redes de dados. Presentemente, é possível aum qualquer cliente escolher de entre um vasto número de telemóveisque disponibilizam acesso às maisvariadas tecnologias de acesso: Wi--Fi, Bluetooth, 2,5G, 3G e 3,5G. Étambém possível encontrar váriostipos de funcionalidades como sejam email, instant messaging, MMS,jogos, toques, etc.

Já em relação às redes fixas, oaparecimento e oferta em grandeescala da banda larga fixa permitiuo aparecimento de novos tipos deserviços de dados dos disponibilizados pelos ISP, dos quais se destacao serviço de televisão.

Actualmente, a penetração de telemóveis aproxima-se já dos 80% anível mundial, ultrapassando mesmo os 100% em muitos países. Sea isto se juntar a cobertura do telefone fixo verifica-se que o mercadodas telecomunicações mostra já

grandes níveis de saturação no querespeita a serviços de voz. Comoresultado, os operadores vêem-seobrigados a apostar noutros tiposde serviços, aparecendo os serviçossobre redes de dados como formade fazer evoluir o seu negócio e dediferenciação da concorrência. Osclientes já não procuram apenas aoperadora que lhes oferece o tarifário mais barato ou que lhes permite falar mais barato com os seusamigos e familiares, procuram também uma operadora que lhes ofere-ça uma boa cobertura, bons tarifários e uma diversidade nos serviçose acessos de dados.

Para além do suporte a novos tiposde interfaces, aplicações e serviçosde dados, os operadores pretendem que o controlo e tarifação dosacessos a esses novos serviços seja sempre que possível feito emtempo real. Aquando do lançamento de um novo serviço é comumque a taxação desse serviço sejaefectuada offline com base nos registos gerados pelos elementos derede. No entanto, isso pode conduzir a uma utilização indevida porparte de alguns clientes (por exemplo, usufruírem do serviço sem quetenham saldo para tal). Assim, a tarifação online deste tipo de serviçostorna-se muito importante, pois permite um melhor controlo ao nível dafraude e da utilização das plataformas e das receitas efectivas dooperador. O controlo online destetipo de serviços tem-se mostradoum garante da diminuição da fraude,permitindo ainda uma transparênciarelativamente ao número de clientese de plataformas de serviços emexploração na sua rede. Rapidamen-te se percebeu também que o controlo em tempo real, mais que impe-dir fraudes, é essencial tambémpara uma experiência mais favorávelao cliente final, pelo seu controlo decustos em tempo real, notificações,Advice Of Charge (AoC), permitindouma interactividade desconhecidaaté então.

A tarifação online assume uma importância ainda maior quando setrata de serviços disponibilizadospor parceiros do operador, com osquais são firmados acordos de revenue sharing. Neste tipo de acordoso operador é responsável por pagarao parceiro um determinado valorpor cada acesso ao serviço efectuado a partir da sua rede. No caso dehaver utilização indevida por partede alguns clientes, aos quais nãoseja possível cobrar, o operador incorre assim em perdas de capital.

Como foi atrás referido, os serviçosde dados são cada vez mais factores diferenciadores entre os váriosoperadores, no entanto é necessário perceber que os serviços devoz e de mensagens continuam aser responsáveis por uma grandepercentagem das receitas. Destemodo é de todo o interesse fornecersoluções onde estes três tipos deserviços sejam unificados. De formaa cumprir estes novos requisitos, assoluções de controlo e taxação avan-çam então para modelos onde osdiferentes tipos de serviços (voz, dados e mensagem) se encontram interligados e onde é possível oferecertaxação, promoções e campanhasintegradas — por exemplo, umapromoção onde se oferece minutosde conversação, SMS e downloadde toques.

Com o fim de responder às solicita-ções geradas pela alteração de mercado descrita anteriormente, a PTInovação desenvolveu a solução ipRaft (que disponibiliza diversas interfaces de rede para controlo da sessãoe da largura de banda associada acada cliente) à qual se aliou a criaçãoe utilização de modelos de dados fle-xíveis e integrados.

Este artigo pretende apresentar umexemplo de uma possível instalaçãocomercial, com uma vasta gama deconteúdos e tipos de acesso, quereflecte a forma como os novos requisitos dos operadores de teleco-municações, derivados do aumento


de popularidade dos serviços de dados, podem ser respondidos pelasolução desenvolvida pela PT Inovação.

2. Uma solução de dados comcontrolo PTINEmbora inicialmente desenvolvidacomo uma plataforma quase autónoma dentro do universo de produtos NGIN, a solução de controloe taxação em tempo real paraserviços de dados está hoje completamente integrada com os demais serviços.

A primeira solução de controlo deserviços de dados, o NGIN Pack,apareceu como uma plataforma independente, capaz de ser integradacom outras plataformas NGIN através de mecanismos de reserva desaldo. Esta solução permitia ocontrolo em tempo real de clientespré-pagos NGIN que se encontravam nas plataformas que executavam os serviços típicos de redesinteligentes.

Apesar de o conceito de redes inteligentes ter sido aplicado tambéma solução para controlar os serviçosde dados, as particularidades decontrolo destes tornaram necessária a existência de uma plataforma nova. As plataformas NGIN nãoestavam nessa altura preparadasainda para acolher um mundo tãodiferente, o que colidia com a ne-cessidade de, rapidamente, colocaruma solução no mercado.

Os serviços de dados revestiram--se de alguns desafios que, na altura,não existiam com os típicos serviçosde redes inteligentes. Até então ocontrolo era tipicamente por tempo,passou a sê-lo também por volumede tráfego e conteúdos, o clientecomeçou a poder usar simultaneamente diversos tipos de serviço nocontexto de uma única sessão. Oselementos de rede usados, tipicamente não conheciam os clientes queestavam a controlar e não sabiampor isso qual a plataforma onde se

55

encontravam. Os clientes pós-pagosforam por isso controlados tambémem tempo real e foram necessáriosmecanismos de saber qual a plata-forma NGIN onde se encontrava ocliente (por exemplo para saber osaldo ou o seu estado). Outros deta-lhes, como por exemplo, a taxaçãopor QoS ou saldos em volume, foramtambém incorporados.

Os serviços de dados são vistoshoje como mais uma forma de alargar a oferta comercial dos operadores aos seus clientes, e é nestavertente que cada vez mais surgemofertas comerciais que combinamserviços do mundo Circuit Switched(CS) com serviços do mundo PacketSwitched (PS). A fusão da execuçãodas regras de negócio de CS e PSnuma única plataforma era por issoessencial.

Actualmente, na solução PTIN, aexecução das lógicas de negóciode serviços de dados é realizada namesma plataforma dos restantesserviços CS oferecidos ao cliente.Esta convergência permitiu, além daoferta de produtos conjuntos, algumas sinergias tornando a soluçãoconceptualmente mais simples,apesar da crescente complexidadedas regras de negócio.

Como subsistema integrado noframework NGIN, os serviços de dados facilmente passaram a estar integrados com os restantes sub-sistemas NGIN, beneficiando demais de uma década de evoluçãotecnológica.

Ainda assim, os serviços de dadoslidam com realidades diferentes,controlam elementos de rede também diferentes, muitas vezes semprotocolos normalizados, e requerem que exista uma normalização aonível do processamento de regrasde negócio, que terão de ser inte-gradas com os restantes serviçosem termos de oferta comercial.

Como foi referido anteriormente, afuncionalidade básica do controlo

em tempo real de serviços de dadosé o encerramento das sessões dosclientes que não possuam autoriza-ção ou saldo que lhes permita usufruir do serviço, minimizando a exis-tência de saldos negativos e fraudes.O tratamento em mecanismos offlineou hot billing devem também sersuportados, mas apenas em situa-ções de contingência em que não seja possível o controlo em tempo real.

Devido à possibilidade da existênciade múltiplos serviços em uso simultaneamente, as sessões de serviçopartilham o mesmo saldo mas comreservas independentes. Como assessões de serviços de dados sãotipicamente muito longas quandocomparados com os serviços tradicionais, o débito dos respectivoscustos são realizados ao longo dasessão e não apenas no final.

Tão importante como o controlo sobre os elementos de rede é o cálculo do custo de um serviço, pois sócom um mecanismo de rating emtempo real é possível saber quandoo cliente passa para uma situaçãoem que deve ser impedido de continuar. Com um motor de rating emtempo real, é necessário não só obter o custo baseado nos consumosdo cliente, mas também saber o inverso, isto é, com o saldo que possui, qual a quota de utilização (emvolume, tempo, eventos) permitidapara o cliente para um dado serviço.

A solução PT Inovação permite queo custo a aplicar dependa de váriosfactores que podem ser divididosem três grupos: as característicasdo cliente, as circunstâncias doacesso e o consumo realizado. Ascaracterísticas do cliente são determinantes, pois cada cliente tem necessidades específicas e pode, dependendo dos planos tarifários quepossui, das promoções que subscreveu ou dos seus saldos (em dinheiro, volume, tempo e eventos),ser cobrado de uma forma diferenciada. As circunstâncias do acessocaracterizam o que deve ser pago

pelo cliente e atributos como o serviço usado (APN (…….), IP/porto,conteúdo), a hora do acesso, a localização onde o cliente usou, a tecnologia do acesso ou o QoS, podem influenciar a tarifa. Finalmente,a quantidade do consumo, seja emtempo, em volume ou em eventosserá o factor que mais afectará o cus-to a imputar ao cliente.

O controlo que é realizado não seresume apenas a autorizar ou nãoo início de uma sessão ou ao barramento da mesma no final de saldo.A qualquer instante é possível saberqual o consumo do cliente e agir deacordo, como por exemplo o enviode notificações ao cliente, reencaminhamento para páginas ou atémesmo limitar a largura de bandado acesso. É possível também impedir o acesso a serviços que o cliente não possua, ou mesmo avisá--lo que o custo será mais elevado eperguntar-lhe se quer ou não prosseguir. Esta interactividade resultanuma experiência mais rica com ocliente e constitui também um gran-de valor acrescentado às soluçõesde controlo em tempo real.

3. Exemplo de uma soluçãocomercialCom a solução desenvolvida pelaPT Inovação é possível a um operador definir e empregar diferentesmodelos de controlo e taxação paraas diversas tecnologias de acesso,tipos de serviços e conteúdos quedisponibiliza aos seus clientes.

Um operador que opere na rede fixae nas redes móveis, e que pretendadisponibilizar serviços de dados, poderá utilizar a solução PTIN para ocontrolo dos seus clientes (Figura 1).

É possível ao operador escolher deentre os vários tipos de controlo etaxação disponibilizados, nomeadamente: tarifa fixa; taxação por volume cursado (uplink e/ou downlink);taxação por tempo de acesso; nú-mero de eventos consumidos.

O operador pretende disponibilizar

Exemplo Comercial de uma Solução deControlo de Serviços de Dados


os seguintes serviços para a redefixa:

1. Acesso internet;

2. Televisão.

Assim, para a cobrança de acessosinternet de ISP (Internet Service Provider) de rede fixa, sobre arquitecturas ADSL (Asymmetric Digital Subscriber Line) é utilizado o controlo comtarifa fixa. Neste, é normalmente associado a um valor que o utilizadordeverá pagar mensalmente e quelhe permite aceder ao serviço enquanto não esgotar o seu crédito.Após esgotar o crédito, o cliente écobrado do tráfego realizado paraalém do limite contra factura a emitirpelo operador.

Para a rede móvel, o operador disponibiliza os seguintes serviços dedados (a serem controlados diferenciadamente):

1. Acesso Internet (com diferenciação de URL);

2. Acesso ao portal Web do operador;

3. MMS;

4. Video-Streaming;

5. Download de jogos;

6. Download de imagens;

7. Download de vídeos;

8. Download de toques e músi-cas;

9. Ring Back Tones;

10. Operações bancárias;

11. Serviços de localização.

Para o controlo dos acessos à suarede móvel, é possível aplicar o controlo de sessões por volume e/ou portempo de ligações a um dado serviçoe aplicar o controlo por consumo deeventos para o acesso a um determinado conteúdo.

Para o acesso via wap ou banda larga para ligações à internet, para fazer streaming de vídeo ou acederao portal do operador, é utilizado ocontrolo de sessões por volume e/ou tempo. Neste tipo de controlo éatribuída, ao cliente, uma determinada quota em bytes e/ou segundosmediante o saldo disponível, a qualpermite ao cliente aceder ao serviçoenquanto a quota não esgotar.

Após o consumo da quota atribuída, os elementos da rede respon-sáveis pelo controlo da sessão pedem mais quota para que o clientepossa continuar a sua sessão e,caso exista saldo suficiente, paraatribuir nova quota; esta é indicadaà rede que permite, assim, a continuação da navegação. Se em algum caso o saldo disponível paraeste serviço for consumido na suatotalidade, então é indicado à redeque esta sessão deverá ser terminada. O operador cobra também diferenciadamente por tecnologia deacesso (por exemplo: GPRS, UM-TS, HSDPA, Wi-Fi) e por nível de

Figura 1 - Solução de dados com controlo PT Inovação

PortalOperador

Internet

ipRaft

Plataforma de taxação

NGIN

Localização OperaçãoBanca

VídeoStreaming

OperatorNETWORK

DownloadJogos

DownloadImagens

DownloadToques

57 Exemplo Comercial de uma Solução deControlo de Serviços de Dados

qualidade de serviço disponibilizadapela rede.

Por fim, os restantes serviços, quese baseiam no consumo de um nú-mero de conteúdos de determinadotipo, são controlados por evento. Pa-ra este tipo de controlo, é feita umaconsulta inicial para verificar se ocliente cumpre todos os requisitospara poder aceder ao conteúdo (entre estes encontra-se naturalmentea verificação se o saldo disponívelé suficiente para comprar o conteú-do desejado). Após a verificação, po-de ser indicado ao cliente o preçoque irá custar o conteúdo ao qualpretende aceder. Caso o cliente pretenda prosseguir e adquirir o con-teúdo é então reservado o saldo correspondente. Depois de efectivadaa aquisição do mesmo é então subtraído ao saldo do cliente. Neste tipode controlo estão incluídos os con-teúdos disponíveis através das redes de dados, que neste casoserão: envio de MMS; download dejogos, imagens, vídeos e toques,acesso a noticias e informação útil

(farmácias, restaurantes, etc.), loca-lização de um grupo autorizado deamigos e realização de operaçõesbancárias.

O operador disponibiliza ainda osserviços de dados para os seus clientes quer estejam eles na sua redelocal ou em roaming numa rede visi-tada. Os acessos efectuados a partirde outra rede são cobrados de for-ma diferente através da identificaçãoda rede onde o cliente se encontra.

4. Importância para os negóciosdo grupo PTComo exemplificado, foi possível àPT inovação criar uma solução paracontrolo de serviços de dados, integrada com os modelos de negóciojá existentes nos operadores de tele-comunicações, e que correspondeàs solicitações dos mercados fixo emóvel.

Esta solução permite efectuar o controlo e taxação online (i.e., em temporeal) de acessos a serviços de dadose diversos conteúdos, permitindo

assim aos operadores disponibilizarem, controlarem e cobrarem servi-ços tais como acesso à internet embanda larga, download de jogos outoques, streaming de vídeo. É possível também processar em offline(pós-processamento de registos doselementos de rede) outros serviçospara os quais não existam interfacede taxação online.

Com o advento e massificação desoluções de internet de banda largapré-pagas ou com controlo de custos, o crescimento das solicitaçõestêm tido um crescimento exponencial e cada vez mais a quota dosserviços de dados é superior, tendouma maior influência nas receitasdos operadores.

Mesmo clientes pós-pagos, até a-gora tratados apenas em offline,começam cada vez mais a seremtratados em tempo real, pelo graude interactividade permitida. Por ou-tro lado, as regras de negócio sãocada vez mais flexíveis e permitemcada vez mais ofertas comerciais

Figura 2 - Arquitectura lógica actual da lógica para serviços de dados é composta por 4 layers:> Signaling Control Logic que trata das especificidades dos elementos de rede;> Business Control Logic que contem as regras particulares de um operador;> Building Blocks que disponibiliza funcionalidades especificas de PS e uma abstracção das necessárias à BCL;> Suite Genérica que disponibiliza funcionalidades requeridas habitualmente na construção de serviços inteligentes.

Balance

Alarms

Status Notifications

SPAC

SuiteGenérica

BuildingBlocks

BCL

SCL

SubServices

PS CORE

Quota Management Event Based

CAP3 FlexiISN MSSP CSG MMSC DiNO

...

...

...

...


arrojadas, permitindo a sua colocação rápida em produção. Outrorademorariam demasiado tempo a serem colocadas no mercado. O agregado de solicitações por segundodas soluções para o controlo de ser-viços de dados instaladas nos váriosoperadores atinge já os 500 eventos.

A solução aqui exemplificada temvindo a provar ser capaz de responder aos diversos clientes da PT Inovação e controla actualmente maisde 30 milhões de utilizadores em todoo mundo.

A solução desenvolvida na PT Inovação que dá suporte ao aqui exemplificado permite à empresa colocar--se numa posição favorável em rela-ção aos seus concorrentes directosno fornecimento de controlo e taxaçãode serviços de nova geração. Estasolução permite não só o aumentoda influência da PT Inovação nosoperadores para os quais controlavaanteriormente os serviços de voz;como também criar uma plataformapara a atracção de novos clientesdentro e fora do grupo.

Por fim, a solução foi desenvolvidapara que seja possível à PT Inovaçãoestar preparada para o aparecimentode novos requisitos associados anovas tecnologias, sejam elas relacionadas com novos serviços dedados ou relacionadas com redesconvergentes (p.ex: IMS).

6. ConclusõesA PT Inovação foi capaz de disponibilizar uma solução que respondeeficazmente às novas solicitaçõesresultantes das alterações do paradigma de negócio dos operadoresde telecomunicação, resultante doincremento da popularidade e deimportância dos acessos de dadose conteúdos associados.

A solução da PT Inovação tem demonstrado o seu potencial quer aonível da robustez, quer da sua fiabili-dade. Tem ainda mostrado que a

flexibilidade de configuração tem permitido a sua adaptação para instala-ção e operação em mercados comrequisitos bastante diferentes, comoo Europeu, o Africano e o Sul-Americano.

A prova de que estamos perante umasolução consolidada e com perspec-tivas de futuro torna-se clara diantedas contínuas solicitações dos clien-tes, com vista à incorporação de novostipos de serviços e modelos de ne-gócio a disponibilizar aos utilizadores.

Referências[1] www.3gpp.org[2] Ip-Raft Online/Offline Charging System -DataSheet[3] Miguel Santos, Paulo Pereira, ipRaft: Soluçãopara um Mercado em Expansão, Revista Saber& Fazer Telecomunicações 2007.

Miguel Santos, licenciado em Engenharia Electrotécnica e Computadores pela Faculdade deEngenharia da Universidade do Porto (especialização em Telecomunicações e Computadores)em 1998, concluiu o mestrado em EngenhariaElectrotécnica e Computadores na Universidadeda Florida em 2001. Desde 2002 trabalha na PTInovação integrado na equipa de desenvolvimentoda solução de redes inteligentes. Desempenhaactualmente as funções de gestor da divisão deredes e protocolos de dados onde se inclui ossistemas ipRaft (interface com as redes tele-comunicações para o controlo de serviços dedados), WAP gateway (adaptação de pedidosWap dentro da rede do operador) e RADIUS AAA(autenticação e autorização do acesso de clientesà rede de dados). É o representante da PTInovação no 3GPP TSG SA WG2 - Architecture.

Rui Quaresma, licenciou-se em Engenharia deElectrónica e Telecomunicações na Universidadede Aveiro, em 2000. Ingressou nesse mesmo anona PT Inovação, no departamento de Serviços deRedes Inteligentes, tendo-se focado nas redesinteligentes de nova geração. Em 2001 participouna arquitectura e desenvolvimento do NGIN Pack,a primeira plataforma de controlo real de serviçosde dados da PT Inovação. Desde então foi responsável pelo desenho e desenvolvimento delógicas de controlo de serviços de dados. Actualmente desenvolve tarefas de especificação eevolução de produtos do departamento de Desenvolvimento de Plataformas e Produtos.

através de elementos sensoriais, introduzir sistemas para inferir infor-mação de contexto do utilizador, eusar os mecanismos de controlo depublicação, subscrição e notificaçãodos sistemas de presença. Este artigo procura responder a algumas destas questões apresentando a visão ealguns resultados preliminares do projecto UPCASE.

Estamos no início de uma nova eraa evoluir para a ubiquidade da com-putação e para ambientes inteli-gentes (AmI) preenchidos por redessensoriais. As infra-estruturas depresença constituirão num futuro pró-ximo a base para um ecossistema deserviços conscientes do contexto, capazes de proporcionar experiênciasricas e completas aos seus utilizadores. Para satisfazer estas visões épreciso introduzir mecanismos derecolha automática de contexto

palavras-chave:Contexto, Sensores, Presença,Context-awareness, Inferência

Diogo R. Ferreira(IST)

João M. P. Cardoso(FEUP)

Paulo Chainho

UPCASE (User ProgrammableContext-Aware Services)

59

05


1. IntroduçãoA identificação de contextos relacionados com a situação de uma pessoa, ou o ambiente de um dispositivo móvel (e.g., telemóvel, PDA),ganha uma importância acrescidanas aplicações conscientes do contexto (vulgarmente designado porcontext-aware computing) [1][4]. Ouso da informação de contexto doutilizador para adaptar dinamica eautomaticamente uma série de ser-viços, tais como o toque das chamadas telefónicas, os anúncios depublicidade num serviço de IPTV, oua oferta de serviços no ambienteonde o utilizador se encontra, sãoalguns exemplos de potenciais novos casos de negócio.

O projecto UPCASE1 (User-Pro-grammable Context-Aware Servi-ces) pretende investigar e desenvol-ver métodos de recolha e inferênciade contextos. Estes métodos terãopor base um conjunto de sensoresligados ao dispositivo móvel, a partir

do qual é possível a inferência de con-textos através de técnicas de aprendizagem. Os métodos investigadosdarão origem a um sistema protótipo.

Este artigo encontra-se estruturadoda seguinte forma: na secção se-guinte é feito um enquadramento ge-ral sobre o mercado, requisitos e trabalhos anteriores relacionados coma identificação de contextos e a pró-pria utilização desses contextos. Nasecção 3 são apresentados os dispositivos usados no projecto, incluindo sensores e dispositivos paracomunicação com o telemóvel. Nasecção 4 é descrita a solução técnica preliminar para o sistema e nasecção 5 é explicada a importânciaque os objectivos do projecto têmpara o negócio do Grupo PortugalTelecom. Por último, a secção 6 te-ce algumas conclusões.

2. EnquadramentoAs funcionalidades de Presença po-pularizadas pelos serviços de Men

sagem Instantânea2 como o SAPOMessenger são actualmente usadas para definir a disponibilidade doutilizador para comunicar. Mais recentemente, novos serviços comoo Twitter3 na Internet ou o Yammer4

e o Present.ly5 no universo empresarial, juntaram as funcionalidadesde Presença com as funcionalida-des de Redes Sociais — PresençaSocial — permitindo aos seus utilizadores difundir todas as suas acti-vidades (broadcast people life), aumentando a sensação de ligação eproximidade.

A informação gerada por estes ser-viços pode ser usada para carac-terizar o Contexto do Utilizador e oaumento exponencial dessa informação é um indicador claro de como o mercado está receptivo a ser-viços conscientes do contexto. Noentanto, ainda existem algumas fragilidades nestes serviços que os impedem de se tornarem comercialmente mais interessantes. Dessas

1 Projecto do Plano de Inovação 2008-2009 do Grupo Portugal Telecom.2 Mais de 1 000 milhões de utilizadores em todo o mundo (http://www.cynapse.com/solutions/enterprise_instant_messaging/worldwide_enterprise.aspx).3 http://twitter.com/4 http://www.yammer.com/5 http://www.presentlyapp.com/

fragilidades destacam-se a neces-sidade de o utilizador ter que indicarmanualmente o seu contexto (e.g.,escrevendo no telemóvel) e a faltade segurança e controlo de privaci-dade associada a esses serviços.

O projecto UPCASE ambiciona resolver parte deste problema desenvolvendo um protótipo capaz degerar dinamicamente informação decontexto a partir de telemóveis, deuma forma segura e controlada peloutilizador. A informação de contextoinferida no telemóvel será publicadausando as infra-estruturas de Presença introduzidas em [2], estandosujeita a regras de autorização dedistribuição seguras. Deste modoresolve-se o problema do controlode privacidade.

O projecto UPCASE usa como re-ferência a visão de Ambiente Inte-ligente – AmI6 . Segundo esta visão,os utilizadores e os objectos estarãorodeados por redes sensoriais querecolhem informação usada paraadaptar os serviços às necessida-des específicas e espontâneas decada utilizador.

As primeiras abordagens nos sistemas de identificação de contextonos dispositivos móveis foram orientadas para a localização (e.g., “emcasa”, “no corredor”, “no escritório”,“no centro comercial”). Contudo, recentemente, têm sido apresentadostrabalhos que focam contextos maisabrangentes, como actividades doutilizador (e.g., “a andar”, “a correr”,“parado”, “sentado”), característicasdo ambiente (e.g., “frio”, “calor”), estado do utilizador (e.g., “contente”,“triste”, “nervoso”), etc. Esses contextos são identificados a partir deconjuntos de sensores integradosno dispositivo móvel, transportadospelo utilizador (em utensílios pessoais ou na própria roupa), ou disponíveis no ambiente. O dispositivo

móvel recolhe os dados captadospelos sensores e identifica a partirdesses dados um determinado contexto. Esta identificação é o cernedo problema e têm existido inúme-ros trabalhos (ver, e.g, [5] ou a des-crição de alguns desses trabalhosem [3]) que propõem técnicas parainferência/identificação de contextos, normalmente validadas com umnúmero restrito de contextos.

O outro grande desafio está relacionado com a usabilidade. O processodeve ser o menos intrusivo possível,garantindo ao mesmo tempo umafiabilidade aceitável da informaçãode contexto produzida. Por outro la-do, deve evitar-se a necessidade deter um novo objecto pessoal, procu-rando reutilizar objectos pessoais comas funcionalidades adicionais neces-sárias, e.g., relógio, sapatos, colar/pulseira, óculos, etc. Adicionalmentedeve ser possível utilizar infra-estru-turas públicas/não pessoais, e.g.,detectores de movimento, fumo, ehumidade, disponíveis no ambiente.

3. DispositivosOs sensores são os elementos cha-ve para a aquisição de informaçãoutilizada na inferência de um determinado contexto. Existe uma gamavariadíssima de sensores, estandoa utilização de um determinado conjunto de sensores dependente doscontextos que se pretendem inferir.Sensores como os de tacto, de ace-leração, de vibração, de sinais bio-lógicos (EMG e ECG, por exemplo),de movimento, de luz, de som, detemperatura, de humidade, de posi-ção (e.g., GPS), de gases, da veloci-dade do vento, da pressão atmosférica, do nível de carregamento dabateria do dispositivo móvel, da intensidade da rede, da hora actual,etc., podem fornecer inúmeros contextos. Na primeira abordagem doprojecto UPCASE estão a ser testados contextos baseados em 4 sen

UPCASE (User ProgrammableContext-Aware Services)

61

sores, nomeadamente um sensor detemperatura, um sensor de luz, umsensor de som, e um acelerómetro.

No projecto UPCASE a informaçãocaptada do ambiente por sensoresnecessita de ser transmitida para odispositivo móvel para que estepossa fazer o tratamento e processamento dessa informação, tendocomo objectivo final a inferência docontexto a partir de um conjunto decontextos pré-definidos. Tambémexistem sensores integrados no pró-prio dispositivo, como são os casosdos acelerómetros existentes em alguns dispositivos móveis de últimageração (e.g., iPhone, Nokia N95,Sony Ericsson K850 e W910), dosmicrofones existentes em todos ostelemóveis e na maioria dos PDA,dos receptores de GPS integradosem muitos dos dispositivos móveis,e dos dispositivos que permitem obter informação sobre o estado dosmartphone ou do PDA, como a intensidade do sinal de rede ou o nívelde carregamento da bateria. Estessensores também podem ser utilizados para inferir contextos. Note--se, contudo, que a existência desensores no próprio dispositivo po-de não suprir a necessidade daexistência de outros sensores domesmo tipo. Por exemplo, aceleró-metros complementares podem terde estar localizados no calçado ounos braços para permitirem a infe-rência de determinados movimentosrelacionados com actividades como“correr”, “gesticular”, etc..

No projecto UPCASE preconizou-seque os sensores externos ao dispo-sitivo móvel fossem ligados a um dispositivo de aquisição de sinais desensores com interface Bluetooth®.Para tal foi seleccionado o BlueSentryTM 7. As razões mais importantespara esta escolha residiram nasseguintes propriedades: dimensõesreduzidas (adequado por isso para

6 http://en.wikipedia.org/wiki/Ambient_intelligence7 http://www.rovingnetworks.com


contextos de mobilidade), facilidadede controlo por envio de comandosvia Bluetooth, capacidade de ser co-locado em modo “sleep”, possibili-dade de conectar vários sensores,etc.. Note-se, contudo, que paraum produto comercial poderá fazersentido desenvolver um dispositivoespecífico para aquisição de sinaisde sensores. A Figura 1 apresentauma imagem com o protótipo actualmente utilizado nos testes.

4. Descrição técnicaOs sistemas de tratamento de dados e inferência de contexto estãoa ser desenvolvidos em J2ME soba forma de MIDlets. Essas MIDletssão executadas num smartphone.A Figura 2 ilustra a arquitectura dosistema. A aplicação no dispositivomóvel é constituída por três componentes principais: aquisição de dados, pré-processamento, e inferênciade contextos. A fase de pré-proces-samento é responsável por extrair ca-racterísticas (features) dos dados lidos em cada sensor. A fase deinferência de contextos é responsável pela identificação do contextotendo por base as característicasextraídas na fase anterior. A infe-

rência de contextos é um processode aprendizagem que resulta numconjunto de regras. Estas regraspermitem determinar o contexto doutilizador a partir de um conjunto deleituras dos sensores. Desta formaconsegue-se traduzir informação debaixo nível (i.e., características processadas com os dados de cada sensor)em contextos de alto-nível (i.e., queenvolvem informação induzida apartir das características extraídasdos múltiplos sensores).

Para aquisição de dados capturados pelos sensores integrados nosdispositivos móveis é utilizado oJSR-256 Mobile Sensor API8. Contudo, este API não é disponibilizadopela maioria dos smartphones, capazes de executar aplicações Java,e os dispositivos que incluem tecnologia Bluetooth de ligação a sensores investigados numa fase preliminar do projecto não são com-patíveis com a especificação JSR-256. Por esse motivo, para a comu-nicação com o BlueSentry, o dispo-sitivo de aquisição de dados dossensores, é utilizado o JSR-82 Bluetooth API9.

A fase de pré-processamento utilizaum conjunto de configurações quepermitem categorizar os dados obti-dos pelos sensores. Em muitos doscasos a categorização dos dadosobtidos pelos sensores é concre-tizada utilizando médias e variânciascalculadas, tendo por base um conjunto de leituras sucessivas. Poderátambém ser necessário aplicar filtrosou outras transformações para minimizar perturbações na leitura de sensores e para reduzir os erros de cate-gorização no processo de extracçãode características. O pré-processamento de dados lidos pelo aceleró-metro utiliza a FFT (Fast FourierTransform) e a variância por formaa determinar, com base em compa-rações de algumas característicasdos sinais no domínio da frequênciae de valores de variância com valo-res limiares, a actividade do utilizador, nomeadamente: “em movimento”, “parado”, etc..

No processo de inferência de contexto são utilizadas árvores de decisão(decision trees) [6]. Estas estruturassão adequadas à indução de regrase são mais rápidas de construir e processar do que outras técnicas de

8 http://jcp.org/en/jsr/detail?id=2569 http://jcp.org/en/jsr/detail?id=82

Figura 1 - Imagem com os dispositivos utilizados actualmente noprojecto: o smartphone (Sony Ericsson W910 que inclui umacelerómetro), caixa de pilhas (caixa preta do lado direito dosmartphone), os sensores (de temperatura e de som localizadosno topo à direita e de luz localizado no fundo à direita), e o dispositivoBlueSentry (localizado no centro da imagem), com tecnologiaBluetooth, usado para a aquisição dos sinais oriundos dos sensores

Figura 2 - Arquitectura do sistema protótipo

Context Server(e.g., High-Level Context

Identification Engine)

Context

Publisher

Pre-definedSensors(XML)

Context Rulesand Associated

ActivitiesContext Recognition/Identification/Inference Engine (CIE)

Pre-Processing Engine (Features’ Extraction) (PPE)

Sensors Data Acquisition

JSR 256 MobileSensor API

JSR 82Bluetooth API MIDP

Java Virtual Machine (J2ME)

Operating System (e.g., Symbian)

Mobile Device (e.g., Smartphone, PDA)

ContextExamples

CM

CM

CM

CM

63 UPCASE (User ProgrammableContext-Aware Services)

indução lógica [7], o que as tornamais apropriadas para implemen-tação em dispositivos com capaci-dade de processamento limitada.

A inferência tem por base um conjunto de exemplos registados a partirdas acções do utilizador. Numaprimeira fase de aprendizagem é outilizador que define manualmente oseu contexto, o que resulta num conjunto de exemplos que podem serusados para construir uma árvore dedecisão. Esta árvore de decisão, quepode ser usada como um conjuntode regras servirá de base à identifi-cação automática do contexto durante a fase de operação. Nesta fa-se, o utilizador deixa de especificarmanualmente o seu contexto, sendo este determinado automaticamente para cada leitura dos senso-res. Em caso de erro na inferênciado contexto, a árvore é recalculadaapós a correcção do utilizador. Desta forma a árvore de decisão aproxi-ma-se sucessivamente dos hábitosdo utilizador e a inferência de contexto torna-se cada vez mais precisa.

O resultado da indução da árvorede decisão permite obter as regrasque definem cada contexto e quepodem estar associadas a diferen-tes actividades do utilizador.

Na fase actual do projecto encontram-se em estudo técnicas quepermitam identificar múltiplas activi-dades utilizando o acelerómetro.Essas actividades incluem: “a andar”, “a correr”, “a subir escadas”,“a descer escadas”, “a conduzir”,“a andar de bicicleta”, etc.. A iden-tificação destas actividades associada a características determinadas pelos sensores presentes noprotótipo (Figura 1) permitirá a infe-rência de contextos com maior utili-dade prática (i.e., “a descansar”).

A inferência local de contextos podeser complementada por um processo de inferência de contextos locali-zado no servidor. Esse processopoderá ser responsável por contextos

que recorram a informação externa enão acessível no dispositivo móvel.Essa informação pode incluir histó-rico de contextos ou de dados armazenados que permitam definir um determinado perfil e com os quais sepode prever uma determinada situa-ção ou actividade futura. Pode também incluir acesso a outras fontes,tais como: mapas, serviços, calenda-rização de actividades, etc.

5. Importância para os negóciosdo grupo PTA informação de contexto tem apli-cações praticamente ilimitadas. Omaior desafio passa por identificaraquelas que têm maior potencial denegócio para justificar os investimentos necessários. De uma forma geral,a grande linha orientadora centra-seem conhecer melhor o cliente e satisfazer melhor as suas necessidades.Neste âmbito distinguimos dois tiposde aplicações: a monitorização de contextos, e as aplicações conscientesdo contexto. Estas aplicações são des-critas de forma sucinta em seguida.

5.1. Monitorização de contextosNeste tipo de aplicações, a informa-ção de contexto é notificada directamente aos utilizadores que a subs-creveram. Uma aplicação imediata éo enriquecimento da informação dePresença de serviços de Messaging,como o SAPO Messenger, ou servi-ços de Unified Communication, coma informação de contexto inferida. Ou-tro tipo de aplicação está relacionado com serviços de assistência como:

> Assistência de Saúde – Dadosclínicos são notificados a Médicos;

> Assistência Infantil – Informaçãosobre actividades das criançassão notificadas aos pais;

> Assistência Sénior - Informaçãosobre actividades de pessoas seniores são notificadas a utilizado-res próximos familiarmente (e.g.,filhos), mas distantes geografica-mente.

5.2. Adaptação Dinâmica:Aplicações Conscientes do ContextoEste será, porventura, o tipo de apli-cação com maior potencial de negó-cio, mas simultaneamente apresentamaiores desafios tanto técnicos, como comerciais. Identificam-se de se-guida alguns exemplos de aplica-ções conscientes do contexto:

> Comunicação Consciente doContexto, i.e., o toque de chamarou o encaminhamento das chamadas (i.e., secretária, voicemail) éefectuado de acordo com o contexto do utilizador;

> Publicidade Consciente doContexto, por exemplo, a publicidade do serviço MEO é perso-nalizada e dependente do Contexto do Utilizador;

> Centros de Contacto Cons-cientes do Contexto, por exemplo, o cliente recebe recomen-dações de novos serviços, viaAgente ou directamente, de acordo com o seu contexto.

Para além destas aplicações, a in-formação de contexto pode ser usa-da para construir um histórico, sobreo qual se podem aplicar motores deaprendizagem para construir umPerfil de Utilizador. Desta forma, épossível adaptar a oferta de servi-ços de acordo com o Perfil do Utili-zador, aumentando o ARPU (Avera-ge Revenue Per User) e diminuindoo Churn por cliente.

Na Figura 3 é apresentado o esboçoduma possível solução para a intro-dução de uma plataforma de Ser-viços de Contexto na rede, reutilizando a infra-estrutura de serviços dePresença.

6. ConclusõesO projecto UPCASE visa a inferên-cia automática de contextos rela-cionados com o utilizador, de formaa possibilitar a criação de serviçosconscientes do contexto.


O levantamento efectuado no início doprojecto sobre trabalhos existentes naárea dos serviços conscientes do contexto confirma as expectativas sobreo potencial do projecto e sobre a suaimportância no futuro mercado dastelecomunicações. É possível desdejá antecipar quais os maiores obstá-culos a ultrapassar para uma aplica-ção comercial dos resultados do UPCASE. O maior obstáculo reside nosdispositivos utilizados, possível decontornar com a utilização de artefactos não intrusivos (embebidos emobjectos já usados como o telemó-vel, telefone, roupa) ou suficientemente desejáveis pelo utilizador (potenciais objectos de moda e de arte).

O outro grande desafio reside naconcepção e implementação em sis-temas embebidos de algoritmospara inferir alguns contextos comelevados graus de fiabilidade. Nesteâmbito, um exemplo de um desafioaliciante a nível da inferência de contextos é a inferência de estadosemocionais como “irritado”, “alegre”,etc., com base, i.e., em dados reco-lhidos do batimento cardíaco, a temperatura do corpo e a detecção de

alguns padrões sonoros.

Por fim, temos do lado da rede odesafio final do uso da informaçãode contexto mantendo, ou mesmoaumentando, o grau de confiançaque o cliente deposita na PortugalTelecom.

Referências[1] J. Coutaz , J. L. Crowley, S. Dobson, andD.Garlan, “Context is key,” Communications of theACM, vol. 48, no. 3 (Mar. 2005), pp. 49-53.[2] P. Chainho, et al., Presença: Aplicações Conscientes do Contexto, Revista Saber e FazerTelecomunicações Nº5, 2007.[3] J. M. P. Cardoso, D. Ferreira, Arquitectura eCasos de Estudo para o Projecto UPCASE,Relatório Técnico, IST/UTL, Julho 2008.[4] A. K. Dey, “Understanding and Using Context,”in Personal and Ubiquitous Computing Journal,5(1), 2001, pp. 4-7.[5] D. P. Siewiorek, et al., “SenSay: A Context-Aware Mobile Phone,” In. Proc. 7th Int'l Symposiumon Wearable Computers (ISWC), White Plains, NY,USA, 2003.[6] J. R. Quinlan, “Induction of Decision Trees”,Machine Learning, (1), pp. 81-106, 1986.[7] M. M. Oprea, “Rule Generation Versus DecisionTree Induction”, Proc. of 20th Int'l ConferenceApplied Informatics (AI’02), Innsbruck, Austria,2002.

Paulo Chainho, Mestrado em Telecomunicaçõespelo IST da Universidade Técnica de Lisboa.Gestor de Projectos, Actualmente responsávelpelo Desenvolvimento de Plataformas de Presença e Serviços Colaborativos no departamentoDPP4 (Desenvolvimento de Novas Plataformas eProdutos). Entusiasta do "Open Source". Grandeexperiência em projectos Internacionais deInvestigação e Desenvolvimento incluindo Eurescom, ETSIN SPAN e EU IST. Consultoria naintrodução de plataformas de serviços RPG eIMS no Grupo PT.

João M. P. Cardoso é actualmente ProfessorAssociado no Departamento de Engenharia Informática da Faculdade de Engenharia da Universidade do Porto (FEUP) e investigador no INESC-ID. Anteriormente foi Prof. Auxiliar no Departamento de Engenharia Informática do Instituto Superior Técnico (IST), Universidade Técnica deLisboa (UTL) e na Universidade do Algarve. Durante um período de um ano (2001/2002) traba-lhou na empresa PACT XPP Technologies, Inc.,uma startup localizada em Munique, Alemanha.Tem sido membro do comité científico e membroda organização de diversas conferências internacionais. É co-autor de algumas patentes, co-autorde um livro editado pela Springer, co-editor dedois volumes LNCS da Springer, e autor de cercade setenta publicações científicas. Os seus interesses científicos incluem Compiladores, Arquitecturas Computacionais Específicas, e SistemasEmbebidos.

Diogo R. Ferreira é professor auxiliar de sistemasde informação no Instituto Superior Técnico nocampus do Taguspark. É especialista na área deBusiness Process Management e autor de umtrabalho premiado sobre a aplicação de técnicasde inferência à descoberta de processos denegócio. Realizou o seu doutoramento na Universidade do Porto. Desenvolve investigação na áreade process mining e é responsável pelas disciplinas de Bases de Dados e Sistemas EmpresariaisIntegrados.

Figura 3 – Plataforma de Serviços de Contextobaseada numa Infra-estrutura de Serviços dePresença

ContextReasoning

ContentReasoning

Rules(XMD)

PresenceSystem

ApplicationWatcher

GetReasoning

Rules

Publish HighLevel Context

Notify LowLevel Context

Notify HighLevel Context

Publish LowLevel Context

Private/PublicSensor

Network

PersonalSensor

Network

Estatísticas conservadoras indicamque cerca de 85% do e-mail total quecircula no mundo é composto porconteúdos sem origem real e não solicitados [1]. Estes e-mails tentamvender ou publicitar produtos, enganar o destinatário a enviar dadosconfidenciais ou instalar programasindesejados. Representam custosde muitos milhões de euros mundialmente em horas de trabalho desper-diçado, custos com hardware e software adicional e necessidade deassistência especializada.

palavras-chave:e-mail, spam, open-source,

filtro de conteúdos

Paulo Roncon

Este artigo apresenta a solução quea PT Inovação implementou parafiltrar conteúdos indesejados no e--mail, com o uso de soluções open-source. É feita uma abordagem ge-nérica ao conceito de SPAM — de-finição, tipos e problemas — depoissão descritos alguns métodos e técnicas usadas na sua filtragem. Étambém retratado como foi implementada a filtragem de conteúdosde e-mail na PT Inovação e as váriasetapas que levaram ao sistema como hoje existe.

06

Filtragem de Conteúdos deE-mail Open-source

65



1. Introdução1.1. Filtragem de conteúdos de e--mailCom a massificação do uso da Internet, e das suas facilidades de co-municação associadas, assistiu-seà adopção generalizada do e-mailcomo um dos principais meios decomunicação assíncrona. O e-mailé um método de escrever, enviar,receber e guardar mensagens porum meio de comunicações electró-nico, baseada no protocolo SMTP(Simple Mail Transfer Protocol). Aevolução do uso do e-mail foi acompanhada pela proliferação de con-teúdos de e-mail não desejados enão solicitados, normalmente enviados em massa e sem origem real –SPAM [2].

Este problema obrigou a concep-tualização de sistemas que conseguissem decidir se um determinado e-mail era legítimo e devia serentregue ao destinatário, ou se eraapenas SPAM.

2. Conceitos2.1. O que é o SPAME-mail SPAM, também conhecido

como e-mail em massa não solicitado – unsolicited bulk email (UBE) oue-mail comercial não solicitado – unsolicited commercial email (UCE), éa prática de enviar mensagens dee-mail não solicitadas, frequentemente com intuito comercial, em largas quantidades, para um conjuntoindiscriminado de e-mails destino.

O SPAM no correio electrónico co-meçou a ser um problema quandoa Internet se abriu para o público ameio da década de 90. Tem vindoa crescer exponencialmente e hojeperfaz entre 80 a 85% do e-mail total que circula pelo mundo – numaestimativa conservadora.

Pressões para tornar o SPAM ilegaltêm tido sucesso em alguns países,mas nem em todos. Os spammers– quem envia o SPAM – aproveitameste facto para utilizar recursos depaíses onde o SPAM não é ilegal como base para as suas operações,evitando assim problemas.

Cada vez mais o SPAM é enviadoatravés de redes zombie - redes dePC infectados com vírus ou malware

- a partir de qualquer ponto do mundo. Está-se a tornar claro que os autores de vários tipos de ameaças –vírus, phishing, malware – estão atrabalhar em conjunto, tornando todoo processo bastante elaborado e so-fisticado.

O e-mail é um meio de comunicaçãoextremamente barato e os spammers profissionais têm em grandeparte processos automatizados. Assim, o negócio de enviar SPAM po-de-se tornar bastante lucrativo:mesmo cobrando valores ridiculamente baixos por cada e-mail comSPAM enviado, tal é a quantidadede e-mails que conseguem enviarpor hora que o somatório atinge valores bastante grandes.

2.2. Tipos de SPAMMalware (vírus, worms, cavalos deTróia, etc.): este tipo apresenta-sesob disfarce e induz o destinatárioa executar um programa maliciosoanexado à mensagem recebida;

Phishing: São mensagens que assu-mem o disfarce de SPAM comercialou cujos títulos simulam mensagens

comuns, como comunicados transmitidos dentro de uma organizaçãoou mensagens pessoais oriundasde pessoas conhecidas. Tal disfarcetem como objectivo iludir o destina-tário, solicitando-lhe que envie dados confidenciais (preenchendo umformulário, por exemplo) para algumendereço electrónico ou que se re-giste numa página da Internet, quena verdade é uma cópia de outrapágina;

Hoaxes: O termo hoax — boato —está associado a histórias falsas,escritas com o intuito de alarmar ouiludir aqueles que a lêem e instigar asua divulgação o mais rapidamentee para o maior número de pessoaspossível. Geralmente tratam de pessoas que necessitam com urgênciade algum tipo de ajuda, alertas a al-gum tipo de ameaça ou perigo, difa-mação de marcas e empresas ouofertas falsas de produtos gratuitos.Aquelas que relatam histórias cujospersonagens, época ou localizaçãosão desconhecidos são conhecidascomo "lendas urbanas";

Chain letters: Mensagens destacategoria prometem sorte, riquezaou algum outro tipo de benefício à-queles que a reenviem para um nú-mero mínimo de pessoas, num tempo pré-determinado; garantindo poroutro lado que aqueles que inter-romperem a corrente, deixando dedivulgar a mensagem, sofrerão mui-tos infortúnios. Com esse mecanis-mo, elas têm a capacidade de atingirum número exponencial de pessoasnum curto período de tempo;

Scams: Trata-se de oportunidadesenganosas e ofertas de produtosque prometem falsos resultados.Entre as ofertas mais comuns estãoas oportunidades miraculosas denegócios ou emprego, propostaspara trabalhar em casa e empréstimos facilitados. Um dos golpesmais conhecidos da Internet é amensagem cujo remetente alegaser um nigeriano que, devido a ra-zões políticas ou pessoais, está dis

posto a transferir uma grande quantidade de dinheiro ao destinatário,desde que este pague uma certataxa como garantia;

Propaganda: Divulgam desde pro-dutos e serviços até propagandapolítica. Este tipo de SPAM é dosmais comuns e mais antigos já re-gistados. Embora existam mensa-gens comerciais legítimas, enviadaspor empresas licenciadas e conhecidas, nota-se que não é raro que oproduto ou serviço oferecido pelamensagem tenha alguma caracte-rística ilegal e o spammer, e a empresa, sejam desconhecidos do pú-blico ou completamente anónimos.Entre outros, um SPAM publicitáriocostuma apresentar medicamentossem prescrição, software pirata ouilegal, diplomas universitários, oportunidades de enriquecimento rápido,produtos eróticos e páginas porno-gráficas. Um dos exemplos mais co-nhecidos é o SPAM que oferece omedicamento Viagra a baixo custo.

2.3. Custos com o SPAMA União Europeia estimou em 2001que o SPAM custa mundialmentecerca de 10 biliões de Euros porano[3].

A legislatura da Califórnia descobriuque o SPAM custou às organiza-ções dos Estados Unidos mais de13 biliões de dólares em 2007 —incluindo perdas de produtividade eequipamento adicional, software erecursos necessários para combatereste problema.[4]

Os efeitos directos do SPAM inclu-em o consumo de recursos computacionais e de rede e consumo emtempo e atenção humanas para eli-minar as mensagens não desejadas.Outros efeitos incluem custos comroubo de identidade e de dados, ví-rus, fraudes e marketing enganoso.

2.4. Filtragem de SPAMAutenticação e repudiação: Umnúmero de sistemas tem sido proposto para aceitar a recepção de e-


67

-mails provenientes de servidoresque tenham sido autenticados dealguma forma como sendo legítimos. Muitos destes sistemas usamo DNS (Domain Name System) paralistar sites que estão autorizados aenviar e-mail e, em alguns casos,para determinar a reputação dessesdomínios. Estes sistemas não detectam se um e-mail específico é ounão SPAM. Utilizam a informaçãodo DNS para confiar ou não no ser-vidor de envio. Ex: domainkeys [5],sender policy Framework [6];

Pergunta – Resposta: Este mé-todo exige que servidores desco-nhecidos passem uma série de testes (desafios) antes de entregarema mensagem;

Filtragem baseada em Checksums: Este filtro explora o facto deque o SPAM é geralmente enviadoem grandes blocos e com pequenas variações nos conteúdos dasmensagens nestes blocos. Para cada e-mail é gerado um número úni-co — checksum e compara-se estecom uma base de dados que con-tém checksums de e-mails que sãoconsiderados SPAM. Se este checksum existe na base de dados, o e-mail provavelmente é SPAM. Ex:Vipul’s Razor [7].

DNS-based Blacklists: Ou DNSBLs são usados para filtrar e bloquear e-mails recorrendo a heurísticas. São publicadas em sites naInternet listas de endereços IP deonde normalmente provém SPAM.Estes sites reflectem algum tipo depolítica: listam sites que enviamSPAM, listam relays abertos ou pro-xies, listam ISP que suportam SPAM,etc..Outros sistemas baseados emDNS listam IP ou URL em gruposde Bom ou Mau;

HELO/EHLO checking: O SPAMpode ser bastante reduzido com umnúmero de testes bastante simples.Em alguns casos basta exigir umFQDN (Fully Qualified Domain Na-me) válido ao iniciar a comunicação


entre servidores de e-mail. Noutrosbasta exigir um cumprimento dasregras do protocolo, etc.

Greylisting: O SMTP permite bloquear temporariamente a recepçãode mensagens e o Greylisting utilizaesta possibilidade para bloqueartemporariamente mensagens de ser-vidores de e-mail desconhecidos.Esta funcionalidade tem um códigode erro associado que é enviadopara o servidor emissor para que eletente o reenvio do e-mail mais tarde.Este sistema opera na premissa queum spammer não tenta reenviar e--mails – isto implica que ele guardeos e-mails para os reenviar – poisiria aumentar os custos associadosao envio do SPAM. O spammer pre-fere descartar estes e-mails e tentaroutros alvos;

Greeting delay: Este método atrasadeliberadamente o início da ligaçãono protocolo SMTP antes de aceitaro envio de dados. Muitas aplicaçõespara envio em massa de e-mailsusadas pelos spammers não têmprevisto este atraso e tentam enviaro e-mail propriamente dito imediatamente depois do envio dos dadosde início de conexão. Como o servidor que está a tentar enviar não res-peita a pausa imposta pelo servidordestino, a conexão é cortada e o e--mail não entra;

Hybrid filtering: Algumas aplica-ções usam uma combinação de mé-todos e testes para tentar detectarSPAM. Cada teste tem associadoum número, que é conhecido comopeso. Cada mensagem que chegaé sujeita à totalidade dos testes. Emcada teste que acuse positivo, umcontador é incrementado pelo pesoassociado a esse teste. Se o valorfinal do contador atingir um valorpredefinido pelo administrador, estee-mail é considerado SPAM. Os falsos positivos – identificação de ume-mail legítimo como sendo SPAM– podem-se reduzir em grande par-te se existir a garantia de que ne-nhum teste tem o peso igual ao va-

lor limite para que a mensagem sejaconsiderada SPAM;

PTR/Reverse DNS checks: Umdos testes mais usados é verificarse existe uma relação válida entre oendereço origem do e-mail, o domí-nio referente a esse e-mail e os endereços IP respectivos. Este testepermite verificar se o domínio do e--mail é forjado;

Rule-based filtering: Baseia-se naespecificação de listas de palavrasou expressões regulares que nãosão permitidas. Assim, se um servidorreceber SPAM a anunciar “Viagra”, oadministrador pode colocar a palavra Viagra na lista de palavras nãopermitidas. De futuro e-mails comesta palavra são bloqueados.

Este método tem algumas desvantagens: exige muita manutenção enormalmente acusa muitos falsospositivos – a palavra “Viagra” podeprovir num e-mail com SPAM, ounum e-mail médico, portanto legítima. Outro problema é que os spammers alteram as palavras: Viagrapode ser V1agra, Via_gra, V i a g r a,etc.. Também podem inserir tagsHTML a meio de uma palavra, de for-ma que passe pelo filtro e seja vistacomo texto simples. Isto torna adetecção apenas por palavra-chaveineficaz;

Sender-supported whitelists andtags: Existe um pequeno númerode organizações que oferecem endereços IP “limpos” e/ou tags licenciados para serem inseridas no e--mail – por um preço. A existênciadestes tags serve para assegurar odestino de que este e-mail nãocontém SPAM. Um problema comeste método é que estas organi-zações ganham dinheiro com a venda de tags e não com o policiamento do processo; assim um spammerpode comprar tags e enviar SPAMsem obstrução;

SMTP callback verification: Comogrande parte do SPAM tem ende-

reços origem falsos pode-se tentarefectuar uma ligação inversa para odomínio do endereço que está a seranunciado. Se este endereço nãoexistir, o e-mail provavelmente éSPAM;

Statistical content filtering: Estemétodo de filtragem tenta prever seuma mensagem é SPAM ou não,baseando-se numa colecção localde e-mails legítimos e de SPAM. Esta colecção é alimentada pelos utili-zadores que vão marcando as mensagens como legítimas ou SPAM eo sistema vai aprendendo com oscritérios dos seus utilizadores. Assim, uma clínica poderá considerare-mails com a palavra Viagra legítimos, mas uma escola primária já ospoderá considerar SPAM. Exemplo:Bogofilter [8], DSPAM [9], SpamBayes [10];

Transparent SMTP proxy: Osproxies transparentes SMTP permitem a filtragem de SPAM em tempo real. Combinam várias técnicasde filtragem e tem feedback imediatopor parte dos utilizadores, evitandoassim a necessidade de armazenarem quarentena e-mails marcadoscomo SPAM.

3. Implementação3.1. Funcionamento geralO sistema de filtragem da PT Ino-vação funciona como um proxySMTP transparente. É compostopor 2 servidores que recebem todoo tráfego SMTP com o destino ptinovacao.pt (outbound). Depois deefectuados os devidos testes, os e--mails considerados legítimos sãoentregues ao servidor de e-mail quecontém as caixas de e-mail dos colaboradores da PT Inovação.

3.2. Detalhe do sistema de filtragemO sistema de filtragem em uso naPT Inovação baseia-se em componentes open-source, não existindograndes custos com licenças oucompra de software.

69 Filtragem de Conteúdos deE-mail Open-source

testes têm atribuído um sistema depontuação que vai sendo incrementado quando os testes acusamSPAM/vírus. Se este valor atingirum valor definido pelo administrador do sistema, o e-mail é conside-rado SPAM. O processamento damensagem é responsável por decidir o que fazer com as mensa-gens: Tem a possibilidade de enviar,apagar, guardar, alterar e reencaminhar para outro destino. Estas ac-ções dependem do valor de SPAMcalculado anteriormente e das pre-definições indicadas pelo administrador do sistema;

Controle e estatísticas: Têm comosuporte um servidor Web e umaBase de Dados. Existe a possibi-lidade de extrair estatísticas porvolume, tipo de mensagem, origemda mensagem, carga nos servido-res, tempo de processamento e intervalo temporal. Existe também apossibilidade de analisar, em temporeal, o processamento dos e-mails,saber quantos estão na pilha paraserem processados e quantos es-tão para ser entregues. A admi-nistração de alguns aspectos destesistema pode ser feita aqui.

Do software que está ser usado pelosistema destacam-se pela popula-ridade o Sendmail – MTA, o Apache– Servidor http, o MySQL – Base deDados, o SpamAssassin [11] – Alguns testes de SPAM e o ClamAV[12] – agente antivírus gratuito.

3.3. Evolução temporalA primeira implementação de umsistema de filtragem de SPAM foifeita em Janeiro de 2006 e apenasnum servidor. As mensagens depoisde filtradas eram TODAS entregues– não se bloqueava nenhuma mensagem. Caso um e-mail fosse considerado SPAM, ao Assunto dessee-mail era acrescentado: [SPAM?].De forma idêntica caso fosse encontrado vírus, a mensagem era assinalada com um tag: [Vírus?] noassunto.

Figura 1 – Sequência da entrega dos e-mails

Figura 2 – Principais blocos do sistema

Conceptualmente é composto pelosseguintes blocos: Hardware, Sistema Operativo, Filtragem e Controlee estatísticas.

Hardware: Tem como principais re-quisitos poder de processamento ememória RAM. Estão a ser usados2 servidores;

Sistema Operativo: Utiliza um SObaseado em RedHat Linux 5, pelasua estabilidade e flexibilidade deconfiguração;

Filtragem: Este bloco é o motor dosistema.

Contém um Mail Transport Agent(MTA), as várias ferramentas que fa-zem a análise dos conteúdos, os testes de vírus e o processamento con-sequente da mensagem.

O MTA é responsável por receberos e-mails que chegam da internet,colocá-los numa pilha para seremprocessados pelas ferramentas quefazem os testes; Os testes que sãofeitos são White Lists / Black Lists,DNS based blacklists, EHLO/HELOchecking, assunto, cabeçalho, URL,rule-based filtering, SMTP callbackverification, vírus, phishing e anexos(tipo tamanho e nome); Todos estes

UserClean Mails

CLEAN MAILS

Exchange

REJECTED MAIL

CLEAN MAILS

UserClean Mails

Controlo em temporal e administraçãoEstatísticasBase de dadosServidores WEB

Processamento de mensagemTestes de VírusTestes de SPAMMTA- Message Transport Agent

SO - Linux

1 Servidor HP 65 (Primário)1 Servidor HP 64 (Secundário)


Isto foi feito para se conseguir aferirda exactidão dos testes que eramfeitos através do feedback dos cola-boradores. Esta tag no assunto também permitiu a criação de regras nosclientes de e-mail dos colaboradorespara, por exemplo, apagar automaticamente os e-mails com esta tag.

Esta implementação esteve em funcionamento durante um ano. Esteintervalo de tempo permitiu afinaros vários métodos utilizados, me-lhorar regras e ganhar confiança nosistema. Findo este tempo de testes, já no terreno, foi instalado umsegundo servidor e as mensagensconsideradas SPAM passaram a serautomaticamente apagadas.

4. ResultadosCom a instalação deste sistema assistiu-se imediatamente a uma re-dução superior a 90% do SPAMque chegava às caixas de e-maildos colaboradores da empresa. Oservidor interno de e-mail, onde es-tão guardadas as caixas de e-mail,passou a estar protegido de grande

parte dos e-mails maléficos com ví-rus e malware. A rede interna daempresa ficou menos sobrecarregada – diariamente são bloqueadosem média 1,5G de e-mails pelo sis-tema. As caixas de e-mail armazenam menos “lixo”, portanto os cola-boradores utilizam menos recursose os backups são facilitados. O trá-fego entre os vários sites da PT Ino-vação teve um grande decréscimo,fruto da eliminação de conteúdosindesejados.

5. Importância para os negóciosdo grupo PTBaixo TCO (Total Cost of Operation)Menor custo de licenciamento e a-quisição de software relativamentea soluções fechadas; Manutençãomínima.

Menor necessidades de hardwarepara armazenamento e backups,menor necessidade de largura debanda interna e entre pólos.

Aumento de produtividade – Só noprimeiro mês deste ano foram elimi

Figura 3 – Detalhe da filtragem

Figura 4 – Resumo de 11 Agosto a 08 Setembro de 2008. Apenas 7% do e-mail é legítimo.

nadas 832717 mensagens comSPAM. Se um utilizador demorar emmédia 2 segundos a ler e apagaruma mensagem com SPAM teríamos:

2x832717 = 1665434 segundos

= 462,6 horas

= 57,8 dias (horário laboral de 8h)

= 3,38 Homensxmês.

Portanto, só no primeiro mês desteano, foram economizadas 462,6horas pela PT Inovação.

6. ConclusõesO problema do SPAM torna indispensável, a nível empresarial, o usode um sistema de filtragem. Existeminúmeras possibilidades: softwarelicenciado, gratuito, soluções completas com hardware e software integrado, etc. Umas terão certamen-te vantagens sobre outras, sendoque o importante é enquadrar a so-lução à realidade da empresa.

E-MAILS

MTA

WhitelistBlacklist RBL Testes

SPAM Vírus TestesAnexos

Processamentoe Decisão

E-MAILS

MTA

- -

71 Filtragem de Conteúdos deE-mail Open-source

Nenhuma solução existente consegue, no entanto, garantir 100%de eficácia. O SPAM, tal como ovírus, tem sofrido uma evoluçãocontínua na sofisticação. Novas formas de entrega são inventadas ecaso as regras do sistema de filtragem sejam demasiado restritas cor-re-se o risco de bloquear e-mailslegítimos.

Existem técnicas que não foram a-bordadas neste artigo (exemplo: reconhecimento de imagens) e outrasque estão ainda em fase embrioná-ria. É responsabilidade do adminis-trador do sistema acompanhar aevolução tecnológica, de forma amanter a qualidade de serviço.

Ultimamente tem-se assistido à ins-talação de sistemas para filtrar também os e-mails que saem para aInternet, o que representa uma crescente necessidade de assegurar aconfiança e de evitar que o domíniode origem não seja listado em RBL.

O mundo open-source contém inú-meras ferramentas e sistemas paracombater o SPAM. Existem aborda-gens e soluções muito díspares, algumas restritivas, outras ainda experimentais e aquelas que são quasestandards. Parte do problema nacriação de um sistema deste géneroé seleccionar, interligar e afinar osvários componentes para que funcionem como um só sistema. A curva de aprendizagem envolvida nestegénero de soluções pode ser algoacentuada, mas como contrapartida ganha-se uma flexibilidade, estabilidade e controlo quase absoluto.

O sistema aqui descrito pode-seconsiderar um caso de sucesso: asua construção modular asseguracapacidade de evolução e permitea criação de novas funcionalidades;a escalabilidade do sistema é facilmente conseguida: aumento de me-mória, processadores e/ou númerode servidores; a redundância estáprevenida – caso um servidor falhe,o outro consegue dar resposta ao

volume total de e-mails que entram;A manutenção necessária é mínimae o número de falsos positivos é virtualmente zero.

Referências

[1] http://www.maawg.org/about/MAAWG20072-Q_Metrics_Report.pdf[2] http://www.spam.com/legal/spam/[3]http://europa.eu/rapid/pressReleases-Action.do?reference=IP/01/154&format=HTML&aged=0&language=EN&guiLanguage=en[4] http://www.spamlaws.com/state/ca.shtml[5] http://tools.ietf.org/html/rfc4870[6] http://en.wikipedia.org/wiki/Sender_Policy_Fra-mework[7] http://razor.sourceforge.net/[8] http://bogofilter.sourceforge.net/[9] http://dspam.nuclearelephant.com/[10] http://spambayes.sourceforge.net/[11] http://spamassassin.apache.org/[12] http://www.clamav.net/

Paulo Roncon, Licenciatura em Engenharia deSistemas e Computação, Universidade do Algarveem 2000. Desde 2000 é colaborador da PTInovação. É membro da equipa de suporte internonas áreas de operação, manutenção e suportede servidores Linux/Windows e de desen-volvimento de software. É responsável peloserviço de Gestão de versões de Software,Filtragem de Spam, Sharepoint. Formador na PTInovação em Linux e Redes e Serviços IP.Responsável de Acção do PR459. CertificaçãoSilver - GIAC Security Essentials – GSEC.

palavras-chave:Identidade, gestão de identidades, autorização,autenticação, privacidade, redes convergentes.

O número de identidades digitais associadas aos utilizadores das redesactuais cresce diariamente. Para tal,tem contribuído o ambiente abertoem que a Internet tem sido desenvol-vida e utilizada, provocando o apa-recimento de uma multitude de ser-viços e oportunidades de negócios.Perante esta situação, e nos modelos correntes, a gestão destas identidades tornar-se-á uma tarefa incomportável para o utilizador, levantandoum conjunto de problemas relacionados com segurança e privacidade.

Este artigo apresenta uma breve jus-tificação para a necessidade da cria-ção de elementos associados à ges-tão de identidades na perspectiva das

redes actuais e das redes de próximageração (RPG). O aparecimento defunções de gestão de identidades possibilita uma nova oportunidade de ne-gócio para os operadores tradicionais,colocando-os novamente a desempenhar uma função fundamental nautilização de serviços IP, evitando quese tornem simples fornecedores deconectividade IP.

Ricardo Azevedo Pedro Santos

Francisco Fontes

Gestão de Identidade e Privacidade em RedesConvergentes: Uma Análise de Potencial


01

1. IntroduçãoO conceito de gestão de identidadesnão é novo. Desde há muito que éusado por organizações governamen-tais (no âmbito do e-government), deforma a consolidar e cruzar informaçãoreferente aos cidadãos, obtendo as-sim melhores resultados na organiza-ção e gestão associada à identidade.Grandes organizações sentem tam-bém a necessidade de gerir a iden-tidade dos seus colaboradores deuma forma centralizada, havendo,para isso, um conjunto alargado deferramentas disponíveis no mercadopara gestão de identidade a nívelempresarial [6] [7]. Embora a gestãode identidades seja um domíniocomplexo, com muitas variáveis efunções, quando aplicado a cenáriosconcretos e de âmbito confinado —como os exemplos anteriores, emque o universo de serviços e utiliza-dores são bem conhecidos — a suautilização, e o desenvolvimento de so-luções, torna-se mais simples quan-do comparado ao mundo das teleco-municações.

O uso intensivo da Internet, comomeio de publicação e transmissão

de informação, por um crescentenúmero de utilizadores, tem provo-cado o aparecimento de uma gran-de variedade de serviços online taiscomo home-banking, lojas online,leilões, serviços administrativos, fó-runs, etc. Grande parte destes servi-ços requer um registo inicial de mo-do a que o utilizador possa usufruirdos mesmos. Esta acção implica,normalmente, a divulgação de dadospessoais, assim como a criação e ob-tenção de credenciais para aceder aoserviço em questão. A constante in-trodução da mesma informação pes-soal (ou similar), a gestão das váriascredenciais, perfis etc., associado acada registo, além de não ser cómo-do, faz com que o utilizador, à medidaque consome mais serviços, se torneincapaz de gerir efectivamente todasas suas “identidades” mantendo umnível adequado de privacidade esegurança.

Neste artigo apresentamos uma pos-sível solução para este problema dagestão de identidades, assim comoum exemplo concreto de aplicaçãodos conceitos daí provenientes.

1.1. IdentidadePor definição a “identidade” de umutilizador é um conjunto de elemen-tos que permitem identificá-lo numdado contexto. Transpondo a defini-ção de identidade para o domínio daInternet e das redes de telecomu-nicações, uma identidade é compos-ta por um conjunto de atributos deum determinado utilizador que esteapresenta perante um dado serviçoou entidade. Estes atributos podemtomar várias formas:

> Aspectos biométricos (ex. cor dosolhos);

> Dados financeiros;

> Morada, número de telefone;

> Credenciais de acesso a serviços;

> Histórico de compras;

> Preferências;

> Reputação;

> Etc.


73

Estes atributos que fazem parte daidentidade do utilizador estão nãosó dispersos por diferentes pro-vedores de serviço, como tambémse encontram duplicados em várioslocais (Figura 1). A existência de umgrande número de contas nos vá-rios serviços poderá resultar na utili-zação de credenciais de acessoiguais (ou de baixa complexidade)na maioria dos serviços, provocan-do assim problemas de segurança.Além disso, com a difusão dos dife-rentes atributos da identidade pelosvários serviços, torna-se tambémincomportável para o utilizador gerirde forma eficaz as regras de priva-cidade aplicáveis aos serviços quetem subscritos, assim como asse-gurar a actualização desses mes-mos atributos de uma forma consis-tente.

1.2. Gestão de identidadesA solução para o problema de ges-tão de identidades, apresentado nasecção anterior, passa por criar me-canismos de interligação entre osdiversos provedores de serviço, fa-zendo com que a informação pes-soal dos utilizadores deixe de estarconfinada em “silos de identidade”,mas que seja acessível por todos osfornecedores de serviço desde quedevidamente autorizados pelo utili-zador (por ex. através de políticas deprivacidade). Este processo de inter-ligação de contas é denominado por“federação”.

A federação de identidade (Figura 2)consiste na interligação, através depseudónimos, dos dados de um cer-to utilizador, entre dois fornecedoresde serviço diferentes. O utilizadorcontinua a manter um papel activo,uma vez que a federação entre duascontas depende da sua autorização.Este também poderá criar um con-junto de regras de privacidade impe-dindo que determinada informaçãoseja transmitida de um SP (ServiceProviders) para outro.

Para que não seja necessário esta-belecer federações de identidades

entre todos os SP, o grupo LibertyAlliance (LA) [1] propõe a ideia de umCircle of Trust (CoT) e uma entidadechamada Identity Provider (IdP). OCoT consiste numa relação comerciale técnica, entre um conjunto de SP eum IdP, sobre como trocar informaçãorelativa à identidade de um utilizador,de maneira segura e o menos intrusivapossível. Ao IdP fica a responsabi-lidade de autenticar o utilizador e demanter a associação entre a Identida-

de do mesmo e as várias contas des-te nos diversos SP.

Desta maneira, cada SP apenas ne-cessita de federar a identidade, ouconta, de um dado utilizador comuma única entidade, o IdP dessemesmo utilizador. Além disso, o SPdeixa também de necessitar de im-plementar o seu próprio mecanismode autenticação, deixando esse pa-pel ao IdP.

Figura 1 – Fragmentação da identidade [9]

Figura 2 – Federação de identidade

Authentication(IdP)

Authentic ID@IdP

John_Smith

Federation by Pseudo

8jg68fdf6g

Pseudo@SP

ABC Service(SP)

Authentic ID&SP

John_ABC


2. Candidatos a Identity ProviderTeoricamente, qualquer entidade ouinstituição, seja ela um SP, operador,instituição governamental, ou atémesmo um utilizador, pode desem-penhar o papel de IdP. No entanto,nem todas as entidades se encon-tram igualmente posicionadas paradesempenhar este papel. A adequa-bilidade de uma certa entidade paracumprir o papel de IdP pode ser ava-liada tendo em conta os seguintespontos [2]:

> Reputação: Ao ser responsávelpela autenticação do utilizador, epela asserção de afirmações so-bre o mesmo, o sucesso de umaqualquer entidade como IdP serásusceptível à sua reputação pe-rante os utilizadores. A reputaçãopoderá envolver aspectos comoas políticas de privacidade, o his-torial de segurança de dados, aqualidade de serviço, etc.;

> Acordos comerciais: Quantomaior for a dimensão do CoT doIdP, ou seja quanto mais acordosIdP-SP houver, maior será a ga-ma de serviços disponibilizadosatravés de um dado IdP;

> Ponto de acesso: Uma vez quepara consumir um qualquer servi-ço, um utilizador necessitará, even-tualmente, de se autenticar no seuIdP, quanto mais cedo a autentica-ção se verificar, melhor;

> Experiência de utilização: A uti-lização do sistema terá de ser sim-ples, intuitiva e adaptada às váriassituações, minimizando a interferên-cia na actividade principal do utili-zador (i.e. a utilização do serviço).Isto poderá, por exemplo, implicaro suporte para vários processos oumecanismos de autenticação.

Tendo em conta os pontos referidos,o operador tradicional apresenta,actualmente, um alargado conjuntode vantagens que o posiciona paramelhor desempenhar a função de IdP,das quais enumeramos as principais:

i) Os operadores já disponibilizamvários serviços (são portanto pro-vedores de serviços) e agem co-mo IdPs para esses mesmos ser-viços;

ii) Já possuem uma grande quan-tidade de informação relativa aosseus utilizadores (por ex. perfis de

utilização, localização, dados deautenticação, etc.) associadosaos serviços por si já prestados.Parte desta informação poderáser reutilizada para autenticar outilizador perante provedores deserviço ou disponibilizada comoatributos do utilizador;

iii) Existe um contrato entre o ope-rador e o utilizador (cobrança mo-netária), o que simboliza uma rela-ção de confiança entre estas duasentidades. Além disso, a grandemaioria dos operadores já pos-suem uma presença forte na so-ciedade e mercado, assim comoum historial no relacionamento como utilizador, pelo que os torna enti-dades de reputação considerável(ou seja, dignos da confiança doutilizador comum);

iv) Além de disponibilizarem váriosmeios de acesso, são também oprimeiro ponto de contacto, peloqual o utilizador tem acesso à In-ternet. Este factor posiciona ooperador numa situação privile-giada no que toca à autenticaçãodo utilizador e à disponibilizaçãodessa funcionalidade para outrosprovedores de serviço.

Resumindo, os operadores detêma infra-estrutura, o conhecimento,informação referente à identidadedos utilizadores, e são organizaçõesde confiança do ponto de vista dosutilizadores. Além disso, são nor-malmente o primeiro ponto de con-tacto de ligação à rede. Estes fac-tores fazem do operador o melhorposicionado para desempenhar afunção de IdP.

3. Operador como um IdentityProvider3.1. Estado actualO ambiente aberto em que a Internetassenta e o recente movimento de-nominado “Web 2.0”, tem propor-cionado o aparecimento de novos evariados serviços e áreas de negó-cios. Os provedores de serviço emer-gentes aproveitam a infra-estrutura

Figura 3 – CoT baseado na arquitectura LA [1]

Circleof

Trust

Service Provider- Geolocation- Payment

Principal- User- Employee- Costumer- Game user

Identity Provider- Authentication- Federation- Service Discovery- Personal Profile

Service Provider- Web Shop- Net


75

identidades virtuais, que associa a siou a outras pessoas. Estas associa-ções detêm um conjunto de políti-cas e credenciais de acesso, dadosde personalização, etc.

O processo de delegação é com-posto por duas partes distintas:

i) Criação de uma nova identidadevirtual e políticas associadas ao

do operador tradicional para pro-porcionar novos serviços, mas reti-ram-no da cadeia de proveitos. Ooperador tradicional, que não apre-sente serviços de valor acrescentado,poderá rapidamente transformar-seapenas num “provedor de conec-tividade IP”. O cenário actual é apre-sentado graficamente na Figura 4.Todo o lucro associado aos serviçosfica apenas no SP.

4. Possibilidade de negócioA possibilidade de o operador tradi-cional desempenhar funções de IdPpoderá recolocá-lo na cadeia de pro-veitos dos novos serviços, desem-penhando um papel central em todoo processo, passando também aobservá-lo e controlá-lo.

As receitas para o operador tradi-cional – como IdP – advêm de doisactores:

i) do utilizador final – o utilizador po-derá pagar, por transacção ouflat-rate, para ter acesso aos ser-viços de gestão de identidade eprivacidade;

ii) do SP – ao aceder à base de da-dos de identidades e às relaçõesque o gestor de identidades de-tém no seu Circle of Trust, o SPestará, potencialmente, a ampliaro seu negócio e deverá pagar poresse serviço. O pagamento po-derá, por exemplo, ser efectuadopor transacção ou por pertencerao Circle of Trust.

4.1. Exemplo – Delegação emIPTVO cenário actual de acesso a ser-viços ADSL ou IPTV é hoje realizadocom base no contrato existente en-tre o subscritor do serviço e o ope-rador. Verifica-se no entanto que,geralmente, cada subscrição (con-trato formal) é partilhada, havendoum conjunto de pessoas a acederao serviço (Figura 5). O subscritor(também utilizador) pode, portanto,ser diferente do utilizador que con-some o serviço em si, não existindo,

actualmente, mecanismos intuitivospara detectar quem, realmente, es-tá a consumir o serviço. Este factoimpossibilita a existência de políticasde acesso, ou personalização des-ses mesmos serviços.

O conceito de identidades virtuais edelegação de serviço poderão ajudara mitigar este problema. O subscriptorcria, junto do IdP, um conjunto de

Figura 4 – Situação actual do operador tradicional

Figura 5 – As várias “faces” do subscritor

Mãe

Empregada

Esposa

Pai

Empregado

Filho Estudante

Data C

onnection


uso do serviço por essa identida-de virtual,

ii) Acesso ao serviço.

A próxima secção apresenta de umaforma mais detalhada uma possívelimplementação dos referidos pro-cessos, embora outras possibilidadesde implementação sejam possíveis.

5. Delegação do acesso a umserviçoNo exemplo apresentado, a autoriza-ção é efectuada pelo IdP e a auten-ticação pelo SP. Como é através doIdP que o subscritor cria e gere asidentidades virtuais, é o IdP o local

mais adequado para gerir as políticasassociadas às identidades virtuais.Por outro lado, o subscritor possui umcontrato com o SP, pelo que tambémserá natural que este seja responsá-vel pela emissão das credenciais as-sociadas a esse contrato.

A criação de uma nova identidadevirtual, e a associação a esta de po-líticas de acesso, apresenta-se naFigura 6. O processo é constituídopor duas fases. A primeira fase con-siste na criação de uma nova identi-dade virtual. O subscritor acede aoIdP e cria uma nova identidade vir-tual (que fica associada à identidaderaiz, i.e. o subscritor) e políticas as-

sociadas (mensagem 1). Uma vezque a autenticação dos utilizadores,para acesso ao serviço, é efectuadapelo SP, o IdP envia um pedido paraeste gerar novas credenciais deacesso para o novo utilizador (men-sagem 2). A informação é enviadapara o IdP e finalmente chega aosubscritor. A segunda fase resume--se à entrega da nova chave de a-cesso ao serviço ao novo utilizador(representado pela nova identidadevirtual criada pelo subscritor). A en-trega pode ser feita de diversas for-mas, através de um smart card, pes-soalmente, etc.

6. Acesso ao serviço por delegaçãoO acesso ao serviço por parte do uti-lizador (identidade virtual), criado an-teriormente pelo subscritor, é apre-sentado na Figura 7. Ao aceder aoserviço, o SP questiona o IdP paraque este verifique as políticas deacesso ao serviço (ex. utilizador XYZtem mais de 18 anos). Uma vez ve-rificadas as políticas de acesso, ecomunicado esse facto ao SP, cabea esta entidade executar a auten-ticação necessária para concedero acesso ao serviço.

7. ConclusõesTodo o trabalho na área de gestãode identidades tem vindo a ser de-senvolvido por organizações maisrelacionadas com as tecnologiasassociadas à Web. Só agora se temtornado um tema a considerar pelosoperadores e organismos de nor-malização “tradicionais”, tais comoo ITU-T [5] ou o ETSI/TISPAN [8]. APT Inovação tem vindo a seguir es-te trabalho, uma vez que faz partedo projecto FP7 – SWIFT (SecureWidespread Identities for FederatedTelecommunications) [4].

Os benefícios associados à gestãoeficaz das identidades dos utiliza-dores são claros e distribuídos portodos os actores. Do ponto de vistado operador, a utilização deste ser-viço poderá recolocá-lo novamentena cadeia de receitas do acesso aserviços disponibilizados por outros.

Figura 6 – Criação de uma nova identidade virtual

Figura 7 – Acesso ao serviço

1. Acesso ao serviço

Utilizador

2. Utilizador pode aceder?

Prov.Serviço

Prov.Identidades

3. Ok. Com base em políticas

4. Challenge

5. Rep. Challenge

6. Consumo do serviço

Subscritor Utilizador Prov.Serviço

Prov.Identidades

1. Req. Credenciais para delegação/ Cria políticas e regras

2. Req. Credenciais para delegação

3. Credenciais e nova chave

5. Chave de acesso ao serviço

6. OK


77

Referências

[1] http://www.projectliberty.org/[2] Identity Management for Converged Networks,Lucent/Sun Whitepaper, 2006.[3] Identity Management in TelecommunicationBusiness, Do Van Thanh , Ivar Jørstad , Do VanThuan , Nicolay Bang, 2007.[4] http://www.ist-swift.org/[5] ITU - Telecommunication Standardization Sector- Focus Group on Identity Management[6] http://www.sun.com/software/products/identity/index.jsp[7] http://www.necam.com/IDS/IdMgmt/[8] European Telecommunications Standards Institute - Telecoms & Internet converged Services& Protocols for Advanced Network -http://www.etsi.org/tispan/[9] http://www.fredcavazza.net

Ricardo Azevedo, MSC em Internet Computingpelo Queen Mary College (Universidade deLondres) em 2006 e Licenciado em Engenhariade Computadores e Telemática pela Universidadede Aveiro em 2004. Foi bolseiro de investigaçãodo IT desde 2004 a Fevereiro de 2006, comtrabalho desenvolvido na área de QoS em redesheterogéneas de 4ª geração. Em Fevereiro de2006 iniciou a sua actividade profissional na PTInovação, tendo por objectivo o desenvolvimentouma entidade gestora de recursos a integrar naplataforma Shipnet. Participação em diversosprojectos de I&D no âmbito do IST na área deQoS e Network Management, privacidade e gestãode identidades. Interesse pelas áreas de QoS,Admission Control Algorithms, Network Measu-rements e mobilidade em cenários de redes hete-rogéneas.

Pedro Santos, licenciado em Engenharia Elec-trotécnica e de Computadores, Ramo deTelecomunicações, pela Faculdade de Engenhariada Universidade do Porto em 2007. Em Janeirode 2008 iniciou a sua actividade profissional naPT Inovação como Estagiário Profissional, tendocomo principais áreas de investigação o MulticastIP e Identity Management. Demonstra interessepelas áreas de Identity Management e Redes deNova Geração.

Francisco Fontes, licenciado em EngenhariaElectrotécnica e de Computadores, ramo deElectrónica e Telecomunicações, pelo InstitutoSuperior Técnico (Setembro de 1991) e Doutoradopela Universidade Politécnica de Madrid (Novembrode 2000) na área de gestão distribuída de redesde telecomunicações. Em Setembro de 1991iniciou a sua actividade profissional na PT Inovação(CET) tendo-se especializado em tecnologias derede de banda larga, especialmente nas tec-nologias ATM e IP. Actualmente os seus interessessituam-se nas áreas de Qualidade de Serviço emredes multi-serviço e na sua evolução paraarquitecturas RPG All-IP.

É também claro que o operador éum dos actores que melhor estáposicionado para desempenhar opapel de SP de identidade, uma vezque já possui o know-how (é pro-vedor dos seus próprios serviços),tem uma relação de confiança comos utilizadores, é dono da infra-es-trutura de acesso à rede e dispõe,já, uma enorme base de dados deidentidades.


palavras-chave:multicast, controlo de acesso, AAA,

redes de acesso heterogéneas

O multicast IP é um método ade-quado para transmissão de conteú-dos 1-N (ex. IPTV) ou N-M (ex.vídeo-conferência, jogos online). Osoperadores, no entanto, têm mos-trado alguma relutância na adopçãodo multicast IP e em efectuar o seucontrolo ao nível da rede, em partepelos problemas que este apresentarelativamente à gestão de membrose fontes, o que não só impede osoperadores de taxarem os serviçosbaseados em multicast IP, como difi-culta a gestão de rede.

Uma solução possível para estesproblemas passa por se implemen-tar um sistema que permita controlaro acesso a grupos e a transmissãode conteúdos multicast (utilizadores

Manuel Ricardo(INESC Porto)

como fontes), ou seja, a implemen-tar um sistema de multicast AAA(Authentication, Authorization andAccounting).

Neste artigo é apresentada umasolução baseada na detecção desessões multicast nos nós das re-des de acesso e a consequenteautorização dessas sessões, aindaantes do estabelecimento dos flu-xos multicast. A solução aproveitaas funcionalidades de AAA tradi-cionais, usadas para identificar outilizador e autorizar as sessõesmulticast. As três redes de acessoconsideradas no projecto foramxDSL, WiMAX e UMTS.

António Pinto(INESC Porto)

Pedro Santos Teresa Almeida

Francisco Fontes

Gestão de Sessões Multicast sobre Redesde Acesso Heterogéneas

79

02

Saber & Fazer Telecomunicações

1. IntroduçãoA proliferação de tecnologias deacesso capazes de suportar liga-ções de alto débito, aliada ao cres-cente número de utilizadores debanda larga, tem contribuído parao aumento de conteúdos multimé-dia na Internet. Para suportar otráfego associado a estes conteú-dos, os operadores vêem-se força-dos a aumentar a capacidade dasligações por si fornecidas e a adqui-rir routers com capacidade de pro-cessamento cada vez maior, o queimplica investimentos substanciaisem infra-estruturas, nem semprefacilmente realizáveis, quer por ra-zões técnicas ou financeiras.

Muitos destes conteúdos enqua-dram-se em modelos de comuni-cação 1-N (ex. IPTV) ou N-M (ex.videoconferência ou jogos online).Nestes casos, o multicast IP [1] sur-ge como um método de transmis-são adequado. Na transmissãounicast é necessário um fluxo dedados por cada receptor, no entan-to, em multicast IP, é criado apenasum fluxo para um conjunto de utili-zadores, obtendo-se assim uma

utilização mais eficiente da rede.

Apesar dos aparentes benefícios domulticast IP [2], a sua adopção pe-los operadores tem sido limitada.Embora já utilizado em serviços,como o IPTV, este método de trans-missão não é suportado nas liga-ções à Internet disponibilizadaspelos actuais Internet Service Pro-viders (ISP). Uma das razões destarelutância deve-se ao modelo abertodo multicast IP — qualquer utilizadoré livre de receber ou transmitir con-teúdos de ou para um grupo multi-cast. O multicast IP é escalável a umgrande número de utilizadores mas,simultaneamente, dificulta o controlodas sessões pelos operadores. Afalta destes mecanismos de contro-lo torna a gestão da rede e o forne-cimento de serviços comerciaisbaseados em multicast difíceis deimplementar, dado que a capaci-dade de AAA é essencial para ataxação e controlo destes serviços.

Neste artigo apresenta-se umasolução que utiliza as funcionali-dades de AAA existentes nas redesde acesso consideradas (xDSL,

WiMAX e UMTS) para identificar aso utilizador e autorizar as sessõesmulticast.

1.1. Multicast IPO multicast IP é um método de en-caminhamento de pacotes IP, emque um fluxo de dados pode ser,simultaneamente, distribuído a umconjunto de destinos. Isto é conse-guido através da replicação dospacotes de dados em todos os nósda rede onde o percurso para osreceptores diverge. A Figura 1 mos-tra uma sessão multicast IP, consti-tuída por três elementos: a fonte deconteúdos, o grupo (receptores) ea árvore de distribuição.

Fonte: elemento responsável portransmitir conteúdos para um, oumais, grupos multicast. Para que umutilizador se torne numa fonte, bastaque comece a transmitir tráfego des-tinado a um endereço multicast (en-dereços IPv4 classe D — 224.0.0.0a 239.255.255.255).

Grupo: conjunto de receptores deum fluxo de dados emitido, em tem-po real, por uma ou mais fontes multi-

Figura 1 – Elementos de uma rede multicast IP

Árvore de distribuição

MembershipReports / Queries

Fonte

Receptores

Protocolo deencaminhamento

multicast

Protocolo degestão de

grupos

80

cast. Um grupo é representado porum endereço multicast. A gestão dosgrupos na rede local é feita atravésdo Internet Group Management Pro-tocol (IGMP) [3].

Este protocolo permite aos recep-tores comunicar a intenção de aderirou de sair de um grupo multicast,bem como renovar as adesões pre-viamente efectuadas. Sendo umprotocolo local, o IGMP é utilizadoapenas entre os receptores e osrespectivos routers de acesso.

Árvore de distribuição: caminhopelo qual o tráfego multicast é enca-minhado. As árvores de distribuiçãosão construídas pelos routers darede, utilizando para o efeito pro-

tocolos de encaminhamento multi-cast (ex. Protocol IndependentMulticast - Sparse Mode - PIM-SM).As árvores de distribuição podemser subdivididas em 2 tipos: árvorescentradas na fonte (a raiz da árvoreé a fonte multicast) e árvores par-tilhadas (a raiz da árvore é um outronó na rede). Para reduzir a repli-cação de pacotes nos elementos derede de nível 2, que por omissãoreplicam os pacotes multicast portodas as portas, é utilizado o IGMPsnooping [4]. Para isso, os equi-pamentos de nível 2 inspeccionamos pacotes IGMP e replicam depoisos pacotes multicast recebidospelas portas que servem membrosdo grupo.

81

1.2. Redes de acessoÀ medida que as redes de acessoconvergem para o modelo all-IP, éde todo o interesse aproveitar asvantagens do multicast IP, que éindependente da tecnologia deacesso. Isto é especialmente rele-vante nas redes rádio onde os re-cursos existentes são limitados. AFigura 2 mostra o cenário usado pa-ra desenvolver este trabalho. Sãoconsideradas 3 redes de acesso:UMTS, xDSL e WiMAX.

1.2.1. UMTSAs redes UMTS possuem suportepara multicast IP desde a R99. Opapel de router multicast é desem-penhado pelo GGSN [5] (Figura 3).Contudo, o transporte do tráfegomulticast na rede UMTS é efecuadosobre ligações / túneis ponto-a-ponto, pelo que a eficiência decor-rente do uso do multicast na redede acesso é desperdiçada.

O suporte eficiente e nativo detransmissão multicast acabou porser introduzido na Release 6 com oaparecimento do Multimedia Broad-cast/Multicast Service (MBMS) [6](Figura 4).

O MBMS adiciona às redes 3GPPum novo elemento funcional, oBroadcast Multicast - Service Cen-ter (BM-SC), responsável pela ges-tão do multicast dentro da redeUMTS, incluindo o anúncio de ses-sões, e a autorização e autentica-ção de utilizadores. Para além doBM-SC, este serviço requer fun-cionalidades adicionais em outroselementos da rede UMTS, comopor exemplo o suporte da sinali-zação MBMS pelo SGSN ou a alo-cação de recursos rádios na RadioAccess Network (RAN).

No MBMS a distribuição de dadosmulticast é efectuada apenas nosentido descendente (GGSN UE);qualquer tráfego multicast prove-niente dos utilizadores deverá serencaminhado até ao GGSN, en-capsulado em ligações ponto-a-

Gestão de Sessões Multicast sobre Redesde Acesso Heterogéneas

Figura 2 – Cenário de Referência

Figura 3 – Plano de controlo para multicast IP em UMTS

3G/UMTS

UE Node B RNC SGSN GGSN BM-SC

xDSL

CPE DSLAM BNG IP Network

WiMAX

SS BS ASN-GW

AAAServer

TE+MT SGSN GGSN Intranet/ISP

IP-M applicationserver

IP-M ProxyIP-M

Application

IGMP

Packet Domain Bearer

IP

LowerLayers

IP IP

IGMP PIM(or equiv)

PIM(or equiv)

IP

LowerLayers

Gi


-ponto. Só a partir deste elementoé enviado em multicast até aos ou-tros UE do grupo. A gestão dos gru-pos multicast usa mensagens IGMPe são também utilizados endereçosIPv4 classe D para representar osgrupos. O MBMS é, portanto, inter-operável com o multicast IP. Noentanto, a interface entre o BM-SCe as redes IP externas ainda não seencontra definida, pelo que oMBMS encontra-se limitado à redeUMTS.

1.2.2. xDSLNa Figura 5 encontra-se repre-sentada a arquitectura xDSL [7]. OBroadband Network Gateway(BNG) assume as funções do routermulticast, processando as men-sagens IGMP provenientes da redede acesso.

Em redes xDSL as ligações dedados são tipicamente Point-to-Point Protocol over Ethernet(PPPoE), estabelecidas entre oCustomer Premises Equipment(CPE) e o BNG. A natureza ponto-a-ponto destas ligações implica quea replicação multicast seja feitaapenas no BNG. Ao receber umfluxo multicast proveniente da redeIP, o BNG replica-o e envia-o sobreas ligações PPPoE para os CPEmembros do grupo. Isto provoca oaparecimento de tráfego redundan-te em alguns segmentos de rede;isto é, tráfego do mesmo grupo éenviado através de ligações PPPoEdiferentes, sobre o mesmo segmen-to DSLAM-BNG.

A optimização da rede de acessoxDSL para distribuição dos con-teúdos por multicast IP exige quetodos os elementos da rede deacesso participem na replicaçãomulticast. Logo, é necessário que aligação de dados seja feita em In-ternet Protocol over Ethernet (IPoE)e que os equipamentos de nível 2executem IGMP snooping. Uma vezque as ligações PPPoE são tam-bém utilizadas para autenticação /autorização de utilizadores, são por

vezes criados 2 tipos de ligação:PPPoE, para conteúdos genéricos,e IPoE, para conteúdos multicastespecíficos (ex. IPTV).

1.2.3. WiMAXA arquitectura da rede WiMAX(802.16d/e) encontra-se represen-tada na Figura 6. Para transmissãode pacotes IP são estabelecidas li-gações de transporte IEEE 802.16,entre a Base Station (BS) e as Sub-scriber Stations (SS), identificadaspelo Connection Identifier (CID), de16bits. Também é criado um túnelentre a BS e o Access Service Net-work Gateway (ASN-GW) para cadauma destas ligações.

O papel de router multicast em

WiMAX cabe ao ASN-GW, que étambém responsável pela auten-ticação / autorização de utilizadores.

As ligações ascendentes (SS ASN-GW) são feitas exclusivamente emunicast. Por outro lado, no sentidodescendente, é possível utilizarmCID (multicast CID) para identificaruma ligação partilhada por váriasSS. A gestão destes mCID aindanão está definida pelo WiMAX Fo-rum.

Outros problemas associados à uti-lização do mCID são a fraca eficiên-cia na transmissão de dados paragrupos mult icast de pequenadimensão e o maior consumo deenergia das SS.

Figura 4 – Arquitectura MBMS

Figura 6 – Arquitectura WiMAX (802.16d)

Figura 5 – Arquitectura xDSL

Rede UMTS PDN Externa

UE RAN SGSN GGSN BM-SC

Fonte deconteúdos

IGMP Join/Leave AAA Server

Fonte deconteúdos

Nós de optimizaçãomulticast

CPE DSLAM Rede deAgregação BNG Rede IP

IGMP Join/Leave

SS

SS

SS

BS ASN - GWCRE Tunnel

IGMP Join / Leave

Rede IP

83 Gestão de Sessões Multicast sobre Redesde Acesso Heterogéneas

2. Solução desenvolvidaO controlo de acesso aos con-teúdos transmitidos por multicast IPpode ser conseguido de duasformas: pela cifra de dados end-to-end, ou controlando o acesso aosgrupos multicast. A cifra protege oacesso não autorizado aos con-teúdos transmitidos, mas não evitaque utilizadores obtenham os fluxosde dados multicast, ainda que cifra-dos. A cifra implica a utilização desoftware específico para a distri-buição e partilha de chaves cripto-gráficas, tanto do lado do clientecomo do operador. Por outro lado,o controlo do acesso a gruposmulticast não garante, por si só, aconfidencialidade dos dados, maspermite ao operador gerir a distri-buição de dados multicast ao nívelda rede.

O controlo de acesso ao grupomulticast foi o método escolhidoneste projecto e baseia-se na ges-tão de sessões nos edge routers.Uma vez que estes equipamentossão os responsáveis por processaras mensagens IGMP dos utiliza-dores, torna-se possível identificare filtrar pedidos de adesão a grupose transmissões multicast de um uti-lizador, sendo portanto, possíveldiscriminar os fluxos multicast a queum utilizador pode ter acesso e paraque grupos multicast o utilizadorconsegue transmitir dados (agircomo fonte).

2.1. ArquitecturaA solução desenvolvida é compostapor dois elementos: o controladormulticast e o servidor de AAA(Figura 8).

Controlador multicast: está situadono nó de acesso à rede e tem fun-cionalidades que incluem um clientede AAA e o processamento demensagens IGMP. Este controladoré responsável pela detecção eintercepção de pedidos de acessoa grupos e transmissões de dadosmulticast pelos utilizadores e tam-bém pela verificação da autorização

Figura 7 – Controlo do acesso a grupos e de fontes multicast

ControladorMulticast

Utilizador Nó de acesso Servidor AAA

Processo de autenticação/autorização para acesso à rede

Controlode

membros

Controlode

fontes

Authorization Request(mcast_session_id, user_id)

Authorization Response(accept | deny)

(IGMP Join)

forward | drop

(IGMP Join)

Multicast stream

Multicast stream (S,G)

Multicast stream (S,G)

Authorization Request(mcast_session_id, user_id)

Authorization Response(accept | deny)

forward | drop

Figura 8 – Protótipo implementado

Access Router Controlador Multicast

Detecção de fontes

Detecção de membros

Gestão de sessõesjá autorizadas

Execução de pedidosde autorização

Application

Transport

Network

Data Link

Physical

DHCPd

mrouted

IGMP & UDP MulticastQUEUE

hostpad

PPPd

EAP-MDS

PAP / CHAP

AAA SERVER

FreeradiusUser 2

User 1


junto do servidor de AAA. Poste-riormente, e em função da respostaobtida pelo servidor de AAA, o con-trolador processa ou descarta opedido de acesso recebido, ou, nocaso de o utilizador ser uma fontemulticast, encaminha ou não o res-pectivo fluxo de tráfego.

Servidor de AAA: este elementopode situar-se num qualquer pontoda rede do operador, desde queacessível ao controlador multicast.O servidor de AAA contém infor-mação de autenticação, autori-zação e de registo relativa à ligaçãodo utilizador à rede; contém aindaum perfil multicast por utilizador,onde constam os direitos de acessoe de criação de sessões multicast.A informação de AAA está organi-zada de forma a permitir que ocontrolador multicast consiga iden-tificar inequivocamente o utilizadorusando apenas os dados contidosnos pacotes de dados e sinalizaçãomulticast.

Os parâmetros usados para identi-ficar as sessões multicast encon-tram-se descritos na Tabela 1, ondese podem observar os vários tiposde endereço usados em função dotipo de dados interceptados.

Apesar desta solução controlar oacesso no elemento que processaas mensagens IGMP, um controlosimilar deverá também ser feito noúltimo elemento de replicação depacotes de dados. Normalmenteeste ponto é coincidente com o nóde acesso.

2.2. ProtótipoO protótipo desenvolvido contém asfuncional idades pr incipais dosistema:

> Autenticação de utilizadores, nomomento da sua ligação à rede,com recurso a um servidor deAAA;

> Detecção de pedidos de adesãoa grupos;

> Detecção de fontes multicast narede de acesso;

> Filtragem do tráfego multicast nãoautorizado.

O protótipo desenvolvido está repre-sentado na Figura 8. Por uma ques-tão de simplicidade, o servidor AAAfoi instalado na mesma máquinaque o controlador multicast (routerde acesso).

Depois do utilizador se ligar à redee de se autenticar, o sistema detec-ta e captura os pacotes IGMP eUDP multicast, usando para isso aQUEUE do netfilter/iptables. Estacaptura é feita antes de o pacotechegar à camada de rede (nível 3),ou seja, antes do router de acessoo processar a nível IP. Na QUEUEsão processados os pacotes um aum pelo controlador multicast, como intuito de se verificar se a sessãoé autorizada. O controlador identi-fica o utilizador e a sessão multicastusando a informação de rede dis-ponível, endereços IP, neste caso.

O controlador multicast usa duaslistas temporárias, contendo infor-mação sobre sessões recentemen-te autorizadas (fontes e membros),com o objectivo de evitar a repeti-ção de pedidos de autorização. Es-tas listas são refrescadas regular-mente. No caso das fontes, estaoptimização é ainda mais crítica jáque a afluência de pacotes é muitosuperior. São criadas regras iptablespara que o tráfego associado asessões já autorizadas seja imedi-atamente encaminhado pelo routersem passar pelo controlador multi-cast. Outra optimização possívelconsiste no bloqueio de pacotesassociados a sessões não auto-rizadas.

3. Importância para a PTA solução apresentada pode serutilizada para gerir o acesso aserviços que façam uso do multi-cast IP, isto é, aplicações que en-volvam a distribuição de dados emtempo real para um grupo de uti-lizadores. A solução proposta nãorequer qualquer modificação deprotocolos ou software do lado doutilizador. Emissão e recepção devídeo por parte dos utilizadores,distribuição de informação finan-ceira em tempo real, rádio por IP,ou jogos online, são exemplos des-te tipo de aplicações.

Por outro lado, uma vez que a ges-tão da sessão multicast é feita noTabela 1 – Parâmetros identificadores de sessões multicast

nó de acesso, os utilizadores sãoimpedidos de receber fluxos nãoautorizados, prevenindo-se destamaneira potenciais riscos de segu-rança, tais como ataques de DoS.

ConclusõesNeste artigo foi apresentada umasolução capaz de gerir sessõesmulticast sobre redes de acessoheterogéneas. Esta solução permitecontrolar e monitorizar pedidos deadesão a grupos, assim como a cri-ação de novos grupos na rede deacesso.

A solução funciona a nível IP, o quea torna adaptável às tecnologias deacesso consideradas; contudo, seexistir também multicast nível 2,torna-se necessário controlar as ta-belas de encaminhamento multicastno último ponto de replicação. Exis-tem limitações relacionadas com asvárias arquitecturas de rede. EmxDSL e WiMAX, uma ligação poderepresentar vários utilizadores, peloque o controlo de acesso é feito porligação e não por utilizador. EmUMTS existem 2 possibilidades: uti-lizar o MBMS ou o multicast IP "tra-dicional". No primeiro caso não sãosuportados utilizadores fonte; noúltimo não são aproveitadas aspoupanças em largura de bandaassociadas à transmissão multicast.

O sistema apresentado é trans-parente para o utilizador, aplica-ções, protocolos e equipamentosde rede, com excepção do equi-pamento que implemente o contro-lador multicast e possíveis modifi-cações ao servidor de AAA.

Referências[1] Deering, S., RFC 1112 Host Extensions for IPMulticasting, Aug. 1989;[2] C. Diot et al., Deployment issues for the IPmulticast service and architecture, Network, IEEE,vol. 14, 2000, pp. 78-88.[3] B. Cain et al., RFC 3376 Internet Group Management Protocol, Version 3, Oct. 2002.[4] M. Christensen, et al., RFC 4541 Considerationsfor Internet Group Management Protocol (IGMP)and Multicast Listener Discovery (MLD) SnoopingSwitches, May. 2006.[5] 3rd Generation Partnership Project (3GPP),Interworking between the Public Land MobileNetwork (PLMN) supporting packet based servicesand Packet Data Networks (PDN) (Release 7), Jun.2007.[6] 3rd Generation Partnership Project (3GPP),Multimedia Broadcast/Multicast Service (MBMS);Architecture and functional description (Release7), Jun. 2007.[7] DSL Forum, Migration to Ethernet-Based DSLAggregation, Apr. 2006.[8] WiMAX Forum Network Architecture Stage 2- 3. Release 1, Version 1.1, Jul. 2007.[9] H. Jeon, M. Riegel, and S. Jeong, Transmissionof IP over Ethernet over IEEE 802.16 Networksdraft-ietf-16ng-ip-over-ethernet-over-802.16-04,Dec. 2007.

85 Gestão de Sessões Multicast sobre Redesde Acesso Heterogéneas


Pedro Santos, licenciado em Engenharia Elec-trotécnica e de Computadores, Ramo de Teleco-municações, pela Faculdade de Engenharia daUniversidade do Porto em 2007. Em Janeiro de2008 iniciou a sua actividade profissional na PTInovação como Estagiário Profissional, tendocomo principais áreas de investigação o MulticastIP e Identity Management. Demonstra interessepelas áreas de Identity Management e Redes deNova Geração.

M. Teresa R. L. de Almeida, é licenciada emFísica Aplicada à Óptica e Electrónica, pela FCUP,1986. De 1987 a 1989 foi bolseira da JNCIT, emC&T, no LIP e integrou a equipa DELPHI, noCERN. Desde 1989 colaboradora da PT Inova-ção, especializou-se em redes ópticas DWDM,actualmente parte do grupo Plataformas e RedesMultiserviço, Área Investigação Aplicada e Difusãodo Conhecimento. Participou em vários projectosnacionais e internacionais, estando actualmentea colaborar no projecto 4WARD, do sétimo Pro-grama Quadro Comunitário. É autora e co-autorade várias publicações.

Francisco Fontes, licenciado em EngenhariaElectrotécnica e de Computadores, ramo deElectrónica e Telecomunicações, pelo InstitutoSuperior Técnico (Setembro de 1991) e Douto-rado pela Universidade Politécnica de Madrid(Novembro de 2000) na área de gestão distribuídade redes de telecomunicações. Em Setembro de1991 iniciou a sua actividade profissional na PTInovação (CET) tendo-se especializado em tec-nologias de rede de banda larga, especialmentenas tecnologias ATM e IP. Actualmente os seusinteresses situam-se nas áreas de Qualidade deServiço em redes multi-serviço e na sua evoluçãopara arquitecturas RPG All-IP.

António Pinto é Licenciado (2000) em EngenhariaInformática pelo Instituto Superior de Engenhariado Instituto Politécnico do Porto, Mestre (2005)em Redes e Serviços de Comunicação pela Fa-culdade de Engenharia da Universidade do Por-to. É Professor Adjunto na Escola Superior deTecnologia e Gestão de Felgueiras (ESTGF) doInstituto Politécnico do Porto, onde lecciona dis-ciplinas de Redes de Computadores, SistemasOperativos e Comunicação e Computação Móvel.Frequenta ainda o curso de Doutoramento emEngenharia Electrotécnica e Computadores naUniversidade do Porto.

Manuel Ricardo é Licenciado (1988), Mestre(1992) e Doutor (2000) em Engenharia Electro-técnica e de Computadores (Telecomunicações),pela Universidade do Porto. É professor associadoda Faculdade de Engenharia da Universidade doPorto, onde lecciona disciplinas de comunicaçõesmóveis e redes de computadores. Lidera tambéma área de "Wireless and Mobile Networks" doINESC Porto.

Optimização dos Mecanismos deMobilidade em Redes de Próxima Geração

87

palavras-chave:IEEE 802.21, MIH, Mobilidade Transparente,

Redes de Acesso Wireless Heterogéneas

O paradigma de acesso à Internetestá a mudar e um novo e vasto conjunto de novas tecnologias de aces-so wireless, como por exemplo Wi-MAX, Wi-Fi, 3GPP LTE/UMTS e DVB,estão agora ao dispor dos utiliza-dores e dos seus terminais multi-mo-do/acesso.

Deste modo, novos mecanismos eprotocolos são necessários parafornecer mobilidade transparente entre todas as tecnologias de acessomencionadas. Actualmente, o orga-nismo de normalização IEEE, nomeadamente o grupo 802.21, está a definiruma plataforma para optimizar osprocessos de mobilidade em redesde acesso heterogéneas, designada

Pedro Neves

Media Independent Handover (MIH)framework.

Tendo como base a framework MIHdefinida pelo IEEE 802.21, este artigo propõe um conjunto de mecanismos e procedimentos com o objectivode fornecer mobilidade transparenteaos utilizadores em ambientes deacesso heterogéneos. Para concluir,um caso prático de aplicação é apresentado, descrevendo o suporte demobilidade entre as promissoras redes de acesso de próxima geração3GPP LTE e WiMAX.

Isabel Borges Telma Mota

Susana Sargento(Universidade de Aveiro)

Francisco Fontes


1. IntroduçãoActualmente os utilizadores exigemestar permanentemente ligados àInternet, independentemente da tec-nologia e do local de acesso, comdébitos elevados, e com garantias demobilidade sem quebra de serviço,usufruindo deste modo do conceitoABC (Always Best Connected). Poreste motivo, as redes wireless debanda larga, como por exemplo3GPP UMTS/LTE, WiMAX e Wi-Fitêm vindo a massificar-se e, comoconsequência, novos estudos têmsido desenvolvidos para permitir acontinuidade das sessões dos uti-lizadores durante os processos demobilidade (handover) entre estasredes – mobilidade transparente.Neste sentido, têm sido colocadosnovos desafios aos operadores paraque consigam integrar nas suas re-des de próxima geração a capaci-dade de garantirem mobilidadetransparente, para um vasto conjun-to de tecnologias de acesso.

Mediante este enquadramento, ogrupo de normalização IEEE 802.21está a definir uma plataforma, de-signada Media Independent Hand-

over (MIH) framework [1], cujo objec-tivo é optimizar e uniformizar os me-canismos de mobilidade entre dife-rentes tecnologias de acesso.

Uma parte significativa das funcio-nalidades necessárias para fornecermobilidade transparente está relacio-nada com as interacções que sãonecessárias estabelecer entre asespecificidades das tecnologias deacesso e as camadas protocolaressuperiores, nomeadamente o “mun-do IP”. É precisamente neste univer-so que o grupo IEEE 802.21 pre-tende contribuir com a definição daframework MIH, fornecendo umacamada de abstracção, indepen-dente das tecnologias de acesso.

Assim, surge finalmente uma normaque permite a interacção entre o“mundo IP” com as tecnologias deacesso, sem ter que se preocuparcom as particularidades de cadauma delas. Através da disponibili-zação de um conjunto de serviços,na forma de comandos e eventos,o IEEE 802.21 fornece informaçãoestática e dinâmica sobre o estadoactual do link wireless da tecnologia

de acesso aos protocolos de gestãode mobilidade IP, como por exem-plo o Fast Mobile IP (FMIP) [2], oSession Initiation Protocol (SIP) [3]e o Proxy Mobile IP (PMIP) [4], au-xiliando estes protocolos na tomadade decisões sobre o processo dehandover.

Neste artigo, começaremos por a-presentar a norma IEEE 802.21,dando particular atenção à arqui-tectura da framework MIH e aosserviços disponibilizados pela mes-ma. Seguidamente, apresentamosuma arquitectura multi-operador emulti-tecnologia, com suporte demobilidade transparente, garantindoa continuidade dos serviços que es-tão contratados com o operador du-rante o processo de handover.

Detalharemos ainda um caso espe-cífico de mobilidade entre as tecno-logias 3GPP LTE e WiMAX, utili-zando a norma IEEE 802.21. Paraterminar, discutimos o impacto queeste tipo de soluções poderá ter pa-ra o Grupo PT e apresentamos asconclusões do artigo.

2. IEEE 802.21 MIHA norma IEEE 802.21 tem comoprincipal função optimizar os me-canismos de mobilidade em am-bientes de acesso heterogéneos.Para isso, está a definir a frameworkMIH, cujo objectivo é uniformizar osprocessos de comunicação entreas tecnologias de acesso e os a-gentes de mobilidade das camadassuperiores. Através de interfacescomuns a todas as tecnologias deacesso, é disponibilizado um con-junto de serviços que contém todaa inteligência da framework MIH.

Nesta secção, iremos descrever osaspectos mais importantes destanorma, nomeadamente as entida-des que a compõem e o seu mo-delo de comunicação num ambien-te heterogéneo, multi-tecnologia emulti-operador. Por último, iremosapresentar os serviços que a norma

IEEE 802.21 coloca ao dispor dosdiferentes agentes de mobilidadeexistentes numa rede de telecomu-nicações de próxima geração.

2.1. Arquitectura IEEE 802.21 MIHA principal entidade definida pelanorma 802.21 é o Media Indepen-dent Handover Function (MIHF). OMIHF pretende abstrair as espe-cificidades das tecnologias de aces-so aos mecanismos de mobilidadedas camadas protocolares supe-riores. O MIHF fornece informaçãointeligente sobre as redes de aces-so aos agentes de mobilidade dascamadas superiores, designadospor Media Independente HandoverFunction Users (MIHU), salientando--se os algoritmos de decisão de mo-bilidade e os protocolos de gestãode mobilidade, onde destacamos oFMIP, o SIP e o PMIP. Os MIHU uti-lizam a informação fornecida pelo

89

MIHF para optimizarem os proces-sos de mobilidade. A comunicaçãoentre todas as entidades da norma802.21 é efectuada através de trêsinterfaces:

> MIH_LINK_SAP: estabelece acomunicação entre as tecnologiasde acesso e o MIHF;

> MIH_SAP: efectua a comunica-ção entre o MIHF e os MIHU;

> MIH_NET_SAP: estabelece acomunicação entre os MIHF exis-tentes em diferentes nós da rede,utilizando o protocolo MIH.

A Figura 1 apresenta, de forma sim-plificada, a arquitectura especificadapela norma IEEE 802.21, incluindoas tecnologias de acesso rádio, eas entidades MIHF e MIHU mencio-nadas anteriormente. Estão tam-bém representadas as interfaces quepermitem a comunicação entre asdiversas entidades da framework.

2.2. MIH ServicesA arquitectura IEEE 802.21, apre-sentada na secção anterior, dis-ponibiliza um vasto conjunto de in-formação cujo principal objectivo éoptimizar os mecanismos de hand-over inter-tecnologia. Para organizare estruturar a informação disponi-bilizada pela plataforma, o IEEE802.21 define os três tipos de ser-viços, representados na Figura 1:

> Media Independent Event Service(MIES);

> Media Independent CommandService (MICS);

> Media Independent InformationService (MIIS).

Sucintamente, estes serviços per-mitem aos MIHU receberem even-tos das tecnologias de acesso, en-viar comandos para as mesmas, eaceder a informação estática sobrea topologia da rede armazenadanum servidor central, respectiva-

Optimização dos Mecanismos deMobilidade em Redes de Próxima Geração

Figura 1 – Arquitectura IEEE 802.21 MIH

SIP MIP FMIP

MIHUL3

MIHEvents

MIHCommands

InformationServices

Remote MIHEvents

MIHU

MIHFL2.5

MIES MICS MIS

InformationServices

LinkCommands

LinkEvents

UMTS WiMAX Wi-Fi LTE

Tecnologias de acesso wireless

Remote MIHCommands

MIH_NET_SAP

MIH_LINK_SAP

MIH_SAP

Link LayersLink Layers


mente. Dado que os MIH Servicesconstituem uma das partes maisimportantes da arquitectura IEEE802.21, iremos descrever detalha-damente cada um deles.

O MIES fornece informação sobreeventos gerados pelas tecnologias deacesso, como por exemplo o estadoe a qualidade do canal rádio. Oseventos podem ser gerados pelo ter-minal móvel ou pelo ponto de aces-so (rede). Dado que diferentes MIHUpodem estar interessados em rece-ber os eventos gerados pelas cama-das inferiores, os MIHU devem come-çar por efectuar um pré-registo detodos os eventos que pretendemreceber. Desta forma, a plataformaencarregar-se-á de entregar os even-tos gerados pelas camadas inferioresà lista de MIHU que subscreveramesses mesmos eventos.

Os eventos podem ser divididos emdois grupos, Link Events e MIH Events.

Os Link Events são gerados pelastecnologias de acesso e recebidospelo MIHF. Os eventos que são pro-pagados pelo MIHF para os MIHUsão denominados MIH Events. Podeainda subdividir-se os MIH Eventsem locais ou remotos.

Os MIH Events locais são propaga-dos para um MIHU situado no mes-mo nó, enquanto os MIH Events re-motos são propagados para MIHUlocalizados noutros nós da rede. AFigura 1 apresenta o MIES, incluindoos Link e os MIH Events, locais eremotos.

O MICS permite aos MIHU contro-larem as tecnologias de acesso. OsMIHU podem utilizar o MICS paraobterem informação sobre o estadodo canal rádio ou para configuraremo comportamento das tecnologiasde acesso e assim optimizar o pro-cesso de handover. Os comandos,tal como os eventos, são classifi-cados em dois grupos, Link e MIHCommands. Os MIH Commandssão enviados pelos MIHU para o

MIHF, podendo ser locais ou remo-tos. Os MIH Commands locais sãoenviados para o MIHF localizado nomesmo nó, enquanto os MIH Com-mands remotos são enviados paraum MIHF localizado noutro nó darede. Os Link Commands são propa-gados pelo MIHF para a tecnologiade acesso.

O MIIS define uma plataforma atra-vés da qual um MIHF, localizado noterminal móvel ou na rede, é capazde obter informação sobre as redesde acesso existentes. O principalobjectivo é obter informação acercade todas as tecnologias de acessoexistentes na área circundante doterminal, permitindo assim a obtençãoda topologia da rede de acesso edando início ao processo de selecçãoda rede de destino para o processode handover. Uma nova entidade, de-nominada MIIS Server, é usada peloMIIS para armazenar toda a informa-ção das redes de acesso.

Assim, os MIHF podem, quandonecessário, enviar um query ao MIISServer para saberem, por exemplo,quais são as tecnologias de acessoque estão disponíveis num deter-

minado instante.

3. Arquitectura de MobilidadeDepois de apresentados os prin-cipais conceitos da norma IEEE802.21, esta secção pretende de-monstrar como é que esta platafor-ma pode ser integrada num am-biente heterogéneo multi-tecnologiae multi-operador. Iremos ainda apre-sentar um caso específico de mo-bilidade entre as tecnologias 3GPPLTE e WiMAX.

3.1. Arquitectura de Rede e o MIHDo ponto de vista da arquitectura,apresentada na Figura 2, a platafor-ma MIH está presente em diversospontos da rede, incluindo o próprioterminal móvel, a rede de acesso e arede de núcleo do operador. Depen-dendo da localização de cada umadas entidades MIH, diferentes fun-cionalidades são atribuídas. As se-guintes entidades de rede MIH fo-ram definidas pela norma:

> Point of Attachment (PoA): pontode conectividade do terminal mó-vel à rede de acesso;

> Point of Service (PoS): ponto de

Figura 2 – Rede multi-operador multi-tecnologia

Non - PoS PoS

MN PoS

WiMAX

WiMAXMIH PoA

WiFi

WiFiMIH PoA

LTEMIH PoA

UMTSMIH PoA

LTE

UMTS

MIIS ServerMIH Non - PoS

MIH PoS

IEEE 802Operator A Home

Core Network

MN PoS

Non - PoS PoS

MIH PoSMIIS Server

MIH Non - PoS

3GPPOperator B Visited

Core Network

MNMIH

91 Optimização dos Mecanismos deMobilidade em Redes de Próxima Geração

comunicação MIH entre o termi-nal móvel e a rede do operador.O PoS pode estar colocado namesma entidade de rede do PoA;

> Non-Point of Service (Non-PoS):ponto de comunicação MIH comum PoS. Esta entidade de redenão troca mensagens MIH com oterminal móvel.

A Figura 2 apresenta uma arqui-tectura de rede, multi-operador emulti-tecnologia, incluindo as enti-dades de rede MIH. É apresentadaa rede de acesso em ambiente he-terogéneo, composta por tecnolo-gias de acesso IEEE, tais comoWiMAX e Wi-Fi, e também por tec-nologias de acesso 3GPP, neste ca-so UMTS e LTE. São também apre-sentadas duas redes de núcleo, umaresponsável por controlar as redesde acesso IEEE 802.x e outra pelasredes de acesso 3GPP.

Para além dos PoA de cada umadas tecnologias de acesso, são tam-bém demonstrados os MIH PoS,localizados nas redes de core dosoperadores.

Tal como é representado na Figura2, os MIH PoS são o primeiro pontode comunicação MIH com o ter-minal móvel. Por último, podemostambém observar o MIIS Server, ouseja o MIH Non-PoS, localizado emambas as redes de núcleo. Os MIHNon-PoS comunicam directamentecom os MIH PoS.

3.2. Mobilidade entre LTE eWiMAXDepois de termos explicado a pla-taforma IEEE 802.21, e a integraçãoda mesma numa arquitectura de re-de de operador, vamos agora apre-sentar um caso concreto de hand-over entre as tecnologias de acessoLTE e WiMAX. Na Figura 3 podemosobservar a troca de mensagens MIHentre os vários elementos de rede,nomeadamente um terminal multi-modo, com interfaces LTE e WiMAX,os MIH PoS para WiMAX e LTE e oFigura 3 – HO Inter-tecnologia (LTE -> WiMAX)

LTEWiMAX WiMAX PoS LTE PoS MIIS Server

MIH_Link_Configure_Thresholds.Req

Configuração do driver LTE comos thresholds apropriados

MIH_Link_Configure_Thresholds.Cnf

MIH_Link_Parameters_Report.Ind

MIH_Link_Going_Down.Ind

Mensagens indicativas de que apreparação do processo de HO

deverá ser iniciado

MIH_Get_Information.Req

Query ao MIIS Server sobre as tecnologiasde acesso disponíveis

MIH_Get_Information.Resp

O MIIS Server indica que existe uma redeWiMAX disponível

MIH_MN_HO_Candidate_Query.Req

MIH_N2N_HO_Query_Resources.Req

Query dos recursos disponíveisna rede WiMAX

MIH_N2N_HO_Query_Resources.Resp

MIH_MN_HO_Candidate_Query.Resp

MIH_MN_HO_Commit.Req

MIH_N2N_HO_Commit.Req

Activação dos recursos na redede acesso WiMAX

[estabelecer os Service Flows de QoS]

MIH_N2N_HO_Commit.Resp

MIH_MN_HO_Commit.Resp

MIH_MN_HO_Complete.Req

MIH_N2N_HO_Complete.Req

Fase de Execução:Estabelecimento de conectividade L2 com WiMAX.

Procedimentos do FMIP para estabelecimentode conectividade L3

Libertar os recursos na rede de acessoLTE [desactivar as ligações PDP]

MIH_N2N_HO_Complete.Resp

MIH_MN_HO_Complete.Resp

Fase de Conclusão do H

O

WiM

AX Interface

LTE Interface

Fase de Preparação do H

OFase de Iniciação do H

O

MIIS Server. Estas entidades de redeMIH foram explicadas sucintamentena secção 3.1.

Como se pode verificar, o processode mobilidade está dividido em qua-tro fases: iniciação, preparação,execução e conclusão. Durante afase de iniciação, suponhamos queo utilizador acabou de ligar o seuterminal móvel à rede de acesso LTE.No instante seguinte, o LTE PoS vaiconfigurar a interface LTE do terminal(1) com o conjunto de parâmetrosde QoS necessários para que aligação wireless satisfaça os requi-sitos pretendidos (MIH_Link_Confi-gure_Thresholds). Se, nalgum mo-mento, a ligação wireless não forcapaz de satisfazer estes parâme-tros, será despoletado um eventodo MIES pela interface LTE. A partirdeste momento, a interface LTE en-viará periodicamente informaçãosobre os seus parâmetros de QoS,ou então quando um dos valores deQoS ultrapassar o limite configurado(MIH_Link_Parameters_Report).

Quando as condições do canal rá-dio estiverem a degradar-se, e forprevisível que a ligação vai cair numdeterminado período de tempo, ainterface LTE envia a mensagemMIH_Link_Going_Down para o LTEPoS. Desta forma, a rede e o pró-prio terminal conseguem, em temporeal, obter informação sobre o esta-do da interface LTE e, se neces-sário, despoletar um processo dehandover, iniciado pelo próprio MN(Mobile Initiated Handover – MIHO)ou pela rede (Network InitatedHandover – NIHO) (2), dando inícioà fase de preparação do handover.

Nesta fase, e dado que no exemplose trata de um MIHO, o terminalcomeça por descobrir quais são asredes de acesso disponíveis à suavolta. Para obter essa informação,utiliza o MIIS e faz um query ao MIISServer (MIH_Get_Information) sobreas redes de acesso circundantes(3). É importante referir que apenasa interface LTE é utilizada neste pe-


ríodo, mantendo a interface WiMAXem modo idle para poupança deenergia. Só depois de o terminalobter informação de que existe umarede WiMAX disponível é que a in-terface WiMAX é colocada no mo-do active para efectuar o processode associação à rede WiMAX (4).

Seguidamente, o terminal verifica seexistem recursos disponíveis na re-de de acesso WiMAX (MIH_M-N_HO_Candidate_Query) que satis-façam os seus requisitos de QoS(5). Caso existam recursos disponí-veis, o terminal móvel vai iniciar oestabelecimento da reserva de re-cursos na tecnologia WiMAX (MI-H_MN_HO_Commit) (6), dando porterminada a fase de preparação dohandover. Depois de activados osrecursos necessários na rede dedestino, pode dar-se a fase de exe-cução do handover, ao nível físico eao nível IP (7).

Finalmente, depois do handover tersido executado e o terminal estar autilizar a interface WiMAX, são liber-tados os recursos na rede de aces-so que estava a ser utilizada ante-riormente (MIH_MN_HO_Complete),ou seja na rede LTE (8) – fase de con-clusão do handover.

4. Impacto para o grupo PTActualmente já existem tecnologiasde acesso wireless no mercado detelecomunicações que permitemaos utilizadores usufruírem de aces-so à Internet sem fios. No entanto,devido às limitações das tecnologiasexistentes, começam a emergir no-vas soluções desenvolvidas pelosprincipais organismos de normali-zação. Num futuro próximo, o 3GPPirá lançar para o mercado a tecno-logia LTE, uma evolução do UMTS, eo IEEE lançará a tecnologia WiMAX,ambas capazes de fornecer débitoselevados em ambientes de alta mo-bilidade e assim serem compatíveiscom os requisitos do ITU para astecnologias de acesso de quartageração. Desta forma, antevê-seque, no futuro, os utilizadores te-

nham ao seu dispor terminais multi---acesso, permitindo o acesso à In-ternet através de uma larga ofertade soluções wireless. Logo, e paraque os operadores, entre eles oGrupo PT, possam tirar o máximoproveito das diferentes soluçõesexistentes, é fundamental garantirque as diferentes tecnologias sãocapazes de coexistir e não de com-petir. Para isso, os operadores terãoque adaptar as suas redes de formaa garantir interoperabilidade entre astecnologias de acesso e, em par-ticular, garantir que os utilizadores sepodem mover livremente entre asmesmas sem interrupção dos servi-ços contratualizados com o operador.

Assim, dado tratar-se de uma so-lução independente da tecnologiade acesso, a norma IEEE 802.21terá uma importância significativa nocontexto da convergência das redestraçado pelo Grupo PT, apresentan-do-se como um factor diferencia-dor, e uma vantagem competitivaface aos seus concorrentes, forne-cendo uma solução inovadora, nor-malizada e independente da redede acesso.

5. ConclusõesDevido à proliferação no mercadode terminais móveis com várias in-terfaces de acesso, torna-se neces-sário desenvolver mecanismos quepermitam a utilização destes ter-minais em ambientes heterogéneos,garantindo mobilidade transparenteentre as diferentes tecnologias deacesso.

Neste artigo foi apresentada umasolução para viabilizar mobilidadetransparente entre diferentes tec-nologias de acesso, baseada nanorma IEEE 802.21. Esta normaestá ainda a definir a frameworkMIH, cujo principal objectivo é op-timizar os mecanismos de mobi-lidade entre diferentes tecnologias.Para isso, define uma camada deabstracção, denominado MIHF, quesepara as especificidades das tec-nologias de acesso dos protocolos

de gestão de mobilidade das cama-das superiores. Define tambéminterfaces uniformes entre as tecno-logias de acesso e as camadas su-periores, permitindo assim a inte-gração de qualquer tecnologia novaque possa aparecer no futuro.

O trabalho apresentado neste artigoencontra-se em fase de validaçãoexperimental através de um simu-lador. Resultados preliminares deum handover entre Wi-Fi e WiMAXpodem ser encontrados em [5]. Nofuturo pretende-se integrar as res-tantes tecnologias de acesso no si-mulador, designadamente UMTS eLTE. Simultaneamente, vamos tam-bém procurar investigar e proporsoluções para algumas das lacunasainda existentes no IEEE 802.21,nomeadamente a definição de ummecanismo de transporte para oprotocolo MIH e também a integra-ção efectiva das primitivas do IEEE

Pedro Neves, licenciado e Mestre em EngenhariaElectrónica e Telecomunicações pela Universidadede Aveiro em 2003 e 2006 respectivamente,encontra-se, desde 2007, a desenvolver o Douto-ramento em Engenharia Informática e Telecomu-nicações na mesma Universidade. Simultanea-mente, participa na co-orientação de alunos deMestrado de Engenharia Electrónica e Telecomu-nicações. Após a Licenciatura, tornou-se bolseirode investigação do Instituto de Telecomunicações,onde trabalhou nos projectos co-financiados pelaComissão Europeia DAIDALOS-I e II, tendo sidoresponsável pela definição de uma arquitecturapara a rede de acesso com integração datecnologia WiMAX. Em Junho de 2006 iniciouactividade na PT Inovação, no domínio das redesde acesso wireless de próxima geração all-IP,nomeadamente na especificação de mecanismospara suporte de mobilidade transparente e QoSpara as tecnologias WiMAX e 3GPP UMTS/LTE,no âmbito de projectos co-financiados pelaComissão Europeia (WEIRD e HURRICANE) e peloEurescom. É co-autor dos livros “Advances inMobile WiMAX” e “Evolving WiMAX” publicadospela Wiley, e tem mais de 25 artigos publicadosem revistas e conferências internacionais.

Francisco Fontes, licenciado em EngenhariaElectrotécnica e de Computadores, ramo deElectrónica e Telecomunicações, pelo InstitutoSuperior Técnico (Setembro de 1991) e Douto-rado pela Universidade Politécnica de Madrid(Novembro de 2000) na área de gestão distribuídade redes de telecomunicações. Em Setembro de1991 iniciou a sua actividade profissional na PTInovação (CET) tendo-se especializado em tecno-logias de rede de banda larga, especialmente nastecnologias ATM e IP. Actualmente os seusinteresses situam-se nas áreas de Qualidade deServiço em redes multi-serviço e na sua evoluçãopara arquitecturas RPG All-IP.

Isabel Borges, concluiu a Licenciatura eMestrado em Engenharia Electrónica e Telecomu-nicações na Universidade de Aveiro. Fez uma pós-graduação em Microondas na mesma Uni-versidade em colaboração com a Teka Portu-guesa, tendo leccionado aulas práticas da disci-plina de Propagação Guiada do curso deEngenharia Electrónica e Telecomunicações.Ingressou na PT Inovação em 1991 e esteveenvolvida nas áreas de Investigação Aplicada emRedes Ópticas, Prospectiva e IntegraçãoTecnológica, Tecnologias de Banda Larga,Tecnologias e Sociedade da Informação, Consul-toria e Sociedade de Informação e Gabinete deConsultoria Tecnológica da PT Inovação. Actual-mente integra o departamento de InvestigaçãoAplicada e Difusão do Conhecimento. Os seusinteresses situam-se nas áreas de Qualidade deServiço em redes IP, Peering e os desafios daevolução da Internet.

Telma Mota concluiu a Licenciatura e Mestradoem Engenharia Electrotécnica e de Computadoresna Universidade do Porto e tirou uma Pós-gra-duação em processamento de sinal na mesmauniversidade. Ingressou na empresa TLP SA, onderealizou trabalho de planeamento e dimen-sionamento de redes de comutação digital, RedesInteligentes e teletráfego. Desde 1994 que integraa PT Inovação e tem estado ligada às áreas degestão e arquitecturas de Redes e Serviços; IN,evolução da IN, TINA, Parlay e mais recentementeIMS, TISPAN e MBMS, normas 3GPP que sededicam a definir aspectos de estabelecimentode Sessões Multimédia, QoS, Mobilidade eMulticast. Participou em diversos projectosEuropeus (Eurescom e IST); actualmente, está en-volvida nos projectos Daidalos, OPUCE e é líderdo C-CAST. É responsável pela secção Plata-formas e Redes Multiserviço.

Susana Sargento (Doutoramento em EngenhariaElectrotécnica em 2003) foi docente no De-partamento de Ciências de Computadores daUniversidade do Porto de 2002 a 2004, eencontra-se desde 2004 na Universidade deAveiro e Instituto de Telecomunicações. Duranteos últimos anos tem estado envolvida em váriosprojectos nacionais e europeus, tendo respon-sabilidades de coordenação de várias actividadesnos projectos, como as actividades de Qualidadede Serviço e Integração de Redes Ad-hoc noprojecto FP6 IST-Daidalos. Os seus interesses deinvestigação centram-se nas áreas de redesheterogéneas e de próxima geração, infra-estruturadas, em malha e ad-hoc, onde tempublicados mais de 100 artigos científicos.

Referências[1] IEEE 802.21, Draft Standard for Local andMetropolitan Area Networks: Media IndependentHandover Services, IEEE P802.21/D10.0, April2008.[2] R. Koodli, Ed., Fast Handover for Mobile IPv6,IETF RFC 4068, Julho 2005.[3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A.Johnston, J. Peterson, R. Sparks, M. Handley, E.Schooler, SIP: Session Initiation Protocol, IETFRFC 3261, Junho 2002.[4] S. Gundavelli, K. Leung, V. Devarapalli, K.Chowdhury, B. Patil, Proxy Mobile IPv6, IETF draft-ietf-netlmm-proxymip6, Junho 2007.[5] P. Neves, M. Melo, S. Sargento, K. Pentikousis,Seamless Mobility in Heterogeneous Environments– Enhanced Media Independent Handover A-pproach, IEEE 69th Vehicular TechnologyConference VTC2009 Spring, Barcelona,Espanha,Abril 2008

93 Optimização dos Mecanismos deMobilidade em Redes de Próxima Geração

palavras-chave:DVB-H, DVB-SH, DVB-IPDC, Mobile TV

As tecnologias DVB-H e complementares, como abordagem para aimplementação de Mobile TV proveniente do Consórcio DVB, vão estando cada vez mais na ordem do dia.O facto de a Comissão Europeia estar a incluí-las como padrão a adop-tar na União, é disto um indicadorsignificativo.

Bernardo Cardoso

Este artigo pretende fazer um pequeno enquadramento destas tecnologias, realçando as suas vantagens, sem perder de vista asalternativas actuais, baseadas emmétodos de difusão unicast.

Roger Salgado

04


1. IntroduçãoÉ incontestável que, ao longo dos úl-timos anos, o número de serviçostradicionalmente oferecidos pelosoperadores móveis sofreu um au-mento significativo, estando hoje dis-poníveis aplicações multimédia,jogos, partilha de conteúdos, com-pras, anúncios publicitários sincro-nizados com o conteúdo, venda/alu-guer de conteúdos multimédia –música/vídeos, etc.

É hoje habitual encontrar terminaismóveis dotados de um vasto núme-ro de tecnologias como cartões dememória, Bluetooth, câmaras foto-gráficas, entre outros. Questões co-mo portabilidade, personalização,estar online e aceder aos conteúdosa pedido são, hoje em dia, factorescruciais e determinantes na escolhados consumidores.

A televisão, quer seja no seu forma-to mais puro e linear, quer em novosformatos em que é o espectadorque determina o que quer ver emcada momento, não podia ficar a-fastada deste nova montra móvel.Deste modo, os operadores fizeram

um esforço no lançamento de ser-viços de televisão móvel digital (Mo-bile TV) que vêm, de uma forma na-tural, satisfazer uma procura que seprevê exponencial, visto que se es-tima um mercado potencial de maisde 335 milhões de utilizadores emtodo o mundo em 2011 [1].

2. Televisão móvelA televisão móvel consiste na difu-são de programas televisivos digitaise serviços associados para um con-junto alargado de terminais sem fios,incluindo telemóveis e PDA, capa-zes de receber e exibir sinal de tele-visão. Estes dispositivos caracteri-zam-se por possuírem dimensõesde ecrã pequenas, capacidade deprocessamento reduzida e autonomiaenergética muito limitada.

De uma forma geral, existem duasabordagens diferentes para a entre-ga dos conteúdos de Mobile TV, omodo broadcast e o modo unicast.Esta dicotomia resulta de existiremdois tipos de operadores a preco-nizarem soluções de Mobile TV, ostradicionais operadores de televisão(broadcasters) e os operadores de

redes móveis. Cada uma destasabordagens surge da evolução datecnologia já detida pelo operadorenvolvido e apresenta um conjuntode vantagens e desvantagens quedevem ser tidas em linha de conta.

Os serviços actuais de Mobile TV,disponibilizados nas redes móveisde terceira geração (3G), recorremao modo unicast, onde apenas osutilizadores que requisitem o conteú-do recebem o sinal. O modo broad-cast, por sua vez, é primordialmenteutilizado para difusão de televisãomóvel nas redes de satélite e terres-tre, onde são empregues tecnolo-gias distintas tais como DVB-H, T-DMB (Coreia), 1-SEG ISDB-T(Japão)/SBTVD (Brasil), MediaFLO(EUA), entre outras.

Como tecnologia de broadcast, oDVB-H (Digital Video Broadcast –Handheld) fornece serviço a um nú-mero ilimitado de utilizadores e é indi-cado para a difusão de um serviçotelevisivo universal, visto não apre-sentar qualquer limitação em termosdo número de utilizadores que po-dem ser servidos simultaneamente.

DVB-H, DVB-SH e DVB-IPDC:Tecnologias DVB para o Mobile TV

95

As tecnologias de transmissão uni-cast, por sua vez, estão desenhadaspara a entrega de conteúdos ponto--a-ponto, a pedido dos utilizadores,e baseiam-se na criação de umaligação virtual dedicada, possuindo li-mitações óbvias de escalabilidade(número máximo de conexões unicastnuma célula). O MBMS (MultimediaBroadcast/Multicast Service) apare-ce, neste contexto, para dar suporteà difusão nas redes 3G e permite em-pregar também nestas o modobroadcast/multicast, no qual todosos utilizadores, ou um grupo de uti-lizadores, podem receber o mesmosinal, aumentando significativamentea escalabilidade do serviço.

Existe hoje uma miríade de testes ede plataformas comerciais à volta deMobile TV que recorrem a ambos osmodos de difusão, mas tendo emconta o enquadramento legal na Eu-ropa, nomeadamente a adopção dostandard DVB-H pela ComissãoEuropeia para a difusão de televisãomóvel, este artigo irá focar-se sobre-tudo na arquitectura DVB-H e nor-mas paralelas como o DVB-SH e oDVB-IPDC.

3. Tecnologia DVB-HA norma DVB-H, para transmissãode Mobile TV no modo broadcast,foi desenhada para reutilizar a mes-ma gama de frequências (VHF/UHF)e infra-estruturas que o DVB-T (Di-gital Video Broadcasting - Terres-trial), o que permitiria a transmissão

simultânea de sinais de TDT e deMobile TV. Esta reutilização do es-pectro poderá ser crucial, pois até2012, ano previsto para a cessaçãodas emissões de televisão analógica(Analog Switch-Off), existe grandelimitação na utilização deste tipo defrequências.

O DVB-H nasce assim como umaextensão da especificação DVB-T eencontra-se largamente dissemina-do na Europa, na Ásia e noutros paí-ses do mundo. A norma preconizaalgumas modificações à especifica-ção original do DVB-T, sobretudopara ser adaptada à realidade dosterminais móveis e às suas limitaçõestecnológicas. Este tipo de dispositi-vos, operados por energia fornecidapor baterias (que é necessário pre-servar), possui tipicamente antenasinternas de baixo ganho e pouca ca-pacidade de processamento, peloque se deve reduzir, tanto quantopossível, a complexidade do sistema.

Sendo o DVB-H uma tecnologia debroadcast terrestre, pode recorrer atransmissores de alta potência (comum raio de actuação de 30 km oumais), apresentando a vantagem po-tencial de servir terminais móveis,mesmo quando estes se encontramno interior de edifícios e/ou usam an-tenas internas de dimensão redu-zida. Como o DVB-H usa a mesmacamada física do DVB-T, e mantéma compatibilidade com o MPEG-2Transport Stream, pode partilhar


com este os mesmos transmissorese moduladores OFDM.

A compatibilidade, ao nível físico,perde-se no entanto se se preten-der tirar partido das novidades intro-duzidas pelo DVB-H, nomeadamen-te, a adição do modo de transmissãocom FFT de 4K (para além das es-pecificadas no DVB-T de 2K e 8K),que pretende minorar problemas re-lativos aos desvios na frequência,normalmente associados à recep-ção em movimento a velocidades re-lativamente elevadas (efeito de Dop-pler) ou o novo modo de utilização dointerleaver, que permite uma maior to-lerância ao ruído impulsivo.

No entanto, as características maisinteressantes da tecnologia DVB-Hsão perfeitamente compatíveis como DVB-T. Por exemplo, a técnicadesenhada para permitir reduzir oconsumo de energia nos terminais,conhecida como Time-Slicing, pos-sibilita que o terminal desligue a ali-mentação da componente rádio doreceptor até 95% do tempo [2], semqualquer perturbação do vídeo exi-bido. Tendo ainda a vantagem a-crescida, de permitir uma mudançade célula por parte do receptor, per-feitamente transparente, já que operíodo em que não são transmi-tidos dados do serviço a que se estáligado (off_time) pode ser usado pa-ra monitorar o nível de potênciadas células adjacentes e permitiruma mudança automática e sem

Figura 1 – Comparação entre os vários serviços de Mobile TV

Tecnologia

DVB-H FLO T-DMB MBMS S-DMB

Classificação

Interface rádio

Organismo denormalização/Empresa

Capacidade efectiva

Tec. de redução de consumo

Bandas de Frequência

Tempo médio de comutaçãode canal

Autonomia média

Broadcast

DVB-T, COFDM

DVB-T

9 Mbps/ canal de 8 MHz

Time-Slicing

UHF, banda L (EUA)

~5segundos

~4 horas

Broadcast

CDMA

Qualcomm

Code selection

700 MHz (EUA), UHF, banda L

~1,5 segundos

~4 horas

Broadcast

TDAB, COFDM

ETSI, DAB Forum

1Mbps / canal 1,54 MHz

Time demultiplexing,selective FFT

VHF, UHF

~1,5 segundos

~2 horas

Broadcast

UTRA WCDMA

3GPP

384 Kbps / canal 5 MHz

Code selection

IMTS 2000

~1,5 segudos

~4 horas

Broadcast

CDMA Proprietário

ETSI

6 Mbps / canal 25 MHz

Code selection

Banda S (Coreia), IMTS2000 (Europa)

~5 segundos

~1,5 horas

DVB-H, DVB-SH e DVB-IPDC:Tecnologias DVB para o Mobile TV

97

nenhuma alteração detectável peloutilizador.

A técnica do Time-Slicing recorre aum método relativamente simples,em vez de elaborados esquemas deagendamento ou de divisão de tem-po. Na prática, no cabeçalho de ca-da rajada (burst) vai sinalizado o mo-mento de transmissão da próximarajada, permitindo desta forma aoemissor variar, quer o tamanho dasrajadas, quer o tempo de off_time, deuma forma completamente dinâmica.

A utilização desta técnica traduz--se, todavia, num ligeiro aumentodo tempo de sintonização dos ca-nais (ou do tempo de comutação deum canal para outro), pois, para tirarintegral partido deste método detransmissão, pode ser necessário es-tar alguns segundos sem transmitirum dado serviço.

Contrariamente ao que sucede comas difusões TDT, no caso do DVB-H,deve ser tido em linha de conta onível de sinal considerado aceitável,particularmente em ambientes in-door, aquando do dimensionamentodo número de antenas transmis-soras e repetidores, isto porque apotência de transmissão tem de sermaior que no caso da TDT. Tal de-ve-se ao facto de os terminais DVB--H possuírem, normalmente, an-tenas de menor ganho, não fixas ecolocadas ao nível do solo, ao con-trário do que acontece em DVB-T.

Para obter uma melhoria significa-tiva do nível de sinal adicionaram--se mecanismos robustos de cor-

recção automática de erros de trans-missão, permitindo assim superar aimprevisibilidade das condições derecepção em ambientes móveis,sendo que estes mecanismos vãopara além das técnicas de FEC (For-ward Error Correction) já existentesao nível da modulação física (DVB-T).Como o DVB-H recorre a tecnolo-gias IP que são transportadas emMPE (Multi Protocol Encapsulation)sobre MPEG-2 TS, a redundância éadicionada em paralelo com os pa-cotes IP ao nível do MPE, daí deno-minar-se MPE-FEC.

Ensaios laboratoriais e teste de cam-po permitiram validar a utilização doMPE-FEC como forma eficaz de me-lhorar a recepção de DVB-H, mes-mo em situações de recepção a ele-vada velocidade, permitindo ganhosde até 9dB em relação à utilizaçãoda correcção de erros, providenciadaapenas pelo DVB-T [2], isto sem one-rar a normal transmissão de TDT noscasos em que a difusão seja conjunta.

4. Arquitectura DVB-HConforme anteriormente referido, oDVB-H socorre-se das tecnologias einfra-estruturas desenhadas para oDVB-T, partilhando muito dos com-ponentes, mas, ao contrário deste,não usa directamente o sistema detransporte MPEG-2 TS, usa em seulugar um sistema de difusão em pa-cotes IP, que são encapsulados emsecções MPE, e estas finalmente é quesão transportadas sobre MPEG-2 TS.

O vídeo é normalmente codificadoem MPEG-4 Parte 10/AVC/H.264,o que permite a difusão de resolu-

ções CIF a débitos baixos (384Kbpsou menos). Quer a resolução, quero frame rate podem ser ajustadoscom vista a atingir os débitos detransmissão desejados pelo opera-dor, sendo também permitida a uti-lização de outros codecs, que não oMPEG-4/AVC, por exemplo o VC-1(versão normalizada do WindowsMedia Video).

Em termos da componente especí-fica DVB-H, é normal a utilizaçãodum encoder por fluxo de serviço.Este equipamento faz a digitalizaçãodos sinais de vídeo e áudio e colo-ca-os numa rede sob a forma de pa-cotes IP, os quais são posteriormen-te multiplexados por um switch IP eencaminhados para um encapsu-lador IP cuja função é combinar emslots temporais (Time-Slices) osvários fluxos, bem como informaçãode sinalização e serviços adicionais,(por exemplo o ESG – ElectronicService Guide) num fluxo de paco-tes IP. É também o encapsulador IPque introduz a correcção automáti-ca de erros multi-protocolar (MPE-FEC), permitindo uma maior imuni-dade a perturbações na recepção.A saída do encapsulador IP é entãoconectada a um modulador COFDMque modula o sinal DVB-H numa por-tadora.

Conforme se pode ver na Figura 3,é possível misturar na mesma por-tadora serviços DVB-H e DVB-T,desde que se usem apenas os mo-dos de transmissão compatíveis, istoé, não se pode usar o modo 4K, nemo interleaver melhorado.

A par com as melhorias já referidasao nível da transmissão, o DVB-H foidesenhado para ter em conta as di-mensões dos terminais móveis e osseus requisitos em termos de capa-cidade de processamento e auto-nomia. Para cada tipo de utilizaçãoprevisível foram definidas classes dedispositivos e respectivos limites emtermos de dimensão de imagem,framerate e bitrate, o que descarta anecessidade do terminal ter de adap-

Figura 2 – Exemplo de Time-Slicing

BurstDuration

Bur

st S

ize off_time

400Kbits/s average

14 Mbit/s

500 ms


tar o formato do conteúdo recebidopara a sua resolução nativa, au-mentando bastante a eficiência, querem termos de performance, quer emtermos de consumo de bateria. Pe-los mesmos motivos, a própria com-plexidade das normas de codifica-ção de vídeo e áudio foi tambémdeliberadamente reduzida.

5. DVB-IPDCPara além das extensões à normaDVB-T acima expostas, o DVB-Hintroduz a noção de um sistema dedifusão de televisão suportado emtecnologias IP, o que representauma inovação significativa em ter-mos das normas de televisão digitaltradicional. Daqui resulta a neces-sidade de especificar um novo sis-tema de criação de serviços de TVbaseado em IP. É neste contexto queaparece o DVB IP datacasting, ouDVB-IPDC, que consiste num con-junto de especificações, desenvol-vidas pelo Projecto DVB, e quedefinem os componentes necessá-rios para a criação de um sistema co-mercial completo assente numainterface IP e que permite aos utili-zadores acederem aos programasdifundidos e utilizarem serviços decomunicações móveis de forma inte-grada num único terminal. Estanorma foi especificada tomando porbase a camada física do DVB-H edas redes 3G. Combina portantocaracterísticas das redes de difusãotípicas do DVB-H, com os canaisde retorno bi-direccionais ofereci-dos pelas redes 3G. Embora tenhasido projectado a pensar no DVB-H, o DVB-IPDC não se limita, noentanto, a essa utilização e podeser empregue em todos os outrossistemas DVB de difusão de MobileTV, tal como é o caso do DVB-SH.

No IPDC são preconizadas duasformas de envio de informação:streaming em tempo real, onde seincluem os fluxos de vídeo e/ou áu-dio, entre outros, e através de fichei-ros. Para o caso da entrega sincro-nizada de conteúdos em tempo real,emprega o protocolo RTP, sendo a

transferência de ficheiros levada acabo recorrendo a um carrossel dedados e ao protocolo FLUTE/ALC.

O tipo de informação transportadapode ser separada em duas cate-gorias: informação que se refere aosconteúdos multimédia, e para a qualnão existe qualquer restrição sobreo tipo de conteúdos que podem sertransportados (vídeo, áudio, HTML,XML, etc.), e informação de sina-lização PSI e ESG. Poderá ainda sertransportada informação de gestãode direitos e acesso condicional.

Os métodos de codificação de con-teúdos que podem ser utilizados notransporte via streaming são espe-

cificados pela ETSI TS 102005.Esta norma impõe que no caso dovídeo sejam utilizados dois codecs,o MPEG-4 H.264/AVC e o VC-1(Windows Media Video), sendo oH.264 o codec recomendado. Nocaso do áudio, a mesma norma pro-põe o MPEG-4 HE AACv2 como ocodec a seguir e o AMR-WB+ comoalternativa.

A camada IP datacasting permiteque a informação, encapsulada empacotes IP possa ser difundida atra-vés da camada física DVB-T/H, re-correndo à pilha protocolar UDP/IPao nível da camada de rede (nível 3 eseguintes do modelo OSI) e MPE ao

Figura 3 – Arquitectura de um sistema de difusão DVB-H.

Figura 4 – Pilha Protocolar DVB-IPDC

MPEG-2TVSERVICES

DVB-T MuxTRANSMITTER

DVB

AntennaDVB-TModulator

DVB-H IP Encapsulator

Video AudioStreaming Server

Live TV

Mpeg-4 TV

ApplicationsFLUTE/ALC RTP HTTP

TCPUDP

IP

GSM, GPRS, UMTS

Interactive NetworkBroadcast Network

PSI/SI MPE MPE-FEC

MPEG-2 TS

DVB-H Radio Layer

RTP

IP

UDP

Basic DVB-HSystem

99 DVB-H, DVB-SH e DVB-IPDC:Tecnologias DVB para o Mobile TV

nível da camada de ligação de dados(nível 2 do modelo OSI).

Uma vez que cada elementary streampode transportar mais do que um flu-xo IP, a distinção de cada fluxo IP éfeita tendo por base o destino dosdatagramas IP (endereço e porto).Para além disso, o IPDC adiciona anoção de rede IP a uma plataformaDVB e determina que os endereçosde destino devam ser únicos dentrode uma mesma rede.

A solução apresentada pelo IPDCpara a implementação do ESG, istoé, do serviço que define o alinha-mento de canais e respectiva pro-gramação, baseia-se num modeloXML, que pode estar sujeito a com-pressão opcional (GZIP, BiM). Estesdados são encapsulados em frag-mentos que depois são entreguesvia protocolo FLUTE.

6. DVB-SHPara contornar os problemas ine-rentes à construção de uma infra--estrutura de Mobile TV com ele-vada cobertura, tanto em ambientes

indoor como outdoor, bem como pa-ra garantir um modelo de negócio ba-seado num valor de subscrição men-sal atractivo e num serviço de boaqualidade, foi especificada uma so-lução de difusão de televisão móveldigital híbrida (satélite – terrestre) de-nominada DVB-SH (Figura 5).

A especificação DVB-SH tira provei-to da rede de satélites geostacio-nários para a difusão de sinal deMobile TV com taxas de coberturabastante alargadas. Isto permite aredução dos custos das infra-estru-turas que seriam necessárias edi-ficar para um mesmo grau de co-bertura e também reduzir o temponecessário para iniciar a comercia-lização do serviço. Por outro lado,em zonas urbanas, o DVB-SH per-mite combinar a solução de satélitecom a retransmissão do sinal porrepetidores terrestres de baixa po-tência, que podem coabitar com asestações de difusão de TV terrestreactuais. Como resultado, o sistemapossibilita manter um elevado nívelde qualidade de serviço em ambi-

entes indoor, visto que o sinal desatélite original sofrerá uma forteatenuação devido aos obstáculosque terá de transpor, sendo nestecaso compensado pelo sinal retrans-mitido.

Portanto, o sistema assenta numasolução combinada onde os sinaissão difundidos para os terminaismóveis por dois caminhos distintos:directo, via satélite; e indirecto, atra-vés das estações terrestres de re-transmissão. A solução opera na ga-ma de frequências 2170-2200 MHz(banda-S), que se encontra alocadadesde 1992 para ser utilizada emserviços móveis via satélite.

Existem dois modos de transmis-são possíveis:

> Recorrendo à modulação OFDMpara ambos os caminhos, de for-ma similar ao que acontece como DVB-H (com alguns melhora-mentos). Em ambientes de SFN,os sinais directo e indirecto sãoentão combinados no receptorpara se obter uma melhor relação

Figura 5 – Arquitectura DVB-SH.

RuralAreas

UrbanAreas User

terminal

DVB-SHin MSS band

2G or 3Gaudio interface

Cellularnetwork

Terrestrialrepeaters

DVB-S2in FSS band

Mobile TVServiceplatform

Broadcaststation

SpaceSegment

DVB-SHin MSS band


sinal ruído;

> Utilizando uma combinação deTDM no caminho directo e OFDMno indirecto. Esta combinaçãopossibilita uma maior robustez aproblemas de transmissão, sobre-tudo nas áreas suburbanas e temespecial interesse em sistemas desatélite com potência do sinallimitada, mas requer mais espectro,sendo portanto, menos atractiva.

Tal como no DVB-H (versão terres-tre), inúmeros testes foram e estãoa ser levados a cabo, atestando obom desempenho deste sistemahíbrido.

7. ConclusõesO DVB-H, e normas complementa-res, apresentam-se como uma so-lução viável para a construção de umserviço de Mobile TV completo eatractivo, podendo ser associadas àcriação de uma infra-estrutura deTDT, para daí retirar sinergias impor-tantes ou ser implementada de persi e permitir uma melhor optimizaçãopara um cenário exclusivamente mó-vel. Neste caso, o DVB-H pode serassociado a uma difusão híbrida DVB-SH para permitir uma potencial redu-ção de custos, com um acréscimosignificativo da área de cobertura.

As principais desvantagens são aslimitações em termos de espectrodisponível, que se vão manter, pelomenos até 2012, e alguma falta dedisponibilidade de equipamentosterminais. Ambas as limitações têmuma influência expressiva na actualmanutenção dos sistemas de Mo-bile TV no modo unicast.

Em termos dos serviços de MobileTV, actualmente, os operadores detelecomunicações tradicionais, e emespecial o Grupo PT, encontram-seperante uma encruzilhada. Se porum lado já possuem licenças paradifusão de Mobile TV nas bandasde espectro 3G, tanto em modounicast, como recorrendo a MBMS;por outro, podem ainda necessitar

de se posicionar como operadoresDVB-H, seja por imposição legal,seja para se precaverem contra aentrada no mercado de operadoresde televisão móvel dissociados dassuas próprias redes e operações.

Referências[1] An EU Strategy for Mobile TV – FrequentlyAsked Questions,http://europa.eu/rapid/pressReleasesAction.do?reference=MEMO/07/298[2] G. Faria, J. A. Henriksson, E. Stare, and P.Talmola, DVB-H: Digital Broadcast Services toHandheld Devices, Proc. IEEE, vol. 94, no. 1, pp.194-209, Jan. 2006.[3] Borko Furht e Syed Ahson, Handbook of MobileBroadcasting, 2008[4] Amitabh Kumar, Focal Press Media TechnologyProfessional, Mobile TV, 2007[5] Estratégia da Comissão Europeia para MobileTV na Europa,http://europa.eu/rapid/pressReleasesAction.do?reference=IP/07/1815

Roger Salgado, licenciado em Engenharia deElectrónica e Telecomunicações pela Universidadede Aveiro. Iniciou o seu percurso profissional noInstituto de Telecomunicações, Pólo de Aveiro,como investigador de redes de telecomunicações,nomeadamente na gestão da qualidade de serviçoem redes IP. Fez parte da equipa deExperimentação e Selecção de Tecnologias –Tecnologias Multimédia (EST4) e da equipa dedesenvolvimento do departamento de Expe-rimentação Tecnológica e Difusão de Conhe-cimento - Tecnologias Multimédia (ETC4) da PTInovação. Actualmente integra o grupo deInvestigação Aplicada e Difusão do Conhecimento- Televisão digital e serviços IPTV, onde participano desenvolvimento de soluções de TV interactiva,Vídeo-on-Demand e Mobile TV.

Bernardo Cardoso é licenciado em AuditoriaContabilística e Mestre em Gestão da Informaçãopela Universidade de Aveiro. Na sua actividadena PT Inovação tem estado envolvido em váriosprojectos relacionados com televisão e vídeodigital, com particular enfoque em sistemasbaseados em MPEG e DVB, nomeadamentesistemas de transmissão de televisão digital einteractividade. Esteve fortemente envolvido noprojecto de Televisão Digital Interactiva da TVCabo, ao nível do desenvolvimento de aplicações,conteúdos, testes e análise de desempenho. Maisrecentemente, e como responsável pela Divisãode Televisão Digital e Serviços IPTV, tem estadoligado às tecnologias associadas ao IPTV econtribuído ao nível da customização e do desen-volvimento de aplicações no serviço MEO.

palavras-chave:XML, SOA, AJAX, Network Activator

Pretende-se com este artigo abordara importância da monitoria de desem-penho em redes de telecomunica-ções. Foca-se em particular o contexto do cluster NetB@nd, apresentandoa implementação adoptada. Demonstra-se que o mecanismo de recolha

Pedro Franco(Withus)

usando HTTP+XML apresenta o melhor compromisso entre escalabilidade, flexibilidade e ocupação derecursos em cada elemento de rede.

Nuno Farinha

01Recolha de Desempenho de Equipamentos

de Rede no Âmbito do Cluster NetB@nd

Recolha de Desempenho de Equipamentosde Rede no Âmbito do Cluster NetB@nd

101


1. IntroduçãoA monitoria do desempenho de umarede de telecomunicações tem umpapel essencial na sua gestão. A in-formação obtida e analisada permite,não só, o melhor aproveitamento dosrecursos, como também a antecipa-ção e resolução de eventuais proble-mas. Em suma, o planeamento e ma-nutenção da rede.

A constante evolução de normas eprotocolos de comunicação conduzà coexistência, na mesma rede, deuma grande variedade de tecnolo-gias (PDH, SDH, ATM, etc.). Comoresultado, o sistema de monitoriadeve ser capaz de englobar e proces-sar uniformemente essa variedade.

Como resposta a estes requisitostêm sido criadas normas internacio-nais para recolha de dados de mo-nitoria (RMON1 [1] [2], RMON2 [1],por exemplo), com o fim de definiras métricas mais importantes parafazer a medição do desempenho ecapacidades de uma rede.

Estes dados podem ser gerados emelementos de rede, probes, espe-cialmente vocacionados para essa

tarefa. Neste caso, deve ser feito umplaneamento prévio da rede paradeterminar os pontos mais indicadospara análise do tráfego, uma vez quenesta topologia apenas algumaszonas da rede são monitorizadas.Em alternativa, podem-se dotar to-dos os elementos de rede com a ca-pacidade de analisar tráfego. Estasolução permite a abrangência totalda rede e maior selectividade a pos-teriori por parte do operador. No en-tanto, requer maior ocupação de re-cursos da rede (volume de dados,processamento dos elementos derede, etc.).

2. Case studyNo contexto do cluster NetB@ndoptou-se pela segunda topologia,respondendo de forma eficiente àsquestões de volume de dados gera-dos e o processo de os recolher.

O processo exige que cada elemen-to de rede (equipamento) seja capazde disponibilizar uma interface derecolha dos dados gerados. A me-lhor forma de responder a este de-safio passa por adoptar o conceitoSOA [3] na rede. Na base desta

arquitectura estão dois actores: oservidor e o cliente. Sendo o serviçoa disponibilização de dados de mo-nitoria, o servidor é o equipamentocapaz de gerar e disponibilizar os da-dos e o cliente o módulo de recolhae análise.

Foram identificadas na solução trêssecções distintas (Figura 1), cadaqual com as suas particularidadese desafios:

> O equipamento: concebido para ofornecimento de serviços de rede.O processo de geração de dadosde monitoria deve ocupar umafracção residual dos recursos deprocessamento e memória dispo-níveis;

> O gestor: entidade centralizada, comcapacidade de processamento ememória muito superior aos equi-pamentos de rede, controla o me-canismo de recolha e análise dosdados;

> O canal de comunicação: deve seragnóstico relativamente aos da-dos que transmite e flexível face

Figura 1 – Representação dos componentes da arquitectura

Canal de Transmissão

Gestor/Agora NG

Network Activator

Equipamento /Elemento de rede

WebTI

Equipamento /Elemento de rede

Equipamento /Elemento de rede WebTI

WebTI

FTP

HTTP

/XML

HTTP/XML

às evoluções no formato e proto-colo de transferência.

A clara distinção destas secçõespermite evolução e optimização decada bloco, sem interferir drastica-mente nos restantes.

2.1. EquipamentoDo ponto de vista do equipamentoexistem dois grandes desafios: a for-ma de armazenamento dos dadose a forma de recolha. A primeira deveseguir dois vectores: a codificação dosdados e o suporte destes em meiofísico. A forma de recolha está inti-mamente ligada à interface protocolardisponibilizada pelo equipamento.

A adopção de normas internacio-nais permite a codificação mais ho-mogénea (diferentes tecnologiaspodem ser codificadas na mesmanorma), eficiente (próxima do forma-to pretendido no utilizador final) eatemporal (probabilidade reduzidade ser alterada ao longo do tempo).

Quanto ao suporte físico, este estámais dependente dos recursosdisponibilizados pelo equipamentode rede. Em particular, foi necessá-rio avaliar, em cada caso, o uso dosistema de ficheiros ou memória vo-látil. Apesar de ser um armazena-mento simples com persistência dedados, o sistema de ficheiros temacessos de escrita e leitura mais len-tos. Pelo contrário, a memória volátil,apesar de não persistente, apresen-ta acessos rápidos, não sequenciaise mais granulares (filtragem a regis-tos isolados). Adicionalmente, a exis-tência de uma camada mediadorapermite armazenar os dados em for-mato binário (menor redundância).Cabe à camada mediadora transfor-mar estes dados num formato maisflexível e uniforme.Os dados podemser recolhidos por protocolo FTP(associado à transferência exclusivade ficheiros) ou protocolo HTTP (u-sado genericamente para transfe-rência de dados, não necessaria-mente f i che i ros ) . O uso doprotocolo HTTP não aumentou a o-

cupação de recursos do equipa-mento, uma vez que passou a serum serviço base para suporte daaplicação de gestão local WebTI.

2.2. GestorDo ponto de vista do gestor, existemdois clientes típicos com requisitospróprios no contexto dos dados demonitoria. O gestor central, mediadopelo NetworkActivator (NA) [4], acedede forma sequencial não repetitiva eexclusiva ao equipamento (os mes-mos dados não devem ser recolhi-dos mais do que uma vez).

O gestor local, integrado na apli-cação WebTI, pode aceder de formanão sequencial e concorrente a to-dos os dados armazenados no equi-pamento (vários utilizadores podemligar-se simultaneamente ao mesmoequipamento).

A gestão central pode integrar ummódulo responsável pela execuçãodo processo de recolha de dados demonitoria. Este módulo é implemen-tado com a tecnologia J2EE, sendoindependente da plataforma ondecorre a gestão central e permitindo aescalabilidade necessária para esteprocesso. Todos os elementos de re-de geridos são inventariados, sendopossível a programação do períodode recolha para cada família de equi-pamentos, bastando para isso alterara configuração de alguns parâmetros,sem qualquer necessidade de inter-romper o processo.

O NA é uma plataforma de activaçãode serviços ou recursos, especificadae implementada pela PT Inovação.Para a activação de serviços é dispo-nibilizada uma interface genérica on-de, através do envio de RFS (Resour-ce Facing Services), mensagens emformato XML que definem o pedidodo cliente, se especificam os recursosque se pretendem usar e a forma deos usar ou configurar.

É possível, através da aplicação detransformações XSLT [5] configurara forma como determinado recursoé usado dentro do NA, escolhendo,

Recolha de Desempenho de Equipamentosde Rede no Âmbito do Cluster NetB@nd

103

por exemplo, o protocolo de trans-ferência de dados a usar para umdeterminado tipo de elementos derede. Da mesma forma, é possívelconfigurar o formato da resposta aum determinado serviço, tornandoeste processo bastante flexível.

A arquitectura do NA permite quetodas estas alterações sejam feitasem tempo real, não requerendo qual-quer paragem no processo. Destemodo, apenas alterando a trans-formação XSLT de entrada ou saídado NA, é possível fazer alteraçõesmais ou menos complexas, tanto noacesso ao equipamento (alterar oprotocolo de transferência dosdados, por exemplo), como na for-matação das respostas, respec-tivamente.

No contexto da gestão local existeuma aplicação web de gestão emcada elemento de rede. Um dos prin-cípios da aplicação é a proximidadeao equipamento. Como tal, no domí-nio da monitoria de tráfego, o utiliza-dor desta aplicação pretende obser-var todos os dados existentes nopróprio.

Criada com a prioridade de fornecerao cliente uma ferramenta de gestãolocal de um elemento de rede, aconcepção desta aplicação web teveem consideração aspectos como:

> facilidade de utilização: menussimples e arquitectura tabular;

> responsividade comparável a umaaplicação de desktop comum.

No desenvolvimento da aplicação, oAJAX [6] foi um conceito essencialpara o sucesso da mesma. Natural-mente, a inclusão do módulo de lei-tura de dados de monitoria iria usara mesma tecnologia. No entanto, a-presenta um novo desafio: o volumede dados transmitidos ultrapassa fa-cilmente qualquer outro dos módulosjá existentes na aplicação. Este mó-dulo tem um papel importante na re-colha por HTTP, sendo o responsá-vel por transformar os dados binários


(armazenados no elemento de rede)em dados XML e garantir a persis-tência de sessões necessária ao NA.

2.3. Canal de transmissãoO canal de transmissão é a pedra an-gular do processo: a codificação dosdados e o protocolo onde assenta de-terminam fortemente as funcionalida-des por si disponibilizadas. A adopçãodo protocolo HTTP e a codificação dedados em XML acrescentaram flexi-bilidade e funcionalidades que o pro-tocolo FTP não proporcionava. Noservidor HTTP optou-se por usarprocessos de interpretação de co-mandos/pedidos simples (uso destrings de formato proprietário e/ouXML em parsers SAX [7]). No enviode dados deu-se primazia ao forma-to XML por duas razões: mais re-dundante que o formato binário, masmais estruturado (útil em situaçõesde debug), e muito flexível a evolu-ções sem perda de compatibilidadecom versões mais antigas. A tecno-logia XML permite o uso do parserDOM [5] com a tecnologia XPath [5](nos clientes), muito eficaz em pro-curas e filtragens dos dados. Paraatenuar o efeito redundante do XML,foram considerados alguns pontosna definição do schema de dadosde monitoria. A dimensão das tagsfoi reduzida ao mínimo essencial parareduzir o volume de informação trans-mitido. Optou-se, sempre que possível,pelo uso de atributos em detrimentodos elementos: redução do overheade maior eficiência no parser (o proces-samento do valor de um atributo émais eficiente do que o valor de um ele-mento, principalmente em parsers SAX).Para garantir a escalabilidade do pro-cesso introduziu-se um mecanismode paginação dos dados. Com estemecanismo é possível o cliente se-leccionar quais os dados que desejaconsultar.

Na aplicação WebTI, o conceito depágina é transportado para a esferado utilizador na medida em que numapágina web, ele vê uma tabela comuma fracção dos dados e é-lhe pos-sível navegar para os dados mais an-

tigos ou mais recentes; portanto oacesso às páginas pode ser não se-quencial (o utilizador pode aceder àpágina 10, por exemplo, saltando to-das as anteriores).

No NA, o conceito de paginação édiferente. Existe apenas para reduziro volume de dados, pois o acesso égarantidamente sequencial. Em cadapedido, o NA deseja apenas recolheros registos mais recentes após osúltimos recolhidos. Uma vez reco-lhidos com sucesso, não volta a pedi--los ao equipamento.

3. Importância destes sistemaspara o negócio da PTUm sistema de monitoria permite adetecção precoce de anomalias narede, logo maior eficiência na resolu-ção de problemas. Adicionalmente, a

partir da análise dos dados reco-lhidos, é possível avaliar o uso da re-de tanto no domínio espacial, comotemporal, permitindo o planeamen-to da sua evolução e crescimento.Deste modo, a recolha da monitoriade desempenho permite disponibili-zar ferramentas de análise úteis aooperador.

Porque as redes têm apresentadocrescimento acelerado, estes siste-mas devem ser de fácil escalabili-dade, rápida transferência de dadose baixa ocupação dos recursos dosequipamentos de rede.

Mostra-se nas figuras 2 e 3 a dimen-são dos dados transferidos, proces-sados e analisados numa rede real,no contexto de um operador de redemóvel.

Figura 2 – Análise semanal do número de amostras processadas

Figura 3 – Distribuição do número de amostras diárias por norma

105 Recolha de Desempenho de Equipamentosde Rede no Âmbito do Cluster NetB@nd

4. ConclusãoConclui-se, neste artigo, que na so-lução com o armazenamento de da-dos feito em memória volátil, a reco-lha sobre o protocolo HTTP com osdados codificados em XML, e agre-gados com o mecanismo de pagi-nação, apresenta vantagens face àsolução com recolha FTP.

O uso da memória volátil acelera oprocesso de geração e armazena-mento de dados no equipamento.

A utilização da tecnologia HTTP+XML permite usufruir das poten-cialidades de processamento no ser-vidor. A existência de uma camadaintermédia possibilita o processa-mento e transformação em XML. OXML traz uma maior elasticidade aoprotocolo, facilitando a sua evolu-ção e uniformização.

O mecanismo de paginação surgecomo resposta à necessidade detransferir grandes volumes de da-dos (observe-se o caso dos dadosATM (figura 2 e 3), onde o volumede dados é muito superior às res-tantes normas suportadas), acom-panhando a complexidade dos e-quipamentos de rede. A recolha porHTTP+XML apresenta o melhorcompromisso dos dois mecanis-mos abordados.

Referências[1] William Stallings "SNMP, SNMPv2, and RMONPractical Network Management,Second Edition" Addison-Wesley ProfessionalComputing and Engineering 1996[2 ] h t tp : / /www. ie t f .o rg / r fc / r fc2819. tx t[3] http://en.wik ipedia.org/wik i/Serv ice-oriented_architecture[4] Network Activator - Plataforma de Activaçãode Serviços /Recursos, documentação SoluçõesOSS, PT Inovação[5] www.w3.org[6] http://en.wikipedia.org/wiki/AJAX[7] http://www.saxproject.org/

Nuno Farinha, licenciou-se em Engenharia deElectrónica e Telecomunicações na Universidadede Aveiro em 2006. Na PT Inovação desdeSetembro desse ano, tem colaborado nodesenvolvimento de soluções de gestão local (noactual DSR1) para os equipamentos desenvolvidosno âmbito do Cluster NetB@nd.

Pedro Franco, licenciado em EngenhariaElectrónica e Telecomunicações pela Universidadede Aveiro em 2005.Participou no desenvolvimento durante a 1ª fasedo projecto europeu Daidalos, na área de Qualidadede Serviço, como parte do trabalho realizado parao projecto final da licenciatura e, mais tarde, comobolseiro de investigação no Instituto deTelecomunicações.Actualmente trabalha para a PT Inovação Aveiro,em desenvolvimento de software. Participou naimplementação e é o responsável pela manutençãodo módulo de recolha de dados de desempenhoutilizado na solução de gestão do Cluster Netb@nd.


palavras-chave:gestão de redes; autonomic networks;

self-organizing networks

As redes de próxima geração serãocaracterizadas por uma elevadadiversidade e dinamismo. O crescimento em número e tipo de equipamentos e serviços de telecomunica-ções em cenários de evolução,associado à necessidade de uma a-daptação contínua às alterações nofuncionamento das redes, demonstra a ineficiência e inadaptação domodelo convencional de gestão dasmesmas. A gestão autonómica dasredes de telecomunicações procuramelhorar a capacidade de gestãonesses cenários, atribuindo a capa-cidade de auto-organização aos vá-rios equipamentos da rede.

In-Network Management (INM) surge como um novo paradigma ondeo plano de gestão se encontra distribuído e integrado na própria rede.Este paradigma está a ser desenvolvido no contexto do projecto 4WARD(IST-FP7).

Neste artigo iremos apresentar oconceito de INM e de gestão auto-nómica de redes, referindo algunsdos objectivos e resultados esperados no âmbito do referido projecto.

Victor MarquesVitor Mirones

Susana Sargento(Universidade de Aveiro)

02Gestão Autonómica

em Redes de Próxima Geração

Gestão Autonómica em Redesde Próxima Geração

107

1. IntroduçãoA abordagem tradicional na gestãode redes de telecomunicaçõesbaseia-se numa arquitectura centra-lizada. As funções de gestão (vulgar-mente conhecidas pelo acrónimoFCAPS - Fault, Configuration, Ac-counting, Performance, Security) sãosuportadas por equipamentos cen-trais (NMS - Network ManagementSystems) que comunicam com os e-quipamentos da rede (NE - NetworkEquipment), através de protocolosnormalizados de gestão (normal-mente SNMP - Simple Network Ma-nagement Protocol). Estes protocolosactuam como mediadores entre ossistemas de gestão e os elementosgeridos, sendo usados pelos NMSpara medir e controlar o comporta-mento da rede.

Com a evolução das redes de tele-comunicações surgem diversos no-vos problemas. A explosão do nú-mero e variedade de equipamentosgeridos, assim como a maior flexibili-dade e variabilidade das tecnologiassuportadas, actuam como principaisfactores de pressão sobre os siste-mas actuais. O número de disposi-

tivos ligados à Internet ultrapassouenormemente as expectativas inici-ais. Novos tipos de dispositivos eredes (sensor networks, home net-works e terminais móveis) introdu-ziram o conceito de ubiquidade nacomunidade, alargando o universode equipamentos com funcionali-dades específicas e, logo, necessi-dades próprias de gestão.

As redes sem fios (wireless) têmigualmente contribuído para o dina-mismo dos cenários das redes detelecomunicações. O factor mobili-dade é introduzido na topologia dasredes: os elementos da rede po-dem deslocar-se, as fronteiras entredomínios podem ser ultrapassadas,os equipamentos podem desapa-recer e reaparecer noutro ponto darede. As alterações na topologia darede reflectem-se naturalmente notráfego. Os mecanismos de encami-nhamento de tráfego têm que a-companhar o dinamismo da própriarede. As redes ad-hoc ilustram es-tes cenários altamente dinâmicos.A abordagem centralizada da ges-tão destas redes, demasiado de-pendente da intervenção humana,

não permitirá uma gestão eficientedas mesmas, nem tempos de reac-ção adequados.

A comunidade científica persegue avisão de uma gestão autonómica(Autonomic Network Management)como resposta aos problemas indi-cados. Gestão autonómica é enten-dida como a capacidade das entida-des da rede para auto-regularem oseu comportamento, de acordo comos objectivos e políticas que a rede,como um todo, procura atingir [1].

Pretende-se que as redes futuras seauto-configurem, adaptando-se di-nâmica e continuamente às altera-ções de forma independente e es-calável. Esta propriedade permitiráreduzir os custos de operacionali-zação das mesmas e minimizar anecessidade de intervenção hu-mana.

2. Estado de arteAutomação não é um conceito novonuma rede de telecomunicações.Os operadores de telecomunica-ções cedo sentiram a necessidadede substituir a gestão manual das

suas redes. Os primeiros comuta-dores automáticos surgiram no iníciodo século XX, com o objectivo deeliminar a necessidade de operado-res humanos na rede. Mais recente-mente, com o surgir da Internet, asrotas de interligação entre os poucosnós da rede eram adicionadas emantidas de forma manual e estáti-ca. O crescimento em dimensão ecomplexidade dessa rede, e o seucomportamento dinâmico, torna-ram-se incompatíveis com essa ges-tão manual, culminando na criaçãodos protocolos de routing. Estes doisexemplos ilustram a colocação dealguma inteligência dentro da rede,como forma de ultrapassar as limi-tações da intervenção humana etornar a gestão das redes mais rá-pida e eficiente.

A metodologia de gestão pode serclassificada atendendo ao grau dedistribuição do sistema. As redes po-dem possuir uma estrutura centra-lizada (ex. SNMPv1), uma estruturalevemente distribuída (ex. SNMPv2,RMON) ou uma estrutura altamentedistribuída [2].

Um sistema autonómico possui acapacidade de recolher e analisar in-formação da rede, tomar decisõescom base nessa análise e actuar emconformidade sobre a rede, num ci-clo de controlo fechado [3]. É a ca-pacidade de tomar decisões que per-mite reduzir a intervenção humanaremetendo-a para decisões de altonível (políticas da rede). Os proces-sos autonómicos podem ser cen-tralizados (NMS) ou distribuídos. Nosegundo caso, as decisões são to-madas localmente junto à ocorrên-cia da anomalia ou alteração [4].

O desenvolvimento de uma redeauto-gerida, auto-configurada eauto-regulada (self-*) constitui umaárea de considerável investigação eenvolve um elevado número de dis-ciplinas como: concepção de proto-colos, gestão de redes, inteligênciaartificial, computação difusiva, teoriade controlo, teoria de jogos, semân-

tica, biologia, sistemas context-awa-re, redes de sensores, segurança econfiança, entre outras [3]. Todasestas áreas contribuem com mode-los e metodologias, permitindo ummelhor entendimento de um sistemaautonómico de comunicações.

Vários projectos contribuíram signifi-cativamente em várias destas áreas.Nos próximos parágrafos faremosuma pequena descrição de algunsdesses projectos.

A arquitectura ASA (Autonomic Ser-vice Architecture) [5] introduziu ferra-mentas para a gestão autonómicade serviços sobre redes IP. Este pro-jecto abordou a gestão de recursosde redes e de serviços, introduzindodiferentes níveis de abstracção.Nestes, os serviços assentam sobrerecursos quer virtuais, quer físicos. Avirtualização de recursos simplifica atarefa da gestão da rede ao provi-denciar interfaces uniformes entre osdistintos e variados recursos físicos.

FOCALE [1] é uma arquitectura paraa gestão autonómica de redes de te-lecomunicações. Esta arquitecturarealça o uso de modelos de informa-ção e modelos ontológicos como veí-culo para adquirir conhecimento so-bre as capacidades e limitações deuma rede, possibilitando uma abs-tracção sobre a especificidade do fun-cionamento de cada equipamento.Esta aproximação acentua o papeldas políticas (policies) da rede, comomodo de exprimir as regras do negó-cio que determinam o uso dos dife-rentes recursos da rede. No FOCALEsão usados dois ciclos de controlo:um de manutenção usado em condi-ções normais (sem anomalias); e umde correcção usado quando é neces-sário actuar sobre a rede por anomaliaou devido à introdução de uma novapolítica.

O projecto Ambient Networks (AN)foi um projecto integrado (IP) do 6ºprograma quadro comunitário (IST-FP6) [6]. Este projecto procurou umasolução inovadora e comercialmente


viável de redes móveis. Esta solu-ção faria um uso eficiente dos recur-sos existentes, tirando proveito daagregação das redes através de di-ferentes domínios tecnológicos oueconómicos. Esta característica im-pulsionaria novas oportunidades denegócio e o crescimento no domí-nio das redes sem fios.

Tal como o anterior, o projecto ANA(Autonomic Network Architecture)foi um projecto integrado do 6º pro-grama quadro comunitário [7]. Oseu objectivo foi a concepção e odesenvolvimento de uma arquitec-tura de rede inovadora que superea tecnologia Internet actual. Esta ar-quitectura irá verificar a viabilidadede uma rede autonómica, identifi-cando as suas principais proprieda-des e características. O ANA explorao conceito de self-* (auto-configura-ção, auto-optimização, auto-moni-toria, auto-gestão, auto-reparação eauto-protecção), demonstrando-as.

3. In-Network ManagementUm novo paradigma de gestão deredes está em desenvolvimento noâmbito do projecto 4WARD [8]. Esteprojecto enquadra-se no 7º Progra-ma Quadro da Comissão Europeiae conta com a participação da PTInovação entre vários parceiros.Este paradigma — In-Network Ma-nagement — explora as limitaçõesdas redes actuais, nomeadamentena reduzida escalabilidade e adap-tabilidade à mudança e a contextosdinâmicos.

O INM introduz uma camada ténuee difusa delegando, de forma distri-buída e cooperativa (in-network), asfuncionalidades de gestão em ele-mentos de rede com capacidadede auto-organização. A capacidadede decisão, baseada no conheci-mento adquirido e partilhado conti-nuamente na rede, é adicionada poresta camada em cada elementodessa mesma rede. Este paradigmapode ser interpretado como a intro-dução da inteligência da gestão naprópria rede.Não se pretende com

109

este paradigma anular a necessida-de de uma plataforma centralizadade gestão (NMS), mas sim comple-mentá-la (ver Figura 1).

Na abordagem clássica de gestãode uma rede, a entidade (externa) degestão comunica com todas as en-tidades geridas, observando o seuestado e actuando sobre as suasconfigurações após análise e deci-são. Estas operações são, em geral,despoletadas e supervisionadas porum operador humano. Esta entida-de central pode estar dotada decomportamento automático e capa-cidade de tomar algumas decisõesautomaticamente sobre o estado darede.

Neste novo paradigma, as platafor-mas de gestão interagem com arede através de pontos de acessoespecíficos. Estes fornecem fun-ções de gestão relativas a toda a re-de. O nível a que estas interacçõesse efectuam é agora mais elevado.O gestor comunica à rede os seusobjectivos através de regras ou polí-ticas. A rede disponibiliza ao gestor

relatórios concisos sobre o seu esta-do operacional. Os pontos de aces-so representam a rede oferecendouma interface funcional suportadanum conjunto de protocolos distribuí-dos e auto-executados para a me-dição e controlo da rede.

Os principais requisitos identificadosnesta arquitectura (INM) são:

> escalabilidade (em número de equi-pamentos e processos de gestão);

> heterogeneidade (equipamentos,tecnologias de acesso, topologi-as, funcionalidades);

> interoperabilidade (entre equipa-mentos);

> suporte em tempo real;

> robustez (falhas, segurança, infor-mação parcial ou incompleta);

> baixa ocupação de recursos;

> possibilidade de hierarquizaçãode entidades;

> nível de integração; usabilidade;

> interactividade;

> adaptabilidade (à evolução dastecnologias); segurança;

> aprendizagem e extensibilidade(novas funcionalidades).

4. Realizações futurasA propriedade de INM baseia-senum mecanismo de controlo distri-buído. Este mecanismo facilita con-tinuamente a interacção entre os nósda rede, por forma à partilha da in-formação referente a cada um delese, consequentemente, a toda a rede.Esta consciência que cada entidadeterá da sua envolvência permitir-lhe--á reagir automaticamente às alte-rações da rede (não só por anoma-lia, mas também normais como au-mento de tráfego ou inserção de umanova regra). Potenciará ainda a per-manente optimização dos recursosda rede (sejam físicas ou virtuais) emconformidade com os mecanismosde optimização estipulados.

Gestão Autonómica em Redesde Próxima Geração

Figura 1 – Abordagem tradicional vs. INM na gestão de redes

Analysis andaction

ManagedDomain

Managementcommand

Network elementwith

embeddedmanagement

processes

Peer-to-peerinteraction

Networkelement

Traditional Network Management In-Network Management

ManagedDomain

Notification

Inclui-se nos objectivos deste pro-jecto a caracterização e definiçãodesses mecanismos de optimiza-ção e protocolos relacionados. Essadefinição exige uma elevada com-preensão das interacções possíveisentre diferentes entidades da rede.Estas interacções dependem dascaracterísticas de cada entidade: oseu tipo, papel e, fundamentalmen-te, o seu comportamento na rede.É necessário classificar de forma sis-temática um nó da rede, conside-rando não só o seu comportamen-to, mas também as funcionalidades(acções e eventos) que suporta.

A especificação dos protocolos e al-goritmos necessários para imple-mentar esta capacidade de INM, ne-cessita de uma identificação clarados seus requisitos, atendendo nãosó ao modelo das entidades e seuspapéis, mas também à identificaçãodos parâmetros relevantes e métri-cas necessárias para optimizar eavaliar os resultados.

Os mecanismos de descoberta darede e de decisão cooperativa de-pendem da definição de um proto-colo de gestão que difunda o conhe-cimento adquirido por cada nó, porquem dele necessite. Por fim, é ne-cessário conceber os mecanismosde decisão e os algoritmos de opti-mização e proceder à sua avaliação.

5. ConclusõesDefendemos que o conceito de INMé particularmente adequado em re-des de grandes dimensões e comcomportamento altamente dinâmi-co. Esta capacidade presente nosnós da rede potenciará em temporeal uma rede ciente do seu com-portamento, algo que não é viávelno actual contexto da gestão de re-des. Esperamos ainda que o planodistribuído de gestão detenha a ca-pacidade de reacção instantâneaperante alterações como anomaliasou novos equipamentos, retomandorapidamente o funcionamento nor-mal e esperado. Comparativamentecom os actuais sistemas de gestão,

Referências

[1]Brendan Jennings, Sven van der Meer,Sasitharan Balasubramaniam, Dmitri Botvich,Micheál Ó Foghlú, William Donnelly and JohnStrassner, Towards Autonomic Management ofcommunications Networks, IEEE CommunicationsMagazine, Vol 45, No 10, pp. 112-121, October2007[2]Jean-Philippe Martin-Flatin, Simon Znaty andJean-Pierre Hubaux, A Survey of DistributedEnterprise Network and Systems ManagementParadigms, Journal of Network and SystemsManagement, Springer, Vol. 7, No. 1, pp. 9-26,1999[3]Simon Dobson, Spyros Denazis, AntonioFernández, Dominique Gaïti, Erol Gelenbe, FabioMassacci, Paddy Nixon, Fabrice Saffre, NikitaSchmidt and Franco Zambonelli, A Survey ofAutonomic Communications, ACM Transactionson Autonomous and Adaptive Systems, Vol. 1, No2, pp 223-259, December 2006.[4]Raouf Boutaba and Jin Xiao, NetworkManagement: State of the Art., Proceedings of theIFIP 17th World Computer Congress (WCC'02) -TC6 Stream on Communication Systems: TheState of the Art. IFIP Conference Proceedings, Vol.220, pp. 127-146, 2002.[5] Yu Cheng, Ramy Farha, Myung Sup Kom,Alberto-Leon-Garcia and James Won-Ki Hong: AGeneric Architecture for Autonomic Service andNetwork Management, Computer Commu-nications, Vol 29, No 18, pp. 3691-3709, November2006.[6] Bengt Ahlgren, Lars Eggert, Börje Ohlman andAndreas Schieder, Ambient Networks: BridgingHeterogeneous Network Domains., In Proceedingsof the IEEE 16th International Symposium on Per-sonal, Indoor and Mobile Radio Communications,Volume 2, pp. 937-941, September 2005.[7] Christophe Jelger, Christian Tschudin, StefanSchmid and Guy Leduc, Basic Abstractions for anAutonomic Network Architecture., In Proceedingsof the 1st IEEE WoWMoM Workshop on Autonomicand Opportunistic Communications (AOC'07), June2007.[8] 4WARD Project: http://www.4ward-project.eu/

Vitor Mirones é licenciado em EngenhariaElectrotécnica e de Computadores, ramo deTelecomunicações, pela Faculdade de Engenhariada Universidade do Porto (1994). No CET desde1995, onde colaborou na área das TecnologiasMultimédia e Desenvolvimento de Serviços eAplicações. Desde 2002 no DSR - Desenvolvi-mento de Sistemas de Rede (ex. SIR - Sistemase Infraestruturas de Rede) da PT Inovação. É ac-tualmente responsável pela equipa de Protocolose Aplicações para Gestão de Elementos de Rede.Em 2007 iniciou um programa doutoral em Tele-comunicações (MAPTele) nas universidades doMinho, Aveiro e Porto, subordinado ao tema “SelfIn-Network Resource Management”.

Victor Marques, obteve a Licenciatura e Mestradoem Engenharia Electrónica e Telecomunicaçõese o Doutoramento em Engenharia Electrotécnicapela Universidade de Aveiro em 1994, 1997 e2005, respectivamente. Desde 1994 a 2001exerceu funções de investigador na Universidadede Aveiro e no Instituto de Telecomunicações.Ingressou na Portugal Telecom Inovação em 2001,onde é actualmente responsável pela divisão de“Desempenho de Rede e Plataformas de Acessoem Rádio e Cobre” do departamento deDesenvolvimento de Sistemas de Rede. Publicouvários artigos em conferências e revistas nacionaise internacionais e tem estado envolvido emprojectos de investigação e desenvolvimento noâmbito dos programas e fóruns Europeus (RACE,ACTS, IST e EURESCOM) e da PT Inovação.

Susana Sargento (Doutoramento em EngenhariaElectrotécnica em 2003) foi docente noDepartamento de Ciências de Computadores daUniversidade do Porto de 2002 a 2004, e encontra--se desde 2004 na Universidade de Aveiro eInstituto de Telecomunicações. Durante os últimosanos tem estado envolvida em vários projectosnacionais e europeus, tendo responsabilidadesde coordenação de várias actividades nosprojectos, como as actividades de Qualidade deServiço e Integração de Redes Ad-hoc no projectoFP6 IST-Daidalos. Os seus interesses de inves-tigação centram-se nas áreas de redes hete-rogéneas e de próxima geração, infra-estruturadas,em malha e ad-hoc, onde tem publicados maisde 100 artigos científicos.

obteremos uma redução significavanos tempos de reacção, especial-mente em redes de grande dimen-são e complexidade.


Agilização dos Processos de Provisão111

Actualmente, a provisão de serviços detelecomunicações, cada vez mais inovadores e integrados, obriga à arti-culação de várias aplicações que dãosuporte a diferentes etapas dos proces-sos de negócio em causa. Estes, porseu turno, são cada vez mais frequentemente criados num editor gráfico e des-critos usando uma linguagem designada por Business Process ExecutionLanguage (BPEL), que é depois executada por um motor de orquestraçãoque se encarrega de garantir o desenrolar do fluxo preconizado e as invoca-ções aos sistemas necessários.

No caso da PT Inovação, é a aplicaçãoOrder Manager (OM) que desempenhaeste papel de coordenação. Neste artigo, descrevemos o processo de selec-ção do motor BPEL open source queserve de base ao OM, a forma comoeste foi integrado com um sistema deversionamento de processos de negó-cio concebido à medida, e os esforçosem curso para minimizar as tarefas manu-ais actualmente necessárias para configuração das interacções entre os vários operations support systems (OSS)sempre que se introduzem novas capacidades ou serviços.

palavras-chave:Service-Oriented Architecture (SOA),

Business Process Execution Language (BPEL),Integração de Sistemas, open source.

Carlos Lopes(UC)

André Macedo

João BicaXLM

Fátima Guerra

José Maio

João Guerrinha

Paulo Rupino(UC)

Paulo Melo(UC)

Cristina Rodrigues(UC)


1. IntroduçãoDescreve-se aqui a forma como doisprojectos realizados no contexto doPrograma de Inovação da PT - oPRADO (Process Analysis and ac-tivities DefinitiOn) e o JUSSA (JoiningUseful Systems in Sustainable Ar-chitecture) - se articulam num esfor-ço de tornar mais simples, fiáveis eágeis os processos de provisão deserviços coordenados pelo OrderManager (OM).

Face aos problemas de desempe-nho e robustez sentidos com o mo-tor BPEL comercial subjacente aosistema Order Manager da PT Ino-vação, foi decidido analisar as váriasofertas open source neste domínio,em busca de uma eventual soluçãocapaz de suportar as cargas típicasdos ambientes de exploração dosseus clientes. A conseguir-se, o usode um produto livre traria ainda umaredução nos custos dos sistemas fi-nais e salvaguardaria a empresa dasestratégias comerciais dos fabri-cantes de software. Este estudo foium dos objectivos do projecto PRA-DO, no contexto do qual se desen-volveu ainda uma ferramenta autó-

noma de versionamento de proces-sos de negócio para complementaro sistema seleccionado.

Com o problema do motor BPEL resol-vido, a atenção focou-se na gestão dasinteracções com os vários operationssupport systems (OSS) durante umprocesso de provisão. As trocas deinformação entre estes sistemas sus-citam questões complexas, obrigan-do a intervenções humanas fastidio-sas e sujeitas a erros cada vez quesão introduzidos novos produtos oualterados os existentes. Com o pro-jecto JUSSA em curso, procura-sesimplificar esta tarefa, desenvolvendouma aplicação que centraliza as al-terações num único ponto e que au-tomatiza a criação de grande partedos documentos XSD e XSLT quecontrolam a interacção com os vá-rios sistemas envolvidos.

Na secção seguinte descrevem-se assoluções preconizadas, apresentan-do-se depois, na secção 3, os princi-pais resultados. A importância dosprojectos para os negócios do grupoPT é discutida na secção 4, imedia-tamente antes das conclusões.

2. Descrição do sistema ousoluçãoA PT Inovação já utilizava orques-tração de serviços em alguns dosseus sistemas, mas deparava-secom alguns problemas de fiabilida-de e desempenho com o motor co-mercial que adoptava. Pretendia-seuma solução que resolvesse os pro-blemas sentidos. Por outro lado, ca-so fosse possível adoptar uma solu-ção open source, isso permitiria àempresa uma maior independênciade terceiros fabricantes e um maiorcontrolo sobre o produto, ficando i-mune a estratégias comerciais quepor vezes forçam actualizações ouque, no extremo oposto, levam aoabandono de aplicações. A escolhade um produto livre alivia ainda os en-cargos com um componente basesobre o qual funcionam as soluçõesOSS desenvolvidas pela empresa.

Numa primeira fase foi feita uma re-visão da literatura para identificaçãodos editores e motores BPEL opensource disponíveis. Seguidamente,cada um dos produtos foi testadonuma máquina virtual VMWare [1]separada, para garantir as mesmas

condições de operação, sem inter-ferências de instalações anterioresou simultâneas de outras aplicações.

Foram experimentados oito editores:

> Savvion Process Modeler [2];

> Tibco Business Studio [3];

> Intalio|BPMS Designer [4];

> Eclipse BPEL Project [5];

> ITP - Commerce Process Modeler[6];

> Enhydra JaWE [7];

> ActiveBPEL Designer [8];

> Sun Netbeans [9] e cinco motoresBPEL:

> Sun Java System Application Ser-ver Platform Edition [10];

> Intalio|BPMS Community Edition[11];

> JBoss jBPM [12];

> ActiveBPEL Open Source Engine[8];

> Apache ODE [13].

Da análise dos motores BPEL resul-tou uma short list que incluía os pro-dutos Sun Java System ApplicationServer Platform Edition e Active-BPEL Open Source Engine (Active-BPEL OSE). Uma comparação maispormenorizada destas duas alterna-tivas revelou a segunda como me-lhor opção. Este produto está dis-ponível sob licença GPL [14].

Para verificar se o ActiveBPEL OpenSource Engine garantia o desem-penho e fiabilidade necessárias aouso em exploração, o produto foisubmetido a vários testes, tanto emlaboratório, num ambiente simula-do, como no ambiente da empresa,onde foi integrado com outras apli-

cações de suporte às operações.Não só foi possível chegar a cargasvárias vezes superiores à actual-mente existente, como não ocorre-ram situações que obrigassem à rei-nicialização do software.

No que toca aos editores de proces-sos de negócio, optou-se pelo Acti-veBPEL Designer, que, não sendoopen source, é fornecido sob licen-ça gratuita pela empresa Active End-points. Este editor está bem integra-do com o motor escolhido, sendo defácil utilização. Não obstante, é umaferramenta de engenharia, não ade-quada ao uso por não técnicos.

O editor e motor seleccionados cum-priam a maior parte dos requisitos daPT Inovação, faltando, no entanto, osuporte para a evolução dos proces-sos de negócio. No sector em causa,estes podem ter uma duração muitolonga (da ordem dos meses entre iní-cio e a conclusão), mas, simultanea-mente, têm que ser frequentementealterados para dar resposta a novosdesafios de negócio ou a problemasencontrados. Ora, dada a duração decada um, e a sua independência, nãoé viável aguardar que todos terminempara fazer alterações. Por outro lado,pretende-se que um processo quetenha iniciado com umas determina-das regras (ex.: uma determinadacampanha promocional), termine nes-se mesmo contexto e só os novos u-sem as regras mais actuais.

A resposta para este problema con-siste em manter várias versões domesmo processo de negócio, ga-rantindo que cada um executa nocontexto em que iniciou, e que al-terações efectuadas posteriormente não afectam os processos já emcurso.

Implementar o versionamento con-siste em ter vários ficheiros BPELrelativos ao mesmo processo de ne-gócio, sendo atribuída a cada umdeles uma versão para ser possíveldiferenciá-los. Assim, se houver umprocesso de negócio chamado “Ac-

113

tivaDSL”, quando se faz a disponibi-lização no servidor (o deploy) o seunome é alterado para “ActivaDSL-VX.Y”, onde X.Y é a versão do pro-cesso. Desta forma, é possível modi-ficar os ficheiros BPEL de um pro-cesso de negócio sempre que fornecessário, não perturbando as ins-tâncias que estão a ser executadas.Os processos que são iniciados numadeterminada versão executam-nasempre até ao final. Já as novas ins-tâncias são sempre ser executadasa partir da última versão disponível.

Ao desenvolver o módulo de versio-namento, optou-se por criar uma so-lução auto-contida, sem modificar ocódigo do motor ActiveBPEL OSE(ainda que este esteja disponível).Com este desacoplamento, a actua-lização do motor fica simplificada ca-da vez que surge uma nova versão,não sendo necessário realizar-lhequaisquer modificações. Pretendeu--se criar uma solução independentedas particularidades do motor e querespeitasse as condições de fiabili-dade e desempenho testadas ante-riormente.

Para implementar esta solução tor-nou-se necessário desenvolver umintermediário (chamado Deployer)entre o editor de processos de ne-gócio e o motor BPEL. Esse inter-mediário tem como função alterar onome do processo antes deste sercolocado no motor, evitando que se-ja feito o deploy de um processocom um nome já existente. Para tal,efectua uma consulta aos dados deversionamento para determinar onome do novo processo que vai sercolocado no motor, havendo assimum mapeamento de 1 (nome do pro-cesso original) para N (várias versõescorrespondentes ao mesmo pro-cesso de negócio).

Como se pode verificar através da Fi-gura 1, a alteração do nome do pro-cesso é transparente para o dese-nhador do processo, pelo que estenão tem que o modificar sempre quesão efectuadas alterações no editor

Agilização dos Processos de Provisão


e é realizado o deploy.

Para facilitar o deploy de processosem máquinas que se encontrem emexploração, foi criada ainda uma in-terface Web baseada em JavaSer-ver Pages (JSP), onde o utilizador in-dica o ficheiro criado pelo editor (noformato BPR) e a versão a que o fi-cheiro corresponde. O processo dedeploy é, neste caso, idêntico ao re-presentado na Figura 1, com a ex-cepção da consulta da versão noficheiro “version.properties”, que dei-xa de fazer sentido visto que o uti-lizador pode escolhê-la através doformulário da interface.

Quando o processo de deploy éconcluído, o Deployer faz uma invo-cação ao processo que acabou deenviar para o motor, para obter a des-crição Web Services Definition Lan-guage (WSDL) e guardar o resultadona base de dados, juntamente coma restante informação da versão.O WSDL guardado na base de da-dos é usado para devolver a defi-nição do serviço sempre que umcliente a solicitar. Nestes casos,em vez de se invocar o motor paraobter o WSDL, este é extraído dabase de dados, ganhando assimalgum tempo e recursos que seriamgastos ao obter o mesmo resultadodo motor. Uma vez efectuado odeploy de um processo, o Deployernotifica o Gateway, através dainvocação de um endereço própriopara o efeito, para que este últimoactualize a sua informação acercados processos BPEL existentes nomotor.

Já com o processo em execução,quando um cliente o invoca não pre-cisa de saber que existe versiona-mento, nem qual a última versão.Apenas invoca o processo atravésdo nome original, no exemplo “Ac-tivaDSL”, sendo efectuado o enca-minhamento do pedido para a ver-são correcta do processo. Esteencaminhamento é realizado pelocomponente a que se chama Gate-way - ver Figura 2. Figura 2 – Encaminhamento de uma invocação de um cliente a um processo versionado

ActivaDSL

2 - getLastName (”ActivaDSL”)

3 - “ActivaDSL-V4.0”

6 - Invoke Reply

Gateway

Database

4 - Invoke “A

ctivaDSL-V4.0”

5 - Invo

ke Reply

Application Server

BPEL Engine

ActivaDSLV-4.0

ActivaDSLV-2.0

ActivaDSLV-3.0

ActivaDSLV-1.0

Figura 1 – Deploy de um processo BPEL

1 - createAndDeploy “ActivaDSL”

ActiveBPELDesigner

2 - getVersion “ActivaDSL”

3 - V4.0

6 - Resultado do Deploy

Version.pro-perties

Deployer

4 - Deploy “ActivaDSL-V4.0”

5 - Resultado do Deploy

BPEL Engine - ActiveBPEL

BPEL Engine

ActivaDSLV-4.0

ActivaDSLV-1.0

ActivaDSLV-2.0

ActivaDSLV-3.0

115 Agilização dos Processos de Provisão

3. ResultadosComo resu l tado do pro jectoPRADO, foi seleccionado um motorBPEL open source, para orquestra-ção dos serviços anteriormente su-portados pelo motor comercial,bem como um editor BPEL que fa-cilita a edição de novos processos.Testes efectuados com o motorpermitiram concluir que cumpria osprincipais requisitos, e permitia car-gas superiores às suportadas como motor anteriormente usado, bemcomo garantia uma maior robustez.

Para permitir a evolução dos proces-sos de negócio, e perante a neces-sidade reconhecida de suportar oversionamento destes, foi desen-volvida uma arquitectura capaz depermitir a existência de diversas ver-sões de um processo num motorBPEL. Testes efectuados com a im-plementação desta arquitectura de-monstraram a capacidade de supor-tar versões de processos com umcusto reduzido em termos dememória (inferior a 10% de sobre-carga) e em termos de tempo de res-posta (inferior a 15% de atraso). Paraalém disto, com pequenas alterações,a arquitectura permite também au-mentar a fiabilidade do sistema, po-dendo funcionar como front-end deum conjunto de motores, aumentan-do a sua escalabilidade.

Para suportar a evolução da inter-ligação de diversos sistemas OSS,para além da substituição de acti-vidades/processos individuais, é ne-cessário considerar também a evo-lução da informação trocada entreestes. Para tal, foi planeado, no con-texto do projecto JUSSA, um sis-tema capaz de descrever o percursode unidades individuais de informa-ção ao longo de um processo, paraque a sua alteração possa ser con-siderada de forma integrada (ao lon-go de todo o processo) e não de umaforma discreta (apenas numa acti-vidade). Tal permite facilitar a des-crição das alterações e ao mesmotempo garantir a sua coerência. Umavez que a descrição das estruturas

de informação é complexa, foi neces-sário criar um sistema capaz de man-ter esta informação, possuindo aomesmo tempo assistentes capazesde facilitar a realização das tarefas dealteração de processo mais comuns.

4. Importância para os negóciosdo grupo PTEm resultado do projecto PRADO,com a adopção do motor BPEL o-pen source proposto, a empresa ga-nha maior controlo sobre esta com-ponente usada pelos sistemas quedesenvolve, ganha maior desem-penho e robustez comparativamentecom a solução paga que usava, epoupa nos custos. Com efeito, porter acesso pleno ao código fonte doproduto, a empresa nunca fica re-fém da estratégia comercial de umfabricante de software tradicional,que pode incluir actualizações for-çadas ou o abandono. Mesmo quea comunidade pare de evoluir o sis-tema aberto, a empresa pode sem-pre introduzir as adaptações queconsidere relevantes para os seuspropósitos. Por outro lado, a robustezdeste produto provou ser superior àda ferramenta paga actualmente emutilização, que apresentava algunsproblemas, tendo ainda sido cons-tatado um desempenho acrescido.Por fim, a ausência de custos de li-cenciamento com este componentebase permite eliminar uma parcelasignificativa do valor das propostasde fornecimento a terceiros do soft-ware desenvolvido pela empresa,tornando-as mais competitivas.

No que toca ao projecto JUSSA, es-pera-se que o sistema actualmenteem desenvolvimento, que permitegerir de forma centralizada os do-cumentos XML, XSD e XSLT envolvi-dos na interacção com os vários OSS,reduza os custos de modificação deserviços existentes e da adição denovos. De facto, quer pela automatiza-ção da geração de alguns dos ficheir-os necessários, quer pelo potencial deredução de erros humanos actual-mente possíveis nas fastidiosas tarefasde edição, as alterações passarão a

ser mais rápidas e fiáveis.

5. ConclusõesDescreveram-se aqui dois projectosrealizados no contexto do Progra-ma de Inovação da PT - o PRADO(Process Analysis and activities De-finitiOn) e o JUSSA (Joining Useful Sys-tems in Sustainable Architecture), quese articulam num esforço de tornarmais simples, fiáveis e ágeis e osprocessos de provisão de serviçoscoordenados pelo Order Manager(OM). No primeiro foi identificadoum motor BPEL open source quepermite a orquestração dos pro-cessos de negócio, tendo ainda sidodesenvolvido um sistema de ver-sionamento para complementar esteproduto. Já no projecto JUSSA, emcurso, o foco centra-se na gestãodos documentos XML necessáriosà interacção com os vários OSSenvolvidos num processo de provi-são, procurando-se eliminar asactuais tarefas manuais, fastidiosas emuito sujeitas a erros.

Referências[1] VMWare Inc. VMWare Server DataSheet. 2008[cited Março de 2008]; Available from:htp://www.vmware.com/pdf/server_datasheet.pdf.[2] Savvion. Savvion Process Modeler User Guide.2006 [cited Maio de 2007]; Available from: https://processxchange.savvion.com/index.php?option=com_content&task=view&id=11&Itemid=25.[3] TIBCO. TIBCO Business Studio InstallationGuide. 2006 [cited Março de 2007]; Available from:http://www.tibco.com/devnet/resources/ business_studio/business_studio_installation.pdf.[4] Intalio. Getting Started with Intalio|BPMS Designer. 2007 [cited Abril de 2007]; Available from:http://bpms.intalio.com/content/view/30/103/[5] Eclipse Foundation. BPEL Project home. 2007[cited Março de 2007]; Available from: http://www.eclipse.org/bpel/index.php.[6] ITP Commerce. Business Process Modelingwith Process Modeler for Microsoft Visio. 2007[cited Maio de 2007]; Available from: http://www.itp-commerce.com/.[7] Together Teamlösungen. Open Source JavaXPDL editor. 2007 [cited Maio de 2007];Available from:http://www.enhydra.org/workflow/jawe/index.html.[8] Active Endpoints. Active BPEL Open SourceEngine. 2007 [cited Maio de 2007]; Available from:http://www.active-endpoints.com/active-bpel-engine-overview.htm.[9] Netbeans. Introducion to the Netbeans. 2007[cited Maio de 2007]; Available from:http://www.netbeans.org/products/ide/.[10] Sun Microsystems. Sun Java System Application Server Platform Edition 9.0 Home Page.2007 [cited Março de 2007]; Available from:htp://www.sun.com/software/products/appsrvr_pe[11] Intalio. Intalio|BPMS CE Overview. 2007 [citedMarço de 2007]; Available from: http://bpms.intalio.com/images/stories/start/intalio_overview.pdf.[12] JBoss. JBoss jBPM. 2007 [cited Maio de2007]; Available from: http://www.jboss.com/pdf/jb_jbpm_04_07.pdf.[13] Apache Software Foundation. Apache ODEArchitectural Overview. 2006 [cited Maio de 2007];Available from: http://incubator.apache.org/ode/achitectural-overview.html.[14] Free Software Foundation. GNU General PublicLicense, version 3. 2007 [cited 2008; Availablefrom: http://www.gnu.org/licenses/gpl-3.0.html.

Paulo Melo é Professor Auxiliar e Coordenadordo Centro de Informática da Faculdade de Economia da Universidade de Coimbra. É doutorado emOrganização e Gestão de Empresas, ramo deAnálise e Planeamento de Sistemas. É investigadordo Instituto de Engenharia de Sistemas e Computadores de Coimbra (INESCC) e responsávelpelas redes e pelo parque informático na mesmainstituição desde 1995. É autor de vários artigoscientíficos e membro da organização ou do conselho científico de diversas conferências internacionais.

Paulo Rupino da Cunha é Professor Auxiliar eCoordenador do Grupo de Sistemas de Informaçãona Universidade de Coimbra. É doutorado emEngenharia Informática. Nos últimos quatro anosfoi o Vice-Presidente do Instituto Pedro Nunes eda IPN Incubadora. Durante três anos foi Coordenador do Colégio de Engenharia Informática daOrdem dos Engenheiros na Região Centro. Durantedois anos foi Vice-Presidente do Departamentode Engenharia Informática da Universidade deCoimbra. É autor de vários artigos científicos emembro do conselho editorial ourevisor de várias revistas e conferências.

Cristina Gomes Rodrigues é finalista do Mestradoem Engenharia Informática da Universidade deCoimbra, opção temática de Sistemas deInformação e Engenharia de Software. É licenciadaem Engenharia Informática pela mesma Universidade. Desempenha funções de investigação noprojecto JUSSA (Joining Useful Systems in Sustainable Architecture).

Carlos João Madeira Lopes é licenciado emEngenharia Informática pela Universidade de Coimbra. Desde 2004 que trabalha no Instituto PedroNunes como Analista/Programador, tendo tidofunções de coordenação de equipa no desenvolvimento do Sistema de Informação da própriainstituição. Actualmente é gestor da Unidade deSistemas de Informação do Laboratório de Informática e Sistemas do Instituto Pedro Nunes etem também funções de investigação e desenvolvimento em vários projectos, entre os quais oJUSSA (Joining Useful Systems in SustainableArchitecture).

José Maio, licenciado em Computação na Fa-culdade de Ciências da Universidade de Lisboa.Pós-Graduação em Gestão da Ciência, Tecnologiae Inovação, na Universidade de Aveiro. Ingressouno Centro de Estudos de Telecomunicações –CET em Aveiro (hoje PT Inovação), em 1987 comoestagiário, tendo sido admitido para o quadro em1988. Mantém a sua actividade na PT Inovação.De 1988 a 2000 participou em diversos Projectosde Investigação Europeus em áreas como planeamento de redes e desenvolvimento rural. Em 1996foi nomeado responsável pelo grupo SuporteEstratégico, tendo sido mais tarde nomeado res-ponsável para outras Unidades Funcionais dentroda área dos OSS (Operating Support Systems).

Foi, e é, responsável por diversos sistemas eprodutos OSS da PT Inovação. Actualmente éresponsável pela Divisão: Controlo de Processosde Operação na direcção dos Sistemas de Suporteàs Operações.

André Macedo, finalista em Engenharia Informáticae Mestrado em Engenharia Informática pela Universidade de Coimbra. Efectua investigação sobrearquitecturas orientadas a serviços desde 2007e iniciou a sua actividade profissional na PTInovação no início de 2008 como programadorda aplicação “Order Management”.

Fátima Guerra, licenciada em Engenharia Electrotécnica, na Universidade de Trás–os–Montes eAlto Douro, em 2003. Realizou o projecto de fimde curso em parceria com a PT Inovação, aoabrigo do Programa Talento, na área dos sistemasde navegação por satélite. Este projecto foi premiado com o 2º lugar no Prémio Inovação JovemEngenheiro 2003, atribuído pela Ordem dos Engenheiros da Região Sul. Também em 2003,frequentou o estágio profissional na PT Inovação,enquadrado na área da automatização de processos de negócio, tendo por base a arquitecturadefinida pelo TMForum. Desde então, participouem diferentes projectos, incluindo projectos Eurescom, nos quais foram adquiridos conhecimentos e experiência em SOA, Web Services, J2EE,BPM e BPEL. Actualmente, aplica os conhecimentos na gestão e desenvolvimento do sistema“Order Manager”.

João Guerrinha, licenciou-se em EngenhariaInformática pela Faculdade de Ciências e Tecnologia da Universidade de Coimbra (2006). Desde2006 tem trabalhado no projecto da PT Inovação,Order Management, como programador, arquitectoe analista de sistemas. A partir de 2008 é tambémresponsável pela concepção e desenvolvimentodo projecto OSS para a CVT.

João Bica Osório, licenciou-se em EngenhariaInformática pela Universidade de Coimbra em2006. Realizou o Estágio Curricular e EstágioProfissional na PT Inovação, onde continua adesenvolver a sua actividade profissional nas áreasde Order Management e Network Activation.Actualmente, os seus interesses são: Arquitecturade Software, Domain Specific Languages e ModelDriven Architecture.


O Impasse da Internet117

palavras-chave: IP, Internet, virtualização

Repensar os fundamentos da Internet e lançar as bases da “Internetdo Futuro” têm constituído os objectivos de diversas iniciativas recentes,com a participação activa da in-dústria de telecomunicações e dacomunidade científica. Mas porquêuma “Internet do Futuro”? A evolu-ção da Internet ao longo de quasequatro décadas tem sido realizadade forma progressiva e sem rupturas. Porque não prosseguir na mesma lógica? À primeira vista, não émuito óbvio que haja vantagem empôr em causa os princípios básicosda Internet, alicerçados no protocoloIP, que têm demonstrado uma enor-me capacidade de adaptação a novos requisitos, muito para além do

Teresa Almeida

que foram os objectivos iniciais daInternet. Porém, uma análise maisprofunda revela que característicasfundamentais do IP constituem hojebloqueios à inovação e à adopçãode novas soluções, indispensáveispara dar resposta a novos requisitos.Neste cenário, o grande desafio seráfazer a transição para esta nova Internet de forma a permitir a sua co-existência com a tecnologia actual.

Jorge Carapinha


1. IntroduçãoNos últimos tempos, diversas inicia-tivas têm sido lançadas nos EstadosUnidos e na Europa1 no sentido deestudar e conceber aquilo que ge-ralmente se designa por “Internet doFuturo”. Comum a estas actividadesestá o objectivo de criar uma novaarquitectura para a Internet, livre delimitações ou constrangimentos di-tados pela tecnologia actual.

À primeira vista, o interesse destetipo de iniciativas seria meramenteacadémico – para quê pôr em cau-sa os princípios que estiveram nabase do sucesso esmagador da In-ternet? E, ainda que houvesse van-tagem em criar uma nova Internet,porquê investir esforço num objec-tivo à partida condenado ao fracas-so, dada a dimensão que a Internetactual já atingiu?

O presente artigo procura demons-

trar que, para ambas as questões, asrespostas podem não ser necessa-riamente aquelas que numa primeiraanálise pareceriam mais óbvias. Osrequisitos da Internet mudaram de talforma que a solução para alguns dosnovos desafios, mais do que remen-dos ou remédios paliativos, implicarupturas. Encontrar soluções que pos-sibilitem dar este passo em frenteconstitui hoje um desafio que não deveser subestimado.

O artigo divide-se em três partes prin-cipais – na primeira parte, é feita umaanálise do passado da Internet e decomo se chegou aos problemas ac-tuais, a segunda parte centra-se nassoluções para o futuro, e finalmentea terceira parte aborda a perspectivados operadores de telecomunica-ções neste contexto.

2. A evolução da InternetEm 1983, o protocolo TCP/IP tornou-

-se no standard de comunicação naInternet, então ainda denominadaARPANET 2. A introdução do TCP/IPestabeleceu em definitivo as condi-ções para que a ARPANET passassede uma rede especializada, operada egerida por uma única organização, pa-ra uma “rede de redes”, tal como existenos dias de hoje. A ARPANET era nes-sa altura essencialmente uma rede aca-démica, suportando um conjunto limi-tado de aplicações e servindo umacomunidade restrita de algumas cen-tenas de utilizadores, com interesses eobjectivos comuns.

Em 2008, o número estimado de uti-lizadores da Internet ronda os 1.400milhões, aproximadamente 21% dapopulação mundial [1]. A Internetconstitui um pilar fundamental da eco-nomia global. Os utilizadores da In-ternet têm interesses e objectivos di-versos, frequentemente opostos.

1A PT Inovação é um dos parceiros da principal iniciativa europeia actualmente em curso nesta área – o projecto 4WARD “Architecture and Design for theFuture Internet”, integrado no 7º Programa Quadro da UE.

2A ARPANET tinha sido lançada 14 anos antes. O primeiro link foi estabelecido no dia 29/10/1969 entre a Universidade da Califórnia e o Stanford ResearchInstitute.

A Internet actual constitui hoje umaplataforma de convergência parauma imensa diversidade de aplica-ções e serviços com requisitos muitodiferentes.

Num futuro não muito distante, a In-ternet ligará não só computadorese terminais de comunicação, maspotencialmente qualquer objecto –aquilo a que se costuma chamar“Internet das Coisas”. A utilizaçãode pequenos dispositivos wireless,tags RFID e sensores, abrirá cami-nho a uma vasta gama de novasaplicações, em cenários residenciaise empresariais.

A avaliação do impacto desta novarealidade na Internet ainda está emgrande medida por fazer, mas obri-gará certamente a reequacionar ca-racterísticas fundamentais da suaarquitectura.

Embora, em muitos aspectos, a Inter-net tenha mudado radicalmente aolongo de 25 anos, há um aspectoque se manteve praticamente cons-tante e imutável – o IP como basefundamental do seu funcionamento.Diversas funcionalidades foramsendo acrescentadas (mobilidade,segurança, qualidade de serviço,multicast), sempre numa lógica de e-

volução iterativa, nunca pondo emcausa os alicerces fundamentais daarquitectura.

Que os princípios básicos da Inter-net tenham tido uma tão grande ca-pacidade de adaptação a novos re-quisitos constitui sem dúvida um feitonotável. Tendo esses princípios pos-sibil itado um crescimento semprecedentes, seria legítimo supor queos mesmos princípios pudessem vira suportar a evolução para a Internetdo futuro.

Há, no entanto, sinais que nos fa-zem supor que a médio ou a longoprazo, poderemos estar confronta-dos com a necessidade de operartransformações radicais em algunsdos princípios básicos da Internet.

2.1. A transformação daampulheta IPA Internet foi concebida em torno deum pequeno conjunto de ideias fun-damentais. Uma dessas ideias foi atransparência entre os pontos extre-mos da comunicação e a concentra-ção da inteligência nesses pontos,permitindo dessa forma o desenvol-vimento de novas aplicações e servi-ços, sem implicar alterações nonúcleo da rede. Outra ideia funda-mental foi a adopção do modelo con-nectionless, em que o conteúdo decada unidade de informação, ou pa-cote, é suficiente para que a rede façao seu encaminhamento, sem neces-sidade de sinalização ou qualquertipo de mecanismos de controlo.

A concepção da arquitectura da Inter-net colocou a ênfase em caracterís-ticas como robustez, simplicidade,adaptabilidade e capacidade decrescimento. Cabe ao protocolo IPfuncionar como único denominadorcomum ao longo da rede. Por um la-do, garante-se a interoperabilidade auma escala global, independente-mente da tecnologia; por outro lado,reduzindo o IP a um conjunto dimi-nuto de funções, minimiza-se acomplexidade da rede e o custo dasua operação. Do protocolo IP, es-

119

pera-se basicamente que sejacapaz de transmitir pacotes entreorigem e destino.

É habitual utilizar a analogia da am-pulheta, representada na Figura 1,para descrever esta ideia – acima ouabaixo da “cintura estreita” do IP podeconstruir-se uma enorme diversidadede protocolos, constituindo o IP o úni-co elemento comum.

Neste contexto, não surpreende queas principais inovações e avanços daInternet ao longo das últimas déca-das se tenham realizado essencial-mente no nível de aplicação (porexemplo, World Wide Web, motoresde busca, telefonia IP) ou abaixo donível de rede (por exemplo, VPNMPLS) — em qualquer dos casos,sem qualquer impacto no nível de re-de, ou seja, no protocolo IP [2].

As evoluções da Internet relaciona-das de alguma forma com o nível derede podem dividir-se em dois gru-pos: as que foram concebidas paradar resposta ao aumento de escalae as que introduziram novas aplica-ções ou funcionalidades, não con-templadas no projecto original da In-ternet.

No primeiro grupo incluem-se, entreoutros, o DNS (Domain Name Sys-tem), para permitir implementar umsistema de nomes a uma escala glo-bal; o CIDR (Classless Inter-DomainRouting), para permitir a sustenta-bilidade do espaço de endereça-mento; os protocolos de routingOSPF e IS-IS, para possibilitar oencaminhamento num domínio ad-ministrativo de rede de forma esca-lável, e o BGP, para possibilitar o en-caminhamento entre diferentesdomínios administrativos. Do segun-do grupo fazem parte soluções co-mo Mobile IP, IPsec, IP multicast,IntServ/DiffServ, concebidas para darresposta à necessidade de introduzirnovas funcionalidades, respectiva-mente mobilidade, segurança, comu-nicação ponto-multiponto (multicast)e qualidade de serviço.

O Impasse da Internet

Figura 1 – O modelo da ampulheta: IPsobre qualquer coisa; qualquer coisa sobre IP


Directa ou indirectamente, o preçoa pagar por estas novas funcionali-dades foi o progressivo aumento decomplexidade do IP, com o conse-quente alargamento da “cintura es-treita” da ampulheta. Mais grave doque isso, as novas funcionalidadesforam sendo introduzidas de formaisolada, muitas vezes sem ter emconta a necessidade de satisfazeroutros requisitos, nem considerareventuais impactos colaterais.

Ou seja, apesar de haver soluçõespara mobilidade, segurança, multi-cast e qualidade de serviço, continu-ou a ser muito complicado, ou mes-mo impossível, conciliar as quatrofuncionalidades numa mesma rede.

Por outro lado, a implementação denovas funções foi sendo conseguidaà custa de princípios fundamentaisdo modelo original da Internet. Porexemplo, o princípio da transparên-cia extremo-a-extremo é posto emcausa com a introdução das cha-madas “middle boxes”, realizandofunções de firewall ou tradução deendereços (NAT); daqui resultam,por sua vez, problemas com umconjunto importante de aplicações.

2.2. Novas preocupaçõesEm diversos aspectos fundamen-tais, a Internet mudou radicalmentenas últimas duas décadas. O au-mento de escala foi a transformaçãomais evidente. Nos anos 90, a es-cassez do espaço de endereça-mento IPv4 foi o primeiro sintomadesse problema (ver à frente). Naverdade, a questão não se restringeà escassez do espaço de endere-çamento. O rápido crescimento dastabelas de encaminhamento nosrouters de núcleo da Internet (a cha-mada “default-free zone”) constituioutro problema de escalabilidade,porventura mais complicado de re-solver [6]. Até agora, o aumento da

capacidade dos routers da Internet,seguindo a lei de Moore, tem per-mitido acompanhar o ritmo de cres-cimentoda internet, resolvendo as-sim a questão. Mas há dúvidas deque seja possível manter a situaçãopor muito mais tempo, a permanecera tendência actual. Ao contrário daescassez de endereços, não pareceque neste caso o IPv6 traga um gran-de valor acrescentado e pode atécontribuir para agravar o problema[3][4][5].

Uma outra classe de problemas re-sulta simplesmente de já não seremválidas premissas fundamentais quenortearam a concepção da Internethá duas ou três décadas atrás. A In-ternet foi originalmente concebidapara garantir a conectividade ponto-a-ponto entre nós fixos. Independen-temente da forma como evoluir a In-ternet no futuro, uma coisa parececlara – o acesso será feito maiorita-riamente através de dispositivos mó-veis sem fios.

O Mobile IP foi criado para permitirmobilidade, mas não para cenáriosde mobilidade generalizada. A raizde uma boa parte destes problemasestá na natureza do endereço IP ena necessidade de que um equi-pamento mude de endereço IPsempre que se desloca de uma redepara outra. Esta necessidade resultada dupla função de identificação elocalização do endereço IP. O aco-plamento das duas funções faziatodo o sentido nos primórdios da In-ternet, em que os nós eram fixos,mas não em cenários em que a mo-bilidade é a regra, e não a excepção.Infelizmente, também neste aspec-to, o IPv6 não trouxe novidades re-lativamente ao IPv4 [4].

Finalmente, o próprio modelo de ca-madas do TCP/IP (ilustrado na Fi-gura 1), herdado do modelo OSI3, é

posto em causa. Por um lado, an-tevê-se que uma grande parte dosdispositivos ligados à Internet no fu-turo (por exemplo, sensores) dispo-nham de recursos computacionaise energéticos muito limitados, tor-nando o processamento da pilha IPum desafio complicado.

Por outro lado, as especificidadesdos sistemas wireless, com desta-que para a variação dinâmica dascaracterísticas físicas da ligação (in-terferências, mobilidade, propaga-ção “multipath”) ou a conectividadeintermitente, desaconselham a sepa-ração estrita das funções associa-das a diferentes camadas, tal comopreconizado no modelo OSI, e obri-gam à interacção entre camadasnão adjacentes [8].

2.3. Resistir à mudança: as liçõesdo IPv6No início dos anos 90 começou aficar claro que, a manter-se o ritmode crescimento da Internet queentão se verificava, o espaço de en-dereçamento IP (limitado a 32 bits)seria esgotado em pouco tempo.Pela primeira vez, foi necessáriorever uma característica fundamen-tal do protocolo IP.

O IPv6 foi então proposto como so-lução para resolver o problema – oaumento do espaço de endereça-mento de 32 bits para 128 bits seriasuficiente para oferecer a cadahabitante do planeta aproximada-mente 5 x 1028 endereços IP. Acre-ditou-se nessa altura que o principalproblema do futuro da Internet es-tava resolvido e que até ao final doséculo XX ter-se-ia registado umasubstituição quase total do IPv4 peloIPv6. Esta previsão falhou completa-mente. Por um lado, a utilização detécnicas de CIDR e NAT foi permi-tindo mitigar o problema da escas-sez de endereços e a premência de

3Na forma de definir e implementar protocolos de comunicação, o TCP/IP seguiu basicamente os princípios do modelo OSI, embora usando um conjuntomais reduzido de camadas. No modelo OSI, cada camada fornece serviços à camada imediatamente superior e usa os serviços da camada imediatamenteinferior. O modelo de camadas torna as funções específicas de cada camada transparentes em relação às restantes e facilita dessa forma a interoperabilidadeentre diferentes tipos de hardware e software.

121 O Impasse da Internet

realizar a migração. Acima de tudo,o que este processo permitiu de-monstrar foi a enorme resistência aqualquer mudança que tenha im-pacto no núcleo da rede (que, no ca-so do IPv6, nem sequer implicavarupturas profundas). Face aos pesa-dos investimentos que uma migra-ção para IPv6 iria implicar, e não ha-vendo uma clara expectativa deretorno desses investimentos, ouuma oportunidade significativa denegócio a explorar, os operadorestendem a protelar essa mudançaaté que ela seja de facto inadiável4.

3. Futuro – como sair do impasseÉ hoje claro que a Internet assentanuma complexa teia de remendos eque, em muitos aspectos, já tempouco a ver com a visão dos seuscriadores. Por outro lado, não é pos-sível dar passos em frente e respon-der aos desafios da Internet actual efutura sem pôr em causa alguns dosfundamentos da sua arquitectura. Ouseja, o que está em causa não é arealização de mais uma etapa nopercurso evolutivo do IP (IPv7?), masuma abordagem radicalmente nova.

Infelizmente, como ficou demons-trado pelo caso do IPv6, no estadoactual da Internet, empreender umatal mudança a uma escala globalconstituiria uma tarefa gigantesca ede sucesso muito duvidoso.

Verifica-se portanto um ciclo viciosona Internet – por um lado, para ultra-passar os seus problemas e limi-tações seria necessário mudar as-pectos fundamentais da arquitectura;por outro lado, para que estas trans-formações pudessem ocorrer, serianecessário realizá-las globalmente deforma concertada, o que não é viável,como o IPv6 demonstrou claramente.É neste contexto que começam aser olhadas com alguma atenção astecnologias de virtualização de rede.

A virtualização tem sido utilizada emdiversos contextos e aplicações. Porexemplo, técnicas de virtualizaçãosão hoje frequentemente usadaspara possibilitar uma utilização efi-ciente de recursos computacionaisem data centres.

Em redes IP, a virtualização também

não é uma ideia nova – o conceitode router virtual já existe há bastantetempo e as VPN BGP/MPLS po-dem ser vistas em parte como umavariante desse conceito, limitandoa virtualização à periferia da rede.

A virtualização permite a construçãode múltiplas redes isoladas, e inde-pendentes entre si, sobre uma infra--estrutura de rede comum. A Figura 2ilustra o conceito.

Do ponto de vista da evolução daInternet, a virtualização oferece vá-rias vantagens potenciais [7]:

> A possibilidade de conceber e ex-perimentar novas soluções, semos constrangimentos e as limita-ções das tecnologias actuais (no-meadamente IP);

> A possibilidade de fazer umamigração faseada para novas so-luções e arquitecturas, sem pôrem causa as redes e os serviçoslegacy.

A Figura 2 ilustra o conceito.

Naturalmente, a virtualização não é,só por si, a solução para resolver osproblemas da Internet. Para isso énecessário conceber novas arqui-tecturas de rede pensadas de raizpara dar resposta a problemasactuais e futuros , alguns já afloradosanteriormente. Mas a virtualizaçãopode ser a chave para resolver oimpasse que se verifica actualmente,possibilitando a introdução gradualde novas tecnologias ficando a suaadopção em larga escala natural-mente ditada pela necessidade eleis do mercado.

4. O papel dos operadoresNo início dos anos 90, a primeira on-da da Internet apanhou os opera-dores de telecomunicações despre-

Figura 2 – Arquitectura básica de virtualização

4Curiosamente, uma outra tecnologia concebida e lançada algum tempo depois do IPv6 acabou por ter um sucesso bem maior nas redes dos operadores– o MPLS. Ao contrário do IPv6, o MPLS proporcionou novos negócios aos operadores – as VPN BGP/MPLS constituem hoje uma importante fonte dereceitas. Outra diferença significativa em relação ao IPv6 foi o facto de o MPLS ter sido concebido como tecnologia intra-domínio, o que deu a cada operadora liberdade de implementar e tirar partido da tecnologia, independentemente de outros operadores o fazerem, ou não.

Referências[1] Internet Usage Statistics - The Internet BigPicture,http://www.internetworldstats.com/stats.htm[2] M. Handley, Why the Internet only just works,BT Technology Journal, Vol 24, No 3, Julho 2006[3] G. Huston, Addressing and the Future Internet,http://ispcolumn.isoc.org/2007-02/address-paper.pdf, Fevereiro 2007[4] G. Huston, The Mythology of IP Version 6, TheInternet Protocol Journal, Vol. 6, No. 2, Junho2003[5] D. Meyer, L. Zhang, K. Fall. IETF RFC 4984,Report from the IAB workshop on routing andaddressing, Setembro 2007[6] BGP Routing Table Analysis Reports, http://bgp.potaroo.net/[7] T. Anderson, L. Peterson, S. Shenker, J. Turner,Overcoming the Internet Impasse through Virtualization, Computer, Abril 2005[8] S. Choi, D. Perry, S. Nettles, A Software Architecture for Cross-Layer Wireless Network Adaptations, Seventh Working IEEE/IFIP Conference onSoftware Architecture (WICSA 2008), Fevereiro2008.

venidos e sem uma estratégia clarapara lidar com o fenómeno entãoemergente.

Apesar do sucesso sem preceden-tes, raramente a Internet constituiupara os operadores uma fonte inte-ressante de receitas. A base do pro-blema está na dificuldade em esta-belecer modelos de negócio que nãoestejam focados exclusivamente naconectividade e no transporte detráfego indiferenciado (best effort). Iro-nicamente, as mesmas caracterís-ticas que funcionaram como alavan-cas para o crescimento da Internet(por exemplo, a transparência ex-tremo-a-extremo) têm constituídopara os operadores um obstáculoao estabelecimento de modelos denegócio atractivos.

Existe um claro confronto, aliás jáantigo, entre visões sobre o papelda rede e dos operadores na Inter-net. Do ponto de vista dos operado-res convencionais e das infra-estru-turas de rede, há um problema pararesolver – o avanço da Internet paranovos serviços implica investimen-tos pesados, nomeadamente nasredes de acesso, mas esses inves-timentos só poderão ser feitos seexistir uma expectativa clara deretorno. Um modelo baseado exclu-sivamente na conectividade e na lar-gura de banda, como o que existiriase os operadores incumbentes fi-cassem reduzidos ao papel de pro-vedores de conectividade, não pa-rece ser suficiente como incentivopara o investimento na renovaçãodas infra-estruturas de rede.

Para os operadores de telecomuni-cações, em particular para os cha-mados incumbentes, a virtualizaçãode rede pode apresentar novas opor-tunidades mas também novos desa-fios. Os operadores actuais executamfrequentemente uma dupla função –por um lado, mantêm e gerem a infra--estrutura de rede; por outro lado,fornecem serviços aos utilizadoresfinais. A virtualização de rede poderácontribuir para a separação destas

Jorge Carapinha obteve a Licenciatura em Engenharia Electrotécnica, Ramo de Informática,pela Faculdade de Ciências e Tecnologia da Universidade de Coimbra (1984) e Mestrado emElectrónica e Telecomunicações pela Universidadede Aveiro (1998). Desde 1985 é colaborador daPT Inovação (anteriormente CET). No âmbito deprojectos nacionais e internacionais tem desenvolvido actividades em diversos domínios, comdestaque para tecnologias de redes de núcleo,redes privadas virtuais e qualidade de serviço.Presentemente coordena a participação da PTInovação no projecto 4WARD, “Architecture andDesign for the Future Internet”, no âmbito do FP7.

M. Teresa R. L. de Almeida, é licenciada emFísica Aplicada à Óptica e Electrónica, pela FCUP,1986. De 1987 a 1989 foi bolseira da JNCIT, emC&T, no LIP e integrou a equipa DELPHI, no CERN.Desde 1989 colaboradora da PT Inovação, especializou-se em redes ópticas DWDM, actualmenteparte do grupo Plataformas e Redes Multiserviço,Área Investigação Aplicada e Difusão do Conheci-mento. Participou em vários projectos nacionaise internacionais, estando actualmente a colaborarno projecto 4WARD, do sétimo Programa QuadroComunitário. É autora e co-autora de várias publi-cações.

duas funções ao permitir a definiçãode uma fronteira clara entre fornece-dores de infra-estrutura e fornecedo-res de serviços.

Os operadores incumbentes nãopodem alhear-se deste processo derenovação da Internet sendo sobre-tudo necessário que percebam e par-ticipem na definição dos novos mo-delos de negócio, cadeias de valor epapéis dos vários actores intervenien-tes nos cenários que se vão dese-nhando para a Internet do futuro.

5. ConclusõesAs expectativas sobre a Internet sãohoje bem diferentes das existentesquando a Internet foi criada; porém,apesar da mudança de expectativase requisitos, a Internet mostrou pos-suir uma admirável capacidade deadaptação, ainda que por vezes àcusta de princípios fundamentais,como a transparência da rede.

Contudo, é hoje claro que algumascaracterísticas básicas do IP consti-tuem um problema para responderadequadamente a novos desafios daInternet e que são necessárias solu-ções de ruptura. No passado recente,a experiência do IPv6 mostrou que,dada a dimensão que a Internet atin-giu, qualquer solução que tenha im-pacto no núcleo da rede a uma es-cala global, dificilmente terá viabilidadeprática.

Neste aparente beco sem saída, avirtualização surge como solução pa-ra ultrapassar o impasse actual efuncionar como ponte para o futuro.Ao permitir a coexistência de velhas


Arquitectura IMS e MBMS Integrada123

palavras-chave:MBMS, IMS, Arquitectura,

Integração, C-MOBILE

Nos últimos anos, tem-se assistidoa uma procura crescente de ser-viços multimédia. O serviço MobileTV é já uma realidade em vários paí-ses, tendo-se revelado um grandesucesso comercial. Para além disso,tem-se verificado a distribuição decontéudos multimédia por gruposde utilizadores, confirmando a ten-dência Web 2.0. O 3GPP tem normalizado duas extensões à normaUMTS para possibilitar a distribuiçãode conteúdos multimédia: o IMS (IPMultimedia Subsystem) e o MBMS(Multimedia Broadcast MulticastService). O IMS providencia um conjunto de novas funcionalidades à rede core, facilitando a gestão de recursos, o controlo de admissão enovos mecanismos de tarifação. OMBMS possibilita o envio de dados

Hugo Cabral

em modo broadcast e multicast nasredes UMTS. A integração destesdois sistemas possibilitará o enviode conteúdos multimédia, usandocanais unicast, multicast e broadcast, de uma forma eficaz, poupando recursos da rede. A integraçãodestes dois sistemas possibilita ainda o desenvolvimento rápido de novos serviços devido às diferentesinterfaces normalizadas. Este artigoirá apresentar uma arquitectura integrada dos sistemas MBMS e IMS,realçando os resultados obtidosatravés de uma rede de teste.

Filipe Pinto

João Gonçalves

António Videira


1. IntroduçãoActualmente, as redes 3G utilizamexclusivamente ligações dedicadas,isto é, estabelecem um canal porcada ligação entre o emissor e o re-ceptor. Este modo de comunicaçãoé denominado de unicast. Este mo-do não é eficaz quando existe umgrande número de utilizadores a que-rer aceder em simultâneo ao mesmoconteúdo, devido ao elevado consu-mo de recursos de rede. Um exem-plo óbvio é o que acontece actual-mente no serviço Mobile TV, em queé criada uma ligação ponto-a-pontoentre cada telemóvel e o servidor. Deforma a optimizar a utilização dos re-cursos de rede, o 3GPP desenvolveuo MBMS na sua Release 6 [1]. OMBMS é o sistema utilizado nas re-des 3G para transmitir a informaçãoem modo broadcast e multicast paragrupos de utilizadores. O MBMSpossibilita a transmissão de streamsde vídeo e áudio, bem como a distri-buição de ficheiros. Como os recur-sos são partilhados, haverá umaefectiva poupança da capacidade darede, sobrando canais livres paraoutros serviços. Assim, a distribuiçãode conteúdos Web 2.0 por grupos

de utilizadores torna-se ainda maisatractiva para os operadores móveis.Para além disso, o MBMS poderásuportar o Mobile TV, convertendo--o num serviço de baixo custo, tor-nando-o mais apetecível para poten-ciais clientes. Como o tráfego alvo émultimédia, faz sentido pensar eminteracções com o IMS. A Release 5do 3GPP define o IMS como o sub--sistema utilizado para a gestão detráfego IP nas redes UMTS, permi-tindo serviços multimédia indepen-dentes das tecnologias de acesso,assegurando a qualidade do serviço[2]. Devido às suas interfaces norma-lizadas, é também possível a integra-ção de diferentes serviços, garan-tindo mais, e melhores, serviços aosclientes das redes móveis. Mas oIMS foi desenhado para lidar apenascom ligações ponto-a-ponto. Paraserviços envolvendo grupos de uti-lizadores que pretendem receber amesma informação em simultâneo,esta característica torna-se umagrande limitação, devido ao desper-dício de recursos. Quando se olhamais em detalhe para os sistemasIMS e MBMS, consegue-se vislum-brar possíveis sinergias: o IMS para

controlar as sessões usando sinali-zação SIP (Session Initiation Proto-col) e o MBMS para distribuir os con-teúdos em modo unicast, multicastou broadcast [5]. Desta forma, serápossível a integração de uma pa-nóplia de serviços que poderãoutilizar ligaões dedicadas ou parti-lhadas, enviando os seus conteúdosmultimédia para grupos de utiliza-dores, garantindo a utilização dos re-cursos de rede da forma mais eficaz.

Para que tal aconteça, é necessárioo desenvolvimento de uma arquitec-tura integrada, com novas interfacese funcionalidades, estendendo os pro-tocolos existentes, de forma a con-trolar os canais unicast, multicast ebroadcast, garantindo a entrega deconteúdos Web 2.0 e serviços Mobi-le TV a comunidades de utilizadores.

Este artigo pretende descrever a ar-quitectura integrada dos sistemasIMS e MBMS. A sua estrutura estádividida da seguinte forma: na sec-ção 2 é feito um sumário das tecno-logias IMS e MBMS; na secção 3são estudadas as diferentes abor-dagens para a integração destes

dois sistemas; a secção 4 apresen-ta os principais resultados obtidos;por fim, na secção 5 são apresent-adas as principais conclusões.

2. Estado da arte2.1. IMSO IMS aparece na Release 5 do 3G-PP como uma extensão da arquitec-tura do UMTS, adicionando-lhe umconjunto de novas funcionalidadesinterligadas por interfaces normaliza-das. O IMS utiliza SIP para a gestãodas comunicações multimédia, as-segurando qualidade de serviço atra-vés de mecanismos de reserva derecursos. O IMS possibilita novosmecanismos de tarifação, tendo emconta o tipo de dados a transmitir. O

IMS permite ainda a integração demais e melhores serviços, cativandoassim novos clientes. A Figura 1 a-presenta a arquitectura IMS, tal comodefinida pela Release 5 do 3GPP.

2.2. MBMSO MBMS surgiu na Release 6 do 3G-PP com o objectivo de possibilitar atransmissão eficiente de dados deuma fonte para múltiplos utilizadoresatravés da rede móvel. Nestesistema, os canais são partilhadospor grupos de utilizadores, poupan-do-se assim recursos de rede. A ar-quitectura MBMS é uma evoluçãoda rede UMTS, em que os elementosda rede, desde o UE até ao GGSN,sofrem modificações. Para além

125

disso, no sistema MBMS apareceum novo elemento de rede denomi-nado de BM-SC (Broadcast Multi-cast Service Centre). Este elementoé responsável pela gestão de recur-sos e implementação dos diferentesserviços. O MBMS tem dois modosde operação: o broadcast e o multi-cast. A principal diferença entre elesé que o multicast necessita de umcanal de retorno para que o utiliza-dor manifeste o seu interesse em sejuntar ou abandonar um determina-do grupo.

A Figura 2 apresenta a arquitecturaMBMS.

3. Integração entre IMS e MBMSTal como descrito em [4], existembasicamente duas possibilidadespara a integração entre o IMS e oMBMS: a centralizada e a distribuí-da. Neste capítulo serão abordadasestas duas soluções. Por fim, é a-presentada a arquitectura definidano âmbito do Projecto Europeu C--MOBILE, que se baseia na arqui-tectura distribuída para efectuar aintegração dos dois sistemas [5].

O C-MOBILE teve como objectivoo desenvolvimento das tecnologiasde broadcast e multicast em redesmóveis beyond 3G, considerandouma rede convergente global commúltiplos canais de transporte dediferentes tecnologias.

3.1. Arquitectura centralizadaA arquitectura centralizada pretendepreservar ao máximo os dois siste-mas existentes. Significa isto que,tanto o IMS, como o MBMS, devempermanacer com todas as suas fun-cionalidades. No entanto, será sem-pre necessário evoluí-las de forma aque possam interagir entre si atravésde novas interfaces. Neste modo deintegração, todas as entidades exis-tentes são mantidas e nenhuma no-va está prevista. Os serviços IMSusarão os canais multicast e broad-cast estabelecidos pelo MBMS pa-ra efectuar a distribuição dos con-teúdos aos utilizadores interessados.

Arquitectura IMS e MBMS Integrada

Figura 1 – Arquitectura IMS definida na release 5 do 3GPP

Figura 2 – Arquitectura MBMS definida na release 6 do 3GPP

Service Plan

Application Server

Control Plane

Access and Transport Plane

Service Plane

Control Plane


ContentProvider


dois sistemas foram desenvolvidosos seguintes enablers: session mana-gement para efectuar a gestão dassessões usando SIP, service announ-cement para anunciar os serviçosaos utilizadores, service schedullingpara agendar as transmissões, con-tent management para gerir os con-teúdos disponíveis e o context ba-sed group management, que criagrupos de acordo com a informaçãode contexto. Esta camada segue asorientações da OMA (Open MobileAliance) na definição dos seus ena-

A Figura 3 apresenta a arquitecturacentralizada.

3.2. Arquitectura distribuídaNa arquitectura distribuída, a inte-gração do IMS e MBMS faz-sedistribuindo as funcionalidades doBM-SC por variados elementos doIMS. Assim, nesta arquitectura, oBM-SC deixa de existir, mas assuas funcionalidades permanecem.As entidades do IMS são evoluídasde forma a assegurarem todos osmecanismos necessários à gestãodos serviços multicast e broadcast.A Figura 4 apresenta a arquitecturadistribuída da integração dos siste-mas IMS e MBMS.

3.3. Arquitectura integradaA arquitectura integrada entre IMSe MBMS aqui apresentada foi de-senvolvida no âmbito do projectoeuropeu C-MOBILE, tendo seguidoo modelo distribuído [4]. A arquitec-tura engloba um conjunto de cincocamadas, denominadas de Accessand Transport Plane, Delivery Plane,Control Plane, Service Enabler Pla-ne, e, finalmente, Application Plane,englobando ainda dois pontos ex-tremos, o User Plane e o ContentProvider Plane. A Figura 5 apre-senta a arquitectura definida.

A camada de Access and TransportPlane engloba o acesso rádio e co-re, assegurando as questões dequalidade de serviço. A Figura 5 sa-lienta a arquitectura LTE/SAE (LongTerm Evolution / System Architec-ture Evolution), mas a arquitecturasuporta também diferentes redesde acesso, como por exemploDVB-H, WLAN ou WiMAX.

A camada Media Delivery Plane éresponsável pelo processamentodos conteúdos. Recebe os contéu-dos do Content Provider através deligações dedicadas e distribui-osaos subscritores, usando ligaçõesunicast, multicast e broadcast. OMDFP é uma evolução do MRFP,adaptado para possibilitar tambémo envio de ficheiros, usando os dife-

rentes modos de transmissão. OControl Plane consiste nas entidadestípicas do IMS, tais como os diferen-tes CSCF. O MDFC é uma evoluçãodo MRFC e controla o MDFP, dando--lhe instruções sobre o que, e como,transmitir.

Na camada Service Enabler Planeestá disponível um conjunto de fun-cionalidades que podem ser usadaspelas diferentes aplicações.

Para possibilitar a integração dos

Figura 3 – Arquitectura IMS e MBMS centralizada

Figura 4 – Arquitectura IMS e MBMS centralizada

Control Plane


Service Plane

Service Plane

Control Plane


127 Arquitectura IMS e MBMS Integrada

blers, tornado-os reutilizáveis emdiferentes aplicações.

A camada Application Plane permiteo desenvolvimento de serviços, ofe-recendo aos utilizadores serviçospersonalizados, que serão distribuí-dos usando canais unicast, multi-cast ou broadcast.

Relativamente aos pontos extre-mos, o User Plane refere-se ao utili-zador que recebe os conteúdosatravés da rede do operador. Naoutra extremidade está o ContentProvider que fornece os conteúdosque deverão ser distribuídos pelosgrupos de utilizadores interessados.

4. Resultados4.1. TestbedComo forma de apresentar as po-tencialidades da arquitectura defi-nida, foi implementado um demons-trador no âmbito do projectoeuropeu C-MOBILE. Este demons-trador utilizou diversas tecnologias

como suporte à sua implementação.Nesta secção vão ser enumeradasas tecnologias utilizadas e vai serexplicado o seu papel na realizaçãoda arquitectura definida.

Os componentes do Service Ena-bler Plane e do Application Plane fo-ram implementados modularmenteem cima de um Application Server(AS) Java Enterprise Edition 5. Oscomponentes do Control Plane ne-cessários ao funcionamento do sis-tema são o HSS e os CSCF. Para odemonstrador foi utilizada a imple-mentação open-source Open IMSCore destes componentes. O MediaDelivery Function (MDF) inclui oMDFP e o MDFC, tendo sido desen-volvido como uma aplicação nativade Linux, à semelhança do MulticastRouter. Como terminais foram usa-dos os Internet Tablets Nokia N800.A Figura 6 mostra o diagrama geralda testbed.

Como AS foi utilizado o projecto Sailfin.

O Sailfin é uma variante do Glassfish,a versão open-source do Sun Appli-cation Server. Estes AS respeitam aJava Specification Request (JSR)244 relativa às funcionalidades doJava Enterprise Edition 5. Respeitamtambém a JSR 220 relativa à defini-ção dos Enterprise Java Beans 3.Estas duas especificações definemfuncionalidades que são essenciaispara a produção rápida de novosserviços e funcionalidades, e que fa-cilitam a escrita de código modulare de qualidade. O que o Sailfin vemacrescentar aos seus antecessoresé a integração com uma implemen-tação da JSR 116 (SIP Servlets 1.0),originalmente desenvolvida pelaEricsson e recentemente tornadaopen-source. Nesta JSR está pre-vista a utilização do paradigma servlet,bem conhecido no Java, para o pro-tocolo SIP.

O Open IMS Core é uma implemen-tação open-source de quatro enti-dades IMS: HSS, I-CSCF, S-CSCF

Figura 5 – Arquitectura integrada MBMS-IMS

User Plane

Application Plane

Service Enabler Plane

IMS-based Control Plane

Media Delivery Plane

Access and Transport Plane ContentProviderPlane

ContentManager

ContentManagement

Enabler

ServiceScheduling

Enabler

Content-basedGroup

ManagementEnabler

ServiceAnnouncement

Enabler

SessionManagement

Enabler

Evolved RAN Evolved PacketCore

Streamingand Download

Source


e P-CSCF. Esta implementação émantida pela Fraunhofer FOKUS,empresa parceira na PT Inovaçãoem vários projectos europeus, entreos quais o C-MOBILE.

O HSS é implementado em Java 5,enquanto que os CSCF são imple-mentados em C nativamente sobreLinux.

O MDF foi implementado em C e cor-re sobre Linux usando várias bibliote-cas open-source das quais vale apena realçar algumas: GStreamerpara a manipulação de formatos estreams media; SofiaSIP como stackSIP; MAD-FLUTE como motor do pro-

tocolo FLUTE, utilizado no MBMS.

Os terminais utilizados, os Nokia N-800, correm um sistema operativobaseado em Linux. Apenas têm Wi-Ficomo interface de rede, e por estarazão foi a tecnologia de acesso utili-zada no demonstrador.

Utilizando as bibliotecas disponíveisfoi desenvolvido uma aplicação parao terminal que permite apresentaras funcionalidades implementadas.

4.2. Principais resultadosAs funcionalidades implementadasdividem-se essencialmente em doiscenários de utilização: Content Cast-

ing e Interactive TV. No caso de Con-tent Casting, o utilizador recebe fi-cheiros media que posteriormentepodem ser visualizados. Neste ce-nário são possíveis várias funcionali-dades adicionais: o escalonamentoda entrega dos conteúdos, tendoem conta a disponibilidade da rede;o desencadeamento de entregas deconteúdos devido à localização dosutilizadores interessados, de modoa optimizar a poupança de recursosdo multicast; e o aprovisionamentoe entrega de conteúdos geradospelo utilizador. No caso do Interac-tive TV, o utilizador vê um canal detelevisão em tempo real. É possívelconsultar o Electronic Program Gui-de (EPG) para esse canal, e caso oContent Provider assim deseje, épossível iniciar votações relativas aocanal, como por exemplo votaçãopara o programa que vai dar de se-guida.

O Nokia N800 permite interagir como sistema de modo a subscrever aserviços de conteúdos e receberanúncios das sessões que se vãorealizar. Depois de receber os anún-cios, o utilizador pode escolher re-ceber um determinado conteúdo ouver um determinado canal. A Figura7 mostra um dos Nokias utilizados acorrer a aplicação desenvolvida noprojecto C-MOBILE. Encontra-se dis-ponível no site do YouTube um con-junto de vídeos refentes à testbed de-senvolvida no projecto C-MOBILE [6].

5. ConclusõesAs redes 3G têm vindo a evoluir pa-ra dar resposta à crescente procurade serviços multimédia. O 3GPPcomeçou por normalizar o IMS na suaRelease 5 para gerir sessões mul-timédia. Já na Release 6, o 3GPPnormalizou o MBMS que permite oenvio de pacotes em modo multicaste broadcast sobre as redes UMTS.O projecto C-MOBILE pretendeuevoluir o MBMS, e propôs a suaintegração com o IMS, definindouma arquitectura distribuída destesdois sistemas. Desta forma, os servi-ços multicast e broadcast passaram

Figura 6 – Diagrama da Testbed

Figura 7 – Nokia N800

WirelessTerminals

OpenIMSCore

ApplicationServer

ContentProvider

MediaDeliveryFunction

ThirdParty

NetworkCore

NetworkAccessNetwork

MulticastRouter

WirelessAccessPoint

Referências[1] 3GPP TS 23.246 V6.12.0 (2007-06), MultimediaBroadcast/Multicast Service (MBMS), Architectureand funct ional descr ipt ion (Release 6)[2] 3GPP TS 23.228 V5.15.0 (2006-06), IP Multimedia Subsystem (IMS) (Release 5)[3] F. Cabral Pinto, M. Knappmeyer, A. Al-Hezmi:Signaling for IMS and MBMS Integration; 17th ICTMobile and Wireless Communications Summit,Stockholm, Sweden, June 2008[4] 3GPP TR 23.847 V1.0.0 (2007-02), Study onEnhancements to IMS Service FunctionalitiesFacilitating Multicast Bearer services (Release 8)[5] http://c-mobile.ptinovacao.pt/[6]http://www.youtube.com/istcmobile[7] M. Sher, F. C. Gouveia, T. Magedanz, IP Multimedia Subsystem (IMS) for Emerging All-IP Networks, Encyclopedia of Internet Technologies andApplications, Mário Freire & Manuela Pereira (editors), Idea Group Inc. (publisher), 2006.

Filipe Cabral Pinto, licenciado em EngenhariaElectrotécnica pela Universidade de Coimbra, commédia final de 15 valores, concluiu o mestrado emtelecomunicações, pela Queen Mary University ofLondon, com a classificação final de Distinction.Actualmente investiga a utilização de informaçãode contexto na optimização de serviços multicast,no âmbito do Projecto Europeu C-CAST. Ao longodo seu percurso na PT Inovação desenvolveuactividades nos Projectos Europeus C-Mobile, B--BONE, EVEREST, OPIUM e NETGATE. Colaborouainda no projecto e instalação de diversas redesde transmissão de dados.

António Videira, Licenciado em Engenharia deSistemas e Informática pela Universidade do Minhoe Mestre em Engenharia Electrónica e Tele-comunicações pela Universidade de Aveiro. Participa desde 2000 em diversos projectos na áreade serviços e redes móveis na PT Inovação. Assumiu em 2004 a responsabilidade técnica pelaplataforma de localização (Locacel) que suportaactualmente os serviços de localização da maioroperadora de telecomunicações móveis em Portugal. Participou no projecto europeu C-Mobile eactualmente coordena os desenvolvimentos deserviços baseados em localização.

Hugo Cabral, licenciado em Engenharia Informática e Computação pela Faculdade de Engenhariada Universidade do Porto, desenvolveu actividadesno departamento de Serviços e Redes Móveis naPortugal Telecom Inovação SA desde Março de2004 até Março de 2008, nomeadamente nodesenho, arquitectura e implementação de umCentro de Mensagens Multimédia (MMSC), naexecução de aplicações para portais móveis(MWiPEP – i9), em processos de estatísticas deplataformas multimédia (DiNO e Video Streaming)e na colaboração no projecto Europeu C-Mobile.Actualmente desenvolve actividade no departamento de Desenvolvimento de Plataformas eProdutos, acumulando as funções já realizadascom a participação no desenvolvimento da plataforma de Mobile Advertisement e Gateway de Carregamentos.

João Miguel Gonçalves licenciou-se em Enge-nharia Informática pela Universidade de Coimbraem 2006 com média final de 15 valores. No mesmoano foi admitido como bolseiro no Instituto deTelecomunicações em Aveiro, no âmbito do projecto europeu C-MOBILE. Em Junho de 2008completou, com Distinção, o Mestrado em WirelessNetworks pela Queen Mary University of London.Em Setembro de 2008 foi contratado a termocerto pela PT Inovação para integrar o projectoeuropeu C-Cast, tendo paralelamente iniciado oprograma doutoral MAP-i.

a ser controlados pelas entidadesIMS usando sinalização SIP. Para a-lém disso, a integração destes doissistemas permite o rápido desenvol-vimento de novos serviços devidoao conjunto de enablers existente eàs diferentes interfaces normaliza-das. No âmbito do projecto europeuC-MOBILE, foi desenvolvido um de-monstrador que permitiu testar a ar-quitectura definida. Com este siste-ma integrado, conteúdos Mobile TVou o Web 2.0 passaram a ser dis-tribuídos por grupos de utilizadores,de umas forma mais eficiente, utili-zando canais unicast, multicast e

129 Arquitectura IMS e MBMS Integrada


palavras-chave:SAE, LTE, 3GPP, E-UTRAN,

UMTS, EPC

Para transportar uma nova geraçãode serviços móveis de banda larga o3rd Generation Partnership Project(3GPP) lançou o projecto Long TermEvolution (LTE) / System ArchitectureEvolution (SAE). A interface ar proposta para o LTE é significantemente dife-rente da existente na actual 3ª ge-ração. São usadas as tecnologiasOFDMA no sentido descendente paraobter débitos superiores a 100 Mbpse Single Carrier – FDMA no sentido

Álvaro Gomes

ascendente para conseguir débitosaté 50 Mbps. O 3GPP propõe também uma nova arquitectura mais simplificada, completamente baseada emIP. Os novos Nós B (eNB, E-UTRANNode B) que também desempenhamagora as funcionalidades de RadioNetwork Controller (RNC) estão directamente ligados à Serving Gateway (S-GW).

Filipe Pinto

Pedro Neves Carlos Silva(IT)

A Evolução da 3ª Geração Móvel,a Visão do 3GPP

131

1. IntroduçãoA última proposta do 3GPP con-siste na evolução da rede de aces-so rádio e da rede core de pacotes3G designada por LTE/SAE. O tra-balho desenvolvido pelo 3GPP nascomunicações móveis em geral enas interfaces rádio em particular aolongo dos anos não deve condi-cionar o desenvolvimento de futurossistemas. Nesse sentido o LTE/SAEtem o seu próprio caminho evolutivo(Figura 1). Não seguindo a evoluçãodo WCDMA e HSPA, o LTE/SAE de-fine gateways que interligam estasdiferentes tecnologias. A interfacerádio foi optimizada para transmis-sões em IP e não tem que suportartráfego ISDN, ou seja, não tem comorequisito o suporte aos serviços decomutação de circuitos que existiapara o WCDMA.

O WCDMA, HSDPA, e até o HSPA,estão em operação comercial emquase todo o mundo. O que signi-fica que a infra-estrutura HSPA jáestá instalada em milhares de sites,servindo milhões de utilizadorescom terminais que suportam asdiferentes versões do 3GPP que

têm vindo a ser introduzidas. A fi-losofia do 3GPP é continuar a evo-lução tecnológica do HSPA, masgarantindo, em simultâneo, a com-patibilidade com os terminais jáexistentes. Este requisito de com-patibilidade na evolução do HSPAcondiciona a sua evolução tecno-lógica, que o LTE não tem [1].

Neste documento iremos abordar anova arquitectura que é constituídapela Evolved Universal TerrestrialRadio Access Network (E-UTRAN)e a Evolved Packet Core (EPC), es-quematicamente representada na Fi-gura 2. A parte da rede de acesso,designada por E-UTRAN [2], é com-posta apenas pela estação base, E--UTRAN Node B (eNB), que pro-porciona a interface rádio e é res-ponsável pela gestão dos recursosrádio do sistema. Relativamente àrede de core, denominada por EPC[3], é composta por três entidadesdistintas: Serving Gateway (S-GW),actuando como uma âncora de mo-bilidade local para os User Equip-ments (UE); Mobility ManagementEntity (MME), cuja função é gerir osprocessos de mobilidade; e Packet

Gateway (P-GW), que permite a in-terligação da rede core com as re-des externas, como a rede IP Mul-timedia Subsystem (IMS) [4] [5] ouredes de acesso non-3GPP. Infor-mação detalhada sobre estas enti-dades será fornecida nas secçõesseguintes.

2. Evolved Universal TerrestrialRadio Access Network (E-UTRAN)A E-UTRAN é composta pelos eNBque estão interligados através da in-terface X2 (Figura 2). Cada eNB estáligado à rede EPC via interface S1.No plano de utilizador (user plane),a interface S1 termina na ServingGateway (S-GW), enquanto que noplano de controlo (control plane) ainterface S1 termina no Mobility Ma-nagement Entity (MME). Os eNBsão os pontos de terminação parao user plane e control plane no sen-tido do UE na E-UTRAN.

Na concepção da E-UTRAN, os se-guintes princípios foram tomados ematenção: separação lógica entre arede de transporte e controlo (sina-lização) e simplificação da divisãofuncional ao nível das interfaces.

Figura 1 – A evolução do 3G

Figura 2 – Arquitectura LTE/SAE

WCDMA HSPAHSDPA HSPA evolution

LTE

Sinalização Dados & Sinalização

E-UTRAN EPC

X2

S1

S1

S1S1

IMS

non-3GPP

2.1. E-UTRAN Node B (eNB)O eNB têm como funções principaisas seguintes [2]:

> Gestão dos recursos de rádio, coma implementação de funciona-lidades como controlo de admis-são, alocação dinâmica de recur-sos aos UE quer no sentido deuplink, quer no sentido de down-link, etc.;

> Compressão e encriptação do ca-beçalho IP das tramas provenien-tes do utilizador;

> Selecção de um MME para o UE,quando nenhum MME é especi-ficado na informação transmitidapelo UE;

> Broadcast da informação prove-niente do MME ou do centro demanutenção;

> Estabelecimento de rotas para ainformação proveniente do utili-zador em direcção à S-GW;

> Fazer/reportar medidas de parâ-metros de rede.

Na Figura 3 apresenta-se esquema-ticamente a divisão funcional entrea E-UTRAN e a EPC, com as diversasentidades/funcionalidades que asconstituem.

2.2. Interface RádioNesta subsecção é apresentada,de forma resumida, a arquitecturaprotocolar da interface rádio da E-UTRAN para o user plane e controlplane, bem como a camada física(PHY).

2.2.1. User Plane e Control PlaneNa Figura 4 mostra-se a stack pro-tocolar para o user plane e para ocontrol plane. No user plane as sub-camadas Packet Data ConvergenceProtocol (PDCP), Radio Link Control(RLC), Medium Access Control (MAC)executam, por exemplo, as funçõesde compressão de cabeçalhos, en-criptação, escalonamento, Automa-

tic Repeat Request (ARQ) e HybridAutomatic Repeat Request (HARQ).

No caso do control plane, as sub-camadas RLC e MAC executam asmesmas funções que no caso douser plane. A sub-camada PDCPfaz a protecção de integridade e en-criptação. A sub-camada Radio Re-source Control (RRC) executa, porexemplo, funções de mobilidade,controlo de medidas do terminal econtrolo de portadoras. A camadaNon-Access Stratum (NAS) é res-ponsável pela autenticação e con-trolo de segurança.


2.2.2. Camada Física (PHY)A camada física definida para a U-TRAN é extremamente eficiente natroca de mensagens de controlo ede dados. Esta camada implementatécnicas que ainda são relativamen-te novas nas redes celulares: Ortho-gonal Frequency Divison Multipexing(OFDM); Orthogonal Frequency Di-vision Multiple Access (OFDMA);Single Carrier – Frequency DivisionMultiple Access (SC-FDMA); e Multi-ple Input, Multiple Output (MIMO).

Os sistemas que implementam atécnica OFDM dividem a largura de

Figura 4 – Stack protocolar do user plane e control plane

UserPlane

LTE/SAE network

eNB

eNB GW

eNB MME

ControlPlane

Figura 3 – Divisão Funcional entre a E-UTRAN e a EPC

Inter Cell RRM

RB Control

Connection Mobility Cont.

Radio Admission Control

eNB MeasurementConfiguration & Provision

Dynamic ResourceAllocation (Sheduler)

RLC

MAC

PDCP

PHY

E-UTRAN

NAS Security

Idle State MobilityHandling

EPS Bearer Control

MobilityAnchoring

UE IP Addressallocation

Packet Filtering

MME

eNB

S-GW P-GW

EPC

RRC

133

A Figura 6 [6] mostra mais clara-mente a diferença entre OFDMA eSC-FDMA.

A técnica OFDMA transmite 4 sím-bolos QPSK em paralelo, um porsub-portadora, enquanto que SC--FDMA transmite os mesmos 4 sím-bolos QPSK por séries, a uma velo-cidade quatro vezes superior, emque cada símbolo ocupa N x 15kHz de largura de banda.

Na técnica OFDMA é a transmissãoparalela de múltiplos símbolos quecria o indesejável alto PAPR. Trans-mitindo N símbolos de dados emséries N vezes superior à taxa detransmissão permite manter a mes-ma largura de banda ocupada no

A Evolução da 3ª Geração Móvel,a Visão do 3GPP

banda disponível em várias sub--portadoras, escolhidas de modo aserem ortogonais entre si. O factode serem ortogonais reduz a inter-ferência entre elas, o que permite atransmissão da informação emfluxos paralelos. Assim, cada sub--portadora pode ser moduladausando diferentes tipos de modula-ção, por exemplo, QPSK, QAM,64QAM, ou superior, dependendoda qualidade de sinal.

DownlinkNa multiplexagem OFDMA, a cadautilizador é dado um número espe-cífico de sub-portadoras duranteum tempo pré-establecido, osPhysical Resource Blocks (PRB). OsPRB têm dimensões de tempo efrequência e são o recurso físicomais pequeno. A distribuição dosPRB é feita no eNB.

No sentido de downlink, o sinal con-siste numa grelha tempo-frequênciade recursos físicos1 (Figura 5) ondecada elemento corresponde a umasub-portadora durante um intervalodo símbolo OFDM.

No sentido de downlink, o sinal édistribuido pelos PRB disponíveis.Os PRB são formados por 84 ele-mentos de recursos rádio (12 x 7),ou seja, 12 sub-portadoras, queperfazem uma largura de banda de180 kHz, e 7 símbolos OFDM, queperfazem a duração um slot detempo de 0.5 ms.

Cada elemento de recurso rádiopode ser modulado com QPSK,16QAM ou 64QAM.

UplinkNo sentido de uplink, a técnica demodulação usada é SC-FDMA. Aprincipal vantagem desta técnicaem relação à convencional OFDMAé o mais baixo Peak-to-AveragePower Ratio (PAPR), sendo cerca

de 2 dB mais baixo. Isto é bastanteimportante, uma vez que permite pou-par a bateria dos terminais móveis.

No sentido de uplink, e à semelhan-ça do sentido inverso, a informaçãoé mapeada numa constelação desímbolos, que pode ser QPSK, 16QAM ou 64QAM, dependendo daqualidade do canal.

Porém, e ao contrário do que acon-tece no OFDMA, os símbolos QPSK/QAM não são directamente usadospara modular as sub-portadoras; sãosim sequencialmente colocados numconversor série/paralelo e depois numbloco onde se processa a transforma-da de Fourier (FFT) antes de seremtransmitidos através da interface ar.

Figura 5 – Grelha tempo-frequência de recursos físicos no sentido downlink

Figura 6 – Transmissão de uma sequência QPSK usando OFDMA e SC-FDMA

1Para MIMO existe uma grelha por cada antena.

12 sub- carriers, 180 kHz

One slot (Tslot = 0.5ms, 7 OFDM symbols)

One resource block( 12 x 7 = 84 resource elements )

f = 15 kHz

One Resource ElementQPSK, 2bits16QAM, 4bits64QAM, 6bits

0

1

-1,1 1,1

1,-1-1,-1

OPSK modulatingdata symbols

Sequence of OPSK data symbols to be transmitted

1,1 -1,-1 -1,1 1,-1 1,1 -1,-1 -1,1 1,-1

Time

OFDMA

symbol

OFDMA

symbol

Time

Frequency Frequency

V V

fc fc

OFDMAData symbols occupy 15 kHz for

one OFDMA symbol period

SC-FDMAData symbols occupy N x 15 kHz for

1/N SC-FDMA symbol periods

SC-FDMA

symbol

SC-FDMA

symbol

CP CP

15 kHz 60 kHz


SC-FDMA e no OFDMA, porém oPAPR é mais baixo.

2.3. Sub-camada MACNesta subsecção iremos abordarapenas a atribuição dos recursosrádio (PRB) que são da respon-sabilidade da sub-camada MAC.

A estrutura de gestão dos recursosdos eNB, como apresentado naFigura 7, consiste em 3 funções:Radio Admission Control (RAC), es-calonamento feito na sub-camadaMAC (QoS Scheduler) e manu-tenção da informação de estado. ORAC determina quais os novospedidos de chamada que devemser admitidos, o escalonador MACatribui os PRB disponíveis, e afunção de gestão da informação deestado colecta e armazena infor-mações tais como as condições dolink wireless, o tamanho das filas,taxa dos pacotes perdidos, etc..

Um dos princípios básicos do aces-

so rádio na tecnologia LTE é o usode canais partilhados quer no sen-tido de downlink, Downlink SharedChannel (DL-SCH), quer no sentidode uplink, Uplink Shared Channel(UL-SCH), o que implica que osrecursos tempo-frequência sejamdinamicamente partilhados pelosutilizadores nos dois sentidos. Aatribuição dos recursos é feito peloescalonador, que é parte da sub--camada MAC.

O escalonador de downlink deter-mina, dinamicamente, em cadaTransmission Time Interval (TTI) de1 ms, quais os UE que devem rece-ber a transmissão do DL-SCH equais os recursos. O escalonador étambém responsável por determi-nar o tamanho do bloco de dados,a modulação a usar e o mapeamen-to da antena (no caso MIMO). Nosentido de uplink, as funções doescalonador são semelhantes, no-meadamente determinar dinamica-mente, para cada TTI de 1 ms, quais

os terminais que vão transmitir infor-mação para os seus UL-SCH e quaisos recursos de uplink a serem usa-dos [7].

A escolha de um algoritmo de esca-lonamento adequado é uma daschaves para adquirir uma boa perfor-mance no serviço fornecido. Doisalgoritmos de escalonamento que po-dem ser implementados são RoundRobin e Best Channel.

3. Evolved Packet Core (EPC)Esta secção pretende descrever aarquitectura EPC, definida pelo 3GPP,incluindo uma breve descrição dassuas principais entidades funcionaise interfaces.

Para suportar o elevado tráfego IPnas redes 3G, o 3GPP tem vindo aefectuar estudos sobre como evoluira sua rede de pacotes. Em comple-mento ao E-UTRAN, o EPC preten-de evoluir a rede General PacketRadio Service (GPRS) de forma a au-mentar o seu desempenho. Assim,o EPC tem como objectivo desen-volver uma estrutura que possibiliteoptimizar a rede de pacotes do 3GPPpara que suporte débitos mais ele-vados, com menores períodos delatência. As entidades definidas noEPC pretendem ainda acomodardiferentes sistemas de acesso, taiscomo Wi-Fi [8], WiMAX [9] ou legacy3GPP, permitindo a mobilidade entreestes sistemas, de forma trans-parente para o utilizador.

A Figura 8 apresenta os novos blo-cos desenvolvidos pelo 3GPP paraevoluir a actual rede UMTS, conhe-cidos como Evolved Packet System(EPS). O EPS é composto pela redede core, denominada EPC [10], epela rede de acesso, denominadaE-UTRAN.

Para demonstrar a relação existenteentre a EPS e a arquitectura UMTS,a Figura 8 apresenta também algunsblocos da tradicional arquitecturaUMTS, nomeadamente a rede deacesso UTRAN, a rede de pacotes,

Figura 7 – Estrutura do eNB com diferentes filas

User callDownlink Traffic

New Call AdmissionRequest

Radio AdmissionControl

eNB and

DownlinkSatus Info.

- CQI- Queuelenght

- VoIPpacket drop

rate

per Call flow traffic

QoS Scheduler

PRB allocation

Available PRBs

OFDM basedwireless transmission

eNB

135 A Evolução da 3ª Geração Móvel,a Visão do 3GPP

conhecida como Packet Switch(PS), e a rede de circuitos, designa-da Circuit Switch (CS). Está tam-bém representada a rede IP Multi-media Subsystem (IMS), interligadacom todas as redes de core repre-sentadas, permitindo o acesso àsredes IP e à rede telefónica (PSTN).

Uma das entidades mais impor-tantes do EPS, e nomeadamenteda EPC, é a Mobility ManagementEntity (MME), que tem como prin-cipal função a gestão da mobilidadedos terminais, tanto em modo idlecomo em modo active. Para supor-tar os mecanismos de mobilidadeinter-3GPP e permitir a comunica-ção com o SGSN foi definida ainterface S3. O MME é o nó centralde controlo para a rede de acessoLTE. Isto significa que o MME tem aseu cargo a gestão das sessões,executando toda a sinalização ne-cessária para a criação dos canais,assegurando os requisitos de Qua-lidade de Serviço (QoS). Para alémda gestão das sessões, o MME é aentidade encarregue da autenticaçãodos UE, autorização de acessos ecriação de identificadores tempo-rários, utilizando para o efeito a in-terface S6 com o Home SubscriberServer (HSS). É também a entidaderesponsável pela negociação dosalgoritmos usados para garantir aconfidencialidade e a integridade dainformação. O MME é uma entida-de dedicada exclusivamente à sina-lização não tendo qualquer relaçãocom o tráfego de dados, permitindoa separação das entidades dedi-cadas à sinalização e ao tráfego depacotes de dados. A comunicaçãocom a rede LTE, nomeadamentecom o eNB, é efectuada através dainterface S1-C.

A EPC é ainda composta peloServing Gateway (S-GW) actuandocomo uma âncora de mobilidadelocal. Isto significa que à medidaque os terminais se deslocam, o S--GW encaminha os pacotes de epara o eNB que está a servir o UE,através da interface S1-U. A inter-

face S1-U é exclusivamente dedi-cada à troca de dados entre o eNBe o S-GW. O S-GW é também res-ponsável pela mobilidade entre di-ferentes tecnologias 3GPP, tais co-mo GSM, GPRS e UMTS, utilizandopara o efeito a interface S4 com oSGSN. Contrariamente ao MME, oS-GW suporta dados e sinalização.Se necessária, a comunicação entreo S-GW e o MME é efectuada atra-vés da interface S11. Para além daS-GW, o EPC define também a Pack-et Gateway (P-GW). Este gateway faza interface com as redes externas,ou seja, permite a ligação de um UE,por exemplo, à Internet ou à rede te-lefónica tradicional (PSTN), atravésda interface Sgi. O P-GW é tambémresponsável por um conjunto de

funções relativas ao mundo IP:atribui endereços, faz a classificaçãoe routing de pacotes, e aplica as re-gras recebidas do Policy Controland Charging Function (PCRF).Adicionalmente, funciona como umaâncora de mobilidade para redes deacesso non-3GPP, como por exem-plo Wi-Fi e WiMAX, utilizando a in-terface S2. A comunicação entreambas as gateways, S-GW e P-GW,é feita através da interface S5. Re-lativamente à localização das gate-ways, podem ser desenvolvidas emelementos físicos distintos, ou nomesmo elemento de rede, depen-dendo dos cenários seleccionados.

Finalmente, o PCRF é responsávelpelo controlo do uso dos canais. As

Figura 8 – Arquitectura EPS e UMTS

MME

NB NB

non - 3GPP IMSPSTN

Referências[1] Erik Dahlman et al., 3G Evolution: HSPA andLTE for Mobile Broadband, Elsevier, 2007[2] 3GPP TS 36.300 v8.4.0 (2008-03), EvolvedUniversal Terrestrial Radio Access (E-UTRA) andEvolved Universal Terrestrial Radio Access Network(E-UTRAN); Overall Description; Stage 2 (Release8)”, 3GPP, 2008.[3] 3GPP TR 23.882 v1.15.0 (2008-02), 3GPPSystem Architecture Evolution: Report on TechnicalOptions and Conclusions (Release 7), 3GPP, 2008.[4] 3GPP TS 23.228 v8.5.0 (2008-06), IP Multimedia Subsystem (IMS); Stage 2 (Release 8), 3GPP,2008.[5] 3GPP TS 23.417 v7.0.0 (2007-12), Telecommunications and Internet converged Services andProtocols for Advanced Networking (TISPAN); IPMultimedia Subsystem (IMS); Functional Architecture (Release 7), 3GPP, 2007. [6] Moray Rumney, 3GPP LTE: Introducing Single-Carrier FDMA, Agilent Measurement Journal[7] Sunggu Choi et al., MAC Scheduling Schemefor VoIP Traffic Service in 3G LTE, IEEE, 2007[8] IEEE 802.11-2007, IEEE Standard for Information Technology; Local and Metropolitan AreaNetworks; Part 11: Wireless LAN Medium AccessControl and Physical Layer specifications, IEEEStandard 802.11-2007, 2007.[9] IEEE 802.16e-2005, IEEE Standard for Localand Metropolitan Area Networks; Part 16: AirInterface for Fixed and Mobile Broadband WirelessAccess Systems; Amendment 2: Physical andMedium Access Control Layers for CombinedFixed and Mobile Operation in Licensed Bands,IEEE Standard 802.16e-2005, Fevereiro 2006.[10] 3GPP TS 23.401 V8.2.0 (2008-06) GeneralPacket Radio Service (GPRS) enhancements forEvolved Universal Terrestrial Radio Access Network(E-UTRAN) access (Release 8)

Álvaro Gomes é licenciado em Electrónica eTelecomunicações pela Universidade de Aveiro,pertence ao quadros da Portugal Telecom desde1981, trabalha actualmente no departamento IAD(Investigação Aplicada e Difusão do Conhecimento)da PT Inovação. Desde 2000 que o seu trabalhode investigação está focado nas redes móveis 3Ge B3G (Beyond 3G), nomeadamente interfacerádio e gestão de recursos rádio (RRM), tendoparticipado nos seguintes projectos IST: SHUFFLE(2000), SEACORN(2002), EVEREST(2004),WINNER(2005), AROMA(2006-07) e WEIRD(2008).Na área da consultoria desenvolveu as seguintesactividades: avaliação da qualidade rede UMTSna área de Aveiro para a TMN (2004), avaliaçãodo estado da arte das tecnologias de acesso semfios (BWA) para a PTC (2005) e Femto células(2008). Menção honrosa do concurso “Fórum deIdeias” com o projecto “FootPrint” (2006). É formador nos cursos da PT Inovação para o UMTS.

Filipe Cabral Pinto, licenciado em EngenhariaElectrotécnica pela Universidade de Coimbra, commédia final de 15 valores, concluiu o mestradoem telecomunicações, pela Queen Mary Universityof London, com a classificação final de Distinction.Actualmente investiga a utilização de informaçãode contexto na optimização de serviços multicast,no âmbito do Projecto Europeu C-CAST. Ao longodo seu percurso na PT Inovação desenvolveuactividades nos Projectos Europeus C-mobile, B--BONE, EVEREST, OPIUM e NETGATE. Colaborouainda no projecto e instalação de diversas redesde transmissão de dados.

Pedro Neves, Licenciado e Mestre em EngenhariaElectrónica e Telecomunicações pela Universidadede Aveiro em 2003 e 2006 respectivamente,encontra-se, desde 2007, a desenvolver o Doutoramento em Engenharia Informática e Tele-comunicações na mesma Universidade. Simultaneamente, participa na co-orientação de alunosde Mestrado de Engenharia Electrónica eTelecomunicações. Após a Licenciatura, tornou--se bolseiro de investigação do Instituto deTelecomunicações, onde trabalhou nos projectosco-financiados pela Comissão Europeia DAIDALOS-I e II, tendo sido responsável pela definiçãode uma arquitectura para a rede de acesso comintegração da tecnologia WiMAX. Em Junho de2006 iniciou actividade na PT Inovação, no domíniodas redes de acesso wireless de próxima geraçãoall-IP, nomeadamente na especificação de meca-nismos para suporte de mobilidade transparentee QoS para as tecnologias WiMAX e 3GPPUMTS/LTE, no âmbito de projectos co-financiadospela Comissão Europeia (WEIRD e HURRICANE)e pelo Eurescom. É co-autor dos livros “Advancesin Mobile WiMAX” e “Evolving WiMAX” publicadospela Wiley, e tem mais de 25 artigos publicadosem revistas e conferências internacionais.

Carlos Silva terminou a licenciatura em Electrónicae Telecomunicações pela Universidade de Aveiroem 2005. Iniciou a sua actividade profissional naSiemens SA como developer na área de sistemasembutidos. Desde Fevereiro de 2006 é bolseirode investigação no Instituto de Telecomunicações(pólo de Aveiro), na área de redes B3G.Participou no projecto europeu WINNER (2006-2007) na área de aplicações e qualidade de serviço.Actualmente é responsável por uma tarefa noprojecto europeu FUTON, cuja função passa pordefinir a arquitectura da gestão dos recursos rádioem ambientes heterogéneos.Os seus actuaisinteresses prendem-se com a gestão de recursosrádio em ambientes onde diversas redes wirelesscoexistem, nomeadamente em algoritmos decontrolo de admissão e de gestão de carga.

decisões tomadas pelo PCRF sãodepois postas em prática pelo Po-licy and Charging Enforcement Point(PCEP) localizado na P-GW. A co-municação entre o PCRF e o PCEPé realizada através da interface S7.Para além disso, o PCRF é tambémresponsável pela tarifação.

4. ConclusõesNeste artigo foram descritas as prin-cipais características e funcionali-dades de um novo sistema wirelessproposto pelo 3GPP o LTE/SAE.Com uma rede de acesso rádio (E--UTRAN), que agrega numa mesmaentidade toda a responsabilidadede gestão e controlo dos recursosrádio, são simplificados os proces-sos de implementação e gestão dosistema. Por outro lado, a utilizaçãode novas tecnologias na rede deacesso, por exemplo OFDM, permi-tem reduzir a interferência e melho-rar significativamente a performancee a capacidade do sistema. A intro-dução na nova rede core (EPC) dáo salto definitivo para o all-IP, cor-tando as amarras com os velhossistemas baseado em comutaçãode circuitos, simplificando tambémdeste modo a arquitectura e optimi-zando o desempenho na comutaçãode pacotes. A nova arquitectura einterface rádio pretendem essen-cialmente dar resposta às neces-sidades crescentes dos utilizadores,maior cobertura a maiores débitos,bem como diminuir os custos deCapital Expenditure (CAPEX) e Ope-rational Expenditure (OPEX) dosoperadores, de modo a garantir acompetitividade e o sucesso co-mercial do sistema.


Evolução de Tecnologias de Transporteem Redes de Agregação/Metro

137

palavras-chave:migração de redes circuitos para redes

pacotes; soluções técnicas de transporte parasegmento de agregação/metro; MPLS, PBT,T-MPLS; Carrier Ethernet Transport; decisão

estratégica para evolução de produtosNetB@nd

António Gamelas

O presente artigo baseia-se no docu-mento “Evolução de tecnologias detransporte em redes de agrega-ção/metro” [1], elaborado pela PTInovação, para efeitos de investigaçãoe suporte de novos produtos a desenvolver para a evolução do portfolio dalinha NetB@nd, no sentido de concretizar a transição estratégica parauma arquitectura plenamente baseada na comutação de pacotes. Dentrodeste contexto, o artigo efectua umaanálise muito sucinta das soluçõestecnológicas actualmente existentesno mercado para o nível de transporte, com especial incidência sobreas mais recentes Provider BackboneTransport (PBT) e Transport-MPLS(T-MPLS), para além da já implementada e adoptada por diversos operadores, MultiProtocol Label Switching(MPLS).

Para os mais interessados, uma consulta ao documento acima mencionado permitirá aceder a uma des-crição bastante detalhada, nãoapenas em termos de característicastécnicas dessas soluções, mas também em termos de quadros comparativos que permitem avaliar o graude inovação e/ou antever o seu de-sempenho operacional. Adicionalmente, procura-se também saber

até que ponto estas soluções vêmdar resposta a algumas questõesque preocupam operadores, entreos quais não pode deixar de se inserir obviamente a Portugal Telecom,bem como fabricantes. Para tal, epara além da referida análise tec-nológica, são também elaborados eestudados os business cases associados, nos quais se inclui, como fac-tor determinante, o estado de nor-malização de cada uma. Para alémdisso, são ainda apresentadas asvisões de alguns dos fabricantesparticularmente envolvidos no processo, bem como um resumo doscenários e conclusões de uma ses-são alargada de testes que engloboutodas as tecnologias.

No final, são tecidas algumas con-siderações acerca do que parece sera tendência global do sector, bemcomo da posição que eventualmente melhor poderá servir os interesses da PT Inovação, naquela queconstitui uma das decisões estra-tégicas que influenciará indubitavelmente, a médio prazo, a orientaçãodo desenvolvimento de produtos pa-ra a camada de transporte das Redesde Próxima Geração.


1. IntroduçãoDurante a última década, e reflec-tindo a tendência para a substituiçãodas redes de comutação de circuitospelas redes de comutação de paco-tes, o conceito básico que tem esta-do por trás da evolução das redes eserviços de telecomunicações é otão apregoado conceito de all-IP.

Como suporte a estas redes conver-gentes, surgiram algumas soluçõestécnicas para o nível do transporte,nomeadamente o MPLS. No entanto,a introdução da tecnologia MPLS co-mo nova tecnologia de transporte depacotes tem vindo a ser por vezesafectada por um certo receio paten-teado pelos operadores, particular-mente no que diz respeito à passa-gem de serviços tradicionalmentesuportados pelas redes PSTN. Osmotivos para essa desconfiança têma ver com o facto desta complexatecnologia não proporcionar o tãopretendido fácil reaproveitamentode conhecimentos e de modos deoperação adquiridos no passado.

De facto, o MPLS pode conduzir aconfigurações e obrigar a tomadas

de decisão muito complexas, que po-dem levar a situações indesejáveis.

Ao incidir a sua atenção apenas nonível de transporte em vez de pre-tender cobrir também aspectos apli-cacionais, o T-MPLS aparece comouma aproximação mais simples doque o IP/MPLS, através da utilizaçãode um número restrito de funcionali-dades.

Dentro deste contexto, a Ethernetestá também a granjear cada vezmaior credibilidade como solução al-ternativa, bastando para tal recordarque 95% do tráfego total de dadosque se espera vir a ter um incremen-to considerável nos próximos anos,tem origem, ou termina, em Ether-net. No entanto, as primeiras solu-ções alcançadas e ensaiadas trou-xeram a nu algumas debilidades daEthernet como tecnologia de trans-porte, especialmente em termos detempos de restauro, escalabilidade,robustez/protecção, segurança e ca-pacidades de OAM (Operation AndManagement).

Torna-se imperioso reconhecer que,

antes de a Ethernet poder ser adop-tada como tecnologia de rede, na-quela que o MEF (Metro EthernetForum) designou por Carrier Ether-net Transport (CET), deverá cumpriros critérios de qualidade exigidospelos operadores para oferta dosseus serviços. Por outras palavras,deve apresentar um desempenhopelo menos semelhante ao que éactualmente oferecido pelas tecno-logias de transporte dominantes(por exemplo: SDH).

Este é o motivo pelo qual a Ether-net, na sua quarta década de exis-tência, tem vindo a ser objecto detantas tentativas de melhoramentotraduzidas através da elaboraçãode novos standards. De facto, talcomo indicado mais adiante, solu-ções como VLAN (Virtual Local AreaNetwork) tag switching, PB (Provi-der Bridge), PBB (Provider Backbo-ne Bridge), e PBB-TE/PBT (ProviderBackbone Bridge-Traffic Enginee-ring/Provider Backbone Transport),têm vindo a ser trabalhadas no sen-tido de resolver os problemas iden-tificados. Enquanto este trabalhonão estiver terminado, a Ethernet

não pode ser encarada como solu-ção cabal e credível em termos detecnologia de transporte.

2. EnquadramentoOs serviços baseados na tecnologiapacket-switched, duma forma glo-bal, podem ser transportados porum conjunto bastante alargado detecnologias/infra-estruturas físicas,tais como fibra, OTN/WDM (OpticalTransport Network/WavelengthDivision Multiplexing), PDH (Plesio-chronous Digital Hierarchy), SDH /SONET (Synchronous Digital Hierar-chy / Synchronous Optical Network),ATM (Assynchronous Transfer Mode),xDSL (Digital Subscriber Line), PON(Passive Optical Network), soluçõesrádio, soluções de transporte Ether-net designadas por nativas incluindoa emergente PBT (Provider BackboneTransport), ou ainda soluções ba-seadas em MPLS (Multi ProtocolLabel Switching), incluindo a emer-gente T-MPLS (Transport MPLS),bem como outras.

A tabela 1 pretende sistematizar as so-luções mais em foco na actualidade,com o intuito de indicar sucintamenteas suas características técnicas, bemcomo os respectivos benefícios e limi-tações de algumas delas, com espe-cial incidência sobre as mais recentes.

Para uma mais fácil abordagem, assoluções foram divididas em doisramos de transporte distintos: o ba-seado em soluções Ethernet nativase o baseado nas restantes soluções,sendo consideradas nestas últimasas que aparecem como herança dastecnologias associadas à comu-tação de circuitos e outras tendo porbase a tecnologia MPLS.

3. Soluções de Transporte deServiços de PacotesNesta secção são referidos de umaforma muito genérica os aspectostecnológicos que caracterizam assoluções que se antevêem comomais promissoras para a rede detransporte: MPLS, PBT e T-MPLS.Para os interessados numa consulta

mais profunda, ver documento [1].

3.1. MPLSA solução MPLS assenta em termosde stack protocolar na operação deprotocolos de sinalização e de proto-colos de routing, em que os proto-colos de sinalização incluem o MPLSe respectivos protocolos associados,p. ex., LDP (Label DistributionProtocol) e RSVP (Resource ReSer-Vation Protocol), ou uma extensão dopróprio MPLS, o GMPLS (Gene-ralized MPLS), enquanto que os derouting englobam protocolos diver-sos, tais como o OSPF (Open Shor-

139

test Path First), o ISIS (IntermediateSystem to Intermediate System), ouo BGP (Border Gateway Protocol).

Em termos de operação, quer pararedes baseadas unicamente em IP,quer para redes baseadas em MPLS,que fazem uso de versões com fun-cionalidades adicionais, o objectivoprimordial dos protocolos de routingé o da troca de informação entrerouters, de forma a anunciar a co-nectividade de cada um, contribuin-do como tal para a disseminaçãoda topologia da rede em termos deelementos constituintes e respectiva

Evolução de Tecnologias de Transporteem Redes de Agregação/Metro

Tabela 1 – Sistematização de soluções para o transporte de serviços de pacote

NG-PDH(New Generation -Plesiochronous DigitalHierarchy)


flooding e address learning.

Adicionalmente, contém ainda umbreve historial das denominadas so-luções Ethernet nativas, anterioresao aparecimento do PBB-TE aka PBT,incluindo todos os melhoramentosque foram sendo introduzidos aolongo do tempo nas diversas solu-ções, os prós e contras de cada uma,bem como diversos cenários de im-plementação.

A Figura 2 evidencia precisamentea evolução global do formato da tra-ma Ethernet até à solução PBB,passando pela solução VLAN e PB,que acaba por constituir uma con-sequência directa dos melhoramen-tos introduzidos.

Embora toda esta evolução tenhamelhorado consideravelmente o de-sempenho das redes Ethernet, mui-tos dos mecanismos e característi-cas originais tais como, por exemplo,a natureza connectionless (CL), floo-ding de endereços e a utilização dosprotocolos para detecção de loops,continuavam presentes e contribuí-ram, de forma notória, para o factode a Ethernet não alcançar reconhe-cimento dos operadores para efei-tos de qualidade de serviço em ter-mos de transporte.

Por outro lado, os próprios mecanis-mos introduzidos no sentido de ul-trapassar algumas limitações maisevidentes estavam a fazer com quea Ethernet começasse a perder o

interligação, permitindo a construçãode tabelas de encaminhamento, o quesucede por exemplo, em situaçõesde arranque, até que uma fase deconvergência seja atingida.

Os protocolos de sinalização apare-ceram numa fase posterior tendocomo objectivo a criação de liga-ções lógicas, a que se deu o nomede Label Switched Paths (LSP), nosentido de individualizar fluxos depacotes.

Desta forma, o MPLS apareceu co-mo uma solução tecnológica inova-dora para transporte, baseada numanova forma de encaminhar tráfegoem que, ao contrário do encaminha-mento tradicional, é introduzido oconceito de fluxo transportado numdeterminado LSP.

Os LSP também podem ser agru-pados em fluxos de tráfego maisalargados, designados por ForwardEquivalence Classes, FEC ou CoSna Figura 1 que representa o for-mato da trama MPLS, os quais seencontram associados a conjuntosde ligações lógicas com uma carac-terística comum, entre equipamen-tos ou redes.

Em resumo, o conceito básico daimplementação de redes baseadasem MPLS consiste no facto de per-mitir que os operadores passassema obter um melhor desempenho eum melhor controlo da sua rede, oque por vezes até nem se verifica naprática, face ao carácter excessiva-mente autónomo e complexo emtermos operacionais que a rede pas-sa a patentear em certas situações.Esse melhor desempenho deveriatraduzir-se na possibilidade de esta-belecimento de caminhos lógicos(LSP) com largura de banda reser-vada, e com garantia de QoS. A parda possibilidade de definição e fácilimplementação de VPN, este é ogrande benefício esperado com aintrodução do MPLS nas redes depacotes.

Em termos de normalização, o MPLSencontra-se perfeitamente estabili-zado, mas apresenta algumas limita-ções, sendo uma delas precisamentea gestão da largura de banda na rede,i.e., o MPLS não tem um procedimen-to específico para solicitar alterações.Este pormenor torna-se particularmen-te relevante quando a evolução dosníveis inferiores de transporte, taiscomo o DWDM e a comutação ópti-ca, passam a oferecer aos operado-res a possibilidade de alterar a largurade banda de um determinado link.

O protocolo de sinalização GMPLS,que se encontra em fase de norma-lização, apareceu então como umaextensão do MPLS, no sentido deproporcionar os mecanismos neces-sários para o controlo, não apenas derouters, mas também de sistemasDWDM, Add/Drop Multiplexers (ADM),cross-connects fotónicos, etc.. Ouseja, com o GMPLS os operadorespassarão a poder efectuar o tal apro-visionamento dinâmico de recursos,a par de funcionalidades adicionais,tais como a necessária redundânciapara a implementação de vários me-canismos de protecção e de restauro.

3.2 PBTO documento [1] contém um conjun-to de informação detalhada acercadas características das redes Ether-net que limitam a sua topologia, porexemplo, aprendizagem do ende-reço dos comutadores adjacentes eprevenção de loops, bem como osmecanismos subjacentes, tais como

Figura 1 – Formato da trama MPLS

Label (20 bits)

MPLS Header IP Packet

32-bits

CoS S TTL

141 Evolução de Tecnologias de Transporteem Redes de Agregação/Metro

seu maior atractivo inicial: a simpli-cidade de utilização.

Dentro deste contexto, a tecnologiaPBB-TE (ou apenas PBT) apareceucomo modelo operacional alterna-tivo, baseado na simplificação demecanismos, em que se procurareutilizar o mais possível as bases datecnologia Ethernet já existentes,mas introduzindo técnicas suscep-tíveis de resolver os problemas dosoperadores, por exemplo, os rela-cionados com escalabilidade, fiabi-lidade e modo de operação da rede.

Precisamente no sentido de ende-reçar este último aspecto, a carac-terística mais relevante da tecno-logia PBT é a de ter sido concebidapara operar numa rede do tipo con-nection-oriented (CO) com comuta-ção realizada por meio de Ethernetswitches, o que vem ao encontroda velha pretensão relacionada comuma operação da rede muito seme-lhante às redes actuais, por exem-plo, SDH / SONET.

As redes PBT foram concebidaspara substituírem as redes PBB, em-

bora possam operar em paralelo. Noentanto, alguns dos antigos meca-nismos não são utilizados pelos equi-pamentos da rede de backbone, p.ex., MAC learning, flooding / broad-casting e protocolos RSTP / MSTP(Rapid / Multiple Spanning Tree Proto-col), para detecção de loops.

Em sua substituição, no transportede L2VPN (Layer 2 Virtual PrivateNetwork) são utilizadas ligações pon-to-a-ponto conhecidas por túneis, osquais são concretizados através dareutilização do cabeçalho da tramaPBB, mas com valores específicos.Com este modo de operação, pre-tende-se utilizar a engenharia detráfego de forma mais eficaz, no sen-tido de melhorar a capacidade da re-de, e de tornar a sua operação maisdeterminística e mais simples.

O aprovisionamento dos túneis éefectuado por um sofisticado sistemade gestão externo. A dependênciabastante acentuada neste sistemade gestão é mesmo apontada co-mo o principal obstáculo para a in-trodução e disseminação do PBT.

A figura 3 denota o formato da tramado standard inerente à solução PBT,o qual mantém inalterado no seu inte-rior o formato da trama PBB, acres-centando-lhe no entanto alguns no-vos campos que servem para aidentificação dos túneis.

3.3. T-MPLSO Transport MPLS (ou T-MPLS)constitui uma nova solução derivadado MPLS em que, face à bem co-nhecida complexidade desta última,a intenção foi a de simplificar a imple-mentação da rede, tendo para tal si-do feita a remoção de tudo o quenão se relaciona com uma configu-ração CO, começando por excluircompletamente a possibilidade deconfigurações do tipo CL. Desta for-ma, espera-se chegar a uma tecno-logia que seja muito mais simplesem termos de modelo de arquitec-tura e de operação e manutenção,de forma a vir ao encontro das pre-tensões dos operadores.

Em termos mais concretos, e à se-melhança do que já foi referido parao PBT, em que a configuração COtambém é a característica domi-

Figura 2 – Evolução global do formato da trama Ethernet

FCS

Payload

TPID

SA

DA

802.1Ethernet

802.1QVLAN

Payload

FCS

TPID

VID

SA

DA

TPID

FCS

Payload

TPID

C-VID

TPID

S-VID

TPID

SA

DA

802.1adPB

802.1aHPBB

B-SA

B-DA

TPID

B-VID

TPID

I-SID

Payload=802.1ad

Frame Withou without

FCS

FCS

nante, este tipo de operação tam-bém é conseguido através da cria-ção de túneis, i.e., ligações ponto--a-ponto estaticamente aprovisio-nadas por via externa a partir de umcentro de gestão, traduzindo-se es-te aprovisionamento num processobastante trabalhoso. Para tal, am-bos os tipos de tecnologia utilizamo mesmo cabeçalho da trama datecnologia em que se baseiam, i.e.,PBB, no caso do PBT, e MPLS, nocaso do T-MPLS, mas fazendo usode valores específicos.

Para atingir este objectivo primor-dial, é utilizado um número reduzidode comandos, de uma forma tal queo T-MPLS pode ser encarado comoum subset CO, ou um profile especí-fico, das RFC do IETF, ou das reco-mendações ITU-T da série G.8110 /Y.1370 [2] que definem o MPLS.

O T-MPLS foi concebido no sentidode constituir um nível de rede dife-rente do associado ao MPLS. Oobjectivo é o de operar o T-MPLSutilizando um codepoint do MPLS,tornando deste modo desnecessá-ria a criação de novos codepoints,uma vez que não se pretende inte-racção entre layers.

No entanto, o T-MPLS utilizará omesmo data-link protocol ID (porexemplo EtherType), o mesmoformato de trama e a mesma se-mântica de forward que os utiliza-dos no MPLS.

A fim de concretizar a anunciadasimplificação em relação ao MPLS,o T-MPLS não faz uso de diversosmecanismos, por exemplo, PHP(Penultimate Hop Pop), LSP merginge ECMP (Equal-Cost Multipath). Poroutro lado, define caminhos de back-up alternativos em caso de falha,continuando a utilizar mecanismosde OAM associados à monitorizaçãode túneis para efeitos de detecçãode falhas e de subsequente restauropara o caminho alternativo. Todosestes mecanismos, bem como a

arquitectura da solução, baseiam-se tanto quanto possível em normasjá definidas para o MPLS, nas quaisse introduziram ligeiras alterações.

4. O factor Engenharia de TráfegoO PBT e o T-MPLS constituem asmais recentes tecnologias propos-tas para a evolução da rede detransporte, e proporcionam funcio-nalidades associadas à engenhariade tráfego susceptíveis de propor-cionar os requisitos necessários à im-plementação dos serviços avança-dos de real-time, que se vislumbrampara um futuro próximo. Esta facili-dade de manuseamento da en-genharia de tráfego, segundo osmoldes tradicionais, constitui um dosfactores mais apelativos destas tec-nologias, sob a perspectiva dos ope-radores.

De facto, os mecanismos de apren-dizagem automática da Ethernet,bem como o mecanismo de routingde label-switched paths do MPLS,impedem o controlo directo dos flu-xos de tráfego ao longo da rede. Deforma a proporcionar a engenhariade tráfego pretendida pelos opera-

dores para as Redes de PróximaGeração, quer a solução PBT, quera solução T-MPLS são obrigadas aultrapassar esta configuração auto-mática e conseguem-no através dasimplificação dos mecanismos as-sociados às tecnologias Ethernetnativas, ou à tecnologia MPLS, pro-cedendo mesmo em muitos dos ca-sos à sua remoção.

A título ilustrativo, uma das vanta-gens da engenharia de tráfego, ma-nuseada da forma tradicional, resideprecisamente na capacidade de re-cuperação de situações de maufuncionamento, i.e., ao permitir ca-minhos de backup aprovisionados deantemão através da rede, o T-MLS eo PBT melhoram de forma signi-ficativa o processo de restauro. Oresultado da melhoria é de tal ordemde grandeza, que tempos da ordemdos 50 microsegundos passam a serpossíveis em redes baseadas emtecnologias de comutação depacotes, semelhantes aos das redesbaseadas em tecnologias decomutação de circuitos. No entanto,tempos semelhantes começamtambém a ser susceptíveis de serem


Figura 3 – Formato da trama IEEE 802.1Qay – Provider Backbone Transport

Tunnel Identifier

Tunnel IdentifierBackbone-DA

Backbone-SA

Backbone-Tag

Backbone-Tag

Consumer-DA

Consumer-SA

S-TagEType

S-VID, PCP, DE

C-TagEType

C-VID, PCP, CFI

Referências[1] António Gamelas, Evolução de tecnologias detransporte em redes de agregação/metro, PTInovação, Maio 2008[2] ITU-T Recommendation G.8110/Y.1370 MPLSlayer network architecture

António José Leite Gamelas, licenciado emEngenharia Electrónica de Telecomunicações pelaUniversidade de Aveiro desde 1984, ingressounos quadros do Centro de Estudos de Tele-comunicações (CTT) em 1985. Trabalha actualmente no departamento de Desenvolvimento deSistemas de Rede da PT Inovação.

obtidos com o MPLS, através daut i l i zação de processadoresbastante mais rápidos disponíveishoje em dia. Este facto permite mi-n imizar os e fe i tos de fa lhascausadas no cliente em serviçossensíveis a tempos de resposta, porexemplo, VoIP e IPTV.

Ainda na mesma linha, as métricasenvolvidas em algoritmos de routing,ou os cálculos efectuados com osresultados dos protocolos do tipoSpanning Tree, levam a que certoscaminhos sejam seleccionadosmuito mais vezes em detrimento deoutros. À medida que a utilizaçãoda rede aumenta, este facto podeconduzir a situações de sobrecargade alguns links, enquanto outrospermanecem subutilizados. Um dosobjectivos da engenharia de tráfegoé o de minimizar este problema, a-través do balanceamento da utiliza-ção dos recursos da rede. Adicio-nalmente, permite também, a umoperador de serviços, a criação dediversidade em termos de encami-nhamento, o que minimiza o riscode que a falha de um único link, oude que um único elemento de rede,provoque a interrupção simultâneado caminho principal, ou primário, edo caminho de backup ao longo darede.

Por último, e tal como já foi tambémanteriormente referido noutras sec-ções, a engenharia de tráfego per-mite a continuação da operação darede segundo modelos familiarespara o operador, evitando deste mo-do grandes investimentos em ter-mos de formação para os recursoshumanos.

5. ConclusõesO presente artigo descreve sucin-tamente as novas soluções tecno-lógicas PBT e T-MPLS para a rede detransporte, as quais têm sido objec-to de normalização nos tempos maisrecentes.

Ambas as soluções, PBT e T-MPLS,vêm de encontro aos requisitos de

evolução suave pretendida pelosoperadores, nomeadamente aopossibilitarem modos de operação darede do tipo connection-oriented. Talnão parece ser possível com asolução MPLS nativa, face à suacomplexidade e à consequente ne-cessidade de aquisição de conhe-cimentos por parte das equipasoperacionais, pelo menos em certoscenários de desenvolvimento da rede.

Deste modo, a solução MPLS, queparece constituir a solução maisapropriada para o segmento de co-re, não o é para o segmento de agre-gação/metro, no qual a escolha deverávir a ser feita entre a sua derivada, T-MPLS, e a última evolução das solu-ções Ethernet nativas, o PBT.

Nota final:Gostaria de agradecer ao meu colega JorgeCarapinha o tempo dispendido na ajuda adesbravar o difícil terreno que constitui o MPLS.

143 Evolução de Tecnologias de Transporteem Redes de Agregação/Metro

01 AVALORE

Avaliação e Acompanhamento de Projectosde Desenvolvimento de Novas Tecnologias

palavras-chave:Avaliação de projectos, modelos multi-critério

de apoio à decisão, avaliação financeira.

Com o projecto AVALORE desenvolveu-se um modelo de avaliaçãode projectos de Inovação, Inves-tigação e Desenvolvimento adaptado à realidade da PT Inovação. Estemodelo permite tomar em conside-ração múltiplos critérios, alguns qua-litativos e outros quantitativos, nãoesquecendo a componente econó-mico-financeira. Distinguem-se doisníveis de decisão, definidos de formaajustada à realidade da empresa, e

podem ainda considerar-se, em cada um destes níveis, vários tipos deprojecto com objectivos diferentes.Pretendeu-se, desta forma, forneceruma ferramenta que, tendo sido desenvolvida de raiz a partir da reali-dade da PT Inovação, irá auxiliar atomada de melhores decisões dedistribuição de recursos pelos projectos desenvolvidos pela empresa.

Ricardo Afonso Gonçalo Regalado

Joana Fialho(INESC-C)

Pedro Godinho(GEMF)

João Costa(INESC-C)


AVALOREAvaliação e acompanhamento de projectosde desenvolvimento de novas tecnologias

145

Figura 1 – Enquadramento de Avaliação

1. IntroduçãoOs projectos de Inovação, Investi-gação e Desenvolvimento têm ca-racterísticas próprias que impossi-bilitam a aplicação dos métodos deavaliação clássicos. Uma avaliaçãocorrecta destes projectos deve con-siderar a qualidade da informaçãoexistente para cada projecto, bemcomo a sua flexibilidade de gestão.Muitas vezes é ainda necessário in-corporar aspectos difíceis de quanti-ficar, como a aquisição de compe-tências ou a imagem junto dosclientes. Requer-se ainda considerarexplicitamente diferentes objectivosou critérios, por vezes em conflito,procurando-se alcançar compromis-sos que incorporem a estrutura depreferências, necessariamente dinâ-mica, de quem arca com a respon-sabilidade de definir linhas de acçãopara o futuro.

Com o projecto AVALORE desen-volveu-se um modelo de avaliaçãode projectos de Inovação, Investi-gação e Desenvolvimento adaptadoà realidade da PT Inovação. Estemodelo tem em consideração doisníveis de decisão distintos, cuja de-

finição se baseou na actual estruturautilizada pela PT Inovação: a acçãoe o agregado de acções. Para cadaum destes níveis foi desenvolvidauma estrutura hierárquica que permi-te identificar os critérios relevantes ea sua importância. Esta estruturapossibilita ainda tomar em conside-ração diferentes tipos de projecto.Admitiu-se que existem agregadose acções com objectivos diferentes,e que os pesos dos critérios devemreflectir estes objectivos.

Admitiu-se ainda que a qualidadeda informação – especialmente dasprevisões financeiras – não é idênticapara todos os projectos. Assim, omodelo de avaliação permite utilizarinformação financeira com diferenteshorizontes temporais, consoante adisponibilidade de projecções demédio e longo prazo. O modelo pres-supõe uma separação clara da infor-mação a fornecer por diferentes áreasda empresa – nomeadamente aspreferências institucionais, definidaspela organização, e os dados concre-tos sobre os projectos, fornecidospelos respectivos responsáveis.

O modelo separa dois níveis de de-cisão distintos, sem esquecer a suainter-relação. A tomada de decisãode atribuição de recursos é separa-da entre decisões, de carácter essen-cialmente estratégico, de atribuiçãode recursos a agregados de acçõese decisões tácticas de divisão dosrecursos de cada agregado pelasdiferentes acções que o compõem.Ao mesmo tempo, a estrutura hie-rárquica de avaliação tem em contaa importância de cada acção paracada agregado, permitindo assimconsiderar a interdependência entreos dois níveis de avaliação.

2. EnquadramentoO esforço de Inovação, Investigaçãoe Desenvolvimento na PT Inovaçãoencontra-se estruturado em dois ní-veis: a acção, que geralmente cor-responde a uma tarefa, e o cluster,que corresponde ao conjunto de ac-ções com algumas característicascomuns. Os problemas de decisãoque se colocam ao nível das acçõessão fundamentalmente diferentes dosque se colocam ao nível dos clusters– enquanto os clusters requerem umplaneamento estratégico de médio e

Satisfazer o Cliente

CriarValor

AdquirirCom

petê

ncia

s

CritériosEconómicosOperacionais

Alinhamento Estratégico

Know-How

Proj

ecto

s Es

traté

gico

s Projectos de Negócio


longo prazo, as acções requerem umplaneamento táctico de curto prazo.

Na actual definição dos clusters daPT Inovação é possível identificar, porvezes, linhas de investigação dife-rentes, focadas em produtos ou ser-viços independentes, que se situamno mesmo cluster; existem ainda si-tuações em que a mesma linha de in-vestigação é partilhada por vários

clusters. Assim, optou-se por utilizaro conceito de agregado de acções emvez do de cluster. Este agregado re-presenta um conjunto de acções in-ter-relacionadas, vocacionadas parauma determinada família de produtosou serviços.

3. ModeloO modelo considera separadamentea avaliação dos agregados e a ava-

liação das acções. Em ambos oscasos se define uma estrutura hie-rárquica que é usada, em primeirolugar para estruturar os critérios re-levantes e determinar os seus pesos.Estes pesos devem reflectir as pre-ferências institucionais, sendo assimdefinidos por representantes da or-ganização.

O passo seguinte é avaliar o desem-penho dos agregados e acções nosdiferentes critérios. Esta avaliaçãorecorre a dados concretos sobre osprojectos, fornecidos pelos respec-tivos responsáveis. Com estes da-dos e com os pesos dos critériosobtém-se uma avaliação global doagregado ou acção.

A avaliação dos agregados serve debase às macro-decisões sobre alo-cação de recursos. A avaliação dasacções serve de base às decisõesde repartição de recursos dentro doagregado.

3.1. Avaliação dos agregadosA estrutura hierárquica usada paraos agregados encontra-se represen-tada na figura 3, contendo os seguin-tes elementos:

> No nível superior encontra-se o ti-po de agregado, que correspon-de a uma primeira classificaçãodos agregados quanto aos seusobjectivos. A classificação actual-mente utilizada divide os agrega-dos em “tipo estratégico”, em quese assumem objectivos de médioou longo prazo, e “tipo negócio”,em que se considera importante aobtenção de lucros a curto prazo;

> No segundo nível encontram-seas classes de objectivos, ou cri-térios de nível superior. Definiram-se três classes: critérios estraté-gicos, critérios operacionais e cri-térios financeiros, sendo possívela alteração destas classes ou in-clusão de novas classes;

> No terceiro nível, encontram-seos critérios. Exemplos de critérios

...

...

...

...

Figura 2 – Modelo de Avaliação

Estratégico

Negócio

Financeiros

Operacionais

Estratégicos

...

...

...

Liderança de Mercado

CompetênciasAdquiridas

1. TIPO 2. CLASSES DEOBJECTIVOS

3. CRITÉRIOS

Figura 3 – Estrutura de avaliação dos agregados

Comparação dosCritérios dosAgregados

Comparação dosCritérios das

Acções

Avaliaçãodas

Acções

Atribuição deRecursos

Avaliaçãodos

Agregados

FiltragemEstruturação

Acções Potenciais:- de continuidade- inovadoras

Restrições Operacionais

Agregados:- características- objectivos

Finalidade dos Agregados

Re-planificação Financeira

Características dasAcções

Prioridade Relativa

Importância dos Critériosdas Acções

Importância dos Critériosdos Agregados

Objectivos Organizacionais

Restrições do Equilibrio Organizacional

Plano de Execução de Acções


147

financeiro que reflecte perspectivasde médio/longo prazo, no segundosão utilizados valores de curto pra-zo, complementados por critériosdefinidos de forma qualitativa (comotendência de mercado e perspec-tivas de crescimento).

O modelo determina desta formaum valor global para cada agrega-do, que constituirá a base da distri-buição de recursos humanos entreos diferentes agregados. Nesta dis-tribuição tem-se também em contao nível de referência de recursos hu-manos (isto é, o nível previsto peloresponsáveis) e o “custo” de re-atri-buição de recursos humanos entreagregados. Assim, o modelo nãopretende substituir completamenteo papel dos decisores, mas preten-de fornecer linhas de orientaçãofundamentadas para a tomada dedecisões de atribuição de recursos.

3.2. Avaliação das acçõesA avaliação das acções baseia-senum processo semelhante ao dosagregados. A estrutura definida foia seguinte:

> No nível superior encontra-se o ti-po de acção, que corresponde auma primeira classificação dasacções quanto às suas carac-terísticas;

> No nível seguinte consideram-seas classes de critérios. A definiçãodestas classes é idêntica à suadefinição para os agregados –classes de objectivos estratégi-cos, operacionais e financeiros;

> No terceiro nível, consideram-seos critérios. O procedimento deobtenção dos pesos dos critérios,e do desempenho das acçõesnos critérios, é idêntico ao usadopara os agregados.

A análise efectuada às acções daPT Inovação permitiu a identificaçãodos seguintes tipos de acções, uti-lizados no primeiro nível da estruturahierárquica definida:

estratégicos são as competênciasadquiridas e a liderança de mer-cado; exemplos de critérios ope-racionais são a criticidade/escas-sez dos recursos necessários e adependência de terceiros; exem-plos de critérios financeiros são ovalor actual líquido e a perda es-perada por abandono.

A forma como os critérios são defi-nidos permite incorporar aspectosquantitativos e não quantitativos noprocesso de avaliação. Permite ain-da incorporar aspectos relaciona-dos com a incerteza e a flexibilidadeoperacional, essenciais para umacorrecta avaliação dos projectos deInovação, Investigação e Desen-volvimento.

O processo de avaliação seguidobaseia-se no Analytic HierarchyProcess ([5], [6]). Assim, a estruturade avaliação é utilizada para deter-minar os pesos dos critérios e o de-sempenho dos agregados em cadacritério, obtendo-se a partir daquiuma classificação global dos agre-gados.

Os pesos dos critérios reflectem aspreferências institucionais, devendopor isso ser definidos pela gestãode topo. O processo de obtençãodos pesos dos critérios estrutura-se da seguinte forma:

> Comparar a importância das dife-rentes classes de objectivos paraos agregados de cada tipo obten-do-se um peso global para cadaclasse;

> Comparar a importância dos dife-rentes critérios de cada classe,obtendo-se um peso para cadacritério.

O peso de cada critério reflecte opeso da respectiva classe de objec-tivos, bem como a importância docritério dentro dessa classe. As com-parações efectuadas são baseadasnuma escala semântica pré-definida,podendo ainda optar-se pela utili-

zação directa de uma escala numé-rica se os utilizadores estiveremsuficientemente familiarizados comesta.

A determinação do desempenhodos agregados nos diferentes crité-rios processa-se de forma diferentepara os critérios quantitativos e paraos de difícil quantificação.

Para os critérios de difícil quantifica-ção estão previstos dois procedi-mentos diferentes: um baseado naavaliação individual dos agregados,e outro na comparação entre diver-sos agregados. No primeiro caso,são definidos agregados “tipo” dereferência, relativamente aos quaiso agregado em avaliação é compa-rado para obter o seu desempenhonos diferentes critérios. No segundocaso, são feitas comparações entreos diferentes agregados para obterum valor do desempenho para cadaum. Note-se, no entanto, que o pri-meiro procedimento também podeser usado para comparar a atracti-vidade de diferentes agregados.

Os critérios quantitativos que foramdefinidos são baseados em valoresfinanceiros. Considerou-se que aforma como estes valores financei-ros são convertidos para desempe-nhos devia reflectir as preferênciasorganizacionais, e não ter caráctercasuístico. Assim, o modelo definepreferências relativas aos diferentesvalores financeiros através de umprocesso de comparação de valo-res pré-definidos. Essas preferênciaspermitem a conversão automáticados valores financeiros em desem-penhos compatíveis com os obtidospara os outros critérios.

No caso dos critérios financeiros,teve-se ainda em consideração que,enquanto existem agregados cominformação suficiente para fazer pre-visões de médio ou longo prazo,existem outros, sujeitos a um nívelde incerteza que apenas permite fa-zer previsões a um ano. Enquantono primeiro caso se utiliza um valor


1. Investigação exploratória – ac-ções que não têm ainda como ob-jectivo uma aplicação concreta,mas que se destinam a explorar edominar tecnologias, por forma asaber se se conseguem ou nãoresultados interessantes;

2. Desenvolvimento experimental –acções que têm como objectivouma aplicação concreta, integradanuma linha de investigação defi-nida, e que são relevantes para oavanço desta linha de investiga-ção;

3. Desenvolvimento de produtos pa-ra venda imediata – acções quevisam desenvolver um produtocom o objectivo principal de serimediatamente vendido;

4. Serviços de engenharia – acçõesque visam fornecer apoio à uti-lização de um produto já existente.

Para efeito de avaliação, considera-se que os dois últimos tipos indi-cados apresentam característicassuficientemente semelhantes parapermitir a sua agregação.

A classificação das acções é utili-zada para determinar o nível de re-cursos que lhe é atribuído, de entreos recursos atribuídos ao(s) agre-gado(s) em que cada acção se inse-re. Para esta atribuição de recursospodem ser usados dois procedi-mentos:

1. Selecção de acções por ordem dasua classificação. Podem utilizar--se restrições neste processo deselecção, como definição de limi-tes (máximos e mínimos) para osrecursos usados por cada tipo deacção;

2. Maximização da soma das clas-sificações das acções selecciona-das através de programaçãomatemática, tendo em conta a res-trição de recursos, e podendoainda considerar limites à utiliza-ção de recursos em acções de ca-

da tipo e mínimos para a pon-tuação agregada nalguns critérios.

Estes procedimentos não substituemcompletamente o papel e o julga-mento dos decisores. Enquanto es-tes procedimentos, correctamentecalibrados, dão indicações valiosas,a sensibilidade para eventuais ajus-tes é importante na construção deum portefólio equilibrado de acções.

3.3. Incorporação de flexibilidadeA flexibilidade operacional pode servista como a capacidade de a em-presa proceder a correcções ou a-daptações na implementação de umprojecto, quando ocorrem desenvol-vimentos que estão fora do cenárioinicialmente considerado. A flexibili-dade operacional é uma fonte impor-tante de valor, permitindo, por exem-plo, maximizar os lucros quando osdesenvolvimentos relativos ao projec-to são positivos, e minimizar as per-das quando estes são negativos. Éimportante que esta flexibilidade o-peracional seja considerada na ava-liação de um projecto, por forma aincorporar correctamente o acrésci-mo de valor que a empresa terá nofuturo se responder, de forma cor-recta, às situações com que se viera deparar.

O modelo que foi adoptado prevêuma incorporação da incerteza e fle-xibilidade operacional através doscritérios de avaliação considerados.Para além desta incorporação daflexibilidade operacional, a metodo-logia de utilização do modelo permi-te também tirar partido desta flexi-bilidade, através do apoio fornecidoà identificação das melhores respos-tas a acontecimentos inicialmentenão considerados.

A flexibilidade operacional é consi-derada em especial nos seguintescritérios: flexibilidade da solução,dependência de terceiros, criticida-de / escassez dos recursos neces-sários, perda esperada por abando-no e possibilidade de adiamento.

A flexibilidade da solução refere-seà possibilidade de a solução adop-tada poder ser adaptada ou confi-gurada (“customizada”) para utiliza-ções diferentes das inicialmenteprevistas. Esta é uma fonte de flexi-bilidade importante com reflexosposteriores ao desenvolvimento doproduto, que permite tirar partidodesse produto, de uma forma queinicialmente não foi considerada.

A dependência de terceiros é umcritério que pretende penalizar osagregados em cuja capacidade daPT Inovação responder a aconteci-mentos imprevistos seja reduzida,por esta não controlar a totalidadedo processo de desenvolvimento.Não obstante a importância das re-lações com terceiros, é necessárioter em consideração que as vanta-gens da capacidade de resposta anovos acontecimentos são tantomaiores, quanto maior a capaci-dade da PT Inovação em controlaro processo de desenvolvimento.

A criticidade / escassez de recursosnecessários pretende ter em con-sideração a forma como o agrega-do pode contribuir para a diminui-ção da flexibilidade da organizaçãocomo um todo. A utilização de re-cursos escassos por parte de umagregado pode inviabilizar o desen-volvimento de outros projectos inte-ressantes por falta destes mesmosrecursos. No caso da PT Inovação,este critério está pensado espe-cialmente para recursos humanosespecializados, mas pode referir-sea outros tipos de recursos, comoequipamento.

A perda esperada por abandono éum critério que pretende ter em con-sideração a probabilidade de aban-dono e a perda em que a empresaincorre caso abandone o projecto.Estes dois factores influenciam a fle-xibilidade operacional inerente aoagregado. Quanto maior for o mon-tante da perda em caso de aban-dono mais irreversível será o projec-to e, consequentemente, menor a


149

flexibilidade existente neste. Por outrolado, a probabilidade de abandonoreflecte a possibilidade de o projectocorrer tão mal que deva ser mesmoabandonado. Este critério, que temem conta os dois factores, penalizaos projectos que, pela probabilidadede correrem mal ou pelos custos in-corridos caso tal ocorra, possam cau-sar grandes prejuízos à empresa.

Finalmente, a possibilidade de adia-mento fornece uma perspectiva dife-rente sobre a flexibilidade operacional.Este critério pretende favorecer o de-senvolvimento rápido dos agregadosque possam ser mais afectados poratrasos, podendo levar ao adiamen-to na alocação de recursos a agre-gados cujo desenvolvimento possasofrer menos com tal atraso. Note--se que o adiamento pode ter aconsequência positiva de permitirobter mais informação antes deefectuar um gasto de recursos, per-mitindo avançar com mais certezade sucesso ou não avançar se o am-biente se tornar menos favorável.

Os critérios utilizados para incorpo-rar a flexibilidade operacional na ava-liação das acções são: dependência(operacional) de terceiros, criticidade/escassez dos recursos necessários,perda esperada por abandono epossibilidade de adiamento.

A dependência (operacional) de ter-ceiros é muito semelhante ao crité-rio “Dependência de terceiros”, utili-zado na avaliação de agregados. Nocaso das acções, explicitou-se ape-nas que a dependência relevante épuramente operacional, pois no ca-so dos agregados pode haver tam-bém outra dependência “política”,decorrente de um processo de de-cisão que não seja exclusivamentecontrolado pela PT Inovação. A cri-ticidade / escassez de recursos ne-cessários tem características muitosemelhantes ao critério com o mes-mo nome utilizado na avaliação dosagregados, mas agora refere-se es-pecialmente à utilização de recursosdentro do agregado. A perda espe-rada por abandono e a possibilida-de de adiamento têm também umadefinição muito semelhante à que foiconsiderada para os agregados.

O processo de selecção de acçõesna PT Inovação tem periodicidadeanual. No entanto, surgem frequen-temente no decorrer do ano:

> Oportunidades de novas acçõesque só podem ser aproveitadasse se proceder a uma alteraçãoimediata no planeamento efec-tuado;

> Pedidos de clientes que, mesmo

sendo de rentabilidade limitada,têm que ser atendidos por formaa manter a satisfação do cliente.

Estas situações correspondem auma necessidade estrutural de flexi-bilidade dentro dos agregados, sen-do necessário proceder a uma re-afectação de recursos dentro doagregado para dar seguimento àsoportunidades ou solicitações. Omodelo permite a integração destassituações, através da sua aplicaçãointercalar dentro dos agregados. Oque se prevê para estas situações é:

> A avaliação das novas solicitaçõesou oportunidades como novas ac-ções a empreender;

> A reavaliação daquelas acções cu-jo decurso mostre diferenças sig-nificativas relativamente ao planea-mento inicial;

> Utilização das avaliações das no-vas acções potenciais, e das ava-liações (ou reavaliações) das res-tantes acções para decidir se sedeve ou não prosseguir com asnovas acções, quais os recursosa alocar a estas e onde os retirar.

Desta forma, a necessidade de rea-gir a novas situações pode ser inte-grada de forma transparente na uti-lização do modelo, usando a mesma

0 3 ... 12 t (meses)

Modelo de Avaliação Modelo de Avaliação

Calibrar Modelo de Avaliação

Plano 3 ... Plano vs Realizado

Dinâmica Organizacional ePotencial já Realizado

Plano 0

Figura 4 – Utilização em Regime Permanente


estrutura de decisão definida paraas decisões iniciais.

4. AplicaçãoUm protótipo do modelo está nestemomento implementado em Micro-soft Excel. Este protótipo foi utiliza-do para uma determinação inicialdas preferências organizacionais,bem como para avaliar um conjuntode agregados e acções de teste.

4.1. Matrizes de comparaçãoNa implementação efectuada, ascomparações necessárias são defi-nidas através de matrizes, nas quaisos decisores preenchem os elemen-tos que se encontram acima da dia-gonal principal, podendo para talusar uma escala semântica pré-de-finida ou uma escala numérica. Apre-senta-se seguidamente um exemplode uma matriz hipotética, definidapara obter os pesos das diferentesclasses de objectivos para um tipode agregado.

A matriz está preenchida usando aescala semântica, e especifica queos objectivos estratégicos são for-temente mais importantes que osoperacionais e moderadamentemais importantes que os financei-ros, e que os objectivos operacio-nais têm importância igual à dosfinanceiros.

A matriz apresentada permite obteros pesos das diferentes classes deobjectivos e um coeficiente de pro-porcionalidade que indica em quegrau é que os pesos reflectem ascomparações efectuadas. Para amatriz apresentada, os pesos obti-dos são 0.659, 0.156 e 0.185 paraos objectivos estratégicos, opera-cionais e financeiros, respectiva-mente, e o coeficiente de propor-cionalidade é 97%.

Uma proporcionalidade inferior a100% indica que as comparaçõesimpedem a definição de pesos queas reflictam de forma exacta (isto é,que existe alguma incoerência nas

comparações). São aceitáveis ma-trizes com coeficiente de proporcio-nalidade superior a 90%, devendonas restantes rever-se as compara-ções por forma a obter maior coe-rência.

Quando o número de elementos acomparar aumenta (o que se passa,por exemplo, na obtenção dos pesosdos critérios), o número de compa-rações par-a-par necessárias tam-bém aumenta. A fim de evitar que opreenchimento das matrizes se tornedemasiado moroso, utilizou-se umametodologia que permite obter ospesos sem efectuar todas as com-parações, bastando que as com-parações introduzidas permitamrelacionar indirectamente todos oselementos a comparar.

4.2. Agregados de referênciaNas avaliações já efectuadas, cons-tatou-se que, mesmo quando sepretende comparar a atractividadede diferentes agregados, o procedi-mento de avaliação individual dosagregados (baseado em agregadosde referência) se torna mais simplese intuitivo para os avaliadores do quea comparação directa dos agrega-dos nos diferentes critérios. Assim,as avaliações efectuadas basearam--se na utilização de três agregadosde referência, definidos da seguinteforma:

> Agregado estratégico – desen-volvimento de uma família de pro-

dutos sem clientes em vista ecom probabilidade reduzida deserem comercialmente bemsucedidos, mas que permitirão aaquisição de novas competênciase, em caso de sucesso nodesenvolvimento, terão grandevisibilidade;

> Agregado de negócio: inovação– desenvolvimento de uma linha denovos produtos, a ser lançada porum operador do Grupo PT, comforte probabilidade de grande su-cesso comercial, mas em que ape-nas uma parcela limitada dos lucrosserão para a PT Inovação;

> Agregado de negócio: explora-ção de competências – desen-volvimento de produtos baseadosem tecnologia já dominada, emconjunto com um cliente/parceirode média dimensão, com a ex-pectativa de obtenção de lucrossignificativos.

Estes agregados de referência fo-ram definidos mais detalhadamente,e efectuaram-se as comparaçõesdestes nos diferentes critérios. Comestas comparações definidas, épossível avaliar um agregado, com-parando-o com apenas um agregadode referência em cada critério.

4.3 ResultadosO modelo foi utilizado para determi-nar as preferências organizacionais,e procedeu-se também à avaliação

ObjectivosEstratégicos

ObjectivosOperacionais

ObjectivosFinanceiros

Fortementemais importante

Moderadamentemais importante

IgualImportância

ObjectivosEstratégicos

ObjectivosOperacionais

ObjectivosFinanceiros

--

--

--

--

-- --

Tabela 1 – Matriz de comparação

O modelo pretende também incen-tivar a identificação de oportuni-dades estratégicas e de flexibilidadeoperacional nas acções e agrega-dos da PT Inovação, através da de-finição dos critérios utilizados. Destaforma, estas oportunidades estraté-gicas e flexibilidade operacionalpassarão a ser um factor relevantenas decisões a tomar, levando osresponsáveis pelas propostas aprocurá-las activamente.

Referências[1] C. Farrukh, R. Phaal, D. Probert, M. Gregory,J. Wright. Developing a Process for the RelativeValuation of R&D Programmes. R&D Management,30(1): 43-53, 2000.[2] P. Godinho, J.P. Costa. Relatório Final doProjecto AVALORE: Abordagens para Avaliaçãodos Projectos da PT Inovação, 2008.[3] P.T. Harker, Incomplete pairwise comparisonsin the analytic hierarchy process, MathematicalModelling 9 (11): 837–848, 1987.[4] K.L. Poh, B.W. Ang, F. Bai. A ComparativeAnalysis of R&D Project Evaluation Methods. R&DManagement, 31(1): 63-75, 2001.[5] T.L. Saaty. The Analytic Hierarchy Process:Planning, Priority Setting, Resource Allocation,McGraw-Hill, 1980.[6] C.-O. Shin, S.-H. Yoo, S.-J. Kwak. Applyingthe Analytic Hierarchy Process to Evaluation of theNational Nuclear R&D Projects: The Case of Korea.Progress in Nuclear Energy, 49: 375-384 2007.

de um conjunto de agregados e ac-ções de teste, para calibrar estaspreferências e o próprio modelo. Osresultados obtidos permitem afirmarque o modelo de avaliação reflecte aestrutura de preferências da PT Ino-vação, constituindo, portanto, umaferramenta poderosa para avaliar aactividade a que a PT Inovação sededica. Note-se ainda que o mode-lo comporta a alteração simplesdesta estrutura de preferências,estando portanto ajustado à dinâ-mica que todas as preferências so-frem, por alterações de julgamentoou contextuais.

5. ConclusõesO modelo apresentado permite apoi-ar a obtenção de decisões solida-mente fundamentadas. A existênciade uma estrutura de preferências ex-plícita permite compreender melhoro que está por trás das decisões to-madas, e permite também detectarcom mais facilidade eventuais incoe-rências no processo de decisão. Es-te modelo conduz também a umamaior responsabilização dos deci-sores, e ajuda-os a perceber ondepoderão ter ocorrido os erros de a-valiação quando se constate que asdecisões tomadas não foram as maisadequadas. Através da utilização doconceito de agregado, o modelopermite também a harmonizaçãode decisões sobre acções interrela-cionadas que estão situadas emclusters diferentes.

O modelo de decisão proposto ser-ve ainda de apoio à tomada de de-cisões intercalares (isto é, entre doismomentos de planeamento) quan-do surgem situações imprevistascomo, por exemplo, o aparecimen-to de novas oportunidades não pre-vistas no momento de planeamen-to. Numa tal situação, a avaliaçãodestas novas oportunidades é facil-mente integrada no modelo e, nocaso de se concluir que as novasoportunidades devem ser imedia-tamente aprove i tadas, a re-atribuição de recursos é tambémbaseada no modelo.

Ricardo Afonso, Mestrado em Gestão da Infor-mação da Organizações, Faculdade de Economiada Universidade de Coimbra. Pós-graduado emFormação Avançada em Políticas e Gestão daInovação, Universidade de Aveiro. Licenciado emEstatística e Investigação Operacional, Faculdadede Ciências da Universidade de Lisboa. Actualmente é responsável pela divisão de Sistema deInovação e Projectos, na PT Inovação.

José Gonçalo Regalado, Mestrando da Rotterdam School of Management, Erasmus University,onde frequenta o programa de Master in Finance& Investments (Entrepreneurial Finance). Licenciatura em Gestão, Faculdade de Economia daUniversidade de Coimbra, tendo sido distinguidocom a Bolsa de Mérito da Universidade de Coimbra de melhor aluno da licenciatura. Pós-gra-duação no Programa de Executive Education emEntrepreneurship and Innovation Management naFaculdade de Ciências Económica e Empresariaisda Universidade Católica Portuguesa. Estagiáriona PT Inovação no âmbito do Programa Talentoda Inova-Ria. Actualmente é vice-presidente daComissão Política Nacional da Juventude SocialDemocrata.

Pedro Manuel Cortesão Godinho, ProfessorAuxiliar da Faculdade de Economia da Universidade de Coimbra e Investigador do Grupo deEstudos Monetários e Financeiros (GEMF). Licenciado em Engenharia Informática pela Faculdadede Ciências e Tecnologia da Universidade deCoimbra e Doutorado em Organização e Gestãode Empresas – Ciências dos Sistemas nas Orga-nizações pela Faculdade de Economia da mesmaUniversidade. Foi colaborador em vários de projectos de investigação e desenvolvimento financiados pela Fundação da Ciência e Tecnologia,e tem artigos publicados em diversas revistasinternacionais das áreas da Investigação Operacional e Finanças. Os seus actuais interesses deinvestigação situam-se nas áreas da Avaliaçãode Projectos, Mercados de Capitais e Gestão deProjectos.

Joana Rita Silva Fialho, doutoranda em Avaliaçãode Projectos de Investigação e Desenvolvimentona área das Telecomunicações. Mestrado emGestão da Informação nas Organizações. Licenciada em Matemática (Ramo Aplicada). DesdeJaneiro 2004 é equiparada a Assistente de 1ºTriénio no Departamento de Matemática da EscolaSuperior de Tecnologia de Viseu.

João Paulo Faria de Oliveira e Costa, ProfessorCatedrático da Faculdade de Economia da Universidade de Coimbra e Investigador do INESCCoimbra. Licenciado em Engenharia Electrotécnicapela Faculdade de Ciências e Tecnologia da Universidade de Coimbra e Doutorado em Economiade Empresa pela Faculdade de Economia damesma Universidade. Foi Investigador Responsávelou colaborador em vários de projectos deinvestigação e desenvolvimento financiados pelaFundação da Ciência e Tecnologia ou por outrasorganizações (empresas). Os seus interessessituam-se preferencialmente nas áreas de Sistemasde Apoio à Decisão, Investigação Operacional eAnálise e Avaliação de Projectos.


151

palavras-chave:pontos de função, medição,

métricas, contagem, estimativa.

Atualmente torna-se cada vez maisnecessário medir os projetos de desenvolvimento de software, visandoestabelecer uma medida de tama-nho independente da tecnologia deprogramação utilizada. Essa quan-tificação contribui tanto na atribuiçãodo “tamanho” de um software existente, como pode ser uma importante ferramenta para estimativas deum novo projeto de desenvolvimento. Uma destas medidas é possívelatravés da “Análise de Pontos de

Função” que, al iada a outrasmétricas, permite administrar os projetos de software através de medidas de tamanho, custo, manutençãoe evolução.

O objetivo deste artigo é apresentaros conceitos de pontos de função,tamanho funcional, processo decontagem e sua possível aplicaçãona PT Inovação.

João Batistella

Guilherme Pelegrin

Neila Campacci

02Pontos de Função e sua

Aplicação na PT Inovação


Pontos de Função e suaAplicação na PT Inovação

153

1. IntroduçãoNa condução de um projeto existemvários processos com o objetivo depermitir a sua gerência. De uma for-ma simplificada, pode-se dividir otrabalho com um projeto em: Pla-nejamento, Execução e Controle. Oplanejamento é uma das fases es-senciais de um projeto, onde se tra-ça o seu percurso e metas, escoposão estabelecidos, riscos são apon-tados e recursos e prazos necessá-rios para cumpri-lo são definidos.

Na prática, para a determinação dospontos citados, geralmente se utilizamais a experiência dos envolvidose sua intuição, do que critérios cien-tíficos baseados em parâmetrosneutros de impressões pessoais.

São notáveis as dificuldades encon-tradas na fase de planejamento poisé a etapa em que são sugeridos osprazos e custos de entrega sem quea especificação técnica dos requi-sitos funcionais tenha sido concluí-da. Como nessa fase só é possíveluma análise prematura da comple-xidade do projeto, é comum, no de-correr do trabalho, a necessidade

de alteração do plano em função deaspectos que foram subestimadosou superestimados durante a inicia-ção do projeto e podem gerar alte-ração de custo, prazo, escopo ouaté mesmo inviabilizar o projeto. Sen-do assim, surge a necessidade deuma metodologia com critérios cien-tíficos para quantificar a complexi-dade de um novo software, ou me-lhoria de um software já existenteantes da especificação técnica de-talhada.

Para o levantamento de complexida-de de um projeto de software exis-tem metodologias baseadas emmétricas de tamanho (contagem delinhas de código) ou baseadas emmétricas de função (Análise de Pon-tos de Função - AFP).

A análise de pontos de função pro-porciona uma medida de tamanhofuncional do software e, em con-junto com outras variáveis, poderáser utilizada para derivar produti-vidade, estimar esforço e custo, atémesmo antes da fase de especifica-ção técnica ser concluída.

2. O que é Análise de Pontos deFunçãoA análise de pontos de função éuma técnica que permite medir fun-cionalidades fornecidas por umsoftware do ponto de vista do seuusuário. Ponto de função é a unida-de de medida desta técnica quetem por objetivo tornar a medida in-dependente da tecnologia utilizadapara a construção do software.Desta forma, a APF busca medir oque o software faz, e não como eleé construído. A partir dos resultadosdessas medições é possível traçara relação entre a complexidade atri-buída e o tempo necessário para odesenvolvimento e por consequên-cia o custo.

2.1. O processo de contagem dePontos de FunçãoO processo de contagem de pontosde função (PF) pode ser resumidonos elementos apresentados na Fi-gura 1.

> Determinar o tipo de contagem:o tipo de contagem deve ser defi-nido pelos responsáveis pela me-dição e consiste em:

Figura 1 – Processo de contagem de pontos de função

Determinaro tipo decontagem

Identificarescopo dacontagem

e dafronteira daaplicação

Contarfunção dotipo Dados

Contarfunção do

tipoTransação

Determinarcontagem de

pontos de funçãonão ajustados

Determinar valor dofactor de ajuste

Calcular o númerodos pontos de

função ajustados

> Contagem de um projeto dedesenvolvimento, em que onúmero de pontos de funçãomede a funcionalidade forneci-da aos usuários finais do soft-ware quanto à sua primeira ins-talação. Conforme os requisitosvão ficando mais claros duranteo projeto, e as funções vão sen-do desenvolvidas, é bastantenatural identificar funcionalida-des que não haviam sido espe-cificadas inicialmente;

> Contagem de um projeto demelhoria, em que o número depontos de função mede as fun-ções adicionadas, modificadasou excluídas e também as e-ventuais funções de conversãode dados;

> Contagem de uma aplicação(ou baseline), que forneceuma medida da atual funcio-nalidade obtida pelo usuário daaplicação. Esta informação de-ve ser atualizada no término detodo o projeto de melhoria.

> Identificar escopo da contageme fronteira da aplicação: a fron-teira da aplicação é a interfaceconceitual que delimita o softwareque será medido e o mundo ex-terior (seus usuários). Esta etapaé uma das mais importantes, poisservirá de premissa para os pas-sos seguintes. Se a definição defronteira não estiver muito clara,há um grande risco de que todotrabalho de contagem posterior se-ja invalidado. O escopo da conta-gem define quais as funções queserão incluídas na contagem, seabrangerá um ou mais sistemas ouapenas parte de um sistema;

> Contar funções do tipo dados:as funções do tipo dados repre-sentam as funcionalidades forne-cidas pelo sistema ao usuário pa-ra atender as necessidades dearmazenamento de dados e sãoclassificadas em:

> Arquivo Lógico Interno (ALI),que consiste em um grupo logi-camente relacionado de dadosou informações de controle man-tidos dentro da fronteira de apli-cação sendo contada. Exemplo:tabela de banco de dados sendoatualizada pela aplicação;

> Arquivo de Interface Externa(AIE), que consiste em um gru-po logicamente relacionado dedados ou informações de con-trole mantidos fora da fronteirada aplicação sendo contada.Exemplo: tabela de banco dedados lida pela aplicação, masatualizada por outra aplicação.

> Contar funções do tipo transa-ção: as funções do tipo transaçãorepresentam os requisitos de pro-cessamento fornecidos pelo siste-ma ao usuário e são classificadasem:

> Entrada Externa (EE), tran-sação que processa dados ouinformações de controle origi-nadas fora da fronteira da apli-cação. Sua principal intenção émanter um ou mais arquivos lógi-cos internos e/ou alterar o com-portamento do sistema. Exem-plo: incluir cliente, alterar cliente,excluir cliente;

> Saída Externa (SE), transaçãoque envia dados ou informaçõesde controle para fora da fronteirada aplicação. Sua principal in-tenção é apresentar informaçãoao usuário através da lógica deprocessamento. Exemplo: rela-tório de totais de faturamentopor cliente;

> Consulta Externa (CE), transa-ção que envia dados ou infor-mações de controle para forada fronteira da aplicação. Suaprincipal intenção é apresentarinformações ao usuário atravésda simples recuperação de da-dos ou informações de controlede ALI e/ou AIE. Exemplo: con-


sulta de cadastro de cliente.

> Determinar contagem de pon-tos de função não ajustados: ospontos de função não ajustadosmedem os requisitos específicosdo usuário. O termo específico in-dica que é possível apontar para umrequisito (um relatório, um gráfico,uma transação de entrada de da-dos, etc.) e dizer o seu valor em PF;

> Determinar o valor do fator deajuste: o fator de ajuste, em con-trapartida aos pontos de funçãonão ajustados, tem o propósito demedir requisitos gerais da apli-cação. A partir do levantamentodos pontos de função não ajus-tados aplica-se um fator de ajustebaseado em notas atribuídas às14 características gerais do sis-tema para a determinação do nívelde influência, como: 1. Comunica-ção de Dados; 2. ProcessamentoDistribuído; 3. Performance; 4.Configuração Altamente Utilizada;5. Volume de Transações; 6: Entra-da de Dados Online; 7. Eficiênciado Usuário Final; 8: Atualização On-line; 9. Processamento Complexo;10. Reusabilidade; 11. Facilidadede Instalação; 12. Facilidade deOperação; 13. Múltiplos Locais e14. Modificação Facilitada;

> Calcular o número de pontos defunção ajustados: cada tipo decontagem (projeto de desenvolvi-mento, projeto de melhoria e apli-cação) possui uma fórmula espe-cífica para a determinação dospontos de função ajustados.

2.2. Críticas e RestriçõesA APF não apresenta uma estruturarígida, pois o resultado de uma esti-mativa pode variar de organizaçãopara organização ou até mesmo en-tre a equipe envolvida na análise.Desta forma, a maior crítica à meto-dologia se deve à subjetividade. Dequalquer maneira, com a experiênciaadquirida com a utilização prática, aanálise tende a ser mais eficaz namedida em que o histórico de análi-

155 Pontos de Função e suaAplicação na PT Inovação

“ServiceOption” em “TipoRede”(nova função);

> Função para a geração do arquivo;

> Função de tela.

Funções do tipo “Dados”: a con-tagem das funções do tipo “Dados”é apresentada na Tabela 1.

Funções do tipo “Transação”: acontagem das funções do tipo“Transação” é apresentada na Ta-bela 2. Pontos de função não-ajus-tados: consiste na soma da contri-buição de cada função. Neste caso34 (Total funções do tipo “Dados”+ To t a l f u n ç õ e s d o t i p o“Transação”).

Fator de ajuste: é obtido pelo nívelde influência das seguintes carac-terísticas gerais do sistema.

O fator de ajuste é obtido pela

ses anteriores, em comparação comos resultados obtidos, é utilizadocomo um importante fator de ajuste.

Como foi projetada inicialmente parao tratamento de projetos comerci-ais, nota-se na teoria proposta paraa APF o foco acentuado nas dimen-sões de dados, o que pode não seadequar a organizações em diferen-tes contextos. Da mesma forma,algumas das características gerais,apresentadas como critérios para a-juste dos pontos de função, podemnão fazer sentido, dependendo dotipo da aplicação em questão. Umapossível solução seria a organizaçãoadotar critérios próprios, de acordocom suas necessidades.

3. Estudo de CasoPara aplicar os conceitos descritosacima será apresentado um exem-plo prático.

O estudo de caso consiste na inclu-

são do campo “ServiceOption” re-cebido na sinalização enviada poruma rede de telecomunicaçõespara uma plataforma de rede inteli-gente, processado por esta platafor-ma e transformado em “TipoRede”.Deverá ser apresentado na tela daaplicação e enviado em um arquivo.

Tipo de contagem: projeto de me-lhoria.

Fronteira da aplicação: a fronteirada contagem é apresentada naFigura 2.

Escopo da contagem: o escopoda contagem consiste em funçõesque serão alteradas e criadas paraatender a inclusão do campo, con-forme descritas abaixo:

> função de recebimento da sinali-zação;

> função para transformar o campo

Rede Plataforma de Rede Inteligente Sistema Receptor de Bilhetes

Compo ServiceOption Campo “Tipo Rede”

Fronteira da Contagem

Figura 2: Estudo de caso – fronteira da contagem

Tabela 1: Estudo de caso – funções do tipo “Dados”

“ServiceOption”

“ServiceOption”

“ServiceOption”


fórmula:

Onde TDI é a somatória dos níveisde influência das característicasgerais e VAF consiste no Valor doFator de Ajuste.

Cálculo dos Pontos de FunçãoAjustados: os pontos de funçãoajustados são calculados com aseguinte fórmula:

Tabela 2: Estudo de caso – funções do tipo “Transação”

Tabela 3: Estudo de caso – nível de influência das características

Em que:

EFP: Número de pontos de funçãodo projeto de melhoria;

ADD: Número de pontos de funçãonão ajustados das funções incluídaspelo projeto de melhoria;

CHGA: Número de pontos de fun-ção não ajustados das funções mo-dificadas (reflete funções depois das

modificações);

CFP: Número de pontos de funçãonão ajustados adicionados pela con-versão;

VAFA: Valor do fator de ajuste da a-plicação depois do projeto de me-lhoria;

DEL: Número de pontos de funçãonão ajustados das funções excluí-das pelo projeto de melhoria;

“ServiceOption” Média

Baixa

Referências[1] Livro Análise de Pontos de Função – Medição,Estimativas e Gerenciamento de Projetos de Software. Carlos Eduardo Vasques, Guilherme SiqueiraSimões e Renato Machado Albert. Editora Érica.7ª. Edição.[2] Artigo Métricas e Estimativas de Software – oinício de um rally de regularidade. APInfo (http://www.apinfo.com/artigo44.htm). Alvaro Eduardo Gomes.

Neila de Faria Ribeiro Campacci, bacharel emComputação Científica pela UNITAU. Pós-Gra-duada em Informática Empresarial pela UNESP eem Engenharia de Redes e Sistemas deTelecomunicações pelo INATEL, com especia-lização em Negociação pela FGV. Atuou comoAnalista de Sistemas na Ericsson do Brasil, de2000 a 2003. É Analista de Sistemas da PTInovação Brasil desde 2003. Atuou na equipe derequisitos onde esteve envolvida na especificaçãode requisitos das funcionalidades da plataformaNGIN em diversos projetos. Trabalha atualmentena equipe de gestão de projetos e entregas, ondeatua no gerenciamento de projetos da plataformaNGIN Pré-Pago da Vivo.

João Paulo Guimaro Batistella, graduado emEngenharia de Computação pela Unicamp e Pós-Graduando em Gestão de Projetos pela FGV.Engenheiro da PT Inovação Brasil desde 2003,esteve envolvido no suporte, implantação e desenvolvimento da solução NGIN no Brasil, envolvido com diversos módulos da solução NGIN,trabalha atualmente com a equipe de gestão deprojetos NGIN para a Vivo no Brasil.

Guilherme Castells Pelegrin, bacharel em Informática pela USP São Carlos. Analista de projetosda PT Inovação desde 2006, onde esteve envolvido no planejamento e controle dos projetos demigração de dados e desenvolvimento. Trabalhaatualmente na equipe de gestão de projetos eentregas onde atua no gerenciamento de projetosda plataforma NGIN Gestão da Vivo.

VAFB: Valor do fator de ajuste da a-plicação antes do projeto de melhoria.

No caso que estamos apresentan-do temos:

Desta forma, este projeto de me-lhoria foi medido em 54 pontos defunção. Com este valor é possívelcomparar este projeto com anterio-res e determinar uma estimativa decusto, esforço, recursos necessá-rios e prazo de entrega dentre ou-tros parâmetros do planejamento.

4. ConclusãoCom a análise de pontos de funçãoé possível medir o tamanho do soft-ware desenvolvido, na qual uma ba-se histórica de medições permite arealização de estimativas cada vezmais precisas, garantindo um pla-nejamento próximo da realidade.

Para a implementação desta técni-ca na PT Inovação, pode se adotara estratégia de aplicação da técnicapara se estimar o tamanho do soft-ware já desenvolvido a fim de serutilizado como parâmetro para esti-mativas futuras. Devido ao tamanhodo sistema, talvez seja inviável pros-seguir com a estimativa por com-pleto, sendo mais proveitoso efetuarmedições de componentes signi-ficativos, obtendo-se amostragenscoerentes.

Além disso, a adoção de critériospróprios para fator de ajuste (comograu de interação entre os módulosde desenvolvimento no caso da PTInovação), aliados aos já apresen-tados, pode ser um importante dife-rencial. Dos critérios apresentadoscomo padrão, alguns possivelmen-te sempre terão um grande pesoatribuído (ex.: comunicação de da-dos ou processamento distribuído)enquanto outros raras vezes pode-rão impactar no ajuste (ex.: eficiên-cia do usuário final). A partir da ex-periência adquirida com a práticano ajuste dos pontos não ajustados

poderá se decidir pela adaptaçãode critérios que apresentarem valo-res constantemente muito altos oumuito baixos. Algumas extensõesde pontos de função estão sendoestudadas e desenvolvidas paraacompanhar a evolução do desen-volvimento de software. Alguns exem-plos são: Feature Points (ou pontoscaracterísticos) que se adaptamelhor para aplicações com altacomplexidade algorítmica e Pontosde Função 3D que permite mensu-rar aplicações que necessitem demuita capacidade funcional e eleva-do grau de controle.

Independente da técnica utilizada,considerando a mais adequada paraas características do software de-senvolvido, a cada dia torna-se indis-pensável a utilização de uma técnicacientífica para a medição de custo,produtividade e qualidade não só doproduto final, mas também de todoo processo. Com estas medições, eo auxílio das técnicas aliadas a ex-periência de desenvolvedores comconhecimento do sistema, é pos-sível realizar estimativas acertadas,pois como diz Alvaro Eduardo Go-mes, autor do artigo ”Métricas eEstimativas de Software” do site

157 Pontos de Função e suaAplicação na PT Inovação

palavras-chave: RPG, ATENA

O Sector das Telecomunicações atra-vessa uma fase de profunda transformação com desafios em váriasáreas, sendo de destacar as ligadasàs tecnologias aos processos e àspessoas. Estas últimas são um dosprincipais factores a ter em contasendo aqui de extrema importânciagarantir a atempada adequação àsalterações tecnológicas e da mudan-ça de paradigma a elas associadas.

Consciente desse problema, a PTComunicações decidiu em Junhode 2006 enfrentar o desafio de reali-zar um diagnóstico dos conhecimentos tecnológicos, das competênciasfuncionais e da gestão operacionaldetidos pelas Quadros das suasDirecções de Redes, iniciativa quedesignou por ”Projecto Atena”, e naqual a PT Inovação foi convidada aassociar-se logo desde a fase deconcepção.

No diagnóstico feito (2º semestre de2006) identificaram-se os principais“espectros” de conhecimentos tecno-lógicos existentes em cada uma dasáreas chave da PTC – Um RetratoActual da PTC – na sequência doqual foram desenhadas e lecciona

das (durante 2007) várias acçõesde refrescamento e qualificação pro-fissional dos colaboradores, visandodotá-los de conhecimentos actuaise suficientes para acompanhar deforma positiva a evolução que estáem curso, em que a oferta de ser-viços suportados em redes TDM está rapidamente a evoluir para o novoparadigma de comunicação, totalmente suportado no Protocolo IP.

A PT Inovação participou na espe-cificação e concepção dos respectivos conteúdos e ficou depois encarregue da execução da formação,desafios que lhe permitiram atingirníveis de desempenho na vertentede formação bastante significativos,quer do ponto de vista tecnológico,quer do ponto de vista de organização.

Este artigo resume os principais aspectos do trabalho desenvolvido, edescreve a suite de formação, pelaqual já tinham passado, no final de2007, cerca de 50% dos Quadrosdas áreas de rede da PTC.

Manuel Marques Mário Almeida

03Os Desafios à Formação do Projecto ATENA


Os Desafios à Formaçãodo Projecto ATENA

159

1. IntroduçãoA reconversão tecnológica de umarede de telecomunicações, colocadesafios a um operador de teleco-municações de dimensões significa-tivas, nomeadamente os relaciona-dos com os recursos humanosespecializados. Os quadros queactuam na área técnica, quer na ope-ração da rede, quer na manutençãoe gestão da mesma, terão de possuirvalências que lhes permitam ter umaeficácia elevada nestes domínios,de modo a responder, em tempoútil, aos problemas colocados.

O desafio actual do grupo PT, emtermos tecnológicos, consiste namigração das redes baseadas emcomutação de circuitos, para redesbaseadas em comutação de paco-tes. Estas redes de comutação depacotes, desenvolvidas em tornodo protocolo IP (versão 4 e versão6), permitem o desenvolvimento deserviços onde o conceito de conver-gência é potenciado ao máximo.Acresce a possibilidade de os mes-mos terem associado o conceito dequalidade de serviço, que pode servariável, permitindo assim novos

modelos de negócio. Quando se fa-la em convergência de serviços esta-mos a falar de convergência total;um serviço em qualquer lugar, emqualquer terminal, a qualquer hora.

Perante este desafio, ao qual presideigualmente a necessidade de se ga-rantir o suporte às tecnologias ma-duras, que coabitarão com as novasainda durante vários anos, haverá,salvo melhor opinião, duas possibili-dades para a solução do problemado conhecimento detido pela organi-zação: a substituição rápida e com-pleta dos seus Quadros e Técnicosespecializados, ou a sua reconver-são tecnológica, total ou parcial, dasactuais tecnologias para as asso-ciadas ao novo paradigma de rede.

A primeira possibilidade contémcustos significativos, não só finan-ceiros, como sociais, para além daperda significativa de conhecimentohoje detido, relativo às diferentes in-fra-estruturas de suporte ao negó-cio, e que continuará a ser funda-mental manter na fase de transição.A segunda solução é então a quemais vantagens oferece, apesar de

ser mais exigente para os recursoshumanos. Este tipo de processosde aprendizagem são normalmentebastante exigentes, seja em termosde tempo, disponibilidade opera-cional, para libertar recursos do seuquotidiano operacional para acçõesde formação, quer em termos de a-daptação aos racionais sobre osquais as redes futuras se estão rapi-damente a suportar.

A PT, como tem sido prática desdesempre, optou pela reconversão deQuadros, a qual foi posta em práticaem paralelo com o refrescamentoobtido com admissões de jovens li-cenciados (trainees) e com uma po-lítica de saídas negociadas.

Este artigo aborda o processo segui-do na PT Comunicações e na PTInovação, na componente de pre-paração de conteúdos pedagógicos,visando o refrescamento e/ou a re-conversão de Quadros, que tevecomo base os resultados recolhidosno trabalho de campo do ProjectoATENA, onde os espectros dos co-nhecimentos individuais foram levan-tados.


2. Descrição do processo (1)Na sua fase inicial, em Agosto de2006, o Projecto Atena identificouum conjunto de conhecimentos téc-nicos e de competências chave, co-brindo todo o espectro das tecnolo-gias presentes no negócio de tele-comunicações, desde os suportesfísicos até aos desenvolvimentosWeb, passando pelas redes madu-ras ou em final de vida, pelas redesIP, pelas Rede de Próxima Geraçãoe pelos conteúdos. Este trabalho ini-cial permitiu caracterizar o conheci-mento tecnológico detido ao nívelde cada Quadro, que levou depoisao desenho de uma matriz de perfisde conhecimentos e à definição deáreas de actuação, actuais e futuras,bem como ao percurso profissionalmais adequado para cada Quadro.

Foram a seguir desenvolvidos Mó-dulos de Formação Atena, desenha-dos em função dos resultados de-tectados na fase de diagnóstico,permitindo depois que cada Direc-ção desenhasse para os seus Qua-dros os percursos formativos ATE-NA que se mostrassem mais eficazespara cada caso. Os primeiros Módu-los de Formação tiveram lugar emJunho de 2007.

O projecto passou assim por 3 Fases:Concepção, Diagnóstico e Operacio-nalização.

Na fase de Concepção foram cons-truídos questionários de diagnós-tico, onde também foram identifica-dos os vários níveis de proficiênciadando origem à elaboração de Ma-trizes de Competências / Conheci-mentos / Processos / Expectativas:

> identificação dos conhecimentose competências a diagnosticar;

> definição das questões de expec-tativas profissionais e processos;

> definições e Key Words.

Foram enviados questionários a2638 Quadros das áreas de redesda PTC, tendo sido finalizados 2573(97,54%).

Os Quadros que acumulavam fun-ções de Chefia/Gestão, preenche-ram igualmente questionários relati-vamente aos seus colaboradoresdirectos. Assim, cada colaboradorficou caracterizado tanto pela suaauto-avaliação, como pela carac-terização da sua chefia.

Os questionários, respondidos via In-tranet, conduziram a que cadaQuadro se auto-avaliasse ao longode 8 Competências Funcionais, 173Conhecimentos Técnicos, e 7 Com-petências de Gestão (apenas parao caso de Quadros com responsa-

bilidades de enquadramento deequipas).

Após uma primeira análise de resul-tados seleccionaram-se, mediantecritério pré-determinado, um sub-conjunto de respostas cujo conteú-do foi considerado necessário aferiratravés de entrevistas individuais.Com esse objectivo foram realiza-das ao longo do país 197 entrevis-tas, correspondente a cerca de15% do universo em estudo.

Foi ainda possível representar a dis-tribuição de conhecimentos e decompetências detidos pela popula-ção diagnosticada, sob a forma deimagem gráfica de leitura rápida, co-mo se exemplifica na Figura 1.

O gráfico exibe o nível de proficiên-cia reportado ao subconjunto das75 primeiras Questões relativas aosConhecimentos Técnicos e tipificao nível de proficiência do universoPTC, onde neste caso predomina onível 0, e 1, numa escala de 0 a 4,onde o nível 4 é o mais elevado.

As primeiras perguntas relacionam--se com teoria de transmissão, su-portes físicos, infra-estruturas desuporte, tecnologia de comutação,e transmissão, x.25, ADSL, framerelay e ATM. O segundo gráfico, Fi-gura 2, refere-se já à tecnologia IP,

Figura 1- Proficiência Tecnologias de Rede

Teoria daTransmissão

SuportesFísicos

Infra--EstruturaSuporte

Tecnologias deTransmissão

RedeTelefónica

Tecnologiade

Comutação Red

e X.

25

Red

e F

Rel

ay

Red

e AT

M

Rede DSL

161 Os Desafios à Formaçãodo Projecto ATENA

-se ainda manchas consistentes depotencial de conhecimentos reporta-dos como não aplicados, tanto nastecnologias maduras, como nas no-vas tecnologias.

Todos estes aspectos foram depoislevados em conta no desenho dasArquitectura de Formação Atena.

3. Arquitectura da FormaçãoATENAO modelo seguido para a imple-mentação do percurso de formaçãofoi estruturado em quatro camadas(Figura 3).

A camada 1 tem como objectivofornecer conceitos básicos de redese sistemas de telecomunicações,de proporcionar uma primeira abor-dagem aos aspectos mais relevan-tes que caracterizam o ProtocoloIP. O diagnóstico do ATENA haviaevidenciado ser necessário dotar amaioria dos Quadros de maisconhecimento acerca deste proto-colo, no qual se estão a baseartodos os negócios nas telecomuni-cações, pelo que foi dada especialrelevância aos respectivos conceitos.

Como atitude pragmática, foi deci-dido iniciar de imediato o desenvol-vimento dos módulos relativos àsduas primeiras camadas do mode-lo. Tirou-se partido do portefólio deprogramas de formação já dispo-nibilizados pela PTIN, cujos conteú-

notando-se neste caso que o pesodo nível 0 é bastante mais significa-tivo, assim como também para astecnologias de informação.

Podemos dizer que, de uma formasimples, o nível de proficiência 0tem, neste exemplo particular, umaadesão muito significativa.

Terminado o diagnóstico e analisa-dos os resultados que foram pre-sentes ao CA da PTC em finais de2006, a PTC passou a ficar dotadade um mapeamento transversal às

Direcções de Redes das competên-cias de conhecimentos tecnológicosexistentes na organização. Esse ma-peamento evidenciou conhecimen-tos significativos em áreas estratégi-cas para o futuro.

Em contrapartida, detectou existiremmanchas significativas de ausênciade conhecimento em todo o universoestudado, ligeiramente atenuadas nastecnologias tradicionais e nas redesdomésticas/soluções de cliente, queprovocaram a redução dos valoresmédios das respostas. Detectaram-

Figura 3 – Arquitectura do modelo ATENA

Figura 2 - Proficiência Protocolo IP

Rede IP Wi-Fi Rede de PróximaGeração - Voz


dos foram devidamente adaptadosde forma a cobrir zonas onde o tra-balho de campo do Atena havia de-tectado maiores lacunas de conhe-cimento.

Todos os módulos obedeciam à li-nha estruturante de passar gradual-mente aos formandos os conceitosque se encontram por detrás do fun-cionamento das Redes de PróximaGeração (RPG), e da mudança doparadigma da comunicação, bemcomo do papel estruturante que aícabe ao Protocolo IP, tratado desdelogo no primeiro Módulo da Camada1, e depois desenvolvido sucessi-vamente ao longo das camadas se-guintes.

A suite de formação ATENA inte-grava sessões em sala, comple-mentadas com warm-up´s de ac-ções de auto-formação suportadasem módulos de eLearning anterior-mente desenvolvidos pela PTIN edos quais o Projecto ATENA tiroupleno partido. Estes módulos deeLearning encontram-se identifica-dos com as siglas LO (LearningObject) nas Figuras 4 e 5.

Para a camada 1 foram identifica-das as acções de formação cons-tantes da Figura 4.

Para a camada 2 foram identifica-das as acções de formação da Fi-gura 5.

As camadas 3 e 4 ainda se encon-tram muito pouco especificadas,uma vez que os conteúdos destassão muito dependentes das aplica-ções em concreto.

4. ResultadosConcluídos os conteúdos relativosas acções de formação para a ca-mada 1 e 2, foram identificados pe-las diversas Direcções das áreas derede cerca de 950 formandos aosquais estas acções seriam minis-tradas. Nesta fase, o envolvimentoda PT Inovação foi mais intenso,seja na definição dos conteúdos

Figura 4 - Formação Básica em RPG

para cada um dos módulos, sejamno aperfeiçoamento dos mesmos ena identificação do formador maisadequado à monitoria de cada mó-dulo. Após uma primeira fase de vali-dação dos conteúdos, com turmaspiloto que decorreram em Junho eJulho de 2007, entrou-se numa fasede produção muito intensa, a qual

atingiu picos de mais de 90 alu-nos/semana durante o mês de No-vembro.

A percentagem de ocupação doscursos, na sua maioria compostapor turmas com 20 formandos, foina faixa dos 90%, número bastanteinvulgar em acções deste tipo.

Figura 5 - Formação Avançada em RPG

LO.WiMAX

A.2.1 A.2.2 A.2.3

LO.VPN’s

A.2.4

LO.Ethernet

A.2.5

LO.RedesConvergentes

A.2.6 A.2.7

LO.VoIP LO.IP Tv

LO.XXX - Módulos de eLearning

Referências

[1] Eng. Mário de Almeida - Projecto “ATENA”Metodologia, Principais Resultados e suaImplementação.

Manuel Veríssimo P. M. Marques, licenciou-seem Engenharia de Electrónica e Telecomunicações(Universidade de Aveiro, 1982) é Mestre em Engenharia de Electrónica e Telecomunicações (Universidade de Aveiro, 2000). Desenvolve actualmente a sua actividade na área das Redes dePróxima Geração (RPG), dedicando especialatenção a formação tecnológica dos quadros daPT em RPG.

Mário J. F. de Almeida, licenciou-se emTelecomunicações e Electrónica no Instituto Superior Técnico, Lisboa (1972), e desde 1974 quedesenvolve a sua actividade no sector das tele-comunicações. Coordenou a intervenção da PTna EXPO’98; entre 2001 e 2003 desempenhoufunções em S. Paulo, como CTO da Primesys.Foi responsável pela primeira fase do ProjectoAtena concluída em Janeiro de 2008.

Nesta fase do plano de formaçãofoi já possível integrar formandos daDON A e da DON M.

No final de 2007, cerca de 50% dapopulação inicialmente identificadahavia passado por um ou mais Mó-dulos de Formação ATENA

5. Importância para os negóciosda PTCEste projecto tem sido fundamentalpara o grupo PT. Sendo previsível acurto prazo a substituição da co-mutação de circuitos por comu-tação de pacotes, (existem refe-rências temporais para início dapróxima década) esta reconversãoprofissional adquire uma premênciaelevada, e uma criteriosa selecçãode novos quadros e de novostécnicos.

6. ConclusõesNo final de 2007, levando em contaa percentagem da população alvoque tinha sido coberta, bem comoo número de horas leccionadas, foipossível retirar algumas conclusões,quer quanto à forma como os con-teúdos foram desenvolvidos, querquanto ao modo como a formaçãodecorreu.

Na camada 1, a Acção A.1.0 - Fun-damentos do Sistema de Telecomu-nicações, com a duração de 2,5dias, foi considerada de enorme utili-dade, sendo opinião generalizadaque ela se afigura aplicável não sóà população oriunda das áreas téc-nicas, mas igualmente à das áreascomerciais, que até ao momentonão haviam sido envolvidas.

A Acção A.1.1 – Fundamentos doTCP/IP no Contexto das Redes dePróxima Geração, igualmente com aduração de 2,5 dias, foi por algunsformandos considerada como dema-siado intensa e especializada paraacção da camada 1. Este aspectoestá a ser levado em conta com vistaa eventuais acções futuras.

O Plano de Formação ATENA 2007

disponibilizou para as duas Acçõesda Camada 1, um total de 440 va-gas, tendo registado em ambas ín-dices de frequência superiores a90%, traduzindo o interesse pelotema, acrescido de uma invulgar ca-pacidade de mobilização do ladodas Direcções de Redes da PTC.

Na Camada 2, as Acções mais fre-quentadas foram a A.2.1. – Rede deTransmissão e a sua Envolvente, ea A.2.5. – Introdução às Redes dePróxima Geração, ambas com índi-ces de ocupação acima de 85%. OPlano 2007 calendarizou 16 turmasno total das Acções da camada 2,equivalente a uma oferta de 400 lu-gares de formação.

Uma área onde se identifica uma ne-cessidade de rever quer conteúdos,quer metodologia de formação é aobservada na Acção 2.7. – IT e Pla-taformas de Serviço. Foram efec-tuadas 3 edições nas quais não selogrou atingir um envolvimento daparte dos formandos na temática aabordar, havendo ainda necessidadede obter consensos relativamenteaos conteúdos estruturantes a quea Acção se deverá subordinar.

Da experiencia conjunta PTC/PTINao longo desta fase do Projecto ATE-NA, podemos afirmar que o sucessode iniciativas deste tipo depende daatempada e eficaz concretização decada uma de 6 etapas estruturantesa levar à pratica de modo sequencial.

Do lado da entidade formadora:

> conhecer a população alvo e de-senhar a adequada arquitecturade cursos;

> especificar objectivos e conteúdos;

> desenvolver os suportes e enqua-drar os formadores.

Do lado dos formandos e de quemos selecciona:

> mapear os colaboradores e defi-

nir-lhes um percurso;

> inscrevê-los nos cursos pela se-quência certa;

> explicar-lhes porque foram inscri-tos.

Como em tantas outras situaçõesque ocorrem no âmbito do negócioda PTC, o resultado final será sem-pre aferido pelo da etapa que vier arevelar-se pior concretizada.

Notas:(1) Esta fase do Projecto Atena incidiu sobre osQuadros do Continente. Foi mais tarde estendidoà DON-A e DON-M. Nos dois casos contou coma colaboração da Accenture, seleccionadainicialmente para apoiar a PTC na definição dametodologia, no lançamento dos questionários ena análise dos resultados.

163 Os Desafios à Formaçãodo Projecto ATENA

siglas &acrónimos

#

3G Terceira geração

3GPP 3rd Generation Partnership Project

A

AAA Authenticathion, Authorization and Accounting

AACv2 Advanced Audio Coding v2

ABC Always Best Connected

ADM Add/Drop Multiplexers

ADSL Asymmetric Digital Subscriber Line

AIE Arquivo de Interface Externa

AJAX Asynchronous Javascript and XML

ALC Asynchronous Layered Coding

ALI Arquivo Lógico Interno

AmI Ambientes Inteligentes

AMR-WB+ Adaptive Multi Rate – WideBand plus

AN Ambient Networks

ANA Autonomic Network ArchitectureAPF Análise de Pontos de Função

API Application Programming Interface

APN Access Point Name

AR Arquivo Referenciado

ARPANET Advanced Research Projects Agency Network

ARPU Average Revenue Per User

ARQ Automatic Repeat Request

AS Application Server

ASA Autonomic Service Architecture

ASN-GW Access Service Network Gateway

ATM Asynchronous Transfer Mode

AVC Advanced Video Coding

BB2BUA Back-to-Back User Agent

BGCF Breakout Gateway Control Function

BGP Border Gateway Protocol

BiM Binary Mode

BM-SC Broadcast Multicast - Service Center

BNG Broadband Network Gateway

BPEL Business Process Execution Language

BPMS Business Process Management Systems

BPR Business Process Reengineering

BS Base Station

BSS Business Support Systems

CCA Conselho de Administração

CAP CAMEL Application Part

CAPEX Capital Expenditure

CCA Command Core Architecture

CDC Connected Device Configuration

CDMA Code Division Multiple Access

CDR Call Detail Records

CE Consulta Externa

CET Carrier Ethernet Transport

CID Connection Identifier

CIDR Classless Inter-Domain Routing

CIF Common Intermediate Format

CLDC Connected Limited Device Configuration

CO Connection-Oriented

COFDM Coded Orthogonal Frequency Division Multiplexing

CoS Class of Service

CoT Circle of Trust

CPE Customer Premises Equipment

CPU Central Processing Unit

CRBT Coloured Ring Back Tone

CS Circuit Switched

CSCF Call Session Control Function

CSE Camel Service Enviornement

CTF Control Transport Framework

DDEI Departamento de Engenharia Informática

DiNO Download Innovation

DLC Dynamic Layer Container

DL-SCH Downlink Shared Channel

DNS Domain Name System

DNSBL DNS-based Blacklists

DOM Document Object Model

DON-A Direcção Operacional de Negócios - Açores

DON-M Direcção Operacional de Negócios - Madeira

DSLAM Digital Subscriber Line Access Multiplexer

DVB Digital Video Broadcasting

DVB-H Digital Video Broadcast – Handheld

DVB-IPDC Digital Video Broadcasting - Internet Protocol Datacasting

DVB-SH Digital Video Broadcasting - Satellite to Handheld

DVB-T Digital Video Broadcasting – Terrestrial

DVD Digital Versatile Disc

DWDM Dense Wavelength Division Multiplexing

EECG ElectroCardiograma

ECMP Equal-Cost Multipath

EE Entrada Externa

EMG ElectroMiograma

eNB evolved Node B

EPC Evolved Packet Core

EPG Electronic Program Guide

ESB Enterprise Service Bus

ESG Electronic Service Guide


siglas & acrónimos165

eTOM enhanced Telecom Operations Map

ETSI European Telecommunications Standard Institute

E-UTRAN Evolved Universal Terrestrial Radio Access Network

FFCAPS Fault, Configuration, Accounting, Performance,

Security

FDMA Frequency Division Multiple Access

FEC Forward Equivalence Classes

FEC Forward Error Correction

FFT Fast Fourier Transform

FLUTE File Delivery over Unidirectional Transport

FLV Flash Video

FMIP Fast Mobile IP

FQDN Fully Qualified Domain Name

FTP File Transfer Protocol

GGDA Group Destination Address

GEMF Grupo de Estudos Monetários e Financeiros

GGSN Gateway GPRS Support Node

GMPLS Generalized MPLS

GPS Global Positioning System

GSA Group Source Address

GSM Global System for Mobile Communication

GZIP GNU Zip

HHARQ Hybrid Automatic Repeat Request

HO Handover

HSDPA High-Speed Downlink Packet Access

HSPA High Speed Packet Access

HSS Home Subscriber Server

HTML HyperText Markup Language

HTTP Hyper Text Transfer Protocol

HTTPS Hyper Text Transfer Protocol Secure Sockets

H-VPLS Hierarchial VPLS

I

I-CSCF Interrogating CSCF

IDE Integrated Development Environment

IdP Identity Provider

IEEE Institute of Electrical and Electronic Engineers

IETF Internet Engineering Task Force

IGMP Internet Group Management Protocol

IMAP4 Internet Message Access Protocol

IM-SSF IP Multimedia - Service Switching Function

IMS IP Multimedia Subsystem

INESC INstituto de Engenharia de Sistema e Computadores

INM In-Network Management

IP Internet Protocol

IPDC IP Datacast (over DVB-H)

IPoE Internet Protocol over Ethernet

IPTV Internet Protocol Television - Televisão Digital

sobre protocolo IP

ISC IMS Session Control

ISDB-T Integrated Services Digital Broadcasting - Terrestrial (Japan)

ISDN Integrated Services Digital Network

ISIS Intermediate System to Intermediate System

IS-IS Intermediate System to Intermediate System

ISP Internet Service Provider

IT Information Technology

ITU-T International Telecommunications Union - Telecommunication Standardization Sector

JJ2EE Java 2 Enterprise Edition

J2ME Java 2 Micro Edition (Sun)

JAIN Java APIs for Integrated Networks

jBPM Java Business Process Management

JCP Java Community Process

JDBC Java Database Connectivity

JEE Java Enterprise Edition

JMX Java Management eXtensions

JSD JavaServer Pages

JSR Java Specification Request

JTWI Java Technology for the Wireless IndustryJUSSA Joining Useful Systems in Sustainable

Architecture

LL2VPN Layer 2 Virtual Private Network

LA Liberty Alliance

LDAP Lightweight Directory Access Protocol

LDP Label Distribution Protocol

LIF Location Interoperability Forum

LSP Label Switched Path

LTE Long Term Evolution

MMAC Medium Access Control

MAS Mobile Service Architecture

MBMS Multimedia Broadcast/Multicast Service

mCID multicast CID

MDF Media Delivery Function

MDFC Media Delivery Function Controller

MDFP Media Delivery Function Processor

MediaFLO Media Forward Link Only

MEF Metro Ethernet Forum

MExE Mobile EXecution Environment

MGCF Media Gateway Control Function

MGW Media Gateway

MICS Media Independent Command Service

MIES Media Independent Event Service

MIH Media Independent Handover

MIHF Media Independent Handover Function

MIHO Mobile Initiated Handover

MIHU Media Independent Handover Function Users


MIIS Media Independent Information Service

MIMO Multiple Input, Multiple Output

MME Mobility Management Entity

MMS Multimedia Messaging Service

MPE Multi Protocol Encapsulation

MPEG -2 Motion Picture Experts Group 2 (Standard - Compressed Video at 4-9 Mbps)

MPLS Multi Protocol Label Switching

MRF Multimedia Resource FunctionMRFC Multimedia Resource Function Controller

MRFP Multimedia Resource Function Processor

MSC Multimedia Session Continuity

MTA Mail Transport Agent

NNA Network Activator

NAS Non-Access Stratum

NAT Network Address Translation

NE Network Equipment

NGIN Next Generation Intelligent Networks

NG-PDH New Geneation –Hierarhy Plesiochronous DigitalHierarchy

NIHO Network Initiated Handover

NMS Network Management Systems

Non-PoS Non-Point of Service

OO2CS Online/Offline Charging System

OAM Operation And Management

OCS Online Charging System

OFDM Orthogonal Frequency Divison Multipexing

OFDMA Orthogonal Frequency Division Multiple Access

OM Order Manager

OMA Open Mobile Alliance

OMA OSE Open Mobile Alliance – Open Services Environment

OPEX Operational Expenditure

OSA-SCS Open Service Access - Service Capability Server

OSE OMA Service Environment

OSE Open Source Engine

OSI Open Systems Interconnection

OSPF Open Shortest Path First

OSS Operations Support Systems

OTN Optical Transport Network

OTT Over The Top

PPAPR Peak-to-Average Power Ratio

PASI Plano de Acção para a Sociedade da Informação

PB Provider Bridge

PBB Provider Backbone Bridge

PBB-TE Provider Backbone Bridge- Traffic Engineering

PBT Provider Backbone Transport

PC Personal Computer

PCEP Policy and Charging Enforcement Point

PCRF Policy Control and Charging Function

P-CSCF Proxy CSCF

PDA Personal Digital Assistant

PDCP Packet Data Convergence Protocol

PDF Policy Decision Function

PDH Plesiochronous Digital Hierarchy

PF Ponto de Função

P-GW Packet Gateway

PHP Penultimate Hop Pop

PHY Physical Layer Device

PIM Personal Information Manager

PIM-SM Protocol Independent Multicast – Sparse Mode

PMIP Proxy Mobile IP

PoA Point of Attachment

PON Passive Optical Network

POP3 Post Office Protocol 3

PoS Point of Service

PPPoE Point-to-Point Protocol over Ethernet

PRADO PRocess Analysis and activities DefinitiOn

PRB Physical Resource Blocks

PS Packet Switched

PSI Program Specific Information

PTC PT Comunicações

PTR Record Pointer record, a type of DNS record

PTZ pan-tilt-zoom

PWE Pseudo-Wire Emulation

PWE3 Pseudo-Wire Emulation Edge to Edge

QQAM Quadrature Amplitude Modulation

QoS Quality of Service

QPSK Quadrature Phase Shift Keying

RRA Resource Adapters

RAC Radio Admission Control

RAM Random-Access Memory

RAN Radio Access Network

RBL Real-time Blackhole List

RFID Radio Frequency Identification Device

RFS Resource Facing Services

RLC Radio Link Control

RMON Remote Network MONitoring

RNC Radio Network Controller

RPG Redes de Próxima Geração

RRC Radio Resource Control

RSS Really Simple Syndication

RSTP/MSTP Rapid / Multiple Spanning Tree Protocol

RSVP Resource ReSerVation Protocol

RTCP Real time Control Protocol

RTDAP Real Time Data Application Protocol

RTP Real-time Transfer Protocol

SSA Source Address

SAE System Architecture Evolution

SBTVD Sistema Brasileiro de Televisão Digital

SCE Service Creation Environment

siglas & acrónimos167

SC-FDMA Single Carrier – Frequency Division Multiple Access

SCIM Service Capability Interaction Manager

S-CSCF Serving CSCF

SDAC Southern African Development Community

SDF Service Delivery Framework

SDH Synchronous Digital Hierarchy

SDK Software Development Kit

SDP Service Delivery Platforms

SE Saída Externa

SFN Single Frequency Network

SGSN Serving GPRS Support Node

S-GW Serving Gateway

Shipnet® Service Handling on IP Networks

SI Sistemas de Informação

SID Shared Information and Data Model

SIP Session Initiation Protocol

SIP-AS Session Initiation Protocol - Application Server

SLA Service Level Agreement

SLEE Service Logic Execution Environment

SMPP Short Message Peer-to- Peer (protocol)

SMS Short Message Service

SMTP Simple Mail Transfer Protocol

SMTP Simple Message Transfer Protocol

SNMP Simple Network Management Protocol

SO Sistema Operativo

SOA Service Oriented Architecture

SONET Synchronous Optical Network

SP Service Providers

SS Subscriber Station

SS#7 Signaling System7/Sistema de Sinalização nº7

SVG Scalable Vector Graphics

SWIFT Secure Widespread Identities for Federated Telecommunications

TTCAP Transaction Capabilities Application Part

TCO Total Cost of OperationTCP Transmission Control Protocol

CP/IP Transmission Control Protocol/ Internet Protocol

TD Tipo de Dado

TDAB Terrestrial Digital Audio Broadcasting

TDI Total Degree of Influence (Nível Total de Influência)

TDM Time Division Multiplexing

T-DMB Terrestrial Digital MultimediaBroadcasting

TDT Televisão Digital Terrestre

TISPAN TIPHON (Telecommunications and Internet Protocol Harmonization over Networks) and SPAN (Services and Protocols for Advanced)Networks

T-MPLS Transport-MPLS

TR Tipo de Registro

TS Transport Stream

TTI Transmission Time Interval

UUBE Unsolicited Bulk Email

UC Universidade de Coimbra

UCE Unsolicited Commercial Email

UDP User Datagram Protocol

UE User Equipment

UHF Ultra High Frequency (300-3000 MHz; 1m-10cm)

UL-SCH Uplink Shared Channel

UMTS Universal Mobile Telecommunication System

UPCASE User Programmable Context-Aware Services

URL User Datagram Protocol

VVAF Valor do Fator de Ajuste

VAFA Valor do fator de ajuste da aplicação depois doprojeto de melhoria (After)

VAFB Valor do fator de ajuste da aplicação antes doprojeto de melhoria (Before)

VC1 SMPTE 421M Video Codec

VCC Voice Call Continuity

VHF Very High Frequency (30-300 MHz; 10-1m)

VLAN Virtual Local Area Network

VM Virtual Machine

VoIP Voice over Internet Protocol

VPLS Virtual Private LAN Service

VPN Virtual Private Network

WWCDMA Wideband Code Division Multiple Access

WDM Wavelength Division Multiplexing

Wi-Fi Wireless Fidelity (IEEE 802.11b wireless networking)

WiMAX Worldwide Interoperability for Microwave Access

WSDL Web Services Definition Language

XXAF eXtensible Application Framework

XCAP XML Configuration Access Protocol

XDM XML Document Management

XDMC XML Document Management Client

XDMS eXtensible Document Management Server

xDSL x Digital Subscriber Line

XML eXtensible Markup Language

XMPP eXtensible Message and Presence Protocol

XSD XML Schema Definition

XSLT eXtensible Stylesheet Language Transformations


Documents

Shipnet®, IMS,Application server, Service enablers ... · Gestão de identidades,Redes convergentes, Multicast, Redes de acesso ... as noções de ... tam o contacto entre pessoas