UM MODELO DE TARIFAÇÃO PARA SERVIÇOS COMPOSTOS NA …

UM MODELO DE TARIFAÇÃO PARA SERVIÇOS

COMPOSTOS NA ÁREA DE COMUNICAÇÕES

MÓVEIS

FREDERICO CHARLES SIMPLÍCIO FARIA

UM MODELO DE TARIFAÇÃO PARA SERVIÇOS

COMPOSTOS NA ÁREA DE COMUNICAÇÕES

MÓVEIS

Dissertação apresentada ao Programa dePós-Graduação em Ciência da Computaçãodo Instituto de Ciências Exatas da Univer-sidade Federal de Minas Gerais como req-uisito parcial para a obtenção do grau deMestre em Ciência da Computação.

Orientador: José Marcos Silva Nogueira

Belo Horizonte

Junho de 2010

FREDERICO CHARLES SIMPLÍCIO FARIA

A CHARGING MODEL FOR COMPOSITE

SERVICES IN MOBILE COMMUNICATIONS

Dissertation presented to the GraduateProgram in Computer Science of the Fed-eral University of Minas Gerais in partialfulfillment of the requirements for the de-gree of Master in Computer Science.

Advisor: José Marcos Silva Nogueira

Belo Horizonte

June 2010

c© 2010, Frederico Charles Simplício Faria.Todos os direitos reservados.

Simplício Faria, Frederico CharlesF224a A Charging Model for Composite Services in Mobile

Communications / Frederico Charles Simplício Faria.— Belo Horizonte, 2010

xlii, 108 f. : il. ; 29cm

Dissertação (mestrado) — Federal University ofMinas Gerais

Orientador: José Marcos Silva Nogueira

1. Telecomunications-Thesis. 2. MobileTelephony-Thesis. 3. Mobile CommunicationSystem-Thesis. 4. Charging-Thesis. 5. Broker - Thesis.6. 3GPP-Thesis. 7. OCS-Thesis. I. Título.

CDU 519.6*22(043)

I dedicate this work to my children and mother

ix

Acknowledgments

Firstly, I thank my parents for unconditional support. My mother has been very closerat all times of my life and she gave me comfort and energy needed to move throughthe hardest life lessons. My father gave me one of the great lessons in perseverance,assisting me in winnning my daily challenges.

To my children Ana Rafaela and Miguel. They understood and accepted byseveral occasions that Daddy had to devote to their studies the part of the time theyought to be reserved. To Sinara, who often had to demonstrate enough patience tosupport the moments of stress resulting from simultaneous activities related to study,work and trips.

To my sister Fernanda, who has always shown her love and affection and gave mea great incentive for completing this work.

To my dears aunts Sandra and Hilário, for having adopted me almost like a thirdchild and have contributed significantly to my professional and personal development.They were two big supporters. For you, I’m very grateful.

To Grandma Elza, who always remembered to send me some goodies when I cameback from those trips to the hometown.

To my advisor, José Marcos Nogueira, for having been willing to me guide evenaware of my limitations of time to devote to the research’s project , and for havingbeen providing valuable contribution at writing my technical papers.

Thanks to all, who, while not cited here, were present and gave their contributionto completing the work.

Finally, my special thanks to God.

xi

“There are men who fight one day and are good. There are others who fight for a yearand are better. There are some who fight many years and are very good. But there are

those who struggle all their lives: these are essential.”(Bertolt Brecht)

xiii

Resumo

Os avanços tecnológicos e a entrada de novos competidores têm transformado o mer-cado de comunicações móveis. Novos modelos de negócios fizeram surgir um mercadomais inovador para aplicações e serviços baseados em dados. Arranjos colaborativos en-tre diferentes atores provocaram uma nova dinâmica no mercado. Com a abertura dasredes dos provedores de serviços de comunicações através de APIs abertas, as aplicaçõesmóveis podem se beneficiar de recursos avançados de comunicações. Novos ambientesorientados a serviços estão sendo desenvolvidos com suporte para composição. A com-posição de serviços é uma técnica para criar serviços mais complexos e de maior valoragregado pela combinação de serviços autônomos, disponibilizados como componentespor provedores de serviços independentes. Esta técnica poderá prover um mais efetivovalor para provedores de serviços de comunicações se existirem sistemas de tarifaçãoavançados para explorar modelos de cobrança mais flexíveis e robustos para suportaros diferentes relacionamentos de negócios existentes entre os provedores de serviço. Nanossa pesquisa, propomos mecanismos baseados em contexto para tarifação de serviçoscompostos em comunicação móvel. Mais especificamente, nosso objetivo é propor umaextensão para o modelo de tarifação desenvolvido pelo 3rd Generation PartnershipProject (3GPP) para que ele suporte a disseminação de informações de contexto deum serviço composto entre os diferentes domínios administrativos. A solução propostaé baseada na incorporação de um broker para gerenciamento de contexto e na adap-tação das interfaces dos sistemas de tarifação. Nossos resultados mostram que, comestas modificações, os principais requisitos funcionais da tarifação de serviços compos-tos podem ser cumpridos.

Palavras-chave: Tarifação, Serviços, Composição, Broker, Preço, Contexto, Móveis,Modelo, 3GPP, OCS.

xv

Abstract

A couple of changes have come up through mobile communication business in the lastyears. Emergent business models like the application stores and the multi-sided ones,enabled by the open communications service models, have attracted large resources inthe mobile communication services industry. Service platforms enable the creation ofinnovative services by the packaging and orchestration of a number of service compo-nents delivered by different service providers.

Service composition is a technique to create complex and sophisticated servicesfrom existing autonomous and self-contained ones. To provide value for communicationservice providers, collaborative service arrangements should benefit from innovativecharging systems, which could support complex business policies and models estab-lished among service providers. However, traditional mobile charging models likely donot take into account that a service may be being used within a composite contextwhen designing rating policies, schemes, and discount models.

The objective of our research is to propose and evaluate charging mechanismsthat could be suitable for supporting the use of inter-domain service data in compositeservice environments within the mobile communications field. More specifically, ourwork suggests to extend the 3GPP Charging Model by adding a context broker entityand by enhancing the standard charging interfaces.

The results show that with the proposed extensions the main functional require-ments can be achieved.

Palavras-chave: Charging, Composite, Services, Context, Mobile, Applications,Communications, Model, 3GPP, Pricing, Billing .

xvii

Resumo Estendido

O mercado de comunicações móveis atravessou significativas mudanças nos últimosanos. Os recentes lançamentos de dispositivos móveis e os avanços tecnológicos emredes de banda larga sem fio têm provocado um avanço significativo na utilização deaplicações móveis. Há um aumento na procura por novos conteúdos, aplicações eserviços, o que tem feito que, no final de 2009, o volume de tráfego de dados tenhaultrapassado aquele gerado por serviços de voz.

Esta corrente de inovação tecnológica propiciou uma nova dinâmica no mercadode serviços móveis. Novos atores ingressaram na área de serviços móveis e fizeram comque uma série de novos modelos de negócios se desenvolvesse nesta indústria. O maisconhecido modelo de negócios foi o da loja de aplicativos móveis, lançado pela Apple.Dados do final do ano de 2009 apontam que havia sido realizado mais de 2 bilhões dedownloads na loja de aplicativos da Apple, que contava com mais que 85.000 aplicativosdisponíveis. Este modelo de negócios tem sido adotado por fabricantes de dispositivosmóveis, por agregadores de serviços, por fornecedores de sistemas operacionais móveise outros segmentos de mercado.

O aumento da concorrência no mercado de serviços móveis afetou os provedoresde serviços de comunicação ( PSC ), que já estavam a enfrentar o declínio das receitasde seus serviços tradicionais, tais como voz. Eles deixaram de exercer o controle sobrea cadeia de valor, e assim, seus clientes são capazes de obter conteúdo e aplicativosde fabricantes de celulares e outros provedores. Os PSC foram levados a procurar poralternativas viáveis para rentabilizar seus serviços, pois caso contrário, iriam se tornarmeros provedores de rede, ou seja, serviços de transporte de dados. Alguns deles,criaram sua própria loja de aplicativos, com o objetivo de competir com os fabricantesde dispositivos e provedores de serviços. No entanto, as lojas de aplicativos das CSPainda não se estabeleceram como modelos dominantes e não se sabe ainda se este seriaum modelo interessante para elas.

O movimento mais significativo que se operou nos provedores de serviços de co-municação foi a adoção de um modelo de negócios aberto, em oposição àquele tradi-

xix

cionalmente fechado, utilizado por vários anos. Neste novo modelo, provedores decomunicação abriram suas redes e disponibilizaram o acesso a seus serviços - men-sagem, localização, presença, billing, etc - para terceiros. Uma das vantagens destaestratégia foi explorar uma nova fonte de receita, pela abertura da cadeia de valor aoutros segmentos verticais de serviços, que podem incorporar funcionalidades de co-municação em suas aplicações para produzir novos produtos. Um notável exemplo doemprego dessa estratégia é a do serviço de short message (SMS), que se tornou parteelementar de algumas aplicações da mídia na TV e no rádio.

Estes arranjos colaborativos e emergentes em serviços móveis têm sido possíveisdevido a técnicas de composição de serviços. A composição de serviços é uma técnicaque torna possível a reutilização de serviços de outros fornecedores na forma de compo-nentes, com o objetivo de construir rapidamente ofertas mais atraentes de produtos aum mais baixo custo. Os benefícios que este método traz para uma organização podemser vários:

1. Rápido lançamento de novos produtos projetados através da reutilização de com-ponentes

2. Redução de Custos através da reutilização de infra-estrutura que já existe e estádisponível através de outros fornecedores

3. Uma nova fonte de receita através da comercialização de componentes para outrasempresas.

4. Um relacionamento estreito com os clientes mesmo que utilizando-se de compo-nentes de terceiros.

Como um exemplo típico de composição de serviços, podemos imaginar um agre-gador de serviços, que agrega várias ofertas para um viajante ou turista, dentro deuma aplicação móvel. O agregador de serviços depende do fornecimento de serviçosde terceiros para realizar sua oferta. A aplicação pode agrupar serviços de localização,reserva de hotéis, aluguel de carros e venda de tickets . No modelo de composiçãode serviços, baseado na perspectiva do usuário, existe uma entidade responsável pelaprestação do serviço composto. O usuário geralmente não fica ciente que o serviço podeser prestado por múltiplos PSC. O usuário recebe, por exemplo, uma fatura única parao serviço composto. O agregador de serviços tem de pagar o serviço para os fornece-dores que participam da cadeia. Ele fornece mecanismos para informar ao usuário opreço do serviço prestado com base na informação que ele recebe dos provedores. Estaé um visão genérica, mas pode haver variações.

xx

A tarifação de serviços compostos é uma área de investigação ativa em serviçosmóveis. Normalmente, a arquitetura dos sistemas de cobrança são desenvolvidas deacordo com o modelo criado pelo 3GPP. A arquitetura de tarifação do 3GPP nãoaborda completamente os problemas da cobrança de serviços compostos. Daí sistemasmais avançados de tarifação são fundamentais para suportar os modelos de negóciosemergentes e suas cadeias de composição.

Há um conjunto de requisitos que se pretende atingir quando se trata da tari-fação de serviços compostos: beneficiar-se dos acordos comerciais estabelecidos entreos prestadores de serviços permitindo a definição de regras complexas de tarifação,garantir a tarifação em tempo real de serviços compostos, assegurar a consistência dastransações entre os diferentes provedores, e ser, na medida do possível compatível comos modelos de tarifação estabelecidos pelo 3GPP.

O objetivo principal do trabalho de pesquisa aqui apresentado é projetar mecan-ismos de tarifação que permitam explorar a informação contextual relativa a cadeia dosprovedores e seus serviços durante a definição das regras de tarifação. A pesquisa real-izada utiliza o modelo do 3GPP como base e adiciona os mecanismos necessários parasuportar a disseminação de contexto e sua transferência, com o propósito de realizar ocontrole das funções de tarifação.

Esta abordagem de pesquisa é inovadora na área de tarifação de serviços com-postos. A literatura está principalmente restrita a modelos para a realização de trocade informações de faturamento, e para a correlação e agregação de registros individu-ais de tarifação produzidos pelos prestadores de serviços, com o objetivo de obter umvalor final para o serviço. A literatura existente é normalmente dividida em duas abor-dagens. Na primeira, as operações de tarifação são realizadas através de um serviçocentralizado. O sistema de tarifação não tem qualquer conhecimento dos fornecedoresindividuais de serviços. Este tipo de projeto gerencia separadamente a utilização dosserviços dos modelos de cobranças, ou seja, o agregador de serviços utiliza de umasessão de tarifação única que é utilizada por diferentes sessões de serviço. As infor-mações completas de tarifação são produzidas pelo serviço centralizado.

O segundo e mais comum modelo de pesquisa baseia-se num identificador detransação ( transaction-id ), que é gerado quando a primeira solicitação é recebida peloagregador de serviços compostos. Após isso, ele é transmitido a todos os serviços quecompõe o serviço composto. Daí, ele pode ser inserido nos registros de cobrança paraque eles possam ser correlacionados posteriormente. As regras de preço que levam emconta a informação sobre o contexto são aplicadas somente após a agregação dos reg-istros de tarifação. Existem algumas pequenas variações relacionadas à forma como oscomponentes que formam a arquitetura são organizados. Jennings e outros propuseram

xxi

uma variação baseada em um método de dois estágios. Em primeiro lugar, o serviçoé cobrado individualmente, e, em seguida, são aplicadas as regras de composição. Fi-nalmente, os registros de tarifação são agregados, fornecendo uma valor final para oserviço composto. A abordagem dos autores é diferente e para melhor compreênde-lautilizar-se-á de um exemplo.

Considere um agregador que crie uma aplicação movel destinada a viajantes, umAssistente de Viagens por exemplo. O Assistente de Viagens é um aplicativo compostodestinado a ser utilizado por viajantes em suas viagens de negócios. Ele proporciona aoportunidade de gerenciar completamente sua viagem através de um dispositivo móvel.O serviço combina aplicações para reservas de hotel e veículos, serviços para compra depassagens aéreas, e aplicações de comunicação, com recursos de mensagens, localização,e presença. Parceiros de negócios de diferentes domínios estão envolvidos na prestaçãodeste serviço de viagem para o Usuário via aplicação móvel.

Table 1. Composite Services Charges

Evento de Tarifação Quantidade(unidades/tempo/kb) Valor($)Consulta Localização 6 6*0.40 = 2.40

MMS 15 15*0.50 = 7.50SMS 10 10 * 0.40 = 4.00

Reserva Hotel 3 3*150.00 = 450.00Sumário Total = 463.90

Do ponto de vista típico do negócio, o usuário paga pelo provedor da aplicaçãopara obter todos os serviços de viagem e assistência relacionados. Para oferecer todosesses serviços, o Assistente de Viagem utiliza de componentes de serviços para reservade hotéis, para locação de veículos, para compra de bilhetes aéreos fornecidos por outrosempresas parceiras na cadeia de valor. O broker de serviços paga aos parceiros pelautilização de seus serviços. Portanto, a direção dos fluxos financeiros implica que osolicitante do serviço é obrigado a pagar ao seu prestador.

O agregador de serviços é a entidade responsável por acumular os registros indi-viduais de tarifação, correlacioná-los, e produzir o valor final para o serviço. Durantesuas atividades de planejamento de viagem, o Usuário realiza um conjunto de solici-tações na aplicação. Ele busca informações sobre hotéis disponíveis, realiza reservas,adquire bilhetes, acessa vídeos de curta duração e troca mensagens instantâneas. Umasérie de eventos de tarifação, derivado das ações do usuário será produzida.

Vamos supor que uma sessão de usuário gere o conjunto de tarifas individuaisdescritos na Tabela 1. O correspondente preço total do serviços l é de $ 463,90, queserá cobrado do usuário pelo provedor da aplicação. No que diz respeito às políticas

xxii

de preços para serviços compostos, apenas o agregador dos serviços pode definir regrasde tarifação avançadas que explorem o contexto da composição, uma vez que só eleconhece sobre os provedores envolvidos e seus serviços associados.

Imagine que, devido à alguma redução de custos de operação que o agregadorde serviços possa vir a ter ( por exemplo devido a cobrança unificada dos serviços )ele defina uma política de preços que permita um desconto final de 2%, se qualqueisdois parceiros específicos estão presentes como sub- fornecedores na sessão do usuário.Então, ele pode criar uma regra de tarifação da seguinte forma:

if Partner(CommunicationsServices) = “X” and Partner (Ticket Serviços) = “Y”,then:

FinalCharge = TotalCharge * 0,02;Essa política de aplicação de regras de tarifação, baseadas no contexto, somente é

possível porque o agregador conhece todos os parceiros envolvidos no serviço. Imagineagora, que o Provedor de Comunicação tenha acordos comerciais ativos com algunsdos outros provedores da cadeia de serviços. Um destes acordos tem uma política depreço que permite que o Hotel Broker realize campanhas comerciais via mensagens aosusuários móveis e em troca estes usuários podem acessar conteúdo ( vídeos , etcs )relacionados aos serviços da empresa a custo de transporte ( utilização da rede móvel) zero.

Observe que, embora desejável, este tipo de política de preços não pode ser im-plementada porque o provedor de Comunicações não tem nenhuma informação sobreos outros prestadores de serviços envolvidos na transação. Portanto, não será possívelassegurar um custo zero para o serviço, quando o usuário acessar conteúdos do HotelBroker. Concluindo, em modelos de politicas de preços para serviços compostos, osprestadores de serviços participantes nos serviços de compostos não tem nenhuma au-tonomia para definir as regras tarifárias baseadas em composição, devido à falta dasinformações disponíveis sobre o contexto da composição.

Mas se esse tipo de informação está disponível como entrada para sistema detarifação, então regras de classificação como as seguintes podem ser definidas:

if PartnerList.findProvider (“Broker Hotel”) = “YES” and Applica-tionType = “vídeo”, then :

charge = 0;Então o objetivo da pesquisa é prover os mecanismos necessários a gerência de

contexto da composição com a finalidade de permitir sua utilização dentro dos sistemasde tarifação.

Na solução proposta, os autores levam em conta a arquitetura de cobrançadefinida pelo 3rd Generation Partnership Project (3GPP), que é descrita principal-

xxiii

mente nas especificações técnicas TS 32.240 e TS 23.203 .A solução proposta é composta por dois componentes:

1. Um Broker de Contexto

2. Uma interface de tarifação estendida

O broker de Contexto é uma entidade funcional, cuja principal função é gerir ainformação inter-domínio que pode ser usada para fins de tarifação. Basicamente, asfunções que o broker de contexto exerce são:

1. Recebe notificações de atualização do contexto

2. Gerencia solicitações de subscrição para as atualizações contexto

3. Realiza a troca de dados de contexto com outros domínios administrativos

4. Gerencia repositório de dados

O broker de contexto pode ser organizado em uma modalidade federada, re-fletindo o regime de organização dos prestadores de serviços em uma composição. Elenão interage diretamente com a sistemas de tarifação, mas ele fornece as informaçõesnecessárias para as entidades de tarifação utilizá-las.

O contexto broker implementa o modelo Observer e segue o paradigma de sub-screver / publicar. Ele tem duas interfaces: do assinante, que responde a solicitaçõesrecebidas de terceiros, interessados em obter dados contextuais, e de publicação, querecebe as notificações de mudanças de contexto de entidades de serviços.

A interface é baseada no protocolo Diameter e os autores definiram uma novaaplicação Diameter que implementa o modelo publish / subscribe . A opção peloprotocolo Diameter foi pelo seu papel central na arquitetura de tarifação proposta pelo3GPP e pelo conjunto de mecanismos de extensão disponíveis no protocolo.

Os autores definiram algumas extensões para as interfaces de tarifação, cuja in-tenção é criar a capacidade para transmitir dados contextuais inter-domínio para ossistemas de tarifação. As interfaces de tarifação do 3GPP são baseadas no protocoloDiameter e são descritas em 3GPP TS 32.299 . Os autores estenderam as interfacespadrões, incorporando um conjunto de Atributo-Valor Pair (AVPs). Os AVPs sãoincorporados como atributos não mandatórios, por isso, é possível a reutilização deaplicações 3GPP existentes.

Este conjunto de AVPs funciona como um como um envelope Diameter, contendoinformações sobre provedores e serviços envolvidos e seus serviços.

xxiv

Nenhum novo comando Diameter foi necessário. O conjunto de AVPs é adicionadopara todos comandos Diâmeter relacionados a contabilização e de controle de crédito :ACR / ACA e CCR / CCA. Essa técnica garantiu a interoperabilidade com sistemasde tarifação compatíveis com 3GPP.

A fim de realizar a avaliação dos mecanismos propostos, os autores desenvolveramum protótipo. No protótipo, cada prestador de serviços dentro da cadeia foi implemen-tado através de uma aplicação de software. Tais aplicações têm uma API disponívelpara invocar o seu serviços. Por exemplo, um PSC exporta uma interface de aplicaçãosemelhante a:

getLocation (LocationRequest, locationResponse);sendSms (endereços, SenderName);

Os prestadores de serviço de outros domínios definem interfaces no seguinte for-mato:

bookingRoom (hotelName, roomClass, reservationDate);rentCar (carClass, reservationDate);

Uma série de serviços e suas regras de preços correspondentes foram configuradosdentro de cada provedor. Tabela 2 contém dois serviços configurados para o provedorde telecomunicações.

Table 2. Example of defined services and rating rules

Serviço Descrição RegraIM Id=001; Desc:

Serviço Men-sagem In-stantâneaCategoria:IM-A1

Tarifa = IM-1;Preço Padrão:0,3 USD

Localização Id=002; Desc:LocalizaçãoCategoria:LOC-A1

Tarifa =LOC-1; PreçoPadrão: 0,1USD

Em seguida, um conjunto de regras de preços para os serviços compostos foramconfigurados, proporcionando descontos para os serviços, caso o parceiro de negóciosesteja envolvido no contexto de transação. Tabela 3 traz um exemplo como as regrasde composição são configuradas.

Foi utilizado um Toolkit que contém uma implementação do Diameter base ( RFC3588 ) e também do Diameter CC ( Controle de Crédito ) . Uma aplicação Diameterde Contexto foi desenvolvida para troca de informações de contexto entre os domínios

xxv

Table 3. Examplo de Regras de Serviços Compostos

Regra Serviço/Conteúdo Regras Tari-fação

Provedor Comunicações IM 10% dis-contoparaparceiros

Hotel Broker Hotel Classe C 5% discontopara parceiros

administrativos. O envelope Diameter que contém AVPs transportando a informaçãosobre o contexto foi definido. Para o protótipo, os autores criaram duas instâncias doBroker de Contexto ( uma dentro do Provedor de Serviços de Comunicação e outrono Agregador de Serviços ) . Foi projetado um fluxo de utilização do serviço quecontém a invocação de diversas funções nos provedores. Um conjunto de cenários detarifação básica (Event based, baseados na sessão, o conselho de cobrança, etc) foramexecutados. Os resultados foram avaliados e estão descritos em detalhes ao longo dotexto.

