Desafios no desenvolvimento de aplicações aderentes ao protocolo Diameter: ambiguidades e indefinições

Transcrição

1 Desafios no desenvolvimento de aplicações aderentes ao protocolo Diameter: ambiguidades e indefinições Willian Eduardo de Moura Casante, André Temple de Antônio Diretoria de Soluções em Billing Fundação CPqD Centro de Pesquisa e Desenvolvimento em Telecomunicações Rod. SP-3 km 8,5 CEP Campinas SP Brasil wcasante@cpqd.com.br, andret@cpqd.com.br Abstract The diameter protocol has become the new industry standard for communication between the next generation network elements, in an IP environment. In addition to the compatibility with the functions as well as the current legislation, the development of a rating solution in real-time and in conformity with the protocol is crucial. This paper explores the main difficulties facing the conformity with the protocol while developing the application, due to uncertainties, indefiniteness, and imprecision of specifications. Resumo O protocolo Diameter é o novo padrão da indústria para a comunicação entre os diversos elementos das redes de nova geração, em um ambiente IP. Desenvolver uma solução de tarifação em tempo real aderente ao protocolo é uma necessidade, bem como manter a compatibilidade com as funcionalidades e legislação vigentes. Este artigo explora as principais dificuldades de aderência ao protocolo encontradas no desenvolvimento desta aplicação, decorrentes das ambiguidades, indefinições e imprecisões das especificações. Palavras-chave: convergência, Diameter, indefinições, dificuldades, tarifação I. INTRODUÇÃO O protocolo Diameter é um protocolo de autenticação, autorização e apropriação para redes de computadores, definido pela comunidade internacional responsável pela arquitetura e evolução da Internet o IETF (Internet Engineering Task Force), que permite a criação de aplicações e a extensão de suas funcionalidades. Esse protocolo suporta diversos protocolos de transporte, é compatível com segurança de rede e provê uma grande área de extensões em decorrência de seu modelo baseado em elementos de 32 bits para mensagens que são formadas por pares de atributos e valores, os chamados AVPs (Attribute-Value Pairs). A base do protocolo Diameter é definida pelo IETF através da RFC 3588 (Request for Comments) []. O IETF, através da RFC 6 [2], define a aplicação de controle de crédito para o protocolo Diameter. Ambos os documentos servem como uma das bases para a criação da especificação técnica do 3GPP (3rd Generation Partnership Project) [3], um grupo formado por empresas e operadoras de telefonia com o objetivo de estabelecer padrões para o mercado. Esse documento define uma série de extensões complementares à RFC 6 [2] visando atender às necessidades e anseios do grupo 3GPP por um cenário de telecomunicações baseado em IMS (IP Multimedia Subsystem) para aplicações de controle de crédito. Figura. Estrutura das especificações técnicas abordadas neste artigo Segundo [], o IMS é uma arquitetura global baseada em redes IP que possibilita o oferecimento de serviços multimídia aos usuários através da Internet. Com o crescimento da Internet e a facilidade de acesso através de diversos dispositivos, inclusive móveis (como celulares), fica evidente que é possível utilizar a estrutura de rede e protocolos para ofertar novos serviços de telecomunicações e melhorar a qualidade da experiência dos usuários, com grande possibilidade de agregação de valor aos serviços prestados [5]. Nesse cenário, é necessário realizar o controle de uso dos serviços de telecomunicações e a eventual cobrança em tempo real, promovendo a utilização consistente dos créditos e franquias, além da convergência dos serviços oferecidos, permitindo tanto a modalidade de pagamento pré-paga como a pós-paga. Para prover essas funcionalidades, a especificação técnica [3] define a interface de referência para controle de créditos on-line (Online Charging Reference Point Ro), responsável pela integração de uma aplicação de tarifação e controle de créditos (Online Charging System OCS) à arquitetura IMS. Segundo a [6], no Brasil, 8,62% dos assinantes de linhas móveis utilizam a modalidade pré-paga, o que evidencia a importância do OCS, especialmente no cenário de controle de créditos pré-pagos. Em um cenário IMS, mantendo-se os modelos de negócio já existentes, e considerando-se a adição de novos produtos e serviços de valor agregado, a existência de