As comunicações móveis estão evoluindo rapidamente. Neste trabalho de pesquisaa proposta de os autores é criar esquemas avançados de tarifação de serviços aplicadospara a cadeia de serviços compostos. No trabalho, os autores propõem um mecanismode disseminação de contexto entre domínios administrativos de serviço, com a finalidadede aplicá-lo na definição de regras avançadas de tarifação.

Os resultados preliminares mostram que os mecanismos de extensibilidadedisponíveis no protocolo Diameter são de grande utilidade ao desenvolver extensõespara as aplicações de tarifação. Através de suas extensões, os autores projetaram umaaplicação no modelo subscriber/publish e definiram um envelope para fornecer dadosde contexto como uma entrada para controle de faturamento. Através dos resultadospreliminares, os autores observaram que a tarifação de serviços compostos é fundamen-talmente dependente de um controle transacional robusto , que seja capaz de controlaras dependências entre os prestadores de serviços e manusear corretamente esquemasnecessários para refundar as partes em situações de falhas em transações dentro dosprovedores individuais.

Observou-se que alguns modos de tarifação normal (como caso de débito direto )criam uma complexidade adicional para o controle de transações, uma vez que é difícildesenvolver rotinas de compensação para situações onde a transação é comitada emfase única.

Como melhorias e sugestões de trabalhos futuros os autores sugerem:

xxvi

1. O emprego de ontologias para representar dados de contexto . Ontologiasfornecem um vocabulário de termos e estabelece as relações entre eles.

2. Realizar experimentações em um Testbed. Testbeds permitiem uma rigoroso , etransparente ambiente para avaliação de sistemas computacionais.

3. Avaliar o desempenho das extensões propostas. Performance é um atributo funda-mental para sistemas de tarifação e as alterações propostas podem eventualmenteintroduzir alguma penalidade para o desempenho do processo de tarifação. Osautores pretendem avaliar com mais rigor este aspecto.

xxvii

List of Figures

1.1 A typical example of a composite service application. . . . . . . . . . . . . 2

2.1 A service composition graph. . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1 The Charging Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 3GPP Charging Related Specifications . . . . . . . . . . . . . . . . . . . . 263.3 Entity and Technologies relationship by 3GPP. . . . . . . . . . . . . . . . . 273.4 3GPP Charging Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 3GPP off-line charging architecture. . . . . . . . . . . . . . . . . . . . . . . 303.6 3GPP on-line charging architecture. . . . . . . . . . . . . . . . . . . . . . . 303.7 The PCC architecture in EPC. . . . . . . . . . . . . . . . . . . . . . . . . 353.8 An EPC Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Service Broker in a Composite Business Scenario. . . . . . . . . . . . . . . 434.2 Service Composition Flow - No Context. . . . . . . . . . . . . . . . . . . . 444.3 Charging Flow in Brokered Service Composition. . . . . . . . . . . . . . . 484.4 Federated Brokered Service Composition. . . . . . . . . . . . . . . . . . . . 494.5 Service Composition Flow - (with context information). . . . . . . . . . . . 50

5.1 Composite Services Reference Scenario. . . . . . . . . . . . . . . . . . . . . 525.2 Federated ID-CMF model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.3 ID-CMF entity in EPC-PCC. . . . . . . . . . . . . . . . . . . . . . . . . . 665.4 Example of Diameter Context Application. . . . . . . . . . . . . . . . . . . 76

6.1 Roles represented in validation scenario. . . . . . . . . . . . . . . . . . . . 806.2 General service usage flow within validation scenario. . . . . . . . . . . . . 826.3 Implementation Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 866.4 Validation Scenario IEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 876.5 Validation Scenario IEC with adjust. . . . . . . . . . . . . . . . . . . . . . 886.6 Validation Scenario IEC with reservation. . . . . . . . . . . . . . . . . . . 89

xxix

6.7 Price Lookup Validation Scenario . . . . . . . . . . . . . . . . . . . . . . . 906.8 Validation Scenario for Refund. . . . . . . . . . . . . . . . . . . . . . . . . 916.9 Validation Scenario for Session with Unit Reservation. . . . . . . . . . . . 93

xxx

List of Tables

1 Composite Services Charges . . . . . . . . . . . . . . . . . . . . . . . . . . xxii2 Example of defined services and rating rules . . . . . . . . . . . . . . . . . xxv3 Examplo de Regras de Serviços Compostos . . . . . . . . . . . . . . . . . . xxvi

4.1 Service Providers Rating Rules. . . . . . . . . . . . . . . . . . . . . . . . . 444.2 Service Provider E1 Rating Rules. . . . . . . . . . . . . . . . . . . . . . . . 464.3 Solution Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.1 Charging Commands under If and Io. . . . . . . . . . . . . . . . . . . . . . 585.2 AVP Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.3 Diameter Context Application Commands. . . . . . . . . . . . . . . . . . . 675.4 Diameter Context Application AVP Codes. . . . . . . . . . . . . . . . . . . 73

6.1 Service Configuration Example. . . . . . . . . . . . . . . . . . . . . . . . . 816.2 Entity Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 836.3 Content Provider - Content List. . . . . . . . . . . . . . . . . . . . . . . . 846.4 Facility Provider - Services. . . . . . . . . . . . . . . . . . . . . . . . . . . 856.5 Communication Provider - Enabler Services. . . . . . . . . . . . . . . . . . 85

xxxi

List of SymbolsBc Reference point for the CDR file transfer from the Circuit Switched CGF to the BD.Bi Reference point for the CDR file transfer from the IMS CGF to the BD.Bl Reference point for the CDR file transfer from the GMLC CGF to the BD.Bm Reference point for the CDR file transfer from the MMS CGF to the BD.Bo Reference point for the CDR file transfer from the OCF CGF to the BD.Bp Reference point for the CDR file transfer from the Packet Switched CGF to the BD.Bs Reference point for the CDR file transfer for CAMEL services to the BD, i.e. from

the SCF CGF to the BD.Bt Reference point for the CDR file transfer from the PoC CGF to the BD.Bw Reference point for the CDR file transfer from the WLAN CGF to the BD.Bx Reference point for CDR file transfer between any (generic) 3G domain, subsystem

or service CGF and a BD.CAP Reference point for CAMEL between a network element with integrated SSF and

the OCS.Ga Reference point for CDR transfer between a CDF and the CGF.Gb Interface between an SGSN and a BSC.Gc Interface between an GGSN and an HLR.Gd Interface between an SMS-GMSC and an SGSN, and between a SMS-IWMSC and

an SGSN.Gf Interface between an SGSN and an EIR.Gi Interface between the Packet-Switched domain and an external packet data network.Gn Interface between two GSNs within the same PLMN.Gp Interface between two GSNs in different PLMNs.Gr Interface between an SGSN and an HLR.Gs Interface between an SGSN and an MSC/VLR.Gx Reference point between a PCRF and a PCEF.Gy Online charging reference point between a PCEF and an OCS.Gz Offline charging reference point between a PCEF and a CGF.Iu Interface between the RNS and the core network.

kbit/s Kilobits per second. 1 kbit/s = 210 bits per second.Lr Interface between Gateway MLCs.

Mbit/s Megabits per second. 1 Mbit/s = 220 bits per second.Mc Interface between the MGW and (G)MSC server.Rf Offline charging reference point between a 3G network element and the CDF.Ro Online charging reference point between a 3G network element and the OCS.

xxxiii

Rx Reference point between the PCRF and an AF.Um Interface between the Mobile Station (MS) and the GSM fixed network part.Uu Interface between the User Equipment (UE) and the UMTS fixed network part.Wf Offline charging reference point between a 3GPP WLAN CTF and the CDF.Wo Online charging reference point between a 3GPP WLAN CTF and the OCS.

xxxiv

Abbreviations

For the purposes of the present document, the following abbreviations apply:

3G 3rd Generation3GPP 3rd Generation Partnership ProjectAF Application FunctionAMF Account Balance Management FunctionAoC Advice of ChargeAPN Access Point NameAS Application ServerAVP Attribute Value pair

BBERF Bearer Binding and Event Reporting FunctionBBF Bearer Binding FunctionBD Billing DomainBS Bearer ServicesCAP Reference point for CAMEL between a network element with integrated SSF and

the OCS.CAMEL Customized Applications for Mobile network Enhanced LogicCAP CAMEL Application PartCDF Charging Data FunctionCDR Charging Data RecordCG Charging GatewayCGF Charging Gateway Function

CORBA Common Object Request Broker ArchitectureCS Circuit Switched

CSCF Call Session Control Function (I-Interrogating; P-Proxy; and S-Serving)CSP Communications Service ProviderCTF Charging Trigger FunctionEBCF Event Based Charging FunctionECUR Event Charging with Unit ReservationCTF Charging Trigger FunctionDRA Diameter Routing AgentEBCF Event Based Charging FunctionECUR Event Charging with Unit Reservation

xxxv

EPS Evolved Packet SystemE-UTRAN Evolved Universal Terrestrial Radio Access Network GGSN

Gateway GPRS Support NodeGPRS General Packet Radio ServiceGSM Global System for Mobile communicationGSN GPRS Support Node (either SGSN or GGSN)HLR Home Location Register

HPLMN Home PLMNHTPP Hypertext Transfer ProtocolIEC Immediate Event ChargingIETF Internet Engineering Task ForceIMEI International Mobile Equipment IdentityIMS GWF IMS GateWay FunctionIMS IP Multimedia SubsystemIMSI International Mobile Subscriber IdentityIP Internet ProtocolISC IMS Service ControlJCP Java Community ProcessITU-T International Telecommunication Union - Telecommunications standardization sec-

torLAN Local Area NetworkLCS Location ServicesMAP Mobile Application PartME Mobile Equipment

MGW Media GateWayMLC Mobile Location CenterMMS Multimedia Messaging ServiceMMSE Multimedia Messaging Service EnvironmentMRF Media Resource FunctionMRFC MRF ControllerMS Mobile StationMSC Mobile Services Switching Centre

MSISDN Mobile Station ISDN numberMT Mobile TerminatedMTC MT CallNE Network Element

xxxvi

OCF Online Charging FunctionOCS Online Charging SystemOMA Open Mobile AlliancePCEF Policy and Charging Enforcement FunctionPCRF Policy and Charging Rules FunctionPDN Packet Data NetworkPDP Packet Data Protocol, e.g. IPPLMN Public Land Mobile NetworkPoC Push-to-talk over CellularPS Packet-Switched

PSPDN Packet-Switched Public Data NetworkQoS Quality of ServiceRf Offline charging reference point between a 3G network element and the CDF.Ro Online charging reference point between a 3G network element and the OCS.Rx Reference point between the PCRF and an AF.RF Rating FunctionRMI Remote procedure InvocationSBCF Session Based Charging FunctionSCCP Signalling Connection Control PartSCF Service Control FunctionSCUR Session Charging with Unit ReservationSGSN Serving GPRS Support NodeSIP Session Initiation ProtocolSMS Short Message ServiceSOA Service Oriented ArchitectureSPICE Service Platform for Innovative Communication EnvironmentSSF Service Switching FunctionTR Technical ReportTS Technical SpecificationUE User Equipment

UMTS Universal Mobile Telecommunications SystemVAS Value Added ServiceVLR Visitor Location RegisterVMSC Visited MSCVPLMN Visited PLMN

Wf Offline charging reference point between a 3GPP WLAN CTF and the CDF.Wo Online charging reference point between a 3GPP WLAN CTF and the OCS.

WLAN Wireless LANxxxvii

Contents

Acknowledgments xi

Resumo xv

Abstract xvii

Resumo Estendido xix

List of Figures xxix

List of Tables xxxi

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 The Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Related Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.6 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Service Composition 112.1 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Service Composition Techniques . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 Service Exposure Techniques . . . . . . . . . . . . . . . . . . . . 152.2.2 Protocol Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 182.2.3 Mashup, Widgets Library and portlets . . . . . . . . . . . . . . 19

2.3 Service Orchestration Techniques . . . . . . . . . . . . . . . . . . . . . 202.3.1 Policies-Driven . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.3 AI techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

xxxix

2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Charging of Mobile Services 233.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2 3GPP Charging Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 3GPP Charging Principles . . . . . . . . . . . . . . . . . . . . . 263.2.2 3GPP Charging Architecture . . . . . . . . . . . . . . . . . . . 283.2.3 3GPP Charging Scenarios . . . . . . . . . . . . . . . . . . . . . 313.2.4 3GPP Charging Protocols . . . . . . . . . . . . . . . . . . . . . 32

3.3 3GPP Evolved Packet Core . . . . . . . . . . . . . . . . . . . . . . . . 343.3.1 Charging Functions in EPC . . . . . . . . . . . . . . . . . . . . 353.3.2 3GPP EPC - PCC Reference Points . . . . . . . . . . . . . . . . 363.3.3 3GPP PCC Charging Control . . . . . . . . . . . . . . . . . . . 37

3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Charging of Composite Services 434.1 Composite Service Charging Overview . . . . . . . . . . . . . . . . . . 444.2 Enhanced Composite Charging . . . . . . . . . . . . . . . . . . . . . . 454.3 Solution Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 A Model for Charging of Composite Services 515.1 Composite Services Reference Scenario . . . . . . . . . . . . . . . . . . 515.2 Model Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.3 Architecture and Components . . . . . . . . . . . . . . . . . . . . . . . 55

5.3.1 Charging Extensions . . . . . . . . . . . . . . . . . . . . . . . . 555.3.2 Service Plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6 Case Study 796.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.2 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.2.1 Implementation Overview . . . . . . . . . . . . . . . . . . . . . 826.2.2 Scenario 1: Immediate Event Charging (IEC) . . . . . . . . . . 856.2.3 Scenario 2: Event charging with unit reservation (ECUR) . . . . 866.2.4 Scenario 3: Advice of Charge . . . . . . . . . . . . . . . . . . . 886.2.5 Scenario 4:Refund . . . . . . . . . . . . . . . . . . . . . . . . . 896.2.6 Scenario 5: Session Charging with Unit Reservation (SCUR) . . 92

xl

6.3 Analysis of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 926.3.1 Conformance and Interoperability to 3GPP Charging Model . . 926.3.2 Requirements Fulfillment . . . . . . . . . . . . . . . . . . . . . . 94

6.4 Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . . 956.4.1 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . 956.4.2 Composition Model . . . . . . . . . . . . . . . . . . . . . . . . . 96

7 Conclusion 997.0.3 Future research . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Bibliography 103

xli

Chapter 1

Introduction

The mobile market has been subject of many changes over the last years. Recent tech-nological developments have led to the convergence of networks and services towardsIP-based packet networks. Political incentives towards universal access for mobile andbroadband resulted in an increased demand for new data-based applications and ser-vices. In December 2009, the global mobile data traffic surpassed voice for the firsttime. Data-based applications are driving part of innovation in the mobile communi-cations industry.

1.1 Motivation

That couple of changes previously cited have created a dynamic mobile services mar-ket. New actors have come up to the mobile services field; this has made emerge aset of new business models in the mobile industry. Recently, the mobile applicationstore phenomenon comes up through Apple, originating a new business model thathas been widely adopted. Communication service providers - e.g. Deutsche Telecom,British Telecom, Orange, etc - which did not traditionally allow access for their net-works, have exposed their communication capabilities such as presence, location, shortmessage, MMS, through open services interfaces [Blum et al., 2008a] [Blum et al.,2008b] [Francis, 2008] [Pascotto et al., 2008] [Hu et al., 2008]. Service providers, ag-gregators and developers take into account these newly available telecom enablers andlaunch more powerful and attractive products and applications. Device manufacturersentered in mobile applications field through their mobile application stores and devel-opment platforms innovative ways to expand the mobile service market. A couple ofthese business models have been identified and described in several publications [Nesse,2008]. The fact is that several of them have fundamentally depended on collaborative

1

2 Chapter 1. Introduction

arrangements among the involved actors. Service composition is essential in supportingthese emergent cooperative business scenarios [Cuevas et al., 2008].

Service composition is a technique that makes possible the reuse of services avail-able in form of components from other providers in order to build rapidly more at-tractive product offerings at a lower cost. It enables us to design more sophisticatedservices, which will actually be composed of a set of autonomous services offered byother providers in the form of components. The benefits that this method brings to anorganization can be several:

- Rapid launching of new products from best-of-breed components

- Savings generation through the reuse of infrastructure that already exists andis available via other providers

- A new source of revenue via the marketing of components to other value-addedservice providers.

- Closer relationship with the customer while relying on third-party providers

As a typical example of service composition, we could suggest a service brokerthat aggregates multiple offerings to a traveler or tourist inside a converged user inter-face. The service broker relies on third-party service providers that deploy elementaryservices that enrich the application. The package might bring location services, accom-modation, transport and ticket sales. This is illustrated in Figure 1.1: the user accessthe travel application through its mobile phone, the travel application relies on a set ofthird-party service providers delivering car rental, accomodation, transport and ticketservices.

Travel Application

User

Car Rental

Accommodation

Transport

Ticket

Figure 1.1. A typical example of a composite service application.

Service composition brings a couple of technical issues for service providers indifferent aspects. One of them is related to the charging of the composite services.

1.2. The Problem 3

Charging is a function related for collecting information about resource consump-tion, rate it based for example on provider policies, subscriber profile and service in-formation and so proceed to authorize and to bill the usage of resources. Charging is arelatively mature area when we consider elementary, traditional, mobile services suchas voice and contents. The mobile industry has already adopted the charging stan-dards published by 3GPP - The 3rd Generation Partnership Project. However, thecharging of composite services is an active research field, which has become relevant aslong as telecom operators have opened their networks and the collaborative businessarrangements in mobile market have emerged.

1.2 The Problem

In the service composition domain, from user’s perspective, there is an entity responsi-ble for providing the composite service. The user is not usually aware that the servicemay be being provided by multiples CSP. For example the user receives a single bill forthe composite service. The service broker needs to pay the service providers constitut-ing the chain by the supplied services. The service broker must provide mechanismsto inform the user the price of the provided service based on charge information thatit gets from the service providers. The elementary providers may be aware of servicecomposition and to design advanced rating policies. This is a general view but thereare variations.

Charging of composite services is an active research area. Usually, the chargingand billing solution used in mobile telecommunications follows the one described by3GPP. It doesn’t fully address the problems of composite charging. According toNiemöller and others, the charging infrastructure is therefore the technical enabler ofemergent business models and the standard charging solution needs to be reviewed inorder to identify needs for adaptation [Niemoeller, 2008].

Various business agreements can be established among the service providers todeploy a complex service chain. Support flexible rating rules, ensure charge transactionsin real time, guaranteeing transaction consistency and being interoperable with thestandard charging model are among the most challenging issues in designing compositeservices charging systems.

In order to better understand the problem we are going to outline in details someof the relevant issues that need be considered in a solid study of the subject.

• Overall Cost of Service (rating): When an elementary service is being pro-vided within the context of a composition, the service provider would wish to


charge for a different value than when the service is provided on an individualbasis. This could occur, for example, if the service provider, following its com-mercial agreements and alliances - is willing to afford some discount based onthe overall context information presents in the composition chain. In this sense,composite charging does not mean the sum of elementary, separated charges.

The technical issue should be how this kind of flexibility can be embedded intraditional charging models. Firstly, the involved charged systems need to gatherinformation regarding the service composition chain in order to apply such rules.We could suggest some design choices:

1. In the composite chain, each service provider could define two types of rules,one for the individual use of the service and the other for the composition. Inthis case, how the information about the overall context of the compositionis shaped and transmitted to the involved charging systems ?

2. Broker entity being responsible to apply final discount rules based in com-position context information. In the final rating stage, after receiving theindividual values for each rating engine, the broker could apply the discountsand penalties based on the context of the composition. In this case, the au-tonomy and privacy required to manage the price schemes is removed fromthe individual service providers.

In summary, the employment of flexible rating rules to composite services requiresto solve some tradeoffs.

• Transaction Control and Compensation : In a service composition domainsince that the provision of the service is divided among multiple providers, ro-bust enough charging mechanisms are needed to handle situations in which aservice component fails or can’t be deployed. In a standalone policy model theuser should not be charged by the service that failed. However in more com-plex composition scenarios, more diverse models of compensation, for example,based on the level of importance that an elementary service holds in the servicechain, should be supported. The fact is that this type of situation may requireadvanced pricing scenarios and mechanisms for intelligent control of distributedtransactions and their compensation mechanisms.

• Advice of Charge : The subscribers might be willing to be notified of servicecost as in traditional charging. But in composite rating, how could we designmechanisms by which the user is clearly noticed of discounts or additional fees

1.3. Related Research 5

incurred by service composition context once this data depend on current contextof the service being purchased.

• Efficiency : Managing context information could aggregate overhead for thecharging functions. Charging must be a highly efficient operation because itneeds to support in real time a large number of transactions. The question ishow could we add context management without affect charging performance?

• Topology not centralized : Composite charging is usually addressed in bro-ker/mediator scenario. When there is no broker or mediator entity, how thecomposite charge could be implemented ? How much fundamental would be thisscenario to service composition ?

Concluding, these are some general aspects that the charging of composite servicesneeds to address. Some of them will be briefly addressed here. It is still fundamental toimplement the charging for composite services while maintaining interoperability withthe charging framework proposed by 3GPP. It is desirable that a charging architecturecan be in conformance and be interoperable with implementations based on 3GPP forreusing the charging infrastructure that already exists. This includes online and off-linecharging support, event and session based charging and additional mechanisms suchas advice-of-charging. In addition, the charging for composite services should ensuresome basic principles and requirements such as transparency, autonomy of providers,traceability and confidentiality, which will be addressed ahead.

1.3 Related Research

Composite service charging is a recent area of research and to the best of our knowledgethere is not yet a common accepted model of charging of composite services. Most ofthe literature mainly focuses on the methods of composition of services based on webservices and ontologies. They do not address in details issues related to charging. Inthis section, we do a brief review of research in charging of composite services.

Two approaches are considered in SPICE project regarding composite servicecharging [SPICE, 2006]. In the first one, the charge operations are realized througha centralized service. The charging system is not aware of the individual services;all charging information is produced by centralized service. In the second one, anidentifier, named Spice Correlation Id ( SCid ), is generated when the first requestis received by the composite broker - assuming the centralized service model - andit is transmitted to all the elementary services that comprise the composite service.


Therefore the elementary services insert the SCid within its charging records so theycould be correlated lately. The work does not discuss in details neither if the brokeredservice could have access for rating rules from the elementary ones nor if contextbased rating rules could be implemented in the elementary services once that contextinformation is not propagated.

Huitema and others present a simple yet powerful framework focusing specificallyin service compensation[Huitema et al., 2007]. However the way they explore thesubject is only in business level. It is in modeling commercial agreements inside acomposite environment.

Ren and others proposed a way to make sure that the composite overall chargeis valid, e.g, correspond to the flow of services executed. Its focus is limited for fraudcontrol and the method is based in service templates invoked after each charging trans-action. [Ren et al., 2006]

Bhushan and others propose an accounting function for a federated B2B envi-ronment within the project FORM - Federated Organizations Management [Bhushanet al., 2002]. It is a model focused on static composition of services and it requires apre-agreement for the type of information exchanged by the providers. In its proposal,information on the usage of individual services is aggregated within the domain of sys-tem services. In this model, individual providers can’t use context information fromglobal composition to rate the service.

Agarwal and others propose the architecture MACS - metering and accountingof composite services - for composite e-services accounting [Agarwal et al., 2003]. Itranks, correlates and adds usage records reported by individual services. The pricingrules are applied only after the information is aggregated.

Taylor and others propose a model for pricing services in SOA where the infor-mation about the value of the individual services is reported by the primary serviceproviders and then aggregated - in the upper layer - to form the final price of thecomposite service [Taylor et al., 2005]. In their model, the main components related tocharging are a ticketing agent that reports the value of individual services and a trans-action manager, which controls the execution of services and aggregates their values.She explores a simple scheme to charge composite services: if a transaction completessuccessfully it may be billed; otherwise the partial results should be discarded andno bill is generated. A unique identifier is appended to the request/response com-munications, providing a means to track and tally the financial cost for the completetransaction. Then the transaction manager has the responsibility of tallying all thecharges received with the same query identifier. Although the proposal ensures theautonomy of providers to calculate the price of the service, it also does not allow

1.3. Related Research 7

propagate the overall inter-domain context information.Jennings and others have published some articles as result of the project devel-

oped in ADCS TSSG (Telecommunications Software and Systems Group). In the firstone, they report the challenges for dynamic composition of services and an assessmentprocess in two stages is proposed. Charging schemes contains two types of chargingrules: the first one, the elementary services rules and the second one, the compositeservices rules. Firstly, the service is charged as elementary, after are applied the com-posite rules. Finally the modified charges are summed, providing a final charge forthe composed service. In this scheme, charging topology must be transmitted to thecentered rating engine. Charging records carry information about the service in a tu-ple (providerID, serviceID, instanceID) and involves a correlation transaction Id. Thatscheme involves a protocol between the federated rating engines to collect elementarycharges and rate schemes [JENNINGS et al., 2005] [JENNINGS and Malone, 2006].Jennings and others also studied the problem of distributed transactions and proposeda tree-based structure to describe the relationships and dependencies among the trans-actions and after used it to coordinate the implementation and the failure scenarios[JENNINGS et al., 2007] [JENNINGS and Xu, 2007]. Finally, the group proposes an"Accounting Logic Generator"(ALG) for automating the generation of the logic of val-uation for the composite services, using as input the individual rules. It is based onDSL ( Domain specific language ) that is target for easy specification and modificationof service charging schemes. ALG component consolidates charging schemes for ser-vices in a composed service into charging schemes targeting particular rating engines.Such sort of mechanism is out of scope of our work [JENNINGS and Xu, 2008]. Ourresearch uses a transaction model as Jennings. However, the aspects related to contextpropagation are distincts.

The work of Jennings is relevant because it focuses on different aspects regardingcharging of composite services. But the authors do not mention interoperability aspectsto standard models like 3GPP. It is also not so much clear neither how the system couldconvey service information using standard charging protocols nor if it could rely on astandard protocol to perform the interaction among the rating engines. The solutionrelies on rating engines being upgraded to implement the two-phase rating process,which would make deployment more difficult.

There is also some related research proposing techniques to choose the better ar-rangement of services based on some kind of criteria. The works of Balke and Niemöllerare in this field. [Balke and Diederich, 2006] [Niemoeller, 2008]. But this perspectiveis out of our study scope.

Beijnum and others propose a charging system for composite services target to


IMS environment. Their design manages the charging separately from the services,e.g. the service broker creates a single charging session that is used for different servicesessions. [van Le et al., 2009]. This is the same approach used in other research efforts,e.g. it performs the aggregation of individual charges.

There are also standard efforts related for charging. Standard API interfacesrelated to charging such like Parlay Payment [ETSI, 2006a] and Parlay Account [ETSI,2006b] are not flexible enough and currently do not have any additional parameter toreceive context data. The 3GPP charging model does not address composite servicesas well.

In summary, the current research in charging of composite services presents somedrawbacks:

• Most of methods are based on the aggregation of individual charges by the servicebroker through a correlation identifier that is disseminated among the adminis-trative domains. This approach does not consider the possibility of propagateinter-domain context data. Therefore rating flexibility is limited.

• Most of solutions are not concerned with conformance and compliance to stan-dards.

• Although the authors do not address aspects related to performance through aformal model, most of literature does not provide any performance considerations.

1.4 Objectives

The primary objective of work is to design charging mechanisms based on 3GPP charg-ing to support the propagation of inter-domain contextual data during the charging ofcomposite services. The secondary objectives are:

1. Understanding how service composition is realized, creating a common vo-cabulary to express composite services concepts. Such objective involves to know theelementary concepts and figure out the techniques for service exposure and serviceorchestration.

2. Acquiring a good understanding of 3GPP charging model; explore chargingconcepts and principles as long as charging models, architectures and scenarios thatcomprises 3GPP Charging.

3. Address the details how the IETF standard protocol Diameter and its relatedapplications ( e.g. diameter credit control ) perform its role into the 3GPP charging

1.5. Contributions 9

interfaces. Figure out how the protocol can be extended to support context basecharging, which is the foundation for our proposal.

4. Understand IMS and SIP services in order to illustrate as the charging modelmay fulfill within this architecture and to design the application used on presented usecase.

1.5 Contributions

The research brings the following contributions:

1. A context based charging model in conformance with 3GPP to be used in com-posite services scenario

2. A short review in service composition.

3. A overview in 3GPP Charging including the PCC - Policy and Charging Control

4. A general approach for extending charging models based on Diameter.

1.6 Organization

The document is organized in the following parts :

• Service Composition : That chapter presents a general review about the com-position of services. Its objective is to introduce a terminology basic and topresent the common concepts and techniques related to service exposure andservice orchestration.

• Charging of Mobile Services : That chapter brings a short overview of charg-ing function within a communication service provider. Additionally, it describesthe standard charging models for mobile services specified by 3GPP.

• Charging for Composite Services : That chapter addresses in more detailsthe problem that we intend to solve. It describes how the solution addressescomposite service charging and defines its scope.

• A Model for Charging of Composite Services : In this chapter, the charg-ing mechanisms that the authors propose are described. The authors stated areference scenario, the basic principles and requirements, the architecture withits functional entities and data interfaces.


• Case Study : it presents the use case objectives and the application scenariothat is used during testing. The authors do a brief description of how the imple-mentation was performed. The results are analyzed.

• Conclusion : The research review is realized. The authors highlight the obtainedresults and identify further activities that might be developed to enrich the work.

Chapter 2

Service Composition

This chapter gives a general overview about service composition. It covers the termi-nology and important aspects related to service exposure and orchestration.

The objectives of this chapter are:

1. Provide common vocabulary and concepts related to service composition

2. Highlight service exposure and orchestration techniques focusing on their funda-mental role within service composition.

This chapter is organized as follow: Section 2.1 presents a more detailed con-ceptual description of service composition and its related concepts, Section 2.2 coversservice composition techniques, Section 2.3 addresses service orchestration techniques.Finally, the last section contains the conclusion.

2.1 Concepts

A composite service is to be assembled from other elementary services and/or othercomposite services. Therefore, the structure of service chain may be represented as agraph structure, where composite services are identified as "C" nodes, and elementaryservices as "E" nodes. In the Figure 2.1, the composite service C1 relies on servicesprovided by composite service C2 and elementary service E1.

A good definition for service composition through orchestration comes fromCuevas: "service orchestration takes as input a set of independent service capabilities,and generates as output an integrated service where, from the perspective of a user, thecombined service capabilities should interwork seamlessly, with all the functionality ofthe integrated service being accessible via a uniform interface" [Cuevas et al., 2008]

11

12 Chapter 2. Service Composition

C1

C2 E1

E2 E3

Figure 2.1. A service composition graph.

. A service capability will typically be an existing end-user service, although it mayalso be a service enabler (such as a location or messaging server) or may even be justa feature of a service (such as the call waiting, call block or another any feature of atelephony service).

Service composition can be described taking into account four different aspects:

1. Composition Time

This refers to the time that the composition is performed. It can be static ordynamic [Bucchiarone et al., 2006]:

Static : In this mode, the different providers of a service chain already have aprior knowledge - in design time - of the way their services are related; hence,in order to provide the service, they can prepare in advance the necessaryresources in terms of systems and networks.

Dynamic : In this mode, there is no necessarily any prior knowledge of possibleassociations that a service may participate. The associations among servicecomponents are built dynamically and can be based on policies. Since thereis no prior knowledge by the suppliers of the relationships to be established,dynamic composition is likely to be more complex than static [Bucchiaroneet al., 2006].

2. Service Arrangement

This refers to the way in which the services are arranged for the exchange of infor-mation, determining its topological classification [Hull et al., 2003] [SPICE, 2006].The possible arrangements are: Package, Peer-to-Peer, Mediator and Broker:

Package : The simplest form. This is an arrangement where various servicesare grouped within a package and are used independently and without per-forming any exchange of information among them. Such arrange is typically

2.1. Concepts 13

used to group related services within an attractive package; it supports twovariations: the implicit one, where the customer is unaware of providersbelonging to composition and the explicit one, where the customer knowsthe service providers.

Peer-to-Peer : This is the way in which services play an equal role in the processof collaboration. A particular service can exchange information with anyother in the composition. There is not the role of a central office to controland coordinate the services that are part of the composition. Usually eachservice has knowledge of its participation and role in the composition. Thisarrangement is commonly known as choreography in the service literature.

Mediator : A service will assume the role of mediator in the topology. Theexchange of information and control data on collaborative chain is alwaysdone via a service broker entity and a service does not directly interactwith any other within the composition. The services components have noknowledge that they are part of a composition. The orchestrator explicitlyset the order of operations.

Broker : a variation of the Mediator model. In this form of collaboration, allcontrol information is still performed via a centralized service, that is knownas broker. However, different from the Mediator one, the peers can makethe exchange of information between them.

Mediator and Broker arrangements are referred as orchestration models in theliterature because of the presence of a central service responsible for achieving thecoordination. The mediator and broker models can still be classified according tothe way user access the service. It can be either centralized, where the access tothe service is always centered, or complex, where the user can access any service[SPICE, 2006].

3. Composition Layer

This refers to the layer where the service composition is performed.

Client : The composition is performed in client layer. Normally, it is achievedby a converged services interface got by GUI integration through mashupsand widgets components. However, there are other possible ways of clientlayer composition, since that the composition logic resides in client.

Server/Network : The composition is performed in the server or network side.This configuration allows a greater control of composition chain because


event management, transaction control, and session management functionscould be better achieved if they are performed in the server/network layer.

Mixed: The composition is performed in both client and server (network) layers.

4. Orchestration method

This is related to what technique is used to govern the interaction among theservices, stating their execution order. This category is mainly employed to rankMediator and Broker models.

Protocol : is based on monitoring of signaling protocols. This technique re-quires to exist any decision logic support in the protocol. By being awareof protocols events is possible to design an event-based decision engine toselect among multiple services.

Policies : This is a more general mechanism that is independent of protocol. Itrequires any kind of event management and policy support. The decisionentity is notified of events so it uses their information to feed a policy enginethat will apply the configured policies and will take the appropriate decisionsconcerning the flow of services.

Workflow : Performs the implementation of a service-based Workflow. A work-flow is a sequence of operations. Workflow techniques rely in well definedservices interfaces, e.g., service results and exceptions are known a prior.

2.2 Service Composition Techniques

This section describes the methods typically used to service composition in the mo-bile communication services industry. The authors have noticed the dominance ofmodels based on Mediator topology because such sort of arrangement seems betterto accomplish Telecom requirements. Telecom services likely have stringent require-ments related to security, transaction control, failure tolerance, performance and highavailability, which would be better enforced by a mediator entity.

Our interest is in evaluating service composition strategies within two perspec-tives: service exposure and service orchestration. Service exposure is related to the waysin which the services are made publicly available to access by their service providers.Service orchestration refers to the techniques to state the order and priority of serviceinvocation within service execution chain.

2.2. Service Composition Techniques 15

2.2.1 Service Exposure Techniques

We observed in the literature the predominance of 3 main groups: based on APIs,protocols and Web 2.0.

2.2.1.1 Proprietary and Standard Open APIs

In such technique, services and capabilities are exposed through application program-ming interfaces. There is likely a broker entity acting as orchestrator that is theresponsible to service invocation. There are a number of different flavors supportingthis technique.

Proprietary APIs Service providers may design public proprietary APIs and exposethem to be invoked by interested third parties. This can be developed using pureprogramming languages such as Java, C++, Perl and some distributed program-ming support. In early stages, the telecom industry employed technologies basedon RPC paradigm such as CORBA, DCOM and Java-RMI to implement the in-terfaces to their services. Recently, the diffusion of Service-Oriented Architecture(SOA) paradigm and the tool support has made these implementations be basedon Web Services concept, which is still a programming paradigm well similar tothe old ones.

SOA is an architectural style based on services. In SOA, autonomous, loosely-coupled and coarse-grained services with well-defined interfaces provide businessfunctionality and can be discovered and accessed through a supportive infrastruc-ture. This allows internal and external system integration as well as flexible reuseof application logic through the composition of services. Web Services is just theimplementation of SOA service. Hull and others present a precise definition forWeb Services: "a collection of network-resident software services accessible viastandardized protocols, whose functionality can be automatically discovered andintegrated into applications or composed to form more complex services" [Hullet al., 2003]. SOA uses the find-bind-execute paradigm. In this paradigm, ser-vice providers register their services in a public registry. This registry is used byconsumers to find services that match certain criteria. If the registry has sucha service, it provides the consumer with a contract and an endpoint address forthat service. In Web Services method, service providers expose their applica-tions and capabilities by Web Services Description Language (WSDL) interfaces.WSDL provides a model and an XML format for describing Web services. Itallows one to separate the description of the abstract functionality offered by a


service from concrete details of a service description such as "how" and "where"that functionality is offered [W3C, 2004]

Each time more common is to evoke architectural principles in the construction ofhigher quality APIs. REST, acronym to Representational State Transfer, bringssome architectural principles, which do REST style APIs to be more compactand readable than other type of APIs [Fielding, 2000; Mäkeläinen and Alakoski,2008]. Fielding was who first proposed and described the REST principles in hisdoctoral dissertation. REST ignores the details of component implementationand protocol syntax in order to focus on the roles of components, the constraintsupon their interaction with other components, and their interpretation of signif-icant data elements. In REST, the resource is the concept of most fundamentalimportance. Data and functionality are resources and they are exposed troughWeb URI (Uniform Resource Identificators). All action is described in terms ofHTTP methods (Get, Post, Put and Delete ) and they act about the resourcesidentified by their URIs. APIs which follow REST principles are often referredto as "RESTful" APIs.

Standard Based APIs Proprietary APIs lacks some benefits that standardizationcould bring. Standardization reduces the complexity to manage many proprietaryand often specialized, proprietary APIs. Standards APIs are the communicationsAPIs introduced by Standard Development Organizations such as Parlay Group,ETSI, 3GPP, OMA and industry.

The Parlay Group is a multi-vendor consortium formed to develop open,technology-independent application programming interfaces (APIs) that enable thedevelopment of applications that operate across multiple, networking-platform envi-ronments. Initially, Parlay group described a network API that allowed developers tocreate telephony applications that accessed telecom capabilities. Late, Parlay X en-hanced this API designing the Parlay X API. Parlay X is a set of Web service APIs thatenable software developers to use the capabilities of an underlying network. Telecomcarriers are responsible to provide support for Parlay so they expose their capabilitiesto developers and providers through these standards interfaces. In 2008, the respectiveBoards of Directors of both Parlay and OMA, along with the joint working groups of3GPP and ETSI, have agreed to move the continuing work to OMA.

Some industry efforts also have produced APIs specifications that are largelyaccepted within a community as an industry standard. An example is the Java Com-munity Process (JCP) program. The JCP is the mechanism for developing standard


technical specifications for Java technology. Java standardization initiatives produceda couple of APIs, which typically bring for the Internet world the Telecommunicationprotocols, ensuring that services can be rapidly created and developed by a large Javadevelopment community.

The Java SIP Servlet API is one of them. Session Initiation Protocol (SIP) is anapplication-layer protocol created by IETF to manage media sessions with one or moreparticipants. It is the standard base protocol for 3GPP IP Multimedia Systems ( IMS) in mobile services. The Java SIP Servlet API specification defines an environment forexecution of network based SIP applications. It is implemented on application serversthat support SIP and optionally also HTTP and the J2EE platform. Java SIP Servletsupports baseline SIP [IETF, 1998] and some SIP extensions.

A Servlet application may contain both SIP and HTTP components and bothmay be deployed and have the state shared within a container. State maintenancein the SIP Servlet API is based on the session model of the HTTP Servlet API. SIPServlet API brings the SIP protocol functionality from communication side to IT world.Its audience is to web developers who are quite familiar with servlet model but knowlittle about communication protocols. Anyway, it is still necessary fundamental SIPskills to program with SIP servlet. We would recall Java SIP Servlet as a protocoloriented API. Java SIP Servlet 1.1 API is described in JSR 289 [Microsystems, 2008b].

Another Java API is the IMS Services API [Microsystems, 2008a]. It exposes IMSfunctionality through high-level APIs in an integrated and consistent way. Its targetis Java Micro Edition (Java ME). The IMS Services API allows application developersfor mobile devices to easily utilize the IMS functionality without requiring knowledgeof the underlying protocols and IMS implementation details. IMS Communicationenablers ( ICE ) is still an another ongoing JCP effort to provide the capabilities byexposing a set of the abstract high level IMS Communication Enablers within Java MEplatform [Microsystems, 2008c]. It will make use of the framework defined in JSR-281.

Java Jain (Java APIs for Integrated Network) is other effort within the JavaCommunity Process, developing APIs for the creation of telephony (voice and data)services. It consist of two areas: the container interfaces provide standard and unifiedways to cater for the lifecycle of a service, thus accelerating communications servicedeployment; the application interfaces provide different levels of abstraction and acces-sibility to cater to many types of developer community, thus proliferating the creationof new communications services [Microsystems, 2007].


2.2.2 Protocol Interfaces

In this technique, services are invoked via protocol interfaces. It is based on monitoringof signaling protocols and in the implementation of actions, which are likely guided byrules, to decide which service invoke. Such method is event based and data driven, andcommonly used in communications domain. Session Initiation Protocol (SIP) [IETF,1998] and Diameter [IETF, 2003] are key control protocols to implement the servicecomposition in mobile services field.

In IP Multimedia System (IMS) domain [3GPP, 2009b], 3GPP defines a mecha-nism for service invocation, which can be used to service composition within the SIPprotocol. This mechanism relies on user’s service profile evaluation performed by theentity S-CSCF (Serving-Call Session Control Function). The user profile can hold anumber of rules that matched over the SIP session contextual information will de-termine what will be the next application to trigger. This mechanism, named IMSService Control Interfaces Component (ISC), governs the interaction between the AS (Application Server ) and the CSCF. The CSCF forwards the service request to the cor-responding application server based on filter criteria that are referred as SPT (ServicePoint Triggers ). The IMS Application Server receives the request, processes it andmay route it to other AS. When the control returns to the CSCF entity, it applies thenew filter criteria for selecting the next AS to invoke. It is a priority-based applicationserver triggering mechanism.

The 3GPP body has still introduced the SCIM - Service Capability IntegrationManager specifically to support the integration among different service capabilities.But to our better knowledge, SCIM looks be a conceptual model and 3GPP did notbring further information about it . Recently, 3GPP developed a study that covers thearchitecture impacts of a new functional component in the IMS architecture. NamedService Broker, it adds additional capabilities to static service brokering functionsprovided by the initial Filter Criteria in the S-CSCF and enables the possibility ofdynamic service brokering functions in IMS. With the initial Filter Criteria (iFC), onlya static order of chaining these applications is possible [3GPP, 2008b].

There is related research to enhance the embedded protocol mechanism. Wangand others propose an extension to iFC where the service trigger is moved from S-CSCFto SCIM, removing the burden of S-CSCF [mei WANG et al., 2008]. In their proposal,SIP is enabled with a new header field to indicate the service capability that was lastlyinvocated. Dinsing and others have proposed a composition engine implemented overSIP Servlet Container. In their method, dynamic decisions are taken into the SIPcontainer in AS, and are based in SIP signaling, composition engine state and any


other information [Dinsing et al., 2007]. Yuan and others describe the integration bya SIP Servlet model [YUAN et al., 2007]. Developers create SIP Servlet functions insimilar ways they create HTTP Servlet functions.

Although API and protocol based composition methods share some similarities,they contain a number of differences. Protocol oriented compositions are suitableto communications systems, which are basically event-driven. They are likely basedon sessions rather than request-response invocations. During the session lifetime, anumber of request-response among the entities may succeed. Composition via APIis orchestrated and the interactions are performed between the orchestrator and theservices. But in protocol oriented composition the interactions may happen directlyamong the services and the orchestrator may not be aware. A more complete anddetailed comparison of composition based on SIP and Web Services, e.g. protocol vsAPI paradigms, can be found in the research by Bond and others [Bond et al., 2008].

2.2.3 Mashup, Widgets Library and portlets

These are a set of methods that can more recently be grouped as Web 2.0. Basically,they rely on aggregation and syndication of content into the user layer. A widget is anend-user’s conceptualization of an interactive single purpose application for displayingor updating data on the Web, packaged in a way to allow a single download andinstallation on a user’s machine or mobile device [W3C, 2008]. A widget may run asa standalone application (meaning it can run outside of a Web browser), or may beembedded into a Web document. Each widget has a URI that refers to its presentationlayer. The service aggregation that is performed in user layer is made by requestingthe widgets and displays them as independent modules inside a web page. Mashup is aweb page or application that combines data or functionality from two or more externalsources to create a new service. Mashups can be built by the aggregation of a coupleof Widgets.

Communications service providers may benefit from this paradigm by creatingwidgets performing functions from network capabilities such like a "Send SMS" widgetfor example. But such approach may be classified like a bit different than open APIsbecause widgets will likely invoke the device APIs to perform their services rather thaninvoke service gateway interfaces. There are some ongoing initiatives to standardizedservice access in user layer. Moving in this direction, the Open Mobile Terminal Plat-form (OMTP) launched its BONDI project with the aim of acting as a catalyst to drivethe standardization of a small set of key interfaces from web services to mobile devices.

BONDI objective is to address the fragmentation existing on packaging and de-


ployment models of web runtime/widgets systems. BONDI does define requirementsgoverning device capability access by JavaScript APIs to promote interoperability andsecurity of implementations. Separately, BONDI includes definitions of JavaScriptAPIs in a number of specific areas of particular relevance to mobile devices. It pro-vides a couple of module interfaces such as Messaging and Telephony.

Laga and others built and deployed a dashboard that blends web informationand telecom services at the presentation layer, on a single web page [Laga et al., 2008].Odini and others present the results of a study on the leverage of web 2.0 technology andopen business models to expand service provider’s platforms [Odini and mei WANG,2008]. Obrenovic studies the aggregation of several marshup styles in the compositionof heterogeneous services [Obrenovic and Gasevic, 2009].