2 um OCS correto e eficaz é obrigatória. Desse modo, para atender à arquitetura IMS (compatibilidade com as definições Diameter e com a interface Ro), o OCS deverá seguir estritamente os documentos de especificações técnicas, conforme mostra a Fig.. Além de inibir a integração com aplicações de outros fornecedores, dúvidas não esclarecidas, inconsistências e falhas de interpretação podem impactar negativamente a implantação da aplicação em um ambiente de uso real, ainda que os testes sistêmicos tenham sido bemsucedidos em ambiente controlado. II. O OCS E O CENÁRIO DE MÚLTIPLOS SERVIÇOS Uma aplicação de controle de créditos consiste basicamente em um Módulo de Controle de Saldos e um Módulo de Tarifação, cctados por um Módulo de Orquestração de Processos (Fig. 2). A aplicação pode atender a serviços que possuem inicialização, atualização e finalização (serviços que mantêm um estado, por exemplo, uma chamada telefônica ou um download) e a serviços sem estado (por exemplo, o envio de uma mensagem SMS). Desse modo, a aplicação deverá distinguir os diversos eventos de rede e armazenar o estado quando necessário, bem como prover mecanismos para recuperação em caso de falha, garantindo a cobrança do serviço e o processamento dos eventos já recebidos. Por conta das características intrínsecas de cada serviço provido, a aplicação deve permitir que as regras para criação de preços, tarifação e uso dos créditos sejam facilmente configuradas durante a operação. O tráfego de dados, por exemplo, apresenta características tarifárias muito distintas de uma chamada telefônica de longa distância nacional. O consumo de créditos, por sua vez, pode depender apenas da sua unidade de medida, caso não seja armazenado em forma de quantidade mtária, bem como pode ser específico para determinado serviço. Os créditos, além de compartilhados pelos diversos serviços, também poderão ser compartilhados entre diversos clientes. Essa característica de compartilhamento exige um controle preciso de reserva de cotas por serviço em andamento. Na autorização de um serviço, deve-se realizar uma projeção de uso com um valor, denominado quantidade requerida, que poderá vir da rede ou constar nas configurações internas da aplicação. A projeção é necessária para simular o uso durante determinado período e obter a quantidade e o valor já ajustados conforme as características tarifárias, que variam de acordo com a data e a hora de execução. Essa projeção também deve ser realizada para cada atualização de uso do serviço e requisição de nova reserva de créditos para posterior uso. Na finalização do serviço, realizam-se a tarifação da quantidade de uso real, registrada durante os eventos recebidos, e a efetivação do consumo do crédito para o valor de uso real calculado, liberando-se as cotas reservadas e não utilizadas, caso existam. O IMS prevê cenários de uso em que um serviço pode, por exemplo, ter início em um meio móvel e ser transferido para um terminal fixo, sem prejuízo do conteúdo trafegado e com a possibilidade de adição de novos serviços, como, por exemplo, a criação de salas de conferência. A rede deve garantir a continuidade da sessão entre os diversos elementos envolvidos e a tarifação deve tratar tudo de forma transparente, diferenciando corretamente os preços e, ainda, permitindo que os serviços prestados na sessão sejam agregados quando demonstrados na fatura. Figura 2. OCS e seus módulos Estabelece-se, desse modo, o conceito de sessão multimídia e, na hierarquia nível inferior da sessão, o conceito de serviço e o contexto de uso, em que, para uma mesma sessão, podem ser estabelecidos diversos serviços em diversos contextos, cada um com suas configurações de tarifação específicas. III. O PROTOCOLO DIAMETER E SEUS PONTOS DE EXTENSÃO O protocolo Diameter é formado por mensagens, sendo que cada mensagem contém um cabeçalho de 2 octetos, e cada cabeçalho possui um tamanho fixo, e um ou mais AVPs, formando a porção de tamanho variável da mensagem, cujo formato é definido pelo tipo de mensagem trafegada [7]. Para a interface Ro, o OCS pode receber e enviar diversos tipos de mensagem, como, por exemplo, CER (Capabilities Exchange Request) ou RAR (Re-Request). Para o escopo deste documento, serão abordadas apenas as mensagens de controle de crédito: CCR (Credit Control Request), responsável por descrever uma requisição, feita pelo cliente ao OCS, de um pedido de controle de crédito (Tab. I); CCA (Credit Control Answer), responsável por descrever o atendimento de uma requisição CCR pelo OCS e o respectivo resultado na aplicação, como a autorização de um serviço (Tab. II). Cada mensagem contém um conjunto obrigatório de AVPs, definidos nos documentos de especificações técnicas e um conjunto de AVPs específicos do serviço que está sendo prestado. No caso de uma requisição de um débito direto, o OCS poderá receber, como identificador da sessão multimídia, um CCR com um AVP de quantidade a abater, além dos AVPs obrigatórios. Já no caso de uma requisição de início de serviço, o OCS poderá receber um AVP de quantidade requerida, mas não poderá receber um AVP de quantidade previamente utilizada.