2.3 Service Orchestration Techniques

In service composition scenarios, it is important determine the order that the differentservice components are invoked. This is what can be named orchestration model.We have identified the following orchestration techniques:policy-driven, workflow, AIbased.

2.3.1 Policies-Driven

Policy based orchestration is an event driven method where an event will trigger the useof policies that will determine the next action to be performed in response to the event.The policies commonly rely on rules that may impose constraints on the selection of aservice over another service.

Policy driven orchestration is likely employed in composition methods by protocolinterfaces and by APIs. In service composition based on services API, a policy enginewould guide the invocation of available services. Policies can govern the authorizationof service requests, the exposure of services within of a service chain and the selectionof rating rules by example.

According to Dinsing and others, policy driven orchestration is more naturaland flexible for composing real-time communications because it directly correlates tosignaling in call control and supports sessions very well [Dinsing et al., 2007]. OMAService Environment architecture contains a Policy component named PEEM (PolicyEvaluation, Enforcement and Management), which is responsible by intercepting theservice requests and by applying the configured policies [Alliance, 2009]. Blum andothers present a policy-based service broker, which allows the definition of request

2.3. Service Orchestration Techniques 21

and service-specific policies between a service access gateway contained in an operatordomain and cloud-based applications in 3rd party domains [Blum et al., 2008b].

2.3.2 Workflow

Workflow driven orchestration is based on execution of a sequence of deterministicsteps that coordinate the service execution flow. Workflow is a process driven orches-tration technique that assumes that the output of services is well known. Workflowdriven orchestration has been mainly used for well known services that would not bringunexpected dynamic conditions.

Different representations may be taken to express the workflow such as sequenceand activity diagrams. However, the current standard that has been proposed in webservices field is the WS-BPEL (Web Services Business Process Execution Language ) .WS-BPEL is a language for specifying business process behavior based onWeb Services,which defines a model and a grammar for describing the behavior of a business processbased on interactions between the process and its partners. The WS-BPEL processdefines how multiple service interactions are coordinated to achieve a business goal, thestate and the logic necessary for this coordination, and how they are to be compensatedin cases where exceptions occur or a partner requests reversal [OASIS, 2006]

EFlow is an implementation that uses a static workflow generation method. Acomposite service is modeled by a graph that defines the order of execution among thenodes in the process. The graph is created manually but it can be updated dynamically[Casati and et. al, 2000].

2.3.3 AI techniques

Artificial Intelligence techniques also may be employed to achieve service orchestration.McIlraith and others present a method to compose Web services by applying logicalinferencing techniques on pre-defined plan templates [Ankolekar et al., 2001]. Theservice capabilities are annotated in DAML-S/RDF and then manually translated intoProlog. Then, given a goal description, the logic programming language of Golog (whichis implemented over Pro-log) is used to instantiate the appropriate plan for composingthe Web services. Golog is based on situation calculus and it supports specificationand execution of complex actions in dynamical systems. The authors extended it tosupport sensing actions that can find values of variables at runtime.


2.4 Conclusion

There are a number of emergent business scenarios supported by collaborative arrange-ments among network operators, service providers, service integrators, device manu-facturers, programmers and designers. These collaborative chains aim to launch moreattractive services by aggregating services and capabilities provided by different actors.Service composition is related to the aggregation of elementary, self-contained and in-dependent services to provide a new converged composite service. Service compositiontechniques look for integrating different fields: the communications services and theIT services fields. Our primary objective was to review the composition of services inmobile services industry upon two aspects: service exposure and service orchestration.

Services architectures and models are likely tied for supporting systems in somemanner. In our case, the better understanding of service architectures and compositionmodels allow us better address the fundamental charging requirements for supportingthem.

The service composition review enabled us identify the following trends in servicecomposition:

1. Standard APIs have gained acceptance from communication service providers

2. Protocol based solutions have been improved through third-party research

3. Policy-based orchestration has acquired importance in service interaction

Chapter 3

Charging of Mobile Services

This chapter is about charging. Initially, the chapter brings an introductory descrip-tion of functional components of a charging system and after it describes the chargingmodel specified by 3GPP for mobile services. Most of this material is originated fromseveral 3GPP specifications related to Charging. The relevant information was se-lected, filtered and appropriately organized to be presented here. The text would haveonly refereed to the 3GPP specifications. However, as this is the central subject of re-search, the authors opted by doing the material self-contained. Therefore, all relevantinformation was brought to here.

This chapter is organized as follows: the first section generically describes theprocess of charging within a communication service provider. The second one focuseson 3GPP charging model, describing its principles, architecture, modes and variants.The last section covers the 3GPP Policy and Charging Control Architecture.

3.1 Introduction

The process of charging in the context of our study concerns the collection of informa-tion related to resource/service usage and its processing in order to produce a valuefor the service. The main functions related to charging are listed in the Figure 3.1;it shows a charging subsystem and its functional entities: accounting, mediation andrating; the output is sent to billing.

The accounting function performs the measurement of consumption of resourcesand services into of network elements. Accounting process creates chargeable eventrecords to be rated in rating phase. Mediation function is responsible for transferringthe resource usage records created by accounting towards rating engine. Within themediation, some additional functions such as correlation, formatting and classification

23

24 Chapter 3. Charging of Mobile Services

Billing

Accounting Accounting Mediation Rating

Charging

Figure 3.1. The Charging Function

of events can be performed. In the rating phase, rules and rating schemes are appliedto arrive at a value for the service. In the last stage of charging, an output is generatedfor billing. Billing is the step where is performed the batch processing of all informationalready valued. At this stage, general discounts and promotions for the services canalso be applied . This is a general view of charging processes. There is more specificscenarios that fit within charging process. For example, if the resource needs some pre-authorization before being delivered so the charging flow is different: it is necessaryto query the CSP accounting database in order to get credit authorization, and if thesubscriber owns required credits so service delivery is performed. It is a scenario similarto pre-paid services. In conclusion, there may have some variation related to how thecharging functions are named and applied. In the next section, this will be describedin details.

In our research, we are interested in designing advanced charging mechanisms formobile services. More specifically, our idea is to suggest an extension for the current3GPP standard charging model enhancing it to cope with the charging of compositemobile services. For this purpose, we are going to review the 3GPP charging modelsapplied in mobile telephony systems such as 3G and 4G.

3.2 3GPP Charging Model

The 3GPP - Third Generation Partnership Project - is formed by officially recog-nized standardization organizations that have agreed to work collaboratively for theproduction of evolved third generation and beyond mobile system specifications. Ithas developed a number of technical specifications that define the charging model fortelephony.

According to 3GPP Scope document [3GPP, 2008a], the purpose of 3GPP is toprepare, to approve and to maintain globally applicable technical specifications andtechnical reports for:

3.2. 3GPP Charging Model 25

1. An evolved 3rd Generation and beyond Mobile System based on the evolved3GPP core networks, and the radio access technologies supported by the Partners(i.e., UTRA both FDD and TDD modes), to be transposed by the OrganizationalPartners into appropriate deliverables (e.g., standards).

2. The Global System for Mobile communication (GSM) including GSM evolved ra-dio access technologies (e.g. General Packet Radio Service (GPRS) and EnhancedData rates for GSM Evolution (EDGE)).

3. An evolved IMS (IP Multimedia System) developed in an access independentmanner.

In this part of the text, the authors do a short review of 3GPP Charging inGSM/UMTS and EPS networks. The description is based on Release 8 of 3GPPCharging documentation set. 3GPP Charging specifications are organized within acore one, describing the charging principles, architecture and functional requirementsand complementary ones that cover charging aspects ( interfaces, CDR contents, on-line/offline ) per domain ( packet networks, circuit switched ), subsystem ( WLAN,IMS, etc ) and service ( MMS, SMS, LCS, PoC ). In specification 32.240 [3GPP, 2008f],the GSM/UMTS and EPS core network charging architecture and principles are spec-ified. The Figure 3.2 shows as charging specifications in 3GPP are organized; there isa master specification covering architecture and principles, and derived specificationsfocusing in domain related aspects.

According to 3GPP, Charging is a function within the telecommunications net-work and the associated components whereby information related to a chargeable eventis collected, formatted, transferred and evaluated in order to make it possible to de-termine usage for which the charged party may be billed (offline charging) or the sub-scriber’s account balance may be debited (online charging) [3GPP, 2008f]. A chargeableevent as referred in the above definition contains information about the resource/serviceusage.

Basically, we are interested in covering the following aspects of 3GPP Charging:

• Charging Principles

• Charging Architecture

• Charging Scenarios

• Charging Protocols


3 2 .2 4 03 2 .2 4 03 2 .2 4 03 2 .2 4 0 C h a rg in g C h a rg in g C h a rg in g C h a rg in g A rch ite c tu reA rch ite c tu reA rch ite c tu reA rch ite c tu re an d an d an d an d P r in c ip le sP r in c ip le sP r in c ip le sP r in c ip le s

32 .2 5 032 .2 5 032 .2 5 032 .2 5 0

C SC SC SC S ---- d om a ind om a ind om a ind om a in C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 513 2 .2 513 2 .2 513 2 .2 51

P SP SPSPS ---- d om a ind om a ind om a ind om a in C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 5 23 2 .2 5 23 2 .2 5 23 2 .2 5 2

W LA NW LANW LANW LAN C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 603 2 .2 603 2 .2 603 2 .2 60

IM Su b sys temIM Sub sys temIM Sub sys temIM Sub sys tem C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 7 03 2 .2 7 03 2 .2 7 03 2 .2 7 0

M M SM M SM M SM M S C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 713 2 .2 713 2 .2 713 2 .2 71

LC SLC SLC SLC S C h a rg in g C h a rg in g C h a rg in g C h a rg in g

3 2 .2 953 2 .2 953 2 .2 953 2 .2 95

C hC hC hC h a rg in g D a ta a rg in g D a ta a rg in g D a ta a rg in g D a ta

R e co rd (C D R ) R e co rd (C D R ) R e co rd (C D R ) R e co rd (C D R ) tr an s fe rtr an s fe rtr an s fe rtr an s fe r

3 2 .2 9 63 2 .2 9 63 2 .2 9 63 2 .2 9 6

O n lin e C h a rg in g S ys tem O n lin e C h a rg in g S ys tem O n lin e C h a rg in g S ys tem O n lin e C h a rg in g S ys tem

(O C S ) ap p lica t io n s an d (O C S ) ap p lica t io n s an d (O C S ) ap p lica t io n s an d (O C S ) ap p lica t io n s an d in te rfa c e sin te rfa c e sin te rfa c e sin te rfa c e s

3 2 .2 993 2 .2 993 2 .2 993 2 .2 99

D iam e te r D iam e te r D iam e te r D iam e te r

C h a rg in g C h a rg in g C h a rg in g C h a rg in g

A p p lic a t io nA pp lic a t io nA pp lic a t io nA pp lic a t io n

3 2 .2 973 2 .2 973 2 .2 973 2 .2 97

C h a rg in g D a ta R ec o rd C h a rg in g D a ta R ec o rd C h a rg in g D a ta R ec o rd C h a rg in g D a ta R ec o rd

(C D R ) f ile fo rm a t an d (C D R ) f ile fo rm a t an d (C D R ) f ile fo rm a t an d (C D R ) f ile fo rm a t an d tran s fe rtran s fe rtran s fe rtran s fe r

3 2 .2 73 2 .2 73 2 .2 73 2 .2 7 4444

SSSSM SM SM SM S C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 983 2 .2 983 2 .2 983 2 .2 98

C h a rg in g D a ta R e co rd C h a rg in g D a ta R e co rd C h a rg in g D a ta R e co rd C h a rg in g D a ta R e co rd

(C D R ) p a ram e(C D R ) p a ram e(C D R ) p a ram e(C D R ) p a ram e te r te r te r te r d e sc r ip t io nd e sc r ip t io nd e sc r ip t io nd e sc r ip t io n

3 2 .2 73 2 .2 73 2 .2 73 2 .2 7 3333

M BM SM BM SM BM SM BM S C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 73 2 .2 73 2 .2 73 2 .2 7 5555

M M Te lM M Te lM M Te lM M Te l C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .2 723 2 .2 723 2 .2 723 2 .2 72

P oCPoCPoCPoC C h a rg in gC h a rg in gC h a rg in gC h a rg in g

3 2 .23 2 .23 2 .23 2 .2 80808080

A d v ice o f C h a rg e A d v ice o f C h a rg e A d v ice o f C h a rg e A d v ice o f C h a rg e (A oC ) se rv ic e(A oC ) se rv ic e(A oC ) se rv ic e(A oC ) se rv ic e

Figure 3.2. 3GPP Charging Related Specifications

3.2.1 3GPP Charging Principles

Charging function into 3GPP has as ground a set of basic guiding principles. They aremainly contained in the references: [3GPP, 2008c] [3GPP, 2008d]. Basically the prin-ciples aim to support a flexible charging parametrization, ensure reliable and accuratecharge information, support different charging scenarios ( roaming, interconnection),special cases ( call forwarding, conference, advertising, etc ) and auxiliary mechanisms( Advice of Charge, top-up, etc ). To illustrate, the authors cite some principles presentin the documents:

• Allow flexible parametrization: on time, destination, location, volume, band-width, access technology and quality and medium used


• Charge by different cost: sending, transporting, delivery and storage

• Ensure charging information availability on time

• Allow flexible multi leg charging ( forward call, conference.)

• Support to Context-based charging

• Charging Indications Support (Advice of Charge )

• Support to the shared network architecture

• To charge unsuccessful calls and sessions

The 3GPP established charging requirements should support different businessscenario and technologies. The Figure 3.3, extracted from 3GPP, depicts these dif-ferent relationships; there are distinct charging perspectives: retail, wholesale, access,supplier, etc.

Figure 3.3. Entity and Technologies relationship by 3GPP.


The technical specification TS 22.115 [3GPP, 2008d] is well informative and de-scribes a number of charging requirements covering different aspects related to chargedparties, media charge options, roaming e interconnection, and services charging.

3.2.2 3GPP Charging Architecture

The 3GPP core charging model is mainly described in the technical specification TS32.240 [3GPP, 2008f]. The architecture of the 3GPP charging defines two modes, onlineand offline. In the online mode, the service needs to be authorized by the chargingengine. Pre-paid service is a good example where online charging fits well. In themodel off-line, charging does not affect the service - which normally has been providedpreviously - and what happens is the processing of records already generated using theservice.

3GPP adopts a common logic view to express the charging architecture coveringthe different charging modes and domains. This common logic view is illustrated inthe Figure 3.4. The figure is very representative because it shows the different chargingentities that the authors are going to describe forward as well as the elements presentin the 3GPP communications domains with their interfaces to charging system.

The arrows in Figure 3.4 indicate logical information flows on the Rf, Wf, Ga,Bx, ISC, Ro, Wo, CAP, and Gy reference points. A reference point is a conceptualpoint at the conjunction of two non-overlapping functional groups

3.2.2.1 OffLine Charging

In offline charging, the charging information is generated in the form of charging recordsonce that the consumption of resource has occurred. Then these charging records willbe transferred to billing system to be processed.

The Figure 3.5 illustrates the logical charging entities that are part of off-linecharging mode architecture:

CTF: Charging Trigger FunctionCDF: Charging Data FunctionCGF: Charging Gateway FunctionBD: Billing Domain. This may also be a billing system/ billing mediation device.The entities in off-line mode are:

CTF The Charging Trigger Function (CTF) generates charging events based on theobservation of network resource usage. CTF collects the information pertaining


Billing Domain

ONLINE CHARGINGOFFLINE CHARGING

WLAN

MRFC

SIP AS

PCRF

AF

CDF

CS -NE

SGSN

CGF

OCSIMS-GWF S-CSCF

Service -NE

P-GW

PCEF

MGCF BGCF IBCF P-CSCF I-CSCF

S-GW

Figure 3.4. 3GPP Charging Architecture.

to chargeable events within the network element, assembles it into matchingcharging events, and send them towards the Charging Data Function.

CDF The Charging Data Function (CDF) receives charging events from the ChargingTrigger Function. It then uses the information contained in the charging eventsto construct CDRs.

CGF The CGF acts as a gateway between the 3GPP network and the Billing Domain.It can aggregate functions such as CDR file Management and CDR routing andfiltering.

3.2.2.2 Online Charging

In online charging, the charging information is transferred from the network to theOnline Charging System (OCS). In online charging, the service request needs to beauthorized before grant permission to use the resource. It is likely done by sending aquery in real-time towards the online charging system prior to grant the resource usage.


CN Domain

Service element

Sub - system

Billing Domain

R f G a B x

C

T

F

C

D

F

C

G

F

3GPP network

Figure 3.5. 3GPP off-line charging architecture.

The charging system upon the request from network will use the subscriber accountinformation, service information and service provider policies to accept or to denyauthorization to the service. The OCS, in turn, may have an offline charging referencepoint used to forward charging information to the billing domain. The architecture foronline charging is depicted in the Figure 3.6.

CN Domain

Service element

Sub - system

Ro

C

T

F

3GPP network

CAP

O

C

F

ABMF

RF

OCS

Rc

Re

Figure 3.6. 3GPP on-line charging architecture.

The entities comprising online charging are:


CTF: Charging Trigger FunctionOCF: Online Charging FunctionABMF: Account Balance Management FunctionRF: Rating Function

CTF As in offline charging, it is the function that collects charging information fromnetwork element. However, CTF carries additional responsibilities because itmust enforce the usage permission policies by querying the online charging sys-tems before authorizes the actual resource usage.

OCF The Online Charging Function (OCF) consists of two distinct modules, namelythe Session Based Charging Function (SBCF) and the Event Based ChargingFunction (EBCF).

Rating Function The Rating Function (RF) determines the value of the networkresource usage on behalf of the OCF. To this end, the OCF furnishes the necessaryinformation, obtained from the charging event, to the RF and receives in returnthe rating output (monetary or non-monetary units), via the Re reference point

Account Balance Management Function The Account Balance ManagementFunction (ABMF) is the location of the subscriber’s account balance within theOCS. During resource authorization, the OCS may send transactions towards theaccount balance system.

The components of 3GPP charging architecture - online and off-line - are func-tional logical entities that might be mapped onto different physical components of3GPP. However, such mapping is not our objective. 3GPP TS32.240 [3GPP, 2008f]contains additional information concerning these aspects.

3.2.3 3GPP Charging Scenarios

The 3GPP describes some charging scenarios that might occur in the online chargingmode and in some cases in off-line charging mode; as their better understanding isfundamental so they are described below:

Direct Debiting the requested resource is already billed during its authorization pro-cedure. As the resource is debited in subscriber account before to be delivered itis needed a mechanism to ensure that the delivery will succeed.


Unit Reservation the OCS cannot a priori know the amount of resources that the enduser may eventually consume, or it cannot be assumed a priori that the resourceusage request can be (completely) fulfilled. In this case, a certain amount of(monetary or non-monetary) units is blocked, or reserved, on the subscriber’saccount on the OCS, and permission to use an amount of resources that matchesthe unit reservation is returned to the network. When the granted units havebeen used or a new, not yet authorized chargeable event occurs, the networkmust send a new request for unit allocation to the OCS. When resource usagehas been executed, the actual amount of resource usage (i.e. the used units) mustbe returned by the NE to the OCS so that eventually over-reserved amounts canbe re-credited to the subscriber account, assuring that the correct amount getsdebited.

Furthermore, there still are 2 types of charging procedure:

Event based charging Results in a single credit control and resource usage autho-rization procedure. Such method is resulting from a single network transactionas, for example, the sending of a short text message. In online charging, theevent charging procedure may occur with or without reservation of units fromthe subscriber’s account ("Event Charging with Unit Reservation" (ECUR) or"Immediate Event Charging" (IEC)).

Session based charging is characterized by any kind of user session in the offeredservice, such as a media session or circuit call. This user session is then matchedby a charging session, resulting in the generation of multiple chargeable/chargingevents and in the creation of one or more CDRs in offline charging or the per-formance of a credit control session in online charging. For online charging, asnot exists no information available at this time concerning the overall evaluationof the session (e.g. complete duration or data volume of the session), sessionbased charging always involves reservation of units from the subscriber’s account("Session based Charging with Unit Reservation" (SCUR))

TS 32.240 [3GPP, 2008f] describes event versus session based charging in moredetails for both, online and offline charging.

3.2.4 3GPP Charging Protocols

For our study, it is essential to understand the protocols employed by 3GPP elements tointerface with the charging system. 3GPP uses the reference point concept to establish


the interface among their functional components.

The off-line reference points are illustrated in Figure 3.4 and the correspondingimplementation protocols are:

Rf This reference point supports the interaction between CTF and CDF. The baseprotocol is Diameter.

Ga The Ga reference point supports interaction between a Charging Data Functionand a Charging Gateway Function. The base protocol is Gtp’

Gz Reference point functionally equivalent to Ga ( Legacy PS domain ) and to Ga orRf ( Evolved PS domain ).

Bx The Bx reference point supports interaction between a Charging Gateway Functionand the Billing Domain.

Wf The Wf reference point is functionally equivalent to Rf

The 3GPP online reference-points are depicted in figure 3.4 as well:

Ro The Ro reference point supports interaction between a Charging Trigger Functionand an Online Charging Function. The interface application is Diameter.

CAP provides similar functionality for online charging as Ro, however, it is based onCAMEL techniques. [3GPP, 2008e]

Gy The Gy reference point is functionally equivalent to Ro

Re The Re reference point supports interaction between the OCF and a Rating Func-tion (RF) in order to determine the value of chargeable events in terms of mon-etary or non-monetary units. [3GPP, 2009c].

Rc The Rc reference point allows the interaction between the OCF and an AccountBalance Management Function (ABMF) in order to access the account of thesubscriber on the OCS. [3GPP, 2009c]

Wo The Wo reference point is functionally equivalent to Ro, and hence is replaced byRo within the common charging architecture.


3.3 3GPP Evolved Packet Core

The 3GPP Evolved Packet Core (EPC) is the evolution of 3GPP core architecture.3GPP EPC supports multiple access networks, from 3GPP and non-3GPP, such as:E-UTRAN, UTRAN, GERAN, Wimax, Wlan, etc. EPC is a common packet corenetwork containing a set of services and capabilities. One of main EPC requirementswas to guarantee the seamless mobility through of different access technologies.

A detailed review of EPC architecture is out of our scope. The authors wish toreview only the aspects of 3GPP Core related to charging. The part of 3GPP EPCrelated to Charging is within of 3GPP PCC - Policy and Charging Control document[3GPP, 2009a]. Policy and Charging Control has evolved from Service Based LocalPolicies (SBLP) mechanism, which has been present in 3GPP technical specificationsin the last years. PCC in Evolved Packet Core encompasses 2 main functions :

1. Flow Based Charging, including charging control and online credit control

2. Policy control

Flow Based Charging is related to service authorization and offline charging.Policy control comprises functionalities for [3GPP, 2009a]:

1. Binding, i.e. the generation of an association between a service data flow and thetraffic plane bearer transporting that service data flow;

2. Gating control, i.e. the blocking or allowing of packets, belonging to a servicedata flow, to pass through to the desired endpoint;

3. Event reporting, i.e. the notification of and reaction to application events totrigger new behavior in the traffic plane as well as the reporting of events relatedto the resources in the GW(PCEF);

4. QoS control, i.e. the authorization and enforcement of the maximum QoS thatis authorized for a service data flow or a traffic plane bearer.

The authors are particularly interested on Flow Based Charging. For that, abrief description will be provided concerning the 3GPP EPC and how the PCC engineperforms its role within EPC .

3.3. 3GPP Evolved Packet Core 35

3.3.1 Charging Functions in EPC

The PCC functionality is comprised by the functions of the Policy and Charging En-forcement Function, the Bearer Binding and Event Reporting Function (BBERF), thePolicy and Charging Rules Function, the Application Function, the Online ChargingSystem, the Offline Charging System and the Subscription Profile Repository. TheFigure 3.7 illustrates the PCC Architecture in EPC. The description of functions islargely based on [3GPP, 2009a] and follows:

Policy Control and Charging Rules Function (PCRF) The PCRF encom-passes policy control decision and flow based charging control functionalities.It is the policy engine of PCC. The PCRF takes policy decisions regarding theservice data flow detection, gating, QoS and flow based charging and send itsdecision to be enforced by PCEF (Policy Control Enforcement Function).

Gy

Gz

Subscription Profile Repository

(SPR)

Rx

AF Sp

Gx

Offline Charging System (OFCS) Gateway

PCEF

Policy and Charging Rules Function (PCRF)

Online Charging System (OCS)

Service Data Flow Based

Credit Control

Gxx

BBERF

Figure 3.7. The PCC architecture in EPC.

Policy and Charging Enforcement Function (PCEF) The PCEF encompassesservice data flow detection, policy enforcement and flow based charging function-


alities. It interacts with online and offline charging. The PCEF enforces thePolicy Control as indicated by the PCRF in two different ways:

- Gate enforcement. The PCEF shall allow a service data flow, which is subjectto policy control, to pass through the PCEF if and only if the corresponding gateis open;

- QoS enforcement

For a service data flow (defined by an active PCC rule) that is subject to bothPolicy Control and Charging Control, the PCEF shall allow the service data flowto pass through the PCEF if and only if the right conditions from both policycontrol and charging control happen, i.e. the corresponding gate is open and incase of online charging the OCS has authorized credit for its charging key.

Application Function (AF): The Application Function (AF) is an element offeringservice information to applications that require dynamic policy and/or chargingcontrol. The AF shall communicate with the PCRF to transfer dynamic sessioninformation, required for PCRF decisions as well as to receive specific informationand notifications about events in the traffic plan. One example of an AF is theP-CSCF of the IM (IP Multimedia )subsystem.

Subscription Profile Repository (SPR): The SPR logical entity contains all sub-scriber/subscription related information needed for subscription-based policies.

The SPR may provide the following subscription profile information (per PDN,which is identified by the PDN identifier):

- Subscriber’s allowed services;

- For each allowed service, a pre-emption priority;

- Information on subscriber’s allowed QoS, including the Subscribed GuaranteedBandwidth QoS;

- Subscriber’s charging related information (e.g. location information relevant forcharging);

Bearing Binding Event Report Function Binding and Event Reporting relatedfunctions.

3.3.2 3GPP EPC - PCC Reference Points

The reference points are named:


Rx The Rx reference point resides between the AF and the PCRF.

This reference point enables transport of application level session informationfrom AF to PCRF. Such information includes, but is not limited to:

- IP filter information to identify the service data flow for policy control and/ordifferentiated charging;

- Media/application bandwidth requirements for QoS control.

Gx The Gx reference point enables a PCRF to have dynamic control over the PCCbehaviour at a PCEF.

The Gx reference point enables the signalling of PCC decision, which governs thePCC behaviour, and it supports the following functions:

- Request for PCC decision from PCEF to PCRF;

- Provision of PCC decision from PCRF to PCEF;

Sp The Sp reference point lies between the SPR and the PCRF.

The Sp reference point allows the PCRF to request subscription informationrelated to the IP CAN transport level policies from the SPR based on a subscriberID, a PDN identifier and possible further IP CAN session attributes.

Gy The Gy reference point resides between the OCS and the PCEF.

Gz The Gz reference point resides between the PCEF and the OFCS

S9 Roaming related reference point between virtual and home operator

Gxx Reference point between PCEF and BBERP

3.3.3 3GPP PCC Charging Control

The PCRF is the entity fundamental in PCC making policy and charging-control de-cisions. The PCRF shall accept input for PCC decision-making from the PCEF, theBBERF if present, the SPR and if the AF is involved, from the AF, as well as thePCRF may use its own pre-defined information. These different nodes should provideas much information as possible to the PCRF.

The PCC formulates its decisions through the rules. Each Pcc rule containspacket filters that are applied to IP packets. The packets detected by applying theservice data flow template of a PCC rule are designated a service data flow. PCC rules


are provisioned by PCRF to the PCEF that will enforce the policy decisions. There 2types of PCC rules: dynamic and pre-defined rules.

The PCC rule contains a couple of attributes including in some of them informa-tion related to charging. The PCC Charging key is the reference to the tariff for theservice data flow. Any number of PCC Rules may share the same charging key value.The charging key values for each service shall be operator configurable. The PCCService identifier identifies the service. PCC Rules may share the same service iden-tifier value. The service identifier provides the most detailed identification, specifiedfor flow based charging, of a service data flow. The PCC Charging method indicateswhether online charging, offline charging, or both are required or the service data flowis not subject to any end user charging. If the PCC charging method identifies thatthe service data flow is not subject to any end user charging, a PCC Charging key shallnot be included in the PCC rule for that service data flow, along with other chargingrelated parameters. If the PCC charging method is omitted, the PCEF shall apply thedefault charging method as determined at traffic bearer session establishment

Thus upon the initial interaction with the PCEF, the PCRF may provide Charg-ing information containing OFCS and/or OCS addresses to the PCEF defining theoffline and online charging system addresses respectively. Upon the initial interactionwith the PCEF, the PCRF may provide default charging method indicating what charg-ing method shall be used in the IP CAN session for every PCC rule where the chargingmethod identifier is omitted, including predefined PCC rules that are activated by thePCEF.

A charge flow example from 3GPP TS 23.203 [3GPP, 2009a] is illustrated indetails in Figure 3.7.

This procedure concerns both roaming and non-roaming scenarios. In the roam-ing case when a Gateway Control Session is used, the V-PCRF should proxy the Gate-way Control Session Establishment information between the BBERF in the VPLMNand the H-PCRF over S9 based on PDN-Id and roaming agreements. The entire flowis detailed below.

1. The BBERF initiates a Gateway Control Session Establishment procedure

2. The GW(PCEF) receives a request for IP CAN Bearer establishment. A PDNConnection Identifier may be included in the request. The GW(PCEF) acceptsthe request and assigns an IP address for the user.

3. The PCEF determines that the PCC authorization is required, requests the au-thorization of allowed service(s) and PCC Rules information. The PCEF includes


GW (BBERF) GW (PCEF) V-PCRF H-PCRF SPR OCS

Roaming Scenarios

1. Gateway Control Session Est ablishment )

6. Policy Decision

2. Establish IP-CAN Bearer Request

-3. Indication of IP CAN Session Establishment

4. Profile Request

5. Profile Response

7. Acknowledge IP CAN Session Establishment

8. Credit Request

9. Credit Response

10. Establish IP -CAN Bearer Response

11. IP CAN Bearer Signaling 12. IP CAN Session Establishment Acknowledge

Figure 3.8. An EPC Flow.

the following information: UE Identity (e.g. MN NAI), a PDN identifier (e.g.APN), the IP CAN type and the IP address(es), if available, the PDN ConnectionIdentifier received for IP CAN Bearer establishment and, if available, the defaultcharging method and the IP CAN bearer establishment modes supported. ThePDN identifier, IP address(es) and UE identity enable identification of the IPCAN session. The IP CAN Type identifies the type of access from which the IPCAN session is established. If the service data flow is tunnelled at the BBERF,the PCEF shall provide information about the mobility protocol tunnelling en-capsulation header. The PCEF may also include the Default Bearer QoS andAPN.

4. If the PCRF does not have the subscriber’s subscription related information, it


sends a request to the SPR in order to receive the information related to theIP CAN session. The PCRF provides the subscriber ID and, if applicable, thePDN identifier to the SPR. The PCRF may request notifications from the SPRon changes in the subscription information.

5. The PCRF stores the subscription related information containing the informationabout the allowed service(s) and PCC Rules information.

6. The PCRF makes the authorization and policy decision.

7. The PCRF sends the decision(s) , including the chosen IP CAN bearer establish-ment mode, to the PCEF. The GW(PCEF) enforces the decision. The PCRFmay provide the default charging method and may include the following infor-mation: the PCC Rules to activate and the Event Triggers to report. The Policyand Charging Rules allow the enforcement of policy associated with the IP CANsession. The Event Triggers indicate to the PCEF what events must be reportedto the PCRF.

8. If online charging is applicable, and at least one PCC rule was activated, thePCEF shall activate the online charging session, and provide relevant input in-formation for the OCS decision. Depending on operator configuration PCEF mayrequest credit from OCS for each charging key of the activated PCC rules.

9. If online charging is applicable, the OCS provides the possible credit informationto the PCEF and may provide re-authorisation triggers for each of the credits.

10. If at least one PCC rule was successfully activated and if online charging isapplicable, and credit was not denied by the OCS, the GW(PCEF) acknowledgesthe IP CAN Bearer Establishment Request.

11. If network control applies the GW may initiate the establishment of additionalIP- CAN bearers.

12. If the PCRF in step 7 requested an acknowledgement based on PCC rule oper-ations, the GW(PCEF) sends the IP CAN Session Establishment Acknowledge-ment to the PCRF in order to inform the PCRF of the activated PCC rulesresult.

3.4. Conclusion 41

3.4 Conclusion

3GPP charging specifications have a fundamental role in charging of mobile services.The model has evolved to incorporate policy control through of PCC - Policy andCharging Control architecture. The authors believe that any innovative charging solu-tion should be in conformance with 3GPP charging; otherwise, it will not reach a widedeployment.

In this section, the authors presented a description of the 3GPP Charging Model.The objective was provide a general overview about the 3GPP charging, which is theground architecture for the proposed solution.

Chapter 4

Charging of Composite Services

In this chapter, the authors are going to give further details about the charging ofcomposite services. In the first chapter of this dissertation, part of subject was intro-duced, outlining relevant challenges and related research. This chapter supplementsthe introductory information. Firstly, a functional overview will be provided. Secondly,the objective is to present the research proposal, and finally, provides a precise scopedefinition for the work.

Figure 4.1. Service Broker in a Composite Business Scenario.

43

44 Chapter 4. Charging of Composite Services

B1

E1 E2 E3

Figure 4.2. Service Composition Flow - No Context.

4.1 Composite Service Charging Overview

This section describes, in details, how the charging of composite services is performed.The objective is figure out how the functional stuff works.

Table 4.1. Service Providers Rating Rules.

Provider Service Rate/Rating Rules

E1 S1A,S1B S1A=0.20,S1B=0.30E2 S2A,S2B S1A=0.40,S2B=0.60E3 S3A,S3B S2A=0.25,S2B=0.30B1 B1A B1A=0.6, 5% discount if ( S1A and S2B )B1 10% discount if ( S3A and B1A )

The authors are interested on brokered composite model. The Figure 4.1, bor-rowed from Cuevas depicts the role of service broker within a mobile business model[Cuevas et al., 2008]. In such figure, the service broker entity (Orchestrating ServiceProvider), provides customer access to its service capabilities as well as to the servicesprovided by elementary service providers. In such model, customer can also directlyaccess service provider capabilities without to need the service broker. Although minorvariations can exist within other mobile business models, this one is quite representa-tive.

Service composition typically encompasses the following phases:

Service Description : The services are designed and their interfaces are describedby service providers.

Service Registration : Services are registered to some service registry entity. Atthis point, they are available to be selected.

Service Discovery : The services are discovered by the broker through some method.

4.2. Enhanced Composite Charging 45

Service Selection : A service selection process is performed based on any criterion.

Service Orchestration : Service interactions are determined following any definedorchestration method.

Service Invocation : The service is invoked.

The research interest is in service invocation step. Such step is where the chargeof services occurs. It can occur either prior to service delivery or post service delivery.Charge records are produced during service session. Then the service broker fetches theindividual charges from elementary service providers and aggregates them to generatethe total service charge. Individual charge records are correlated through a charging ididentifier that the service broker can create. The service broker provides the chargingid as parameter while invoking individual services. Let’s give an example to clarify.

The Figure 4.2 describes a broker entity B1 (e.g. Broker 1) and three elementaryservice providers E1, E2, E3 (e.g. Elementary X). B1 entity relies on three third-partyproviders to supply its services. The exposed services, and their rating and the brokerrules are described in the Table 4.1; each provider may supply more than one service,e.g S1A, S1B; it was assumed a fixed price for each service in order to become theexample clear.

A service usage scenario is described in the Figure 4.3: the user invokes a numberof services through the broker entiy named "Service Broker B1"; each service providerreturns partial charge records that will be aggregated as below:

Total Rate = Rate(S1A) + Rate(S3B) + Rate(S2A) + Rate(B1A) + Rate(S3A)Notice that the service broker contains a business rule that applies a 10% discount

over the elementary B1A rate.Therefore:Total Rate = 0.2 + 0.3 + 0.4 + ( 0.9) * 0.6 + 0.25 = 1,69This is a typical composite service charging. It is characterized by aggregation

of individual charges and post processing of composite rating rules by service broker.Next section addresses how the authors intend to enhance this model for allowingelementary providers benefit from composite information within their rating rules.

4.2 Enhanced Composite Charging

In this section, the authors take the example from previous one to illustrate how thecharging of composite services will be enhanced. The service provider would like design


rating models that take into account the service context. From previous example isobserved that:

1. Elementary service providers have no access to inter-domain service information.Therefore, they can’t define advanced discounts rules based on partnerships agree-ments and service chain information.

2. Service brokers have access only to the context information got from direct chil-dren nodes. Then, if a some service provider relies on other providers to deployits services,e.g. assuming a secondary broker role, so the master broker will notbe aware of other children domain information. Such issue is illustrated in theFigure 4.4. Primary broker B1 knows about E1, E2, B2, but it does not knowabout E3 and E4.

Table 4.2. Service Provider E1 Rating Rules.

Provider Service Rate/Rating Rules

E1 S1A 0.20E1 S1B 0.30E1 none 5% Discount if (S1A and S2A)

For solving this problem, the authors envision adding service context informationto the data exchanged among the service elements. This is depicted in the Figure 4.5.

Such design enables us to explore more complex rating rules within the elementaryproviders as defined in Table 4.2, where provider E1 adds a discount rule based onservice context information, for those ones from previous example. The overall totalrate calculation follows.

Total Rate = Rate(S1A) + Rate(S3B) + Rate(S2A) + Rate(B1A) + Rate(S3A)The service broker contains a business rule that gives 10% of discount over the

elementary B1A rate. Additionally, the elementary provider E1 applies its new ratingrule.

Therefore:Total Rate = (0.95) * 0.2 + 0.3 + 0.4 + ( 0.9) * 0.6 + 0.25 = 1,68

4.3 Solution Scope

Charging of composite services is a large research field. In the introductory chapter,the authors enumerated topic challenges and research gaps. This section provides abetter scope definition to the solution. Such scope is defined in Table 4.3.

4.4. Conclusion 47

Table 4.3. Solution Scope.

Composite Services Charging Requirements In Scope of Research?

Support to brokered composite service architecture. (orchestration) In ScopeSupport to peer-to-peer composite service architecture. (choreography) Beyond ScopeSupport to Static Service Composition In ScopeSupport to Dynamic Service Composition In ScopePropose a composite Rating Engine Rule Generator Beyond ScopePropose a new distributed transaction control mechanism Beyond ScopeSupport API based-compositions In ScopeSupport protocol based compositions In ScopeSupport inter-domain context based charging In ScopeSupport inter-domain context dissemination In Scope

4.4 Conclusion

The objectives of this chapter were to give a functional overview regarding how com-posite service charging is performed and to establish the boundaries of our research.The authors compared the typical model of composite charging with that they areproposing, and outlined the research scope.

In the next chapter, the general requirements of the charge model will be outlined.Both of them, the scope and the requirements, allow us get a better idea about howour solution fulfills within the research in charging of composite services.


Service Broker B1 Service Provider E1 Service Provider E2 Service Provider E3User

Invoke S1A

S1A (12345)

Invoke S3B

S3B (12345)

Invoke S2A

S2A (12345)

Invoke B1A

Invoke S3A

S3A

Rate = 0.20

Charging Id = 12345

Rate = 0.30

Charging Id = 12345

Rate = 0.40

Charging Id = 12345

Rate = 0.60

Charging Id = 12345

Rate = 0.25

Charging Id = 12345

Return Charge

Return Charge

Return Charge

Return Charge

Aggregatedl Charge

Figure 4.3. Charging Flow in Brokered Service Composition.

4.4. Conclusion 49

B1

E1 E2 B2

E3 E4

Figure 4.4. Federated Brokered Service Composition.


Service Broker B1 Service Provider E1 Service Provider E2 Service Provider E3User

Invoke S1A

S1A (12345)

Invoke S3B

S3B (12345)

Invoke S2A

S2A (12345)

Invoke B1A

Invoke S3A

S3A

Rate = 0.20

Charging Id = 12345

Composite Dta ( E1-S1A)

Rate = 0.40

Charging Id = 12345

Composite Data ( E1-S1A,E3-S3B,E2-S2A)

Rate = 0.60

Charging Id = 12345

Composite Data ( E1-S1A,E3-S3B,E2-S2A,B1-B1A)

Rate = 0.30

Charging Id = 12345

Composite Data ( E1-S1A,E3-S3B)

Rate = 0.25

Charging Id = 12345

Composite Data ( E1-S1A,E3-S3B,E2-S2A,B1-B1A,E3-S3A)

Charge Record

Charge Record

Charge Record

Charge record

Aggregated Charge

Figure 4.5. Service Composition Flow - (with context information).

Chapter 5

A Model for Charging of CompositeServices

In this chapter, the proposed charging mechanisms are presented. The authors describethe most relevant requirements, the ground charging architecture and the informationmodel. The foundation is the 3GPP charging model. Therefore, the authors presentonly the necessaries extensions in 3GPP Charging for enabling the charging of com-posite services. Everything else is assumed to follow 3GPP standard charging. Thechapter is organized in three main sections. The first one describes a typical referencescenario for composite services. It aims to capture the business arrangements and usecases. Such part will assist us in determining the fundamental requirements for themodel and in limiting the scope of solution. The second section addresses the charg-ing requirements that need to be fulfilled. In the last section, the charging model ispresented in details, encompassing the architecture, protocols e data interfaces.

5.1 Composite Services Reference Scenario

In order to allow a better definition of the problem, delimiting its scope, assisting onelaborating the requirements, the authors propose a general reference scenario for whichthe solution is valid. In designing this application scenario, the authors were careful inpicking relevant actors, roles and collaborative arrangements. Although it perhaps doesnot cover all known use cases related to composite services, such scenario is enoughsignificant. The Figure 5.1 illustrates the general reference scenario for the charging ofcomposite services. The components are the service providers, the services they host(composite, elementary), and the charging systems. In such figure, the minor circlesrepresent the elementary services. The large ones represent the composite services.

51

52 Chapter 5. A Model for Charging of Composite Services

Solid lines establishe the dependencies between composite and elementary services. Ifthe service provider has its own charging system the authors represent it through arectangle. The detailed description of roles is below.

Service Provider B

Ch

arg

ing

S

yst

em

(C

S)

Ch

arg

ing

S

yst

em

(C

S)

Service Provider A

Service Provider C

Service Provider D

Charging System(CS)

Service Broker

Figure 5.1. Composite Services Reference Scenario.

The reference scenario covers different range of service providers: those thatonly provide elementary services and have no charging system, those similar ones butwith charging system support, those with a mix of elementary and composite serviceswithout charging system, and a similar for the last one containing a charging system.Different broker roles are described as well. There are master and secondary brokersand the composite service within them may be either internal, i.e., they depend onother services belonging to the same provider, or external, depending on services fromother providers.

Service Provider A offers a couple of elementary services and content. As a stan-dalone IT service provider within of his domain there is no charging system.Therefore, its services are charged by a third party entity, which could hold anagreement with and offer their services within a portal. Let’s suppose that it isa content provider offering digital contents such as ring tones, wall papers andmusic.

5.2. Model Requirements 53

Service Provider C is similar to Provider A in offering elementary services. How-ever, rather than depending on a third party charging systems, it owns its owncharging system. So Provider C can choose to charge itself their elementary ser-vices. Let’s suppose that such entity is any telecom operator and exposes itscapabilities through the IMS/SIP interfaces.

Service Provider B provides elementary and composite services ( secondary broker).It owns a charging system that may be used to charge the services. Let´s imaginethat it offers composite services that bring a multimedia messaging applicationwith presence resources taking online digital content from a third-party provider.In the picture, this is illustrated by the connected line to service provider A.

Service Provider D provides a mix of elementary as well as composite services (secondary broker ). However, it can’t directly charge its services because there isno charging system in its domain. Let’s suppose that this provider is some mobileapplication house offering applications in a specific field that relies on networkcapabilities of some operator. In the picture, this is illustrated by its dependencyon service capabilities of provider C.

Service Broker is a service aggregator (master) that manages collaborative arrange-ments in order to provide a couple of rich and attractive convergent services fromdifferent application domains. It maintains a charging system that could chargeby its services in collaboration with the charging system of its providers.

In summary, this general reference scenario encompasses a couple of business rolesthat the proposed charging model should be able to address. During the next sections,the authors will be referring to it when describing either the model or its validation.

5.2 Model Requirements

In this section, the relevant requirements that the charging model should reach areoutlined. Firstly, the model should be conformant and interoperable with 3GPP charg-ing specifications. In our context, it means that despite of introduced modifications,the proposed charging model must achieve the charging principles, requirements, andsupport the charging model and scenarios proposed by 3GPP. The authors do notreproduce here all charging principles and requirements established by 3GPP. Thisinformation can be got from the reference material. Only the charging requirementsthat are either specifically suitable to composite services or really significants to ourcontext are outlined.


Autonomy: Each service provider in the service chain should be able to manage therating of the elementary and composite services it owns. It means that theprovider has to be able to control all the rating context - e.g. rules, schemes, etc- necessary to rate the service. Since the service provider reserves to himself theprivileges to revoke and grant rating privileges, at its discretion it could grantthis capability to a third party entity preserving the autonomy.

Confidentially: Each service provider should be able to keep confidential all the con-textual information employed to rate its services without that that obstructs therating of overall composite service. Therefore, rating rules can support estab-lished business agreements without disclosure confidential business data.