3 TABELA I. POSSÍVEL ESTRUTURA DE AVPS DE UM CCR Nível raiz Nível Nível 2 Valor Session-Id.; ;2 3 Origin-Host aaa:// :3867 Origin-Realm Destination- Realm Destination-Host aaa:// Vendor- Specific- :3868 Vendor-Id 5 Number Context- VOZDADOS Id User-Name cpqd Origin-State-Id 987 Event- /2/2 Timestamp 2:36:3 Subscription-Id Subscription-Id- Subscription-Id- sip: Data Services- Indicator Services-Credit- Control Identifier Requested- Unit IMS- Calling-Party- Called-Party- Id (agregador vazio) sip: sip: Existem centenas de AVPs definidos nas especificações técnicas. O conhecimento e entendimento de cada um deles para a construção do OCS é importante, porém depende diretamente da estabilidade da tecnologia, não somente pela quantidade de atributos existentes quanto pela característica extensível do protocolo podem surgir novos AVPs, seja em uma nova revisão de um documento de especificação técnica seja na oferta de funcionalidades específicas de um cliente ou servidor de determinado fornecedor. A referência [8] descreve um exemplo de aplicação da extensibilidade do protocolo, em que uma implementação de PoC (Push-to-Talk over Cellular) pode definir diversos AVPs específicos, complementares às mensagens para tal serviço. TABELA II. POSSÍVEL ESTRUTURA DE UM CCA Nível raiz Nível Nível 2 Valor Session-Id.; ;37 99 Number Origin-Host aaa:// :3868 Origin-Realm IMS- Calling-Party- Called-Party- sip: sip: Id Result-Code Services-Credit- Control Identifier Sendo assim, a criação de um mecanismo de configuração do OCS, independentemente dos atributos existentes nos documentos de especificações técnicas atuais, é uma forma de garantir a longevidade da aplicação sem a necessidade de novos desenvolvimentos, reduzindo o tempo de implantação e o custo de operação. Um mecanismo de mapeamento de AVPs para conceitos de tarifação internos ao OCS garante também que cada AVP seja corretamente mapeado na fase de implantação, ainda que ele não tenha sido totalmente compreendido na fase de desenvolvimento. Alguns AVPs, todavia, servem para o entendimento dos eventos recebidos pelo OCS e devem ser tratados sempre da mesma forma. Esses AVPs, como o Session-Id, definem como transcorre o serviço, fornecendo as informações usadas no mapeamento dos próprios AVPs para os conceitos internos da tarifação, em um possível metamodelo. Se um desses AVPs apresentar inconsistência de interpretação, todo o desenvolvimento do OCS ficará comprometido, forçando a tomada de decisão com base em premissas potencialmente incorretas. IV. AMBIGUIDADES E INDEFINIÇÕES Esta seção apresentará alguns exemplos de inconsistências encontradas entre os documentos de especificações técnicas (Fig. ) que podem dificultar o desenvolvimento de uma solução que seja independente de provedor, exigindo alto nível de configurabilidade, e, em algumas situações, forçar a criação