Abstraction: The charging model should not add any constraint related to how thecomposite services are delivered to the customer, i.e., it should allow the customerto know if it is accessing services from different providers or through a servicebroker. This decision should be at discretion of collaborative arrangement anddoes not affect the charging. If the users intend either to pay for the requestedservice as a whole or to get the breakdown of charges for transactions by primaryservice providers it should not be a problem for the charge system.

Context Information: The charging architecture should provide means to carryinter-domain context information needed to be employed in rating process. Forexample, the information concerning the service chain might be made availableto the provider of services in order to it employ it in its rating and chargingprocesses. As the service chain may dynamically change so should exist a proce-dure to allow this information be updated to the interested parties during serviceusage. The charging system must support on the fly configuration and operatecontext based information.

Traceability: The system should allow be established the correlation among all thecharging data records produced during the usage of composite service. Thismeans that from a single charging record belonging to a composite service shouldbe possible to retrieve all charging records of its elementary service components.From an elementary service’s charging record should also be possible to identifyin which composite service transaction it was inserted.

Transparency: The customers may need a facility to be noticed of service costs priorto customer acceptance and delivery of service.

5.3. Architecture and Components 55

Reversion: The charging architecture should have control about the transactions thatfailed and correctly refunds them as needed.

Access Control: The architecture should provide mechanisms to ensure that contex-tual information may be controlled and made available only to authorized parties.Perhaps, there will have no need to provide the full execution context informationtowards all charging systems, but only part of it.

5.3 Architecture and Components

This section describes the proposed charging architecture, outlining its main entities,data model and protocols. Recall that the approach is by reusing the charging archi-tecture proposed by 3GPP, adding the entities, interfaces and data model required tosupport inter-domain context data. The 3GPP architecture is described in Chapter3 of this document. The style of description commonly used by standards bodies isadopted here. Therefore, 3GPP and the IETF common vocabulary and presentationstyles are used. Such choice aims to enrich the text through a clean, conformant andstandard method.

The service context information must be consistently represented and describedin a common format so the different charging systems can understand it. Additionally,the mechanisms to ensure the handling of service context information should not addmuch overhead to rating processing.

The authors add protocol support for context-awareness and create mechanismsrelated to gathering, modeling, distributing, and monitoring context data. This sectiondetails the techniques related to modeling and distributing.

The description is divided in two planes: services and charging. Although bothare strongly correlated, e.g. they are part of overall context of charging, this divisionis motivated by design aspects and allow us enforce the possibility of adopt differentstrategies to solve the issues belonging to each plane. The first part covers specifi-cally the charging interfaces extensions. The second one covers the services interfacesextensions needed to manage contextual information in the service control level.

5.3.1 Charging Extensions

The charging extensions intend to give the ability to convey inter-domain contextualdata towards rating. The 3GPP charging interfaces were extended in the followingways:


1. Charging functional elements for both modes, e.g. online and offline, remain asthey are in the original 3GPP specifications.

2. Charging interfaces (Ro and Rf ) are modified to carry inter-domain context data.

In 3GPP, information moving towards charging systems is likely conveyed overthe reference points Ro and Rf ( or variations of them ). The Ro and Rf are Diameterapplications and are described in 3GPP TS 32.299 [3GPP, 2009d] . The authors extendsthe reference points above to create two new ones: Io and If. Io and If are also basedon Diameter applications as well. Therefore, the solution is to extend the Diameterprotocol.

According for RFC 3588 [IETF, 2003] the Diameter protocol is designed to beextensible by several manners, including:

1. Defining new AVP values

2. Creating new AVPs

3. Creating new authentication/authorization applications

4. Creating new accounting applications

5. Create new application authentication procedures

The second way, creating new AVPs, was chosen because it can reuse the existing3GPP applications just adding non mandatory attribute-value pairs to the protocol.The authors decided to extend the Ro and Rf interfaces reusing the command codesand adding some non mandatory AVPs to the commands. None new command codewas created in order to support our model. The set of AVPs the authors have proposedwill be part of both online and off-line commands of Diameter applications: ACR/ACAand CCR/CCA. The benefit is that such extension technique ensures interoperabilitywith 3GPP compliant charging systems.

The distribution of context-information towards the rating engines will be per-formed through of two reference points Io and If, created by the extension of Rf andRo. Their names are private in our work and should not be confused with any otherreference point published with the same name.

Io: This reference point carries inter-domain context information towards the onlinecharging system.


If: This reference point carries inter-domain context information towards the offlinecharging system.

As observed in the service composition section, the service chain may be repre-sented as a graph. During the execution of composite service, we need to represent thecomposite service graph within the diameter AVPs. Each entry representing a serviceinvocation needs to have a nodeId and the parent nodeId associated.

As from 3GPP, the following types of accounting requests - based on RFC [IETF,2003] and the DCCA- Diameter Credit Control application [IETF, 2005] - may be sentvia Diameter

1. START session accounting data.

2. INTERIM session accounting data.

3. STOP session accounting data.

4. EVENT accounting data.

As described in previous section, two cases are currently distinguished for offlineand online charging purposes:

• Event based charging

• Session based charging.

Three control scenarios of user credit for online charging are distinguished:

• Immediate Event Charging IEC

• Event Charging with Unit Reservation (ECUR).

• Session Charging with Unit Reservation (SCUR)

The table below summarizes all the commands of online and off-line referencepoints exchanged among the charging entities over the If and Io reference points.

Capabilities-Exchange-Request and Capabilities-Exchange-Answer do not needconvey contextual information. But the format of messages ( ACR, ACA, CCR andCCA ) must be modified. The authors use non-mandatory AVPs (AVPs with the "M"bit not set) to the commands defined above. The remaining AVPs are those presentin these commands according for the 3GPP [3GPP, 2009c]. The AVPs that have been


Table 5.1. Charging Commands under If and Io.

Command-Name Source Destination

Capabilities-Exchange-Request(CER) CTF OCSCapabilities-Exchange-Answer(CEA) OCS CTFAccounting-Request(ACR) CTF CDFAccounting-Answer(ACA) CDF CTFCredit-Control-Request(CCR) CTF OCSCredit-Control-Answer(CCA) OCS CTF

added for the commands are described below. The other AVPs are already describedin their reference documents. AVP codes are suggested values used in our research.

Below, the authors describe the format of messages, e.g. ACR, ACA, CCR andCCA, containing the proposed AVPs in bold face.

The ACR message format is defined according to the Diameter Base Protocol[IETF, 2003]. The AVPs in bold face are those we are adding. The AVP notation isstandard :

<AVP> indicates a mandatory AVP with a fixed position in the message.

AVP indicates a mandatory AVP in the message.

[AVP ] indicates an optional AVP in the message.

*AVP indicates that multiple occurrences of an AVP is possible.

Acounting Credit Request:<ACR> ::= < Diameter Header: 271, REQ, PXY >

< Session-Id >Origin-HostOrigin-RealmDestination-RealmAccounting-Record-TypeAccounting-Record-Number[ Acct-Application-Id ][ User-Name ][ Acct-Interim-Interval ][ Origin-State-Id ]


[ Event-Timestamp ]*[ Proxy-Info ]*[ Route-Record ][ Service-Context-Id ][ Service-Information ][ ID-Charging-Id][ ID-Service-Context-Req-Action]*[ ID-Service-Context-Info]* [ AVP ]

The Accounting Answer (ACA) messages, indicated by the Command-Code fieldset to 271 is sent by the CDF to the CTF in order to reply to the ACR.

The ACA message format is defined according to the Diameter Base Protocol[IETF, 2003] as follows:

<ACA> ::= < Diameter Header: 271, PXY >< Session-Id >Result-CodeOrigin-HostOrigin-RealmAccounting-Record-TypeAccounting-Record-Number[ Acct-Application-Id ][ User-Name ][ Error-Reporting-Host ][ Acct-Interim-Interval ][ Origin-State-Id ][ Event-Timestamp ]* [ Proxy-Info ][ID-Service-Context-Result-Code]* [ AVP ]

The CCR messages, indicated by the Command-Code field set to 272 is sent bythe CTF to the OCF in order to request credits for the request bearer / subsystem/service.

The CCR message format is defined according to 3GPP as follows:<CCR> ::= < Diameter Header: 272, REQ, PXY >


< Session-Id >Origin-HostOrigin-RealmDestination-RealmAuth-Application-IdService-Context-IdCC-Request-TypeCC-Request-Number[ Destination-Host ][ User-Name ][ Origin-State-Id ][ Event-Timestamp ]*[ Subscription-Id ][ Termination-Cause ][ Requested-Action ][ AoC-Request-Type ][ Multiple-Services-Indicator ]*[ Multiple-Services-Credit-Control ][ CC-Correlation-Id ][ User-Equipment-Info ]*[ Proxy-Info ]*[ Route-Record ][ Service-Information ][ID-Charging-Id][ID-Service-Context-Req-Action]* [ID-Service-Context-Info]*[ AVP ]

The Credit-Control-Answer (CCA) messages, indicated by the Command-Codefield set to 272 is sent by the OCF to the CTF in order to reply to the CCR.

The CCA message format is defined according to IETF RFC 4006 as follows:<CCA> ::= < Diameter Header: 272, PXY >

< Session-Id >Result-CodeOrigin-HostOrigin-RealmAuth-Application-Id


CC-Request-TypeCC-Request-Number[ CC-Session-Failover ]*[ Multiple-Services-Credit-Control ][ Cost-Information][ Low-Balance-Indication ][ Remaining-Balance ][ Credit-Control-Failure-Handling ][ Direct-Debiting-Failure-Handling ]*[ Redirect-Host][ Redirect-Host-Usage ][ Redirect-Max-Cache-Time ]*[ Proxy-Info ]*[ Route-Record ]*[ Failed-AVP ][ Service-Information ][ID-Service-Context-Result-Code]*[ AVP ]

The other supported Diameter commands ( ASR, ASA, CER, CEA,DWR,DWA,DPR,DPA,RAR,RAA,STR e STA ) are as described in RFC 3588 andthey are not described here because they are not affected by contextual data.

The Table 5.2 shows the AVPs codes used in the above commands and theircorresponding flag rules. Such codes are just suggested values for our test purposesand they are not registered in IANA. The Vendor-Id field within our AVPs will containthe value 39991.

Table 5.2. AVP Codes.

Attribute Name AVP Code AVP Attributes

ID-Charging-Id 5000 MUST(V)ID-Service-Context-Info 5001 MUST(V)Service-Context-Node-Id 5002 MUST(V)Service-Context-Parent-Id 5003 MUST(V)Service-Provider-Id 5004 MUST(V)Service-Application-Id 5005 MUST(V)Service-Vendor-Application-Id 5006 MUST(V)Service-Additional-Info 5007 MUST(V)ID-Service-Context-Req-Action 5008 MUST(V)ID-Service-Context-Result-Code 5009 MUST(V)


NOTE 1: The AVP header bit denoted as ’M’, indicates whether support of theAVP is required. The AVP header bit denoted as ’V’, indicates whether the optionalVendor-ID field is present in the AVP header. For further details, see IETF RFC 3588.

The AVPs detailed dscription follows:

ID-Charging-Id The ID-Charging-ID AVP ( Inter-Domain Charging Id AVP ) con-tains a global correlation identifier to the transaction among the several servicedomains. This value is unique and is associated by the service broker during thestart of a composite service session.

It has the following ABNF grammar:

<ID-Charging-Id>::= <AVP Header: V, 5000 >

ID-Service-Context-Info The ID-Service-Context AVP (Inter-Domain Service Con-text AVP) is a grouped AVP and carries information about the service context.It may occur multiple times within the same Diameter message.

The ABNF grammar is the following:

ID-Service-Context-Info ::= < AVP Header: V,5001 >

[Service-Context-Id]

[Service-Context-Parent-Id]

Service-Provider-Id

[Service-Application-Id]

[Service-Vendor-Application-Id]

[Service-Additional-Info]

Service-Context-Id The Service-Context-Id AVP contains a unique identifierUTF8String representing a nodeId in service graph structure. This AVP maybe used to link the context information within a graph structure.

Service-Context-Parent-Id The Service-Context-Parent-Id AVP is a pointer for theparent node in the service composition graph.

Service-Provider-Id The Service-Provider-Id AVP contains the identification of en-tity that is offering the service. It may be an identifier allocated by a standardbody. It should hold a public known identifier.


Service-Application-Id The Service-Application-Id AVP contains the identificationof service. This AVP should be used when the application is standardized andthere is an application code registered to it. The AVP is represented in thefollowing standardized format:

application@domain where:

application contains the registered application code and domain is the entity thatregistered the application. For example:

ftp@iana

Service-Vendor-Application-Id The Service-Vendor-Application-Id contains thevendor specific identification to the service that is being charged.

Service-Additional-Info The Service-Parameter-Info AVP carries additional publicinformation about the service that may be useful to context based rating. Itsvalue is organized in value pairs separated by commas:

Service-Additional-Info = PromotionName=Easter,ValidState=Texas

ID-Service-Context-Req-Action The ID-Service-Context-Req-Action is a enumer-ated AVP that indicates the type of action that is to be performed over thecontext information. In statefull charging systems, this AVP could be used topropagate only the minimal information.

- Add - Delete - Replace

That is an enumerated AVP.

ID-Service-Context-Result-Code The ID-Service-Context-Result-Code is a Un-signed32 AVP that indicates the result of action that was performed over thecontext information inside the diameter server.

2001 => The requested action was performed with success.

10001 => No permission to updated context information in the server node

10002 => Context information updated partially

10003 => Unknown ID-Charging-Id

10004 => Context Information could not be updated

10005 => None action performed

The context based charging application does not change the triggers of accountingand control credit messages exchanged, e.g. the semantic model of application, except


for session interim messages. Multiple interim events are likely possible in order todescribe changes to session characteristics (generally termed "change of charging con-dition", e.g. tariff time switch, change of PDP context QoS or change of IMS sessionmedia types), or when certain limits, e.g. time or volume, are exceeded. So changes ofthe domain context will trigger session interim requests.

5.3.2 Service Plane

The previous section describes as context information is conveyed from service entitiesto charging system through AVPs present within the Diameter applications. Firstly,the composition information needs to be built, secondly, it needs be managed throughthe entire life cycle of session because service providers may join to the service chain andcontextual data need be updated. And finally, it is necessary to design mechanismsto share the context information among the several entities that may originate raterequests towards the charging system. There are contextual data flows intra and interdomain and we need to specify their supporting mechanisms. Thus, this section willdescribe how the context information is managed across the service elements.

The main logical functional component introduced in our architecture is the InterDomain Context Management Function (ID-CMF). It is a inter-domain context brokerentity whose main function is to manage the inter-domain information that might beused to charging purposes. More specifically, in our research context, this entity willmanage the information about providers and their services. Basically the functionsthat the ID-CMF will perform are:

1. Receive notifications of context updates from other services entities from internalor external administrative domains

2. Receive subscription requests of interested entities indicating their willing to re-ceive notifications in the occurrence of context updates

3. Exchange contextual information with other ID-CMF and local interested servicesentities

4. Manage the local data repository for multi domain information ( it is out of scopeof this work determine how this could be achieved )

Each service provider domain should contain at least one ID-CMF component,which will be responsible for supporting contextual data exchanges. This ID-CMFcomponent may be located either internally or externally, e.g. a third-party ID-CMF,


for the domain. The ID-CMF can be organized in a federated mode reflecting thearrangements of service providers in a composite service offering. This work does notdictate any configuration of ID-CMF in an administrative domain. However, it requiresthat each ID-CMF contains the entire context information.

The ID-CMF is not required to interact directly with the charging system butit provides inter-domain context information to the entities that will originate thecharging requests. It means that the service context information may indirectly reachthe charging systems and may be used to rate the services. The authors describe thisprocess in details ahead.

The Figure 5.2 illustrates one possible relationship among the ID-CMF entitieswithin a federated provider environment. In this example, all the service providers thatare assuming a broker role contain their own ID-CMF entity. Other service providers donot have an ID-CMF entity in their domain. Service domains that provide an ID-CMFfunctional entity are able to receive notifications of service updates in other domainsand may propagate context updates to interested parties. Domains that do not containan ID-CMF entity in its benefit have limited access to handle context information; itis implementation specific and is out of scope of our work.

ID-CMF ID-CMF

Provider Domain B Provider Domain C

Im Im

Provider D

Provider Domain A

ID-CMF

Provider E Provider F Provider G

Figure 5.2. Federated ID-CMF model.

Once the inter domain contextual information is created it could be transferredto be used for rating purpose. The contextual information is carried over the standardIo and If reference points described in the previous section. ID-CMF does not interactdirectly with the Charging System. However, it provides context information to others


interested parties.The ID-CMF interacts with other entities through the reference point Im, which

we are going to present in this section.The ID-CMF entity is a contextual inter-domain data broker. The Figure 5.3

illustrates the IDMF entity within the 3GPP - PCC Policy and Charging Controlarchitecture. For example, it could provide context information for the PCRF in thePolicy and Charging Control architecture ( PCC ). The PCRF (Policy and ChargingRules Function) may use this data within its policy rules. That could be realized bysubscribing to the ID-CMF entity to receive notifications of contextual information.The interaction with the ID-CMF is performed through the Im reference point. ( theonly interface to PCRF is shown in Figure 5.3 where ID-CMF entity is connected toPCRF entity.)

Gy

Gz

Subscription Profile Repository

(SPR)

Rx

AFSp

Gx

OfflineCharging System (OFCS)Gateway

PCEF

Policy and Charging Rules Function (PCRF)

Online Charging System (OCS)

Service Data Flow Based

Credit Control

Gxx

BBERF

ID-CMF

Im

Figure 5.3. ID-CMF entity in EPC-PCC.

5.3.2.1 The Reference Point Im

The Im reference point is mainly used to:


• Subscribe to Inter Domain Context updates

• Send notifications carrying context information

• Request context information

• Delivery Context-Information responses

• Publish context information updates

The interface is based on Diameter protocol and the authors proposed to createa new Diameter application named Diameter Service Context Application. (The ID-CMF broker would also support an API interface, but it was left out of research scope).According to IETF RFC 3588, a new application is required when a new Diameter usagescenario find itself unable to fit within an existing application without requiring majorchanges to the specification. [IETF, 2003]. The application Diameter Service ContextApplication defines new command codes and adds new mandatory AVPs to the ABNF.

When not described here the procedures and rules follow what is established onDiameter base protocol, RFC 3588. Every command is defined by means of the ABNFsyntax (as defined in RFC 2234 [IETF, 1997], according to the rules in IETF RFC3588 [IETF, 2003].

There is no application registered with IANA, so the application codes, commandcodes, AVP codes, result codes and similars are only suggested values. Let’s keep thevendor id = 39991 and the application id = 33333331.

The command codes for the Diameter Service Context Application are:

Table 5.3. Diameter Context Application Commands.

Command-Name Abreviation Code

Context-Info-Request CIR 300Context-Info-Answer CIA 300Register-Observer-Request ROR 301Register-Observer-Answer ROA 301Context-Info-Notify-Request NCR 302Context-Info-Notify-Answer NCR 302Publish-Context-Info-Request PCR 303Publish-Context-Info-Answer PCA 303

The following symbols are used in the message format definition:

<AVP> indicates a mandatory AVP with a fixed position in the message.


AVP indicates a mandatory AVP in the message.

[AVP ] indicates an optional AVP in the message.

*AVP indicates that multiple occurrences of an AVP is possible.

The AVPs in bold face are those were added for the standards AVPs. In ourcontext, the Diameter Server is the ID-CMF entity.

Context-Info-Request (CIR) Command:The Context-Info-Request (CIR) whose command code is 300 and the ’R’ bit set

is sent by the Diameter client to request Context-Info data from a Diameter Server.Message Format

<Context-Info-Request> ::= < Diameter Header: 300, REQ, PXY,33333331 >

< Session-Id >Vendor-Specific-Application-IdAuth-Session-StateOrigin-HostOrigin-Realm[ Destination-Host ]Destination-Realm[ Originating-Request ]Caller-DomainCaller-Entity*[ AVP ]*[ Proxy-Info ]*[ Route-Record ]

Context-Info-Answer (CIA) Command:The Context-Info-Answer (CIR) whose command code is 300 and the ’R’ bit

cleared is sent by the Diameter server in response to the Context-Info data request.Message Format

<Context-Info-Answer> ::= < Diameter Header: 300, PXY, 33333331 >< Session-Id >Vendor-Specific-Application-Id[ Result-Code ][ Experimental-Result ]Auth-Session-State


Origin-HostOrigin-Realm*[ID-Service-Context-Info]*[ AVP ]*[ Failed-AVP ]*[ Proxy-Info ]*[ Route-Record ]

Register-Observer-Request (ROR) Command:The Register-Observer-Request (ROR) whose command code is 301 and the ’R’

bit set is sent by the Diameter client to register an entity interested in receiving noti-fications of updates in the context information.

<Register-Observer-Request> ::= < Diameter Header: 301, REQ,PXY, 33333331 >

< Session-Id >Vendor-Specific-Application-IdAuth-Session-StateOrigin-HostOrigin-Realm[ Destination-Host ]Destination-Realm[ Originating-Request ]Subscriber-HostSubscriber-DomainSubscriber-EntitySubscription-Filter*[ AVP ]*[ Proxy-Info ]*[ Route-Record ]

Register-Observer-Answer (ROA) Command:The Register-Observer-Answer (ROA) whose command code is 301 and the ’R’

bit cleaned is sent by the Diameter server in response to a request registering an entityas interested in receiving context information updates .

Message Format

<Register-Observer-Answer> ::= < Diameter Header: 301, PXY, 33333331 >< Session-Id >Vendor-Specific-Application-Id


[ Result-Code ][ Experimental-Result ]Auth-Session-StateOrigin-HostOrigin-RealmObserver-Identifier[ Observer-Subs-Expire-Date ]*[ AVP ]*[ Failed-AVP ]*[ Proxy-Info ]*[ Route-Record ]

Context-Info-Notify-Request (NCR) Command:The Context-Info-Notify-Request (NCR) whose command code is 302 and the ’R’

bit set is sent by the Diameter server in order to inform context info changes occurredin the server to the subscribed parties. The diameter server can dispatch the contextif the subscriber filter matches the available context.

Message Format<Context-Info-Notify-Request>::= < Diameter Header: 302,

REQ, PXY, 33333331 >< Session-Id >Vendor-Specific-Application-IdAuth-Session-StateOrigin-HostOrigin-Realm[ Destination-Host ]Destination-Realm[ Originating-Request ]ID-Context-Notif-Type*ID-Service-Context-InfoLatest-Context-Update*[ AVP ]*[ Proxy-Info ]*[ Route-Record ]

Context-Info-Notify-Answer (NCA) Command:The Context-Info-Notify-Answer (NCA) whose command code is 302 and the ’R’

bit cleaned is sent by the Diameter client in response to receive a context-info-notify-request .


Message Format<Context-Info-Notify-Answer> ::= < Diameter Header: 302, PXY,

33333331 >< Session-Id >Vendor-Specific-Application-Id[ Result-Code ][ Experimental-Result ]Auth-Session-StateOrigin-HostOrigin-Realm*ID-Service-Context-InfoContext-Update-Result*[ AVP ]*[ Failed-AVP ]*[ Proxy-Info ]*[ Route-Record ]

Publish-Context-Info-Request (PCR) Command:The Publish-Context-Info-Request (PCR) whose command code is 303 and the

’R’ bit set is sent by the Diameter client in order to inform server that the contextualinformation was updated in that domain.

Message Format

<Context-Info-Notify-Request>::= < Diameter Header: 303, REQ, PXY, 33333331 >< Session-Id >Vendor-Specific-Application-IdAuth-Session-StateOrigin-HostOrigin-Realm[ Destination-Host ]Destination-Realm[ Originating-Request ]Subscriber-DomainSubscriber-Entity*ID-Service-Context-Info*[ AVP ]*[ Proxy-Info ]*[ Route-Record ]


MD-Publish-Context-Info-AnswerThe Publish-Context-Info-Answer (PCA) whose command code is 303 and the

’R’ bit cleaned is sent by the Diameter server in response to the Context-Info-Notify-Request.

Message Format

<Context-Info-Notify-Answer> ::= < Diameter Header: 303,PXY, 33333331 >

< Session-Id >Vendor-Specific-Application-IdAuth-Session-StateOrigin-HostOrigin-Realm[ Destination-Host ]Destination-Realm[ Originating-Request ]*[ AVP ]*[ Proxy-Info ]*[ Route-Record ]

Diameter Context Info Application Result-CodesThe result codes reported by the application follow diameter standard. Below,

the authors describe some of them.

• 1xxx (Informational)

• 2xxx (Success)

• 3xxx (Protocol Errors)

• 4xxx (Transient Failures)

• 5xxx (Permanent Failure)

DIAMETER_SUCCESS 2001The Request was successfully completedTransient FailuresDIAMETER_ERROR_GENERAL_CONTEXT_TEMP_ERROR 4500Permanent Failures


DIAMETER_ERROR_NOT_SUPPORTED_CONTEXT_INFO_DATA 5500The data received by the diameter server is not supported or recognized.DIAMETER_ERROR_OPERATION_NOT_ALLOWED 5501The requested operation is not allowedDIAMETER_ERROR_UNABLE_TO_REGISTER_OBSERVER 5502The observer can´t be registered.DIAMETER_ERROR_CONTEXT_DATA_CANNOT_BE_MODIFIED

5503The context requested user data is not allowed to be modified.DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED 5104The requested user data is not allowed to be notified on changes.

Table 5.4. Diameter Context Application AVP Codes.

Attribute Name AVP Code AVP Flag Rules

Caller-Domain 5000 MUST(MV)Caller-Domain 5000 MUST(MV)Caller-Entity 5001 MUST(MV)ID-Service-Context-Info 5002 MUST(MV)Service-Context-Id 5003 MUST(MV)Service-Context-Parent-Id 5004 MUST(MV)Service-Provider-Id 5005 MUST(MV)Service-Application-Id 5006 MUST(MV)Service-Vendor-Application-Id 5007 MUST(MV)Service-Additional-Info 5008 MUST(MV)Subscriber-Host 5009 MUST(MV)Subscriber-Domain 5010 MUST(MV)Subscriber-Entity 5011 MUST(MV)Subscription-Filter 5012 MUST(MV)Observer-Identifier 5013 MUST(MV)Observer-Subs-Expire-Date 5014 MUST(MV)Latest-Context-Update 50153 MUST(MV)

The AVPs details follow:

Caller-Domain The Caller-Domain AVP contains the network domain of requester.

Caller-Entity The Caller-Entity contains the identity of requester and has free form.

Subscriber-Host The Subscriber-Host contains the host name of subscriber.

Subscriber-Domain The Subscriber-Domain contains the domain of subscriber .


Subscriber-Entity The Subscriber-Entity contains the identity of subscriber.

Subscription-Filter The Subscriber-Filter contains the subscription filter to receivenotifications from domain updates.

ID-Context-Info-Type The ID-Context-Info-Type AVP is a grouped AVP and car-ries information about the service context. It may occur multiple times withinthe same diameter message.

The ABNF grammar is the following:

ID-Service-Context-Info ::= < AVP Header: 5001 >

[Service-Context-Id]

[Service-Context-Parent-Id]

Service-Provider-Id

[Service-Application-Id]

[Service-Vendor-Application-Id]

[Service-Additional-Info]

Service-Context-Id The Service-Context-Id AVP contains a unique identifierUTF8String representing a nodeId in service graph structure. This AVP maybe used to link the context information within a graph structure.

Service-Context-Parent-Id The Service-Context-Parent-Id AVP is a pointer for theparent node in the service composition graph.

Service-Provider-Id The Service-Provider-Id AVP contains the identification of en-tity that is offering the service. It may be an identifier allocated by a standardbody. It should hold a public known identifier.

Service-Application-Id The Service-Application-Id AVP contains the identificationof service. This AVP should be used when the application is standardized andthere is an application code registered to it. The AVP is represented in thefollowing standardized format:

application@domain where:

application contains the registered application code and domain is the entity thatregistered the application. For example:

ftp@iana


Service-Vendor-Application-Id The Service-Vendor-Application-Id contains thevendor specific identification to the service that is being charged.

Service-Additional-Info The Service-Parameter-Info AVP carries additional publicinformation about the service that may be useful to context based rating. Itsvalue is organized in value pairs separated by commas.

Service-Additional-Info = PromotionName=Easter,ValidState=Texas

Observer-Identifier The Observer-Identifier AVP contains a unique identifier for theregistered observer.

Observer-Subs-Expire-Date The Observer-Subs-Expire-Date informs the subscrip-tion expiration date.

Latest-Context-Update

This AVP informs the more recent date/time that the context was updated inthe server node.

An example of ID-CMF flow in IMS service environment is described below. TheFigure 5.4 ilustrates this sequence.

1-) AS registers with the ID-CMF to receive context notifications2-) ID-CMD sends a response to the register observer request3-) Service Broker publishes the current context data in ID-CMF4-) Service Broker receives the response from ID-CMF5-) ID-CMF notifies the AS about the new context6-) AS sends the response7-) Service Broker sends the SIP Invite8-) S-CSCF sends the SIP Invite for the AS9-) AS sends a reservation request for Online Charging System10-) OCS answers the credit reservation request11-) AS answers the SIP Invite12-) Invite response reaches Service-Broker13-) Service Broker invokes a service in another provider ( context change )14-) Service Broker publishes a new context data in ID-CMF15-) The ID-CMF sends the PCA16-) AS is updated with new context data17-) AS answers the request18-) Reservation is updated in Online Charging System


Service-Broker ID-CMF S-CSCF IMS-GWF/ASOCS

1-ROR

2-ROA

3-PCR

4-PCA

5-NCR

6-NCA

7-INVITE

8-INVITE

9-Reserve Unit Request

10-Reserve Unit Response

11-200 OK (Invite)

12-200 OK (Invite)

13-Invoke third-party service

14-PCR

15-PCA

16-NCR

17-NCA

18-Reserve Unit Request (update)

19-Reserve Unit Response (update)

Figure 5.4. Example of Diameter Context Application.

19-) Get the reservation response from OCS

5.4 Conclusion

In this chapter, the authors explored the advanced charging mechanisms for enhancing3GPP charging. Initially, a general reference scenario that is representative of a coupleof business models was described; it covers different service providers roles. Then, theproposed changes that rely on Diameter extensions were outlined. Basically, two sortof extensions were proposed:

5.4. Conclusion 77

1. Aggregate non mandatory AVPs in charging system interfaces

2. Provide a context broker, which is a logical entity supporting a new Diameterapplication based on subscribe/notify event model

In the next chapter, a case study is presented.

Chapter 6

Case Study

This chapter presents a study of case to our research. It is organized in the followingparts: Section 6.1 describes the objectives and metrics suitable in case study, Section6.2 gives a short overview concerning implementation, Section 6.3 outlines the differ-ent run scenarios, Section 6.4 presents the analisys of results, and last section bringscomplementary analysis.

6.1 Objectives

The authors consider that the objective of the research is acomplished whether:

1. The charging model is supposed be interoperable and conformant to 3GPP charg-ing implementations.

2. The model requirements are achieved.

The use case analysis must give support to evaluate the above items.

6.2 Scenario

In order to perform the case study, the authors designed a purpose specific applicationscenario. It encompasses two parts:

1. Service scenario, which simulates a number of providers, their correspondingservices, and service transactions ( user level ).

2. Charging application,e.g., the extended online charging interface and the chargingcontext application

79

80 Chapter 6. Case Study

The service scenario intends to represent the reference scenario previously de-scribed. The objective is to capture its main characteristics. Our assumption is that,even in lack of complete test environment, it is possible through purpose specific ap-plication to perform a functional preliminary validation.

The service scenario is illustrated in the Figure 6.1. It groups a number of servicesfrom different domains. The objective is to address the needs of tourist and travelers.In the figure, the Master Broker entity aggregates different categories of providers :communications, content and services. Each one of these providers may rely on othersproviders to delivery their services. So, in such scenario, exist elementary servicesproviders and service brokers.

Communicati

on Provider

Facilities

Provider

Car Rental

Fly

Reservation

Hotel Booking

Content

Broker

Services Facili

Music/Video Sport News

Master

Broker

Figure 6.1. Roles represented in validation scenario.

Content Broker : Aggregate some content providers, which provide video, musicand news services. The contents are exposed via API. The content providers relyon Content Broker to charge their services.

Facilities Provider : It groups providers of basic facilities. It has collaboration witha Car Rental company, a Hotel Broker and a Fly company. There is no chargesystem. Its services are charged by the Master Broker.

6.2. Scenario 81

Communication Provider : Provides basic communication capabilities such asvoice, messaging and presence over an IMS environment. The services are ex-posed through IMS/SIP and it own charges its services.

For each provider, a number of services and their rating rules and policies areconfigured in application. The Table 6.1 brings a shape how the things are configured.

Table 6.1. Service Configuration Example.

Role Service/Content Rate Rules

Communications Provider IM $0.20 per IM, 10% discount for partnersHotel Broker Hotel Class C $70.00 5% discount for partnersHotel Broker Hotel Class B $90.00Car Rental Midsize $60.00

In order to exercise the services, two actors were proposed: Bob and Alice. Sup-pose the World Cup Soccer is starting in Brazil. Bob has arrived three days ago andAlice has just arrived. Alice must book rooms, to rent a car and to buy some fly ticketsto the cities where she intends to watch the soccer games. Bob has been in the worldcup initial games and would like share some content with Alice.

We are interested in charging aspects so we will assume for the sake of simplicitythat both actors are already subscribed to the service broker. We also are assumingthat Alice and Bob have no direct access to the elementary services, i.e. they are notaware of the different providers present in the service chain. Such assumptions aresupposed to be the predominant scenario in service composition. Thus, Alice is goingto perform the following activities:

• Exchange instant messages with Bob

• Acquire the basic services necessary for your stay:

• Book the hotel

• Rent a car

• Acquire fly tickets

• Get some content related to the world cup

Figure 6.2 illustrates the typical sequence of transactions performed by Alice.In this figure, the authors have opted for representing only the service invocations.Additional messages were omitted to get a clean shape. Its purpose is just to provide


a common view about the service usage performed by Alice. There is no intentionto present the details. So the portion regarding the exchange of Diameter ContextApplication messages was omitted because they are identical for all scenarios. Eachfigure that presents a scenario is self-described. Service requisitions may be slightlydifferent within each run scenario. Additional configuration information that is notcommon among the cases will be appropriately described. The diagram traces theservice invocation flow among Alice, service brokers and providers.

Alice Com Provider Facilities Content Provider

Hello Greetings Message to Bob

Master broker

Invoke Com Provider IM

Alice starts session to acquire services

Alice reserve fly

Fly Reservation

Alice rents a car

Car Renting

Alice books the hotel

Hotel Reservation

Alice sends IM to Bob


Acquire Subscribe to News Services

News Subscription

Acquire Content

Content Purchase

Alice closes session

Ready Message to Bob


Figure 6.2. General service usage flow within validation scenario.

6.2.1 Implementation Overview

This section brings some few comments concerning how the implementation was per-formed. The objetive is not to describe each detail but only provide a general overview.

6.2. Scenario 83

The authors implement different roles to build the composite service application. TheTable 6.2 presents the entities in the implementation. It describes the name of actor,its role, the services it provides and the rating rules. Each entity is represented by anapplication.

Table 6.2. Entity Roles.

Actor Role Services Rules

SeaServices MasterBroker Aggregate Sev-eral

Aggregated charge

CommMut CommunicationProvider

Instant Message Charged per Unit - EachMessage costs 0.20 . If mes-sage is originated per News-World provider gives a 10%discount. If message is orig-inated by EnjoyWorld theprovider gives a 15% dis-count

EnjoyWorld Facilities Broker Several - Aggregated Charge - Ifthe flys company is SkyBlueand hotel is LiveHere thentotal discount is 15%

FlyFar Airline Fly Reservation Charged by Fly ClassLkHome Hotel Broker Hotel booking - Charged by Room Class. -

If Fly is by FlyFar discount= 2%

GoFar Car Rental Car Rental Ser-vices

- Charged by car class If Flyby FlyFar discount = 2%

Virgis Content Broker Music, Videoand News Deliv-ery

Aggregated Charging.Gives 1% discount for simi-lar contents ( same subject)

FineContent Music and VideoProvider

Music and Video Charged by item

NewsWorld NewsProvider News Services Charged by Item

Each service provider exposes a set of services. These services are invoked incharging flow performed by the actors. Table 6.3 presents the content in the ContentProvider. Table 6.4 presents the services in the Facilities Provider. Table 6.5 presentsthe enablers in the Communications Provider.

Basically, the implementation covers two kind of applications:

1. The service provider applications that expose basic services through simple APIs.


Table 6.3. Content Provider - Content List.

Content Description Rate Rule

Music - "World Cup Theme" Id = 001; Desc: MusicTheme World SoccerCup; Category: M-A1

RateType = M-1;Standalone Price: 0.5

Music - "Brasil Single 2014" Id = 002; Desc: Mu-sic Theme for Cup´sTeams; Category: M-A2


Music - "England Single 2014" Id = 003; Desc: Mu-sic Theme for Cup´sTeams; Category: M-A2


Video - "Rio de Janeiro’s Tour" Id = 004; Desc: Citiesvídeo - Rio de Janeirocity; Category: V-A1

RateType = V-3;Standalone Price:1,20

Video - "Brasil X England" Id = 005; Desc:Games Video - BrasilX England; Category:V-A2


Video - England X Italy" Id = 006; Desc:Games Video -England X Italy;Category: V-A2


2. The Diameter Context Application.

The Figure 6.3 ilustrates as the broker correlates to service providers. In suchfigure, Simple APIs are purpose specific ones related to service access, and containcontext and charge data.

For example, an API method is similar to:

reserveHotelRoom( hotelName, roomClass, context, charge );

The others APIs implement the Diameter Context Application, and a simpleDiameter Charging Interface.

For designing the diameter application, a diameter development toolkit was used.

There are five scenarios described. For each one of them there are two sub cases:the first one for elementary rating, the second one for context based rating. They coverthe most fundamental charging transactions in 3GPP online charging model. In thecorresponding figures, we only represented the scenario carrying context data. Thefigure describes the general invocation model and not brings all details.

6.2. Scenario 85

Table 6.4. Facility Provider - Services.

Content Description Rate Rule

Hotel - "Ib4" Id=001; Desc: Ib4 Ho-tel; Category:H-D1

RateType = H-1;Standalone Price:60,00

Hotel - "Soft" Id=002; Desc: SoftHotel; Category:H-A2

RateType = H-2;Standalone Price:120,00

Car - "Small" Id=003; Desc: SmallEconomy Cars;Category:C-A1

RateType = C-1;Standalone Price:40,00

Car - "Midsize" Id=004; Desc: Mid-size family cars;Category:C-B1


Car - "Offroad" Id=005; Desc:Offroad cars;Category:C-E1


Fly - "BH - Rio - BH" Id=006; Desc: FlyBH-Rio; Category:F-A1

RateType = F-1;Standalone Price:120,00

Fly - "BH - Manaus - BH" Id=007; Desc:Fly BH-Manaus;Category:F-A1

RateType = F-2;Standalone Price:240,00

Tour - Rio Id=008; Desc: Pack-age Tour to Rio;Category:T-A1

RateType = T-1;Standalone Price:200,00

Tour - Manaus Id=009; Desc: Pack-age Tour to Manaus;Category:T-A2

RateType = T-2;Standalone Price:320,00

Table 6.5. Communication Provider - Enabler Services.

Enabler Description Rate Rule

Instant Message Id=001; Desc: In-stant Message ServiceCategory:IM-A1

RateType = IM-1;Standalone Price: 0,3

6.2.2 Scenario 1: Immediate Event Charging (IEC)

Purpose: Evaluate event charging in the presence of contextual information.

Description: This is the basic scenario. The providers charge the services by event.There is no credit reservation and no charging session. This is illustrated in


Broker

Service

Provider

Sevice

Provider

Service

Provider

Diameter Interface: Context API and DCC

Simple API

Simple AP

I

Figure 6.3. Implementation Model.

Figure 6.4 where service invocation is performed together with charging.

During the user session with the master broker, multiple IEC transactions can beperformed. The inter-domain context information is being built at each service invo-cation. Then IEC transactions can receive partial context data and present differentresults depending on the order that the service was invoked by the user. For example,if step two (2) is repeated after the four (4) the service can have a new value. So,depending on service semantic, the final session cost must be adjusted by the servicebroker in the presence of full context data as in Figure 6.5; in such figure, the calls11,12 and 13 are adjustments transactions performed at end of session. Therefore, forcoping with this kind of issue is necessary either to have the subscriber aware of pricerules of service or to have a two-phase mechanism to adjust the charges.

6.2.3 Scenario 2: Event charging with unit reservation

(ECUR)

Purpose: Evaluate context charging in the context of reservation.

Description: Bring the context information for a scenario of reservation. In thisscenario the reservation ensures there are user credits available until that theservice be delivered.

6.2. Scenario 87

Alice Master Broker Com Provider Facilities Content Provider

1-Start Session

2-Acquire Content

6-Purchase facilities ( Direct Debit - Context B)

9-Send Message(Direct Debit - Context C)

11-Close Session

4-Response

7-Response

3-Acquire Content ( Direct Debit - Context A )

5-Purchase Facilities

8-Send Message

Context data changes

during calls

No State for DD transactions

Response brings charges

and result codes

10-Response

Aggregate Final Charge

Figure 6.4. Validation Scenario IEC.

For reservation based scenarios the information about the context that was beingbuilt during service usage can be used to update the reservation in the final of brokersession. That will assure that service usage can be correctly adjusted at end of a sessionat time of reservation termination. This will ensure that the potential issue of partialcontext of IEC does not occur. This scenario is described in Figure 6.6; during the firstservice invocation the reserve is created and at end of session the reserve is updatedand commited as ilustrated.



1-Start Session

2-Acquire Content


9-Send Message( Direc Debit - Context C)

14-Close Session

4-Response

7-Response



8-Send Message


during calls

No State for

direct debit transactionsResponse brings charge

recods and result codes

Additional Transactions occurs here.

Context Changes and charges

are adjusted

11-Adjust ( Commited Context )



10-Response

Figure 6.5. Validation Scenario IEC with adjust.

6.2.4 Scenario 3: Advice of Charge

Purpose: Evaluate advice of charge supplementary service in the context based charg-ing

Description: Analyze the advice of charge method in the inter-domain context basedrating. The advice of charge is used to give the subscriber either an estimate orthe value total of service.

The price enquiry request is sent through price lookup request in diameter creditcontrol application. In this case, neither checking of the account balance nor reservationwill be done; only the price of the service will be returned.

The Price Lookup transaction is an IEC - Immediate Event Charging transaction.Therefore it shows the same behaviour that the scenario 1. The price of service willdepend on current contextual information. This scenario is illustrated in Figure 6.7;

6.2. Scenario 89


1-Start Session

2-Acquire Content

6-Purchase facilities ( Reserve - Context B)

9-Send Message(Reserve - Context C)

14-Close Session

4-Response

7-Response

3-Acquire Content ( Reserve - Context A )


8-Send Message


during calls

State Related to reservation

is kept on CSResponse brings reservation id

and result codes

10-Response


11-Commit Reservation( Context)



Figure 6.6. Validation Scenario IEC with reservation.

in the second invocation of price lookup in the step fourteen (14), a different cost maybe returned for the service. This is not a problem because a cost estimation is allowedon standard charging by 3GPP.

6.2.5 Scenario 4:Refund

Purpose: Analyze the refund scenario in the context based charging

Description: Refund actions may be triggered as result of any service provider notbe able to deliver some service after user has been already charged.



1-Start Session

5-Acquire Content



15-Close Session

7-Response

10-Response



8-Send Message


during calls



and result codes

12-Response


2-Price Lookup X

3-Price Lookup X( Context A)

4-Response

13- Price Lookup X

14-Price Lookup X ( Context C)

This returns a different

price that first query

Figure 6.7. Price Lookup Validation Scenario .

Refund is an IEC - Immediate Event Charging transaction, which indicates toincrease the end user’s account according to information specified in the Requested-Service-Unit AVP,e.g. the value the subscriber payed for the service. Refund is il-lustrated in Figure 6.8; in the step eleven (11) the service is refunded, and in twelve(12) and thirteen (13) the adjust of dependent transactions from other providers isperformed.

The refund request carries the context information present into the current ses-sion, which is not necessary the same previous context used during the service ex-ecution. The failed transactions are tracked through the transaction identifiers soinitial service cost can be correctly got from charge data records. The recorded origi-

6.2. Scenario 91


1-Start Session

2-Acquire Content



14-Close Session

4-Response

7-Response



8-Send Message


during calls



and result codes

10-Response

Content Delivery Failed - Refund

11-Refund Content X (Direct Debit - Context C)

12-Adjust Charge (triggered by refund X )

13-Adjust Charge ( triggered by refund X )

Figure 6.8. Validation Scenario for Refund.

nal context-data is available to be sent through the refund transaction, that gives theflexibility for service provider applies a charge different from the original one.

Notice that other services would have got discounts based on presence of failedservice in the context data. If these services still are part of active charging sessionsthen interim charging requests need be sent to adjust the service cost ( account balance/reservation ). Otherwise, refund actions are required; for this case charging records areused to correlate the services in recovery routine.


6.2.6 Scenario 5: Session Charging with Unit Reservation

(SCUR)

Purpose: Analyze the session with unit reservation charging

Description: Bring the context information for a scenario of sessions with reservation.In this scenario the reservation ensures there are user credits available until thatthe service be delivered.

Context information can be updated during the service session and the currentreservation is updated accordingly as well. That is ilustrated in Figure 6.9; the sessioncreated in step nine (9) is updated in steps eleven (11) and twelve (12).

6.3 Analysis of Results

In this section, the authors analyze the results by verifying the solution upon theperspective of some criteria:

1. The charging model is supposed to be in conformance and to be interoperablewith 3GPP charging.

2. The requirements outlined in the earlier chapter are achieved.