4 de definições que poderão impactar negativamente a implantação em determinados provedores, exigindo desenvolvimento específico para atender a esses pontos de integração. A. Replicação da informação trafegada De acordo com a Tab. I, um CCR pode conter um mesmo AVP, seja na raiz da mensagem seja subordinado a um AVP agregador, para o AVP, presente tanto na raiz quanto subordinado ao AVP Vendor-Specific-Application- Id. Isso pode ocorrer com outros tipos de mensagem, não apenas com o CCR. A replicação da informação trafegada em diversos pontos de uma mesma mensagem, além de gerar uma quantidade maior de bytes trafegados, pode criar inconsistências na mensagem, caso o valor atribuído a cada um dos AVPs replicados seja diferente, ainda que sua semântica seja igual. Como solução para esse problema, é possível adotar uma validação entre AVPs configurável no OCS ou simplesmente utilizar um AVP e ignorar os demais. A única forma, nesse caso, de evitar falhas na integração entre as diversas aplicações é criar conceitos internos ao OCS e mapeá-los na fase de implantação, conforme demonstrado na Seção 3. Com relação ao tamanho (em bytes) da mensagem, infelizmente não há nada a ser feito no nível da aplicação, por conta do modelo de mensagem adotado. Pode-se, todavia, evitar que isso aconteça, adotando-se estratégias de compactação em outras camadas de rede. A replicação da informação trafegada não apenas aumenta o tamanho da mensagem e sobrecarrega a rede, mas também causa ambiguidade da informação, o que pode levar à necessidade de criação de algoritmos de validação, aumentando a complexidade de desenvolvimento da aplicação, seu entendimento e sua implantação. B. AVPs distintos que carregam a mesma informação Podemos observar, pela Tab. I, que o AVP Subscription-Id- Data, subordinado ao AVP Subscription-Id, contém o número do telef do assinante que está inicializando uma sessão (no caso, uma chamada telefônica). A mesma informação pode ser encontrada no AVP Calling-Party-, sob o AVP IMS-, este subordinado ao AVP. Segundo [2], o AVP Subscription-Id-Data é utilizado para identificar o usuário final, que está requisitando o serviço. É utilizado em conjunto com o Subscription-Id- para descobrir o formato do ponto de acesso. Analisando a especificação técnica [3], o AVP Calling- Party- identifica qual usuário final está iniciando a transação. Seu formato, assim como no AVP Subscription-Id, pode variar conforme o serviço em questão. Para o OCS, não há como afirmar qual dos dois AVPs é prioritário e realmente identifica o assinante. Logo, novamente se faz necessária a adoção de uma solução flexível que permita desprender-se do AVP como identificador do assinante, para, então, no momento de implantação, definir o AVP que será considerado para tal tarefa. Para cada conjunto de AVPs que carregam a mesma informação, com nomes diferentes e regulamentados por órgãos técnicos distintos, será necessário realizar uma análise, semelhante à feita anteriormente, o que dificulta o trabalho no desenvolvimento e implantação da aplicação. C. Insuficiência de informação O documento de especificação técnica que serve de base para o Diameter [] define que todo AVP, quando disponível, deverá ser reaproveitado, a fim de evitar que novos AVPs sejam criados, desnecessariamente, por aplicação. Esse documento também permite a criação de AVPs quando necessário. Conforme observado na Seção 3, os AVPs podem agrupar outros, em uma tentativa de organizar o conteúdo de determinada mensagem e permitir, inclusive, que um mesmo AVP seja utilizado dentro ou fora de um agrupamento, em uma mesma mensagem. O documento [3] também especifica um AVP de agrupamento IMS-, responsável pela transmissão de elementos adicionais para serviços IMS específicos. Na Tab. I, podemos ver que o IMS- fica abaixo do agrupamento, que acontece apenas uma vez na mensagem CCR. O AVP Services-Credit-Control, por sua vez, pode conter diversos serviços agregados em uma mesma mensagem, partindo da raiz do CCR, assim como acontece com o AVP, porém, ocorrendo zero ou mais vezes em um mesmo CCR [2]. Em um cenário multisserviços, não é possível ligar as informações contidas nos AVPs IMS- e Services-Credit-Control enquanto o Services- Credit-Control pode ocorrer zero ou mais vezes em um mesmo CCR, o ocorre apenas uma vez. Um cenário de uso como o descrito exige que diretivas de desenvolvimento do OCS sejam tomadas, a fim de resolver as inconsistências e definir como a mensagem CCR deverá ser construída, aumentando as chances de incompatibilidades descobertas apenas no momento da implantação. V. CONCLUSÃO A crescente necessidade de um protocolo robusto e extensível, que proporci um ambiente amigável para o desenvolvimento de aplicações, como o OCS, satisfazendo aos anseios dos grupos de desenvolvimento de aplicações para redes de nova geração, com suporte à migração do legado, levou ao desenvolvimento do protocolo Diameter como alternativa aos protocolos já estabelecidos. A adoção do protocolo Diameter possibilita oferecer ao usuário dos serviços de telecomunicações uma nova gama de funcionalidades, promovendo um nível de convergência ainda não visto. Para tanto, os provedores de soluções de software para telecomunicações deverão, nos próximos anos, desenvolver aplicações para essa plataforma. Todavia, é necessário um cuidado na interpretação das especificações, evitando definir, em código-fonte, regras de negócio que

5 poderão levar a inconsistências na integração entre as diversas aplicações da plataforma. REFERÊNCIAS [] IETF RFC 3588 (23) RFC 3588 Diameter Base Protocol, 2 de dezembro de 2. [2] IETF RFC 6 (25) RFC 6 Diameter Credit-Control Application, 2 de dezembro de 2. [3] 3GPP TS (2) TS Diameter Charging Applications v.., 2 de dezembro de 2. [] Rondini, R. A. (28) IP Multimedia Subsystem (IMS), RogerioRondini_IMS.pdf. [5] Poikselkä, M.; Mayer, G. (29) The IMS IP Multimedia Concepts and Services, 3.ed. John Wiley & Sons. [6] Teleco (2) Estatísticas de celulares no Brasil, 5 de janeiro 22. [7] Camarillo, G.; García-Martín; M. A. (28) The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the cellular worlds, 3.ed. John Wiley & Sons. [8] Rebeiro-Hargrave, A.; Solé, D. V. (28) Multimedia Group Communication: Push-to-Talk over Cellular, Presence and List Management Concepts and Applications, John Wiley & Sons.