6.3.1 Conformance and Interoperability to 3GPP Charging

Model

The authors must ensure that the proposed mechanisms keep the charging architectureconformant and interoperable with 3GPP charging model. Conformance does meanthat the model adheres to the specification. It may be allowed some change but itneeds to keep the similarity. Interoperability is the ability of a system or a productto work with other systems or products. In our context, it means to operate a servicecomposition scenario mixing context-enabled and standalone charging.

The analisys is based on two changes the authors have proposed to 3GPP chargingmodel:

1. Two new interfaces If and Io based on those Rf and Ro; these new interfaces areidentical to Rf and Ro except they bring some non mandatory AVPs to diametermessages. A diameter implementation that adds arbitrary non-mandatory AVPsis not defining a new application. This means that 3GPP implementation that

6.3. Analysis of Results 93


1-Start Session

2-Acquire Content


9-Send Message(Create Session - Context C)

13-Close Session

4-Response

7-Response



8-Send Message


during calls



and result codes

10-Response


Other transactions

11-Update Session ( Context D )

12-Terminate Session ( Context D)

Figure 6.9. Validation Scenario for Session with Unit Reservation.

does not know these AVPs would accept diameter commands and discards theAVPs that are not recognized by them. From these arguments, the new interfacesremain in conformance and interoperable with 3GPP.

2. A new functional entity ID-CMF,Inter-domain context management func-tion,added to PCC architecture.The inter-domain Context management functionis a distinct functional element supporting the Diameter Context Application.All the other elements of PCC architecture remain the same. If a charging im-plementation does not support this application so it can just "ignore", disablingcontext propagation, and working via standalone charging through elementary


3GPP diameter applications.

6.3.2 Requirements Fulfillment

In this section, the authors analyze each one of requirements to verify if the proposedsolution achieves the objectives. A brief description of functional requirements is given,so the explanation about how each one has been accomplished. For a complete require-ments description refer to Chapter 4.

Autonomy: Each elementary service provider in service chain should be able to man-age the rating scheme ( rules, etc ) of elementary service belonging to it.

In our charging model, this requirement is achieved by propagating the inter-domain contextual data towards each service provider domain. The contextualdata reaches the charging system conveyed by Diameter through the proposeddiameter interfaces. Therefore, each service provider has access for all contextualinformation need to rate the service, e.g., it does not require to rely on servicebroker to perform contextual rating. The service provider remains the completecontrol of rating elements, e.g. rules, schemes, policies, and so it has autonomyto rate their provided services.

Confidentially: Keep confidential the private rating stuff without that that obstructsthe overall rating of composite service.

This requirement is achieved in similar ways that the previous one. The contex-tual inter-domain data is distributed for the charging elements and so the serviceprovider has all the elements that could be used for rating. Therefore, the privaterating stuff does not need be disclosed for third-parties like service brokers andother entities. Tariff class and cost information are not confidential and could beinformed through the suitable Diameter fields.

Abstraction/Flexibility: The model chosen to present services to subscriber shouldnot add any constraint to the charging architecture.

In the proposed charging architecture, there is anything that would limit themodel that the subscriber uses to pay for the services. Elementary serviceproviders are able to generate their individual charges. Service brokers collectthe individual charges from the elementary providers and could correlate andaggregate them to produce a final one.

Thus, customer could choose either to receive individual or aggregate charges .

6.4. Additional Considerations 95

Context Information: The charging model should provide means to carry contextualinformation.

In Charging level, the context information is carried over non mandatory diam-eter AVPs. Within the service domain, a diameter application that supports tocarry context data was defined . Dynamically contexts changes may be pub-lished to the ID-CMF. They are propagated for interested parties through of thesubscribe/notify paradigm.

Traceability: Be able to correlate different charge records generated through the dif-ferent service domains.

The model contains a general inter domain transaction identifier. This is a globalinter domain correlation identifier that can be used to correlate the distributedcharges records through the entire service chain.

Transparency: Support to advice of charge supplementary services.

Advice of charge mechanisms are supported in the platform through IEC trans-actions as described in the validation scenario.

Reversion: Support for refund transactions.

Refund actions are supported in the platform through IEC transactions. Referto the case presented in the validation scenario.

Access Control: Provided some basic support to control access for context data.

A type of access control for context information may be implemented based onsubscriber identities. In order to get the context information is necessary supplythe identity. The ID-CIM entity could rely on this identification in order toattribute the right privileges for the controlled data. It is implementation specifichow such mechanism would operate.

6.4 Additional Considerations

6.4.1 Performance Analysis

It is very important to ensure that the proposed solution does not add a high overheadto the charging system. However, it is out of scope of work to develop a performancemodel to 3GPP charging. Therefore, the authors are going just to point how theperformance would be affected.


There are 2 metrics : size and number of exchanged diameter messages. Theyare briefly evaluated in the context of inter-domain context management, e.g. sub-scribe/notify/publish messages, and in the context of charging, e.g. accounting andcredit control messages.

Message Size : for the charging context, the introduced AVPs were described in theTable 5.2. They are basically AVPs of primitive types, and they are not supposedto add a high overhead to the message size. The message size would increase asresult of number of services within of service chain. However, the services thatcomprise a service chain are likely either constrained by business agreements or bysoftware integration interfaces so a high number of elementary services within thecomposition should not be expected. The analisys for the context managementroutines is quite similar because the introduced AVPs are in the same category.

Number of Messages : in respect for the number of messages exchanged, there arenew events that trigger diameter messages: for example, composite service chainupdates and refunds. If a service joins or leaves the chain so updating notifi-cations need to be disseminated to all subscribed entities. Additionally, activecharging sessions will needed be updated through interim diameter requests. Re-fund scenario may trigger IEC messages for different providers.

For further investigation, a model similar to the proposed by Lee and others [Leeet al., 2009] could be applied. They developed a model for evaluating performancesignaling overhead in 3GPP - Policy Charging and Control architecture. In their pro-posal, they take into account a couple of event triggers for the PCC/OCS signaling.Therefore, the context change trigger could be added to the model.

6.4.2 Composition Model

The charging model requires that contextual data be disseminated among the differentadministrative domains. Within the service broker, this requires that the control planeallows inserting the mechanisms necessary to transfer the context data, i.e., it shouldbe able to invoke the Diameter Context Application commands. In our proposal, theID-CMF entity is responsible for managing the context at different domains. Althoughaddressing control mechanisms in broker composite models is beyond of research scope,the authors discuss some aspects that deserve consideration.

The inter-domain contextual information needs be disseminated in synchronywith the service usage because the charging system must have access for this informa-tion in authorizing the service. This means that contextual data need to be available

6.4. Additional Considerations 97

for the administrative domain either before or during the initial credit request. Howthis is performed will depend on service composition techniques that are used by servicebroker. Recall that the Chapter 2 discussed commonly used composition techniques.Two examples regarding how the synchronization between service and context transfercould be achieved were given.

API based composition In this technique, the initial context transfer could be per-formed during the connection negotiation among the administrative domains.During this phase, the reference for the entity that holds inter-domain contextdata is got and the current context data could be sent to the new administrativedomain.

Protocol Based Composition Protocol oriented interactions are event driven andthe interactions may happen directly among the services and the orchestratormay not be aware. Providing means to insert application specific mechanismscan be bit more trick because protocols are likely closed and may have limitedsupport. In situations that is not possible insert diameter support during theservice composition so may be needed to opt by more complex mechanisms em-bedded into the protocol to carry specific data.

The objective of this analysis is highlight the fact that different compositiontechniques may require different mechanisms to insert the diameter support necessaryto disseminate the context information among the administrative domains.

Chapter 7

Conclusion

Services acquired fundamental importance in the modern economy. In the mobile com-munications segment, there are a number of innovative services built over data-basedapplications. The recent launching of mobile application stores changed the shape inmobile industry. According to a TMForum Report, application stores brought a newwave of disruptive change to the mobile applications market [TMForum, 2010]. Newbusiness scenarios continue emerging and through of different categories of partnershipsthey aim for designing rich and innovative services. In communications and internetfields, a number of research efforts have addressed the problem of designing open ser-vices frameworks. Standardization bodies as well as industry, and academia have leadthese initiatives. In our research, we have described some them by OMA, ITU and JavaCommunity Process. Other research initiatives like DBE Digital Business Ecosystem[DBE, 2007], SPICE - Service Platform for Innovative Communication Environment[SPICE, 2006], NEXOF Nessi Open Service Framework [Nessi, 2009] have a sameambition addressing the problem of designing, developing and putting into operationefficient and innovative open service frameworks.

The composition of services is a central functionality in most of the emergingopen service platforms. Service composition is a technique to design services by reusingservice components. It has acquired fundamental importance in the efficient deliveryof advanced mobile applications built by merging communication capabilities exposedby communication service providers within information technology applications. Theresearch motivation was in exploring advanced charging mechanisms to support servicecomposition in next generation open services platforms. Charging is the process bywhich resource consumption is accounted and rated. Likely, the standard chargingsystems do not take into account the fact that the service can be being used in thecomposite context. Therefore, the authors objective was to enhance the 3GPP standard

99

100 Chapter 7. Conclusion

charging model to benefit from composition information in order to support differentbusiness relationships through advanced rating rules.

In more details, the research proposed to extend the 3GPP standard chargingmodel to cope with inter-domain service-based data. Basically, inter-domain contex-tual data is disseminated across domains and charging systems enabling contex-basedcharging. The most of research efforts in the literature do not address the problem inthe way the authors propose. The solution manages and disseminates context data sincethe service control plane until the charging entities at different domains. An adaptedcharging interface able to carry contextual data and a functional context broker entity(ID-CMF) hosting a diameter application to context management are suggested. Thesolution is founded in 2 points:

1. The ability to extend the Diameter protocol

2. The ability to add a functional entity supporting the diameter application into3GPP charging model

Functional requirements were defined and validated through a purpose specificapplication that captures a representative scenario of the inter-domain business servicecomposition. The objective was to represent different application domains and chargingcapabilities within the service actors. Basically, contents and services were instantiatedwithin each service provider, rating rules were designated and relevant rating scenarioswere performed.

The results suggest that the extensions proposed for the charging diameter inter-faces and context broker application are suitable to achieve functional requirements.Additionally, they show that charging systems that wish to benefit from contextualinter-domain data could adopt the following strategy:

1. Provide support for process application specific non-mandatory AVPs in theirdiameter charging accounting applications

2. Deploy a new functional component supporting the diameter context applicationwithin the charging system

The analysis of results showed that when working with some charging scenariosin the category of IEC (Immediate Event Charging) is need to take care of semanticconsiderations in the service price model. This is resulting of the volatile nature ofcontext information and of the one phase transaction method. Contextual data willchange during a service session, therefore IEC transactions might return different tariffs

101

for a service item in consequence of distinct partial context information present whenthe IEC transaction is performed. That is not a complex problem as long as theservice model and price semantic is well defined. Anyway, session or reservation basedscenarios are other means to cope with the issue.

Charging for composite services is a large research subject. In this work, theauthors address part of problem related. There are a number of different approaches forservice composition as well as a number of charging scenarios and flows related to mobileservices. It is difficult define a formal model and a precise scope that could be valid forall service architectures. Even the 3GPP publishes charging specifications organized bydomain. The authors opted for focusing in a common charging architecture, providingthe basic elements to support more advanced contextual charging in different servicesdomains.

7.0.3 Future research

The authors have identified a number of additional activities that could improve thequality of research. In this section, the authors enumerate some of them :

Service composition modeling: For representing service data the authors could optfor using service ontology. Ontology provides a vocabulary of terms and the re-lations between them in order to model a domain [Villalonga et al., 2009]. Aservice’s ontology aims to reach a shared and accepted view of service chainingamong the charging components. Ontology has been already used in the litera-ture within context based charging. Bormann and others have defined a commonontology that can be shared among context aware end user services to performcontext-aware charging [Bormann et al., 2009]. Spice project has developed anontology to the exchange of data among the elements of its platform. Similar on-tology could be used within our research. That would bring a more standardizedbase to exchange service data.

Performance analysis: Performance is a critical attribute for charging systems. Theproposed changes could introduce some performance penalties for the entirecharging system. Although the authors have done some important considerationsregarding the implications of a context application within system performance, itcould be more valuable if a detailed performance model to evaluate the solutionhad been developed. This is a future matter to enhance the research.

Validation Scenario: The authors would like to have worked about more complexvalidation scenarios. However, mobile charging systems based on 3GPP are typ-

102 Chapter 7. Conclusion

ically proprietary and it is very hard to develop one for validation purposes dueto the large number of interfaces. So the authors opted by implementing onlythe Diameter Context Application and the online charging system diameter in-terface. The authors look to use a testbed in their research. A testbed is aplatform for experimentation of large development projects. Testbeds allow forrigorous, transparent, and replicable testing of scientific theories, computationaltools, and new technologies. The authors found none public 3GPP EPC testbed.Only commercial 3GPP EPC products, whose license costs are very expensive.

Explore Service Domain Dependencies: Finally, in the future work, the authorswill explore in more details the charging mechanisms over different service do-mains. The idea is explore better the dependencies existing among the servicecomposition methods and the charging model aiming to provided a more formaldefinition of the capabilities that a service platform should provide for enablingcomposite service charging. e.g. explore the service mechanisms to pass informa-tion about the ID-CMF identities.

Bibliography

3GPP (2008a). Tr 23810 - study on architecture impacts of service brokering.

3GPP (2008b). Tr 23.810 study on architecture impacts of service brokering.

3GPP (2008c). Ts 22.101 service principles.

3GPP (2008d). Ts 22.115 charging and billing.

3GPP (2008e). Ts 23078 - customized applications for mobile network enhanced logic(camel).

3GPP (2008f). Ts 32.240 charging architecture and principles.

3GPP (2009a). Ts 23.203 policy and charging control architecture.

3GPP (2009b). Ts 23.228 - ip multimedia subsystem (ims).

3GPP (2009c). Ts 32.296 online charging system (ocs): Applications and interfaces.

3GPP (2009d). Ts 32.299 diameter charging applications.

Agarwal, M., Karnik, N., and Kumar, A. (2003). Metering and accounting for com-posite e-services. In Proceedings of IEEE International Conference on E-Commerce,pages 35–39.

Alliance, O. M. (2009). Oma service environment.

Ankolekar, A., Burstein, M., Hobbs, J., Lassila, O., Martin, D., McIlraith, S., andNarayanan, S. (2001). Daml-s: Semantic markup for web services. In Proceedings ofInternational Semantic Web Working Symposium.

Balke, W.-T. and Diederich, J. (2006). A quality- and cost-based selection modelfor multimedia service composition in mobile environments. In Proceedings of theInternational Conference on Web Services, pages 621–628.

103

104 Bibliography

Bhushan, B., Gringel, T., Ryan, C., Leray, E., de Leastar, E., and Cloney, J. (2002).Federated accounting management system architecture for multimedia service usagemanagement. In Proceedings of Management of Multimedia on the Internet, pages12–24.

Blum, N., Boldea, I., Magedanz, T., Staiger, U., and Stein, H. (2008a). A servicebroker providing real-time telecommunications services for 3rd party services. InProceedings of the IEEE International Computer Software and Applications Confer-ence, volume 2, pages 85–91.

Blum, N., Magedanz, T., and Schreiner, F. (2008b). Services, enablers and architec-tures: Definition of a connected web 2.0 / telco service broker to enable new flexibleservice exposure models. In Proceedings of the International Congress on InteligentNetworks.

Bond, G., Cheung, E., Fikouras, I., and Levenshteyn, R. (2008). Unified telecom andweb services composition:problem definition and future directions. In Proceedings ofthe International Congress on Inteligent Networks.

Bormann, F., Flake, S., and Tacken, J. (2009). Convergent online charging for context-aware mobile services. In Proceedings of International Conference on Advanced In-formation Networking and Applications Workshops.

Bucchiarone, A., Polini, A., Pelliccione, P., and Tivoli, M. (2006). Towards an architec-tural approach for the dynamic and automatic composition of software components.In Proceedings of Workshop on Role of Software Architecture for Testing and Anal-ysis, pages 12–21.

Casati, F. and et. al (2000). eflow: A platform for developing and managing compositee-services. In HP Labs Technical Report.

Cuevas, M., Abhayawardhana, V., Crowther, M., Crane, P., Brandt, M., OConnell, J.,and Penkler, D. (2008). Using service orchestration to create integrated services innext generation networks. In Proceedings of the British Telecom Technology Journal.

DBE, F. P. (2007). Digital business ecosystem architecture.

Dinsing, T., Eriksson, G. A., Fikouras, I., Gronowski, K., Levenshteyn, R., Petters-son, P., and Wiss, P. (2007). Service composition in ims using java ee sip servletcontainers. In Ericsson Review.

ETSI (2006a). Open service access (osa); parlay x web services; part 6: Payment.

Bibliography 105

ETSI (2006b). Open service access (osa); parlay x web services; part 7: Accountmanagement.

Fielding, R. (2000). Architectural styles and the design of network-based softwarearchitectures. Doctoral dissertation, University of California, 21.

Francis, G. (2008). Identifying the new business and revenue models that apply inthe telco 2.0 market." icin 2008. international conference on intelligent networks. InProceedings of the International Congress on Inteligent Networks.

Hu, Y.-J., Choi, D.-W., Sohn, J.-S., and Lee, S.-H. (2008). Telecommunications-itconvergence service: Adapting to the customers experience. In Proceedings of theInternational Congress on Inteligent Networks.

Huitema, G., Kuhne, R., Meyer, U., Siljee, J., and Zugenmaier, A. (2007). Com-pensation - dynamic charging and billing relashionships in next-generation businessenvironments. In Proceedings of the Mobile and Wireless Communications Summit,pages 1–5.

Hull, R., Benedikt, M., Christophides, V., and Su, J. (2003). E-services: a look be-hind the curtain. In Proceedings of the ACM Symposium on Principles of DatabaseSystems, pages 1–14.

IETF (1997). Rfc 2234 augmented bnf for syntax specifications: Abnf.

IETF (1998). Rfc 3261 - sip: Session initiation protocol.

IETF (2003). Rfc 3588 - diameter base protocol.

IETF (2005). Rfc 4006 diameter credit-control application.

JENNINGS, B. and Malone, P. (2006). Flexible charging for multi-provider composedservices using a federated two-phase rating process. In Proceedings of IEEE-IFIPNetwork Operations and Management Symposium.

JENNINGS, B., Malone, P., and Gaughan, G. (2005). Charging for dynamically com-posed services in the digital business ecosystem. In Proceedings of E-Challenges.

JENNINGS, B., Razavi, A. R., Malone, P. J., Moschoyiannis, S., and Krause, P. J.(2007). A distributed transaction and accounting model for digital ecosystem com-posed services. In Proceedings of Digital EcoSystems and Technologies Conference.

106 Bibliography

JENNINGS, B. and Xu, L. (2007). Automating the generation, deployment and appli-cation of charging schemes for composed ims services. In Proceedings of IntegratedNetwork Management.

JENNINGS, B. and Xu, L. (2008). Specifying flexible charging rules for composableservices. In Proceedings of IEEE Congress on Services.

Laga, N., Bertin, E., and Crespi, N. (2008). A unique interface for web andtelecom services: From feeds aggregator to services aggregator. In Proceed-ings of the International Congress on Inteligent Networks, pages Available at:http://www.icin.biz/files/2008papers/Session5B–2.pdf.

Lee, Y., Sou, S.-I., and jen, J.-Y. (2009). Signaling overhead of policy and online charg-ing control for bearer sessions in lte network. In Proceedings of IEEE InternationalSymposium on Consumer Electronics.

mei WANG, Y., YANG, K., REN, L., and YU, K. (2008). An improved scim-basedservice invocation mechanism for integrated services in ims. In Proceedings of TheInternational Conference on Mobile Technology, Applications Systems.

Microsystems, S. (2007). Jain slee 1.0 specification.

Microsystems, S. (2008a). Jsr-281 ims services api 1.1.

Microsystems, S. (2008b). Jsr 289: Sip servlet v1.1.

Microsystems, S. (2008c). Jsr-325 ims communication enablers (ice).

Mäkeläinen, S. and Alakoski, T. (2008). Fixed-mobile hybrid mashups: experiencesand lessons on applying the rest software architecture principles to exposing mo-bile operator services. In Proceedings of the International Congress on InteligentNetworks.

Nesse, P. J. (2008). Open service innovation in telecom industry - case study of partner-ship models enabling 3’rd party development of novel mobile services. In Proceedingsof the International Congress on Inteligent Networks.

Nessi, F. P. (2009). Nexof-rodmap document.

Niemoeller, J. (2008). Cost control in service composition environments. In Proceedingsof the Next Generation Mobile Applications, Services and Technologies.

OASIS (2006). Web services business process execution language 2.0.

Bibliography 107

Obrenovic, Z. and Gasevic, D. (2009). Mashing up oil and water: Combining hetero-geneous services for diverse users. In Proceedings of IEEE Internet Computing.

Odini, M.-P. and mei WANG, G. W. (2008). Ims, sdp and web 2.0 : Where are theservices ? In Proceedings of the International Congress on Inteligent Networks.

Pascotto, R., Korthals, I., Oliveira, J. M., and Roque, R. (2008). Are partnerships realopportunities for telecommunication operators to increase revenues? In Proceedingsof the International Congress on Inteligent Networks.

Ren, L., Pei, Y. Z., Zhang, Y. B., and Ying, C. (2006). Charging validation for thirdparty value-added applications in service delivery platform. In Proceedings of IEEE-IFIP Network Operations and Management Symposium.

SPICE (2006). Service platform for innovative communication environment- - initialroles, charging and data models document.

Taylor, K., Austin, T., and Cameron, M. (2005). Charging for information services inservice-oriented architectures. In Proceedings of IEEE International Workshop onBusiness services networks, pages 16–16.

TMForum (2010). Mobile application store. Technical report, TMForum.

van Le, M., Huitema, G. B., Rumph, F. J., Nieuwenhuis, L. J. M., and van Beijnum,B.-J. (2009). Design of an online charging system to support ims-based inter-domaincomposite services. In Proceedings of the Management of Multimedia Networks andServices, pages 1–14.

Villalonga, C., Strohbach, M., Snoeck, N., Sutterer, M., Belaunde, M., Kovacs, E., Zh-danova, A. V., Goix, L. W., and DroegehornVillalonga, O. (2009). Mobile ontology:Towards a standardized semantic model for the mobile domain. In Proceedings ofInternational Workshop on Telecom Service Oriented Architectures.

W3C (2004). Web services description language (wsdl) version 2.0 part 1: Core lan-guage. In W3C.

W3C (2008). Widgets 1.0: The widget landscape. consortium draft. In W3C.

YUAN, Y., WEN, J. J., LI, W., and ZHANG, B. B. (2007). A comparison of three pro-gramming models for telecom service composition. In Proceedings of IEEE AdvancedInternational Conference on Telecommunications.

UM MODELO DE TARIFAÇÃO PARA SERVIÇOS COMPOSTOS NA …

Documents

Transcript of UM MODELO DE TARIFAÇÃO PARA SERVIÇOS COMPOSTOS NA …