Conceitos Do Oracle Communications Billing and Revenue Management Elastic Charging Engine

Oracle® Communications Billing e Gestão de
Receitas
Conceitos do Elastic Charging Engine 11.3
Versão 7.5
E70766-03
dezembro de 2016
Conceitos do Oracle Communications Billing and Revenue Management Elastic Charging Engine 11.3,
versão 7.5
E70766-03
Copyright © 2013, 2016, Oracle e/ou suas afiliadas. Todos os direitos reservados.
Este software e documentação relacionada são fornecidos sob um contrato de licença que contém restrições
de uso e divulgação e estão protegidos por leis de propriedade intelectual. Exceto conforme expressamente
permitido em seu contrato de licença ou permitido por lei, você não pode usar, copiar, reproduzir, traduzir,
transmitir, modificar, licenciar, transmitir, distribuir, exibir, executar, publicar ou exibir qualquer parte, de
qualquer forma ou por qualquer meio. A engenharia reversa, desmontagem ou descompilação deste
software, a menos que exigido por lei para interoperabilidade, é proibida.
As informações aqui contidas estão sujeitas a alterações sem aviso prévio e não têm garantia de estarem
livres de erros. Se encontrar algum erro, por favor informe-nos por escrito.
Se este for software ou documentação relacionada entregue ao Governo dos EUA ou a qualquer pessoa
que o licencie em nome do Governo dos EUA, então o seguinte aviso é aplicável:
USUÁRIOS FINAIS DO GOVERNO DOS EUA: Os programas Oracle, incluindo qualquer sistema
operacional, software integrado, quaisquer programas instalados no hardware e/ou documentação,
entregues aos usuários finais do governo dos EUA são "software de computador comercial" de acordo
com o Regulamento Federal de Aquisição aplicável e regulamentos suplementares específicos da agência.
Como tal, uso, duplicação, divulgação, modificação e
A adaptação dos programas, incluindo qualquer sistema operativo, software integrado, quaisquer
programas instalados no hardware e/ou documentação, estará sujeita aos termos de licença e restrições de
licença aplicáveis aos programas. Nenhum outro direito é concedido ao governo dos EUA.
Este software ou hardware é desenvolvido para uso geral em uma variedade de aplicações de
gerenciamento de informações. Não é desenvolvido nem se destina a ser utilizado em quaisquer
aplicações inerentemente perigosas, incluindo aplicações que possam criar um risco de danos pessoais. Se
você usar esse software ou hardware em aplicativos perigosos, então você será responsável por tomar
todas as medidas apropriadas à prova de falhas, backup, redundância e outras para garantir seu uso
seguro. A Oracle Corporation e suas afiliadas se isentam de qualquer responsabilidade por quaisquer
danos causados pelo uso deste software ou hardware em aplicativos perigosos.
Oracle e Java são marcas registadas da Oracle e/ou das suas afiliadas. Outros nomes podem ser marcas
comerciais de seus respetivos proprietários.
Intel e Intel Xeon são marcas comerciais ou marcas comerciais registadas da Intel Corporation. Todas as
marcas comerciais SPARC são usadas sob licença e são marcas comerciais ou marcas comerciais registradas
da SPARC International, Inc. UNIX é uma marca registada do The Open Group.
Este software ou hardware e documentação podem fornecer acesso ou informações sobre conteúdo,
produtos e serviços de terceiros. A Oracle Corporation e suas afiliadas não são responsáveis e renunciam
expressamente a todas as garantias de qualquer tipo com relação a conteúdo, produtos e serviços de
terceiros, a menos que estabelecido de outra forma em um contrato aplicável entre você e a Oracle. A
Oracle Corporation e suas afiliadas não serão responsáveis por quaisquer perdas, custos ou danos
incorridos devido ao seu acesso ou uso de conteúdo, produtos ou serviços de terceiros, exceto conforme
estabelecido em um contrato aplicável entre você e a Oracle.
Índice
Prefácio...................................................................................................................... VIII
Público-alvo..................................................................................................................................................VIII
Acessibilidade da documentação..............................................................................................................VIII
Acessando a documentação do Oracle Communications.....................................................................VIII
Histórico de Revisões de Documentos.....................................................................................................VIII
1 Visão geral do motor de carregamento elástico

Sobre o Elastic Charging Engine...............................................................................................................1-1
Como a ECE cobra solicitações de uso para o sistema de mediação de rede on-line..................1-2
Como a ECE cobra solicitações de uso para o sistema de mediação de rede offline...................1-3
Sobre ECE e PDC...................................................................................................................................1-4
Sobre ECE e BRM...................................................................................................................................1-5
Sobre os clientes ECE e Policy..............................................................................................................1-5
Como a ECE processa solicitações de políticas para software de mediação de rede on-line.....1-6
Integração de aplicações de carregamento com ECE.............................................................................1-8
2 Arquitetura do sistema ECE

Visão geral da arquitetura do sistema ECE.............................................................................................2-1
Sobre os principais componentes ECE no cluster.................................................................................2-3
Sobre o Diameter Gateway........................................................................................................................2-4
Sobre o gateway RADIUS..........................................................................................................................2-4
Sobre o Elastic Charging Server................................................................................................................2-5
Sobre a alta disponibilidade com o Elastic Charging Server...........................................................2-5
Sobre o cliente de carregamento elástico................................................................................................2-6
Sobre o Elastic Charging Controller.........................................................................................................2-6
Sobre o configLoader...................................................................................................................................2-7
Sobre o Atualizador de Preços...................................................................................................................2-7
Sobre o Customer Updater.........................................................................................................................2-8
Sobre o External Manager Gateway.........................................................................................................2-9
Sobre o BRM Gateway................................................................................................................................2-9
Sobre o Rated Event Publisher................................................................................................................2-10
Sobre o evento classificado Formatter....................................................................................................2-10
Sobre a ECE como repositório de perfis de assinante.........................................................................2-11
Sobre os tipos de solicitação ECE...........................................................................................................2-11
iii
3 Noções básicas sobre cenários de carregamento
Visão geral de carregamento.....................................................................................................................3-1
Sobre cenários de carregamento online..................................................................................................3-1
Sobre cenários de carregamento offline..................................................................................................3-2
Sobre a sincronização de dados de clientes BRM e ECE.....................................................................3-2
Sobre atributos de cobrança de uso.........................................................................................................3-2
Sobre os componentes de preços..............................................................................................................3-3
Sobre a classificação....................................................................................................................................3-3
Sobre a reclassificação................................................................................................................................3-4
Sobre o Advice of Charge..........................................................................................................................3-5
Sobre Conselhos de Promoção..................................................................................................................3-5
Sobre o Controle de Crédito de Serviços Múltiplos.............................................................................3-6
Sobre o carregamento baseado em eventos............................................................................................3-7
Sobre o carregamento baseado em sessão..............................................................................................3-7
Sobre os eventos com classificação no meio da sessão....................................................................3-8
Sobre os Descontos.....................................................................................................................................3-8
Sobre a Gestão de Saldo.............................................................................................................................3-9
Sobre a distribuição de encargos..............................................................................................................3-9
Sobre a Validade da Reserva.....................................................................................................................3-9
Sobre a validade do primeiro uso..........................................................................................................3-10
Concedendo recursos de primeiro uso durante a classificação....................................................3-10
Sobre a classificação reversa....................................................................................................................3-10
Sobre o carregamento orientado por políticas.....................................................................................3-11
Sobre produtos de assinatura e produtos de sócio.............................................................................3-13
Carregamento de Eventos com Reserva de Unidade..........................................................................3-13
Carregamento de sessão com reserva de unidade...............................................................................3-13
Carregamento imediato de eventos.......................................................................................................3-13
Solicitações de reautorização iniciadas pelo servidor........................................................................3-13
Sobre o Apoio Fiscal.................................................................................................................................3-14
Sobre o uso de perfis de grupo de usuários fechados para determinar um preço........................3-14
Sobre a atribuição de impactos de saldo a itens de fatura................................................................3-15
Sobre o processamento de solicitações de uso atrasado....................................................................3-15
Sobre o redirecionamento de sessões de assinante para um portal de serviços...........................3-16
4 Sobre solicitações de uso

Visão geral da solicitação de uso..............................................................................................................4-1
Como os sistemas de mediação de rede criam e enviam solicitações de uso...................................4-2
5 Sobre as respostas de uso

Noções básicas sobre respostas de uso....................................................................................................5-1
6 Sobre as notificações
Visão geral das notificações na ECE.........................................................................................................6-1
Sobre notificações na sessão................................................................................................................6-1
Sobre notificações externas..................................................................................................................6-2
iv
Sobre as notificações usadas pelo BRM..................................................................................................6-3
Sobre notificações usadas por clientes de política................................................................................6-4
Notificações de limite de gastos..........................................................................................................6-4
Notificações de preferência do assinante...........................................................................................6-5
Sobre eventos de serviço que disparam notificações externas............................................................6-5
Sobre notificações de recarga...............................................................................................................6-5
Sobre notificações de cobrança............................................................................................................6-5
Sobre notificações de tipo de violação.....................................................................................................6-6
Sobre as notificações de violação de limite........................................................................................6-6
Sobre as notificações de violação do teto de crédito.........................................................................6-6
Sobre as notificações de violação do piso de crédito........................................................................6-6
Sobre o Quadro de Notificação..................................................................................................................6-6
Transformando a carga útil Java do evento de serviço em XML....................................................6-7
Um Conformidade com especificações e normas na ECE

Sobre a conformidade com especificações e normas ............................................................................ A-1
Glossário
v
vi
Prefácio
Este guia fornece uma visão geral do Oracle Communications Billing and
Revenue Management (BRM) Elastic Charging Engine (ECE).
Público-
alvo Este guia destina-se a um público leitor alargado, incluindo:
■ Analistas de negócios que querem entender as capacidades de carregamento
da ECE como um motor de classificação.
■ Desenvolvedores que configuram e estendem o software ECE para dar suporte
aos requisitos de negócios. Por exemplo, um especialista em domínio de
carregamento que toma decisões sobre como os eventos de rede são cobrados.
■ Administradores de aplicativos que configuram a ECE para dar suporte às
ofertas de produtos da empresa e precisam saber como a ECE processa
solicitações de cobrança da rede.
■ Arquitetos ou designers de soluções que precisam saber como a ECE
funciona dentro de um sistema de carregamento mais amplo.
Acessibilidade da documentação
Para obter informações sobre o compromisso da Oracle com a
acessibilidade, visite o site do Programa de Acessibilidade Oracle em
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Acesso ao Suporte Oracle

Os clientes Oracle que adquiriram suporte têm acesso ao suporte eletrônico por meio
do My Oracle Support. Para obter informações, visite
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info ou visite
http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs se você é deficiente
auditivo.
Acessando a documentação do Oracle Communications

Documentação ECE e documentação adicional da Oracle; como a documentação do
Oracle Database, está disponível no Oracle Help Center:
■ http://docs.oracle.com
A documentação adicional do Oracle Communications está disponível no site
de entrega do software Oracle:
vi
■ https://edelivery.oracle.com
Histórico de Revisões de Documentos

A tabela a seguir lista o histórico de revisões deste livro.
Versão Data Descrição

E70766-01 Abril de 2016 Lançamento inicial.
E70766-02 Setembro de 2016 Atualizações da documentação para o ECE
11.3 Patch set 1.
■ Atualizadas as seguintes seções:
Sobre o evento classificado
Formatter Sobre notificações
usadas pelo BRM Sobre
notificações na sessão
E70766-03 dezembro de 2016 Atualizações da documentação para o ECE
11.3 Patch set 2.
■ Acrescentadas as seguintes secções:
Sobre o processamento de solicitações de
uso atrasado solicitação de uso atrasado
vii
1
Visão geral do motor de
carregamento elástico
Este capítulo é uma visão geral do Oracle Communications Billing and Revenue
Management (BRM) Elastic Charging Engine (ECE).
Sobre o Elastic Charging Engine

O Elastic Charging Engine é a principal tecnologia de motor de carregamento do
sistema BRM. O ECE é o motor de carregamento único para carregamento offline e
online. Desenvolvido com base no Oracle Coherence, o ECE é escalável e resiliente e,
como o próprio nome sugere, o ECE pode ser dimensionado (como uma banda
elástica pode se esticar) quando encarregado de processar milhares de transações por
segundo. A capacidade da ECE de escalar com a sua tecnologia de carregamento na
memória suporta baixas latências de serviço e alto desempenho. Consulte "ECE
System Architecture" para obter mais informações sobre ECE e Oracle Coherence.
Pode utilizar a ECE para cobrar aos clientes pela utilização de qualquer produto em
qualquer rede, utilizando qualquer serviço e qualquer tipo de pagamento. Para um
sistema de carregamento convergente, a ECE pode efetuar carregamentos online e
offline ao classificar eventos da rede.
No sistema BRM, a ECE realiza o carregamento de uso. A ECE classifica eventos e
calcula taxas para serviços como uso de telefonia e downloads de conteúdo.
Especificamente, a ECE faz o seguinte:
1. Recebe informações de eventos de um sistema de mediação de rede.
Por exemplo, a ECE recebe informações de eventos do ECE Diameter Gateway (a
interface Diameter suportada) ou de um sistema de mediação de rede de
terceiros.
2. Mede o evento.
3. Aplica uma carga à medição resultante.
4. Adiciona a cobrança ao saldo da conta do cliente.
Para receber dados de eventos, a ECE processa solicitações de uso criadas e enviadas
por programas de software de mediação de rede online e offline. As solicitações de
uso contêm informações de eventos que são usadas para carregamento online e offline
do uso da rede, como a duração de uma chamada ou a quantidade de dados baixados.
Para classificar dados de eventos, a ECE usa dados de preços. A ECE usa dados de
preços do Pricing Design Center (PDC), que define taxas e regras de classificação
usadas para determinar o preço de um evento.
Para classificar dados de eventos, a ECE também usa dados de clientes. A ECE usa
dados do cliente do BRM, que define os produtos que o cliente possui.
Overview of Elastic Charging Engine 1-1

About Elastic Charging Engine
A ECE realiza a gestão do saldo em tempo real, calculando a quantidade de quota que
um cliente pode utilizar com base no seu saldo. Por exemplo, a ECE calcula quantos
minutos um chamador pode usar com base em seu saldo.
A ECE tem APIs para integração com outros sistemas numa solução de
carregamento integrada, como a Função de Política e Regras de Carregamento
(PCRF) para implementar o carregamento orientado por políticas e com sistemas
de carregamento para aplicar carregamentos aos saldos dos clientes.
A Figura 1–1 mostra como a ECE recebe entradas e fornece saídas para outros
sistemas em uma solução de carregamento integrada.
Figura 1–1 Entradas e saídas ECE de e para outros sistemas numa solução de
carregamento integrada
A ECE pode publicar notificações quando ocorrem eventos específicos nos servidores
de carregamento da ECE. Outras aplicações podem subscrever para receber as
notificações para utilizar os dados para o seu próprio processamento. A ECE usa
notificações, por exemplo, para fornecer aos sistemas de mediação de rede
informações de saldo para autorizações pré-pagas. A ECE também usa notificações
para fornecer atualizações de saldo para o BRM.
Além das solicitações de uso, a ECE processa vários outros tipos de solicitações.
Consulte "Sobre os tipos de solicitação ECE" para obter informações.
Como a ECE cobra solicitações de uso para o sistema de mediação de rede on-line
O procedimento a seguir descreve como a ECE normalmente processa uma solicitação
de uso para carregamento online.
1-2 BRM Elastic Charging Engine Concepts

1. O sistema de mediação de rede online recebe eventos de carregamento da rede.

Por exemplo, o ECE Diameter Gateway recebe mensagens de controle de crédito
Diameter de uma rede celular móvel.
2. O sistema de mediação de rede on-line extrai os atributos de evento e os mapeia
para os atributos de uso da ECE na solicitação de uso da ECE.
3. O sistema de mediação de rede online submete os pedidos de utilização à ECE.
4. A ECE processa a solicitação de uso. Notação, alterações, partilha e tributação
fazem parte do cálculo dos encargos. Veja a discussão sobre alterações,
compartilhamento e cálculos de cobrança de impostos em "Entendendo cenários
de cobrança".
Por exemplo, a ECE lê a duração de um evento na solicitação de uso e
calcula as cobranças.
A ECE também suporta operações de débito e reembolso para as quais os encargos
são passados na entrada.
5. A ECE atualiza o saldo do cliente para que ele seja sincronizado com o saldo
do cliente no BRM. Além disso, as reservas e sessões ativas também são
atualizadas.
A ECE gere o estado atual dos saldos dos clientes no sistema de carregamento
online.
6. A ECE envia uma resposta de utilização para o sistema de mediação de
rede online. A Figura 1–2 ilustra como os sistemas de mediação de rede
online funcionam com a ECE.
Figura 1–2 Sistema de mediação on-line e ECE
Como a ECE cobra solicitações de uso para o sistema de mediação de rede offline
O procedimento a seguir descreve como a ECE normalmente processa uma solicitação
de uso para carregamento offline.
1. O sistema de mediação de rede offline recolhe registos de dados de carga (CDR)
a partir de um local conhecido onde a função de dados de carregamento (CDF)
da rede os gravou.
2. O sistema de mediação de rede offline usa opcionalmente os CDRs para executar
processamento adicional, como verificação e agregação de duplicados.

3. O sistema de mediação de rede offline transforma os CDRs em solicitações

de uso ECE.
O sistema de mediação de rede offline extrai os atributos de evento e os mapeia
para os parâmetros de solicitação de uso da ECE.
4. O sistema de mediação de rede offline submete os pedidos de utilização à ECE.
5. A ECE calcula os encargos com base nos atributos de solicitação. A ECE suporta
operações de débito e reembolso para as quais os encargos são passados na
entrada.
Se a ECE detetar erros (por exemplo, não encontrar uma oferta válida para cobrar
pelo pedido), rejeita o pedido. Ele envia uma resposta de uso negativo para o
sistema de mediação off-line que, em seguida, rejeita o CDR.
6. A ECE gerencia o estado atual dos saldos dos clientes dentro do sistema de
cobrança para que ele seja sincronizado com as informações de saldo no BRM.
A Figura 1–3 descreve como o sistema de mediação de rede offline interage com a ECE.
Figura 1–3 Sistema de mediação offline e ECE
Sobre ECE e PDC

A ECE deve ter acesso aos dados de preços para classificar os eventos contidos nas
solicitações de uso que recebe. O ECE usa dados de preços e dados de configuração
relacionados a preços definidos no PDC.
Você projeta componentes de preços no PDC, como ofertas de cobrança e ofertas de
desconto. Você também projeta componentes de configuração que suportam a criação
de componentes de preços, como elementos de equilíbrio, categorias de impacto,
modelos de tempo, métricas de uso taxável (RUMs), mapas de eventos de serviço e
modelos de zona. A ECE usa os critérios em seus componentes de preços para
calcular o preço de seus serviços.
No PDC, você configura suas definições de evento para os eventos criados no BRM. As
definições de evento contêm os dados de especificação de solicitação que os
aplicativos cliente ECE usam para enviar solicitações aos servidores de carregamento
ECE. Sua definição de evento inclui a definição de atributos de uso que a ECE pode
aceitar ao processar solicitações de uso. Você executa o enriquecimento de rede da
definição de evento para seus eventos no PDC. Você adiciona atributos de rede para
todos os atributos de evento na definição de evento que se aplicam a operações de
cobrança de solicitação de uso. Para obter informações sobre definição de evento e

mapeamento de atributos de evento para atributos de rede, consulte Guia do usuário
do PDC.

Consulte "Sobre o atualizador de preços" para obter uma discussão sobre como os
dados PDC são enviados para a ECE.
Sobre ECE e BRM

Depois de classificar um evento, a ECE precisa enviar esse evento classificado para o
BRM para que o BRM possa atualizar o saldo do cliente (débito ou crédito do saldo do
cliente) para que o cliente possa ser cobrado.
A ECE primeiro publica o evento classificado no armazenamento de dados do banco
de dados Oracle NoSQL que você configurou anteriormente para uso pela ECE. A
partir do armazenamento de dados do banco de dados Oracle NoSQL, os dados são
subsequentemente:
■ Extraído
O Rated Event Formatter lê e extrai as informações do evento classificado do
armazenamento de dados do banco de dados Oracle NoSQL para que ele possa
ser formatado.
■ Formatado
O Rated Event Formatter usa seu plug-in BrmCdrPlugindDirect para formatar as
informações do evento classificado em arquivos CDR no formato BRM CDR.
■ Carregado no banco de dados BRM
O carregador de eventos classificados (RE) BRM posteriormente carrega os CDRs
no banco de dados BRM, que atualiza os saldos das contas dos clientes no BRM.
O BRM envia dados para a ECE quando ocorrem atualizações nos dados do cliente
no sistema BRM que devem ser enviadas por push para a ECE. Consulte "Sobre o
Customer Updater" para obter uma discussão sobre como os dados BRM são
enviados para a ECE.
O BRM envia solicitações de reclassificação para a ECE (solicitações de uso e respostas
de uso que são enviadas para reclassificação). Consulte "Sobre a reclassificação" para
uma discussão sobre como os dados BRM são enviados à ECE para reclassificação.
Sobre os clientes ECE e Policy

Para dar suporte ao carregamento orientado por políticas, a ECE oferece uma API de
gerenciamento de políticas. Os clientes de política, como o Diameter Gateway,
podem usar a API para recuperar dados da grade de dados ECE relevantes para a
imposição de políticas.
O carregamento orientado por políticas na ECE baseia-se na Função de Política e
Regras de Carregamento (PCRF), definida na especificação 3GPP TS 23.203 v9.9.0
(2011-06). O PCRF pode integrar-se com a ECE através do seu software de
mediação de rede online.
O ECE expõe seus dados armazenados em cache na memória para que seu software
de mediação de rede on-line possa recuperar informações do contador de políticas e
informações de preferência do assinante relacionadas à política. A ECE publica
notificações contendo as informações da política e seu software de mediação de rede
on-line usa as notificações para enviar as informações ao PCRF para avaliação. Para
obter informações sobre como a ECE interage com seu software de mediação de rede
on-line para carregamento orientado por políticas, consulte "Como a ECE processa
solicitações de política para software de mediação de rede on-line".
Para obter mais informações sobre como a ECE oferece suporte ao carregamento
orientado por políticas, consulte "Sobre o carregamento orientado por políticas".

Para obter informações sobre a API de gerenciamento de políticas ECE e a estrutura
XML das notificações de política ECE, consulte a discussão sobre a integração de
clientes de política com ECE no Guia de implementação do BRM Elastic Charging
Engine.
A Figura 1–4 ilustra como a ECE se encaixa num sistema de tarifação que
implementa o carregamento orientado por políticas.

Figura 1–4 ECE e integração do cliente de políticas
Como a ECE processa solicitações de políticas para software de mediação de rede on-line
O procedimento a seguir descreve como a ECE processa solicitações de cobrança
orientada por políticas do seu software de mediação de rede on-line (ou do Diameter
Gateway).
1. Um cliente começa a usar um serviço que inicia uma sessão de rede.
Por exemplo, o cliente liga um telemóvel que se liga a uma rede sem fios.
2. No início da sessão de rede, a Função de Aplicação de Política e Cobrança (PCEF)
obtém da Função de Política e Regras de Cobrança (PCRF) uma configuração de
política.
O PCEF usa a interface Gx para obter a configuração de diretiva para a sessão de
rede.
3. O PCRF solicita os contadores de políticas e as preferências do assinante do
seu software de mediação de rede on-line (ou Diameter Gateway).
O PCRF usa a interface Sy/Sp de diâmetro.
4. Seu software de mediação de rede on-line inicia uma sessão de política com a
ECE que faz o seguinte:
■ Solicita informações do contador de políticas e do rótulo de status.

Solicita os contadores de política para um produto específico e se inscreve

para receber notificações quando os valores das informações do contador de
política são alterados.
■ Solicita informações de preferências do assinante relacionadas à política
seguindo um destes procedimentos:
– Recupera o valor de um conjunto especificado de preferências do
assinante e se inscreve para receber notificações quando os valores das
preferências mudam durante a sessão de política.
– Recupera apenas os valores de um conjunto especificado de preferências
do assinante e não se inscreve para receber notificações quando os
valores das preferências mudam durante a sessão de política.
Seu software de mediação de rede on-line (e também o Diameter Gateway) usa a
interface Sy/Sp combinada Java/Sp PolicySessionRequest ECE (implementada como
Sh) que usa o procedimento SubscribeNotificationRequest e o procedimento
UserDataRequest.
5. A ECE envia uma resposta de política para o seu software de mediação de
rede online (ou para o Diameter Gateway) que faz o seguinte:
■ Indica se a solicitação foi bem-sucedida ou falhou e uma lista dos
motivos que sustentam a resposta.
■ Envia o status dos contadores de política da seguinte forma para o produto
especificado ou, se os tipos de produto não foram especificados, retorna as
informações de todos os produtos:
– Envia o nome do perfil de oferta configurado para o produto.
– Envia o rótulo de status associado ao contador de políticas.
– Envia um tempo efetivo para os valores dos contadores de política.
Depois que o tempo efetivo expirar, espera-se que o PCRF envie outra
solicitação de informações do contador de políticas e do rótulo de
status (envie outro SpendingLimitReportRequest).
– Envia o nome do rótulo do próximo status provável que será aplicado
após o tempo efetivo expirar. Por exemplo, Medium_QoS.
– Envia o intervalo de atraso. O PCRF pode usar o intervalo de atraso e o
tempo efetivo para determinar quando consultar os contadores de
política novamente.
O ECE usa o procedimento SpendingLimitReportResponse da interface ECE
Java Sy.
As informações listadas acima são apenas um subconjunto da resposta. Para
obter todas as informações incluídas na resposta, consulte Referência da API
Java do BRM Elastic Charging Engine.
■ Envia as preferências do assinante para o conjunto especificado de preferências
do assinante.
O ECE usa o procedimento SubscribeNotificationResponse da interface ECE
Java Sp.
6. O mecanismo de regras do PCRF interpreta as informações e instala uma política
no PCEF que o PCEF impõe.
7. Uma sessão de carregamento é estabelecida e o PCEF envia uma mensagem Ro
para o seu software de mediação de rede online (ou Diameter Gateway).
8. O seu software de mediação de rede online (ou Diameter Gateway) inicia

uma sessão de carregamento com ECE.

Integrating Charging Applications with ECE
9. A ECE publica notificações de políticas para o seguinte:

■ Alterações no status do contador de política para os contadores de
política para os quais o PCRF se inscreveu (dados Sy) no início da
sessão de política.
■ Alterações às preferências do subscritor para as quais o PCRF subscreveu
(dados Sp), se existirem, no início da sessão de política.
Para obter informações sobre notificações de política, consulte "Sobre
notificações usadas por clientes de política".
10. Seu software de mediação de rede on-line (ou Diameter Gateway) consome as
notificações de política e envia os dados para o PCRF.
Para obter informações sobre o formato de dados de notificação de política,
consulte a discussão sobre a integração do ECE com clientes de política no Guia de
implementação do BRM Elastic Charging Engine.
11. À medida que a sessão de cobrança continua, a ECE executa funções de controle
de crédito: classifica eventos, autoriza eventos de uso somente se houver saldo
adequado disponível, administra verificações de limite com base no saldo atual e
reserva consumida do saldo do cliente.
Para obter informações sobre como a ECE processa solicitações de uso, consulte
"Como a ECE cobra solicitações de uso para o Sistema de Mediação de Rede
Online".
12. Quando a ECE deteta uma violação do limite de política durante a sessão de
cobrança, publica uma notificação de política na fila de notificações JMS contendo
o novo status do contador de políticas. O seu software de mediação de rede
online (ou Diameter Gateway) envia os dados para o PCRF.
A alteração do saldo do cliente que causa a violação do limite da política pode
ocorrer devido a qualquer um dos seguintes motivos:
■ Solicitações de uso provenientes do sistema de mediação de rede
■ Solicitações de atualização provenientes do BRM (uma atividade de
assinatura no sistema de gerenciamento de clientes)
■ Recargas provenientes de sistemas de carregamento
13. O PCRF avalia os novos valores do contador de política e os rótulos de status de
política associados e instala uma nova configuração de política no PCEF.
A nova política é estabelecida dinamicamente durante a sessão de carregamento.
14. O cliente deixa de utilizar o seu serviço que termina a sessão de rede.
15. O seu software de mediação de rede online (ou Diameter Gateway) termina a
sessão de carregamento com ECE.
16. Seu software de mediação de rede on-line (ou Diameter Gateway) encerra a
sessão de política com a ECE.
Integração de aplicações de carregamento com ECE

Para integrar aplicativos cliente, como sistemas de mediação, clientes PCRF (Policy
and Charging Rules Function) e sistemas de recarga com ECE, use as APIs ECE.
Consulte a Visão geral da API do Elastic Charging Engine no Guia de implementação do
BRM Elastic Charging Engine para obter um resumo das APIs ECE. Consulte a
Referência da API Java do BRM Elastic Charging Engine para obter informações
detalhadas sobre cada tipo de API ECE.

Para enviar solicitações de uso para ECE, os aplicativos cliente devem chamar as
APIs de carregamento ECE de acordo com o construtor de solicitações de uso
definido. Veja a discussão sobre o uso

solicitações no Guia de implementação do BRM Elastic Charging Engine para obter

informações sobre como as solicitações de uso são criadas e os tipos de operação
suportados.
Um SDK ECE está incluído com o software e contém programas de exemplo que
demonstram os argumentos e métodos que os programas devem usar ao chamar as
APIs ECE. Consulte a discussão sobre o uso de ferramentas de teste ECE no Guia de
implementação do BRM Elastic Charging Engine para obter informações sobre os
programas de exemplo.
Quando introduz diferentes formas de cobrar aos clientes pela utilização dos seus
produtos, pode alargar os pedidos de utilização existentes ou criar novos pedidos de
utilização para suportar os atributos necessários para as diferentes formas de
carregamento. Ao estender ou criar solicitações de uso para lidar com novos atributos
de carregamento, você deve atualizar os pontos de integração no sistema de
carregamento para que os produtos que cercam o ECE possam lidar com os novos
atributos.
Além de integrar aplicativos cliente, você também precisa formatar dados desses
aplicativos para estar em conformidade com os arquivos de esquema de dados ECE.
Consulte a discussão sobre o carregamento de dados no Guia de implementação do
BRM Elastic Charging Engine.


2
Arquitetura do sistema
ECE
Este capítulo descreve a arquitetura do sistema Oracle Communications Billing and

Revenue Management Elastic Charging Engine (ECE).
Visão geral da arquitetura do sistema ECE

ECE é um aplicativo de grade construído em Oracle Coherence. Um aplicativo de
grade é um aplicativo que aproveita uma grade de dados: um sistema composto por
servidores que trabalham para gerenciar informações e operações relacionadas em
um ambiente distribuído. O ECE implementa funções distribuídas em uma rede de
nós. Esses nós são aplicativos Java que incluem bibliotecas Oracle Coherence. Os
serviços são aproveitados para implementar funções de aplicativo nos componentes
ECE. Os principais componentes são:
■ Servidor de carregamento elástico
O Elastic Charging Server (nós do servidor de carregamento ECE) recebe e
calcula dados de clientes ECE (aplicativos cliente). O Elastic Charging Server
realiza toda a lógica de negócios de carregamento, como carregamento de uso, e
executa operações de consulta e atualização em dados de cache ECE.
O Elastic Charging Server envia informações para sistemas externos.
Para enviar solicitações da rede para o Elastic Charging Server para
processamento, os clientes ECE devem ingressar no cluster ECE para acessar os
dados ECE e outros serviços necessários para enviar solicitações. Os clientes ECE
que executam a medição de uso criam solicitações de uso que transportam
informações de uso para o Elastic Charging Server para calcular o uso. Os
aplicativos cliente usam o Elastic Charging Client (descrito abaixo) para ingressar
no cluster ECE.
O Elastic Charging Server suporta solicitações de consulta de sistemas externos,
como autoatendimento do cliente ou sistemas de mediação de rede, para que
esses sistemas possam obter dados de caches ECE. Para sistemas de
autoatendimento, as solicitações de consulta são enviadas ao Elastic Charging
Server quando os clientes consultam o saldo e as informações de senha da conta.
Os clientes ECE usam o Elastic Charging Client (descrito abaixo) para enviar
solicitações de consulta.
Consulte "Sobre o Elastic Charging Server" para obter mais informações.
■ Cliente de carregamento elástico
O Elastic Charging Client é uma biblioteca de cliente instalada em clientes ECE
que permite que clientes ECE se conectem e enviem solicitações para ECE.
Quando os clientes ECE iniciam o Elastic Charging Client, eles ingressam
ECE System Architecture 2-1

automaticamente no cluster que fornece acesso aos caches de dados do nó ECE e

aos serviços necessários para enviar solicitações. O Elastic Charging Client é
usado para enviar todos os tipos de solicitações: uso, consulta, atualização e
gerenciamento.

About Core ECE Components in the Cluster
Consulte "Sobre o cliente de carregamento elástico" para obter mais informações.

■ Gateway de diâmetro
O Diameter Gateway traduz solicitações Diameter recebidas de clientes
Diameter (por exemplo, servidores de aplicativos, servidores de políticas ou
funções de gateway de subsistema multimídia IP) em solicitações de API Java
ECE. Ele traduz a resposta do Elastic Charging Server de volta em solicitações
Diameter e responde de volta ao cliente Diameter solicitante.
O Elastic Charging Client está integrado no Diameter
Gateway. Consulte "Sobre o Diameter Gateway" para obter
mais informações.
■ RADIUS Gateway
O Gateway RADIUS converte solicitações RADIUS recebidas de clientes RADIUS
em solicitações de API Java ECE. Ele traduz a resposta do Elastic Charging Server
de volta em solicitações RADIUS e responde ao cliente RADIUS solicitante.
O Elastic Charging Client está integrado no RADIUS
Gateway. Consulte "Sobre o gateway RADIUS" para obter
mais informações.
■ Atualizador de clientes e atualizador de preços
Para garantir que a ECE dispõe dos dados mais atuais para utilizar nos cálculos de
carregamento:
– O Customer Updater gerencia as solicitações de atualização de dados do
cliente a partir do servidor BRM para garantir que os dados e saldos do
cliente estejam atualizados no cache ECE. Consulte "Sobre o Customer
Updater".
– O Atualizador de Preços processa solicitações de atualização do Centro de
Design de Preços (PDC) para garantir que os dados de preços estejam
atualizados no cache ECE. Consulte "Sobre o atualizador de preços".
■ BRM Gateway
O BRM Gateway sincroniza os dados do Oracle Communications Billing and
Revenue Management BRM com os dados ECE enviando solicitações de
atualização do ECE para o BRM. A ECE envia solicitações de atualização ao BRM
por vários motivos: por exemplo, ao BRM para atualizar o estado do ciclo de vida
do assinante no BRM e para acionar o faturamento no BRM para um cliente.
Consulte "Sobre o BRM Gateway" para obter mais informações.
■ Rated Event Publisher e Rated Event Formatter
O Rated Event Publisher e o Rated Event Formatter persistem os eventos
classificados gerados pela ECE e enviam-nos para sistemas externos. A ECE
publica eventos classificados no banco de dados Oracle NoSQL usando o Rated
Event Publisher. A ECE formata eventos classificados para o sistema BRM usando
Rated Event Formatter. Para um sistema não-BRM, os eventos classificados são
formatados através de um plug-in personalizado. Consulte "Sobre o editor de
eventos classificados" e "Sobre o Formatter de eventos classificados" para obter
mais informações.
■ Controlador de carregamento elástico e controle de nuvem do Oracle Enterprise
Manager
O Elastic Charging Controller (ECC) e o Oracle Enterprise Manager Cloud

Overview of ECE System Architecture
Control monitorizam e mantêm o sistema ECE. Você instala esses aplicativos na
máquina do driver, que é o servidor configurado para ser a máquina do
administrador principal.
Um administrador de sistema que deseja manter, atualizar e ajustar o sistema
ECE usa o ECC. ECC é o aplicativo de linha de comando ECE usado para a
administração, gerenciamento e operação do sistema ECE no dia-a-dia. Consulte
a discussão sobre o uso do ECC no BRM Elastic Charging Engine System
Administrator's Guide para obter mais informações.

About Core ECE Components in the Cluster
Um operador de sistemas que deseja monitorar o sistema ECE e executar tarefas

operacionais básicas usa o Oracle Enterprise Manager Cloud Control. A ECE
aproveita o Oracle Enterprise Manager Cloud Control para gerenciamento de
operações. Para usar o Oracle Enterprise Manager Cloud Control for ECE, você
deve instalar o Oracle Application Management Pack for Oracle
Communications. O Oracle Application Management Pack for Oracle
Communications fornece recursos de gerenciamento para BRM e outros
aplicativos Oracle Communications suportados. Para obter informações
detalhadas sobre os recursos de gerenciamento fornecidos pelo Oracle
Application Management Pack for Oracle Communications, consulte Oracle
Application Management Pack for Oracle Communications System Administrator's
Guide.
Para obter informações gerais sobre monitoramento e gerenciamento de
componentes ECE, consulte a discussão sobre monitoramento e gerenciamento de
ECE no Guia do Administrador de Sistema ECE.
■ Gateway do Gerente Externo
O gateway do Gerenciador Externo (EM) permite que o BRM envie solicitações e
receba respostas da ECE convertendo flists de opcode BRM em solicitações
formatadas em API Java da ECE. A BRM envia solicitações à ECE por vários
motivos. Por exemplo, durante a reclassificação, o BRM solicita o cálculo de taxas de
uso para eventos que precisam ser reclassificados. Consulte "Sobre o gateway do
gerenciador externo" para obter mais informações.
Sobre os principais componentes ECE no cluster

A Figura 2–1 mostra os principais componentes ou nós do ECE no cluster. Os
componentes principais são mostrados nos componentes principais do ECE na
caixa Cluster.
Figura 2–1 Como os componentes principais do ECE interagem com aplicativos externos

About Diameter Gateway
Sobre o Diameter Gateway

O Diameter Gateway traduz solicitações Diameter recebidas de clientes Diameter (por
exemplo, servidores de aplicativos, servidores de políticas ou funções de gateway de
subsistema multimídia IP) em solicitações de API Java ECE. Ele traduz a resposta do
Elastic Charging Server de volta em solicitações Diameter e responde de volta ao
cliente Diameter solicitante.
O Diameter Gateway serve como o servidor front-end do sistema de carregamento on-
line (OCS) para o sistema BRM. Ele processa solicitações de rede para interfaces Gy,
Sy e Sh Diameter. Atua como um servidor Diameter e apresenta o ECE à rede como
uma aplicação de controlo de crédito Diameter.
O Diameter Gateway e o Elastic Charging Server são executados no mesmo cluster
Coherence, que oferece alta disponibilidade e continuidade de serviço.
O Diameter Gateway se comunica com o Elastic Charging Server por meio de
chamadas de API Java ECE.
O Diameter Gateway expõe interfaces personalizadas para operações de consulta de recarga e
equilíbrio.
O Diameter Gateway lê a fila de notificações ECE (tópico JMS) e processa notificações
por push do Elastic Charging Server. A partir das notificações push ECE (notificações
de solicitação de reautorização ECE (RAR), notificações de limite de gastos ECE e
notificações de preferências de assinante ECE), o Diameter Gateway constrói
mensagens Sy e Gy e as envia de volta para clientes Diameter (por exemplo, para
responder a notificações push-notification-request (PNR), subscribe-notification-
request (SNR) e RAR).
Para obter informações sobre como adicionar nós do Diameter Gateway à topologia,
conectar instâncias de nó à rede e configurar instâncias de nó, consulte Guia do
administrador do sistema do BRM Elastic Charging Engine.
Para obter informações sobre como usar o Diameter Gateway para processar tipos de
solicitação de interface Gy, Sy e Sh, consulte a discussão sobre integração de rede para
carregamento on-line usando o Diameter Gateway no Guia de implementação do BRM
Elastic Charging Engine.
Para obter informações sobre os pares atributo-valor padrão (AVPs) Diameter e os
AVPs personalizados Oracle usados pelo Diameter Gateway para processar tipos de
solicitação de interface Gy, Sy e Sh, consulte BRM Elastic Charging Engine Diameter
Gateway Protocol Implementation Conformance Statement.
Sobre o gateway RADIUS
Importante: O Gateway RADIUS é um componente opcional que

requer uma licença separada.
O Gateway RADIUS converte solicitações RADIUS recebidas de clientes RADIUS em

solicitações de API Java ECE. Ele traduz a resposta do Elastic Charging Server de
volta em solicitações RADIUS e responde ao cliente RADIUS solicitante. Você usa o
Gateway RADIUS para processar solicitações de autenticação e contabilização quando
seus clientes usam servidores de terminal ou Servidor de Acesso à Rede (NAS) para se
conectar ao ECE.
O RADIUS Gateway serve como o servidor front-end do OCS para o sistema BRM.
Atua como um servidor RADIUS e apresenta o ECE à rede como uma aplicação

About Elastic Charging Server
RADIUS.

About Elastic Charging Server
O RADIUS Gateway fornece interfaces personalizadas para processar solicitações de

autenticação e contabilidade de clientes RADIUS.
O Gateway RADIUS está incluído na instalação do servidor ECE e você pode
implantar nós do Gateway RADIUS no cluster ECE da mesma forma que
implanta outros nós ECE. O RADIUS Gateway tem arquivos de configuração de
exemplo prontos para uso para facilitar a implementação.
Para obter informações sobre como adicionar nós do Gateway RADIUS à topologia e
configurar instâncias de nó, consulte Guia do administrador do sistema do BRM Elastic
Charging Engine.
Para obter informações sobre como mapear atributos de rede RADIUS para atributos
de evento e personalizar o dicionário de dados RADIUS no ECE, consulte a discussão
sobre como configurar e personalizar o gateway RADIUS no Guia de implementação
do BRM Elastic Charging Engine.
Para obter mais informações sobre como usar o Gateway RADIUS para processar
solicitações de autenticação, consulte a discussão sobre autenticação usando o
Gateway RADIUS no Guia de Implementação do BRM Elastic Charging Engine.
Para obter mais informações sobre como usar o Gateway RADIUS para processar
solicitações de contabilidade, consulte a discussão sobre contabilidade usando o
Gateway RADIUS no Guia de Implementação do BRM Elastic Charging Engine.
Para obter informações sobre as interfaces personalizadas e os pontos de extensão
disponíveis para processar solicitações de clientes RADIUS, consulte BRM Elastic
Charging Engine Extensions.
Para obter informações sobre os AVPs padrão RADIUS e mensagens usadas pelo
RADIUS Gateway para processar solicitações de clientes RADIUS, consulte BRM
Elastic Charging Engine RADIUS Gateway Protocol Implementation Conformance
Statement.
Sobre o Elastic Charging Server

O Elastic Charging Server usa seus nós de servidor de carregamento para executar
toda a lógica de negócios de carregamento, como carregamento de uso, consulta e
lógica de atualização.
Usando a grade de dados na memória do Oracle Coherence, a ECE pode distribuir
objetos necessários para o carregamento de uso e seu processamento relacionado em
vários servidores físicos, eliminando pontos únicos de falha e pontos únicos de
gargalo. Além disso, o Coherence permite escalabilidade vertical e horizontal para
ECE.
Os servidores de carregamento ECE recebem solicitações de uso contendo
informações de uso do Elastic Charging Client. Os dados de clientes e preços
necessários para processar solicitações ECE são armazenados em cache no cluster
ECE (onde ocorre o processamento de transações) para que os servidores de
carregamento ECE não sejam obrigados a realizar pesquisas de dados em aplicativos
externos.
Sobre a alta disponibilidade com o Elastic Charging Server

O Elastic Charging Server tem recursos integrados de alta disponibilidade. Os
componentes ECE que fazem parte do sistema de carregamento geral, como
gateways, clientes e o banco de dados Oracle NoSQL, também têm recursos internos
de alta disponibilidade.
Os nós do servidor de carregamento ECE usam a tecnologia Oracle Coherence e
aproveitam os recursos dos clusters Coherence para alta disponibilidade, incluindo:
About Diameter Gateway
■ Distribuição de objetos ECE em vários servidores físicos
■ Processamento distribuído, sem pontos únicos de falha ou contenção

About Pricing Updater
■ Armazenamento de informações em vários nós em vários servidores físicos e

racks para proteção contra falhas de nós, máquinas e racks
Sobre o cliente de carregamento elástico

O Elastic Charging Client é uma biblioteca de cliente instalada em clientes ECE que
permite que o ECE se conecte e envie solicitações para o ECE. Quando os clientes ECE
iniciam o Elastic Charging Client, eles ingressam automaticamente no cluster que
fornece acesso aos caches de dados do nó ECE e aos serviços necessários para enviar
solicitações. O Elastic Charging Client é usado para enviar todos os tipos de
solicitações: uso, consulta, atualização e gerenciamento.
Os eventos de carregamento em tempo real e os registos de detalhes de chamadas
offline (CDRs) da rede são transformados por programas de software de mediação de
rede em pedidos de utilização que utilizam um formato exigido pela ECE. Os
programas de software de mediação de rede usam a API de carregamento ECE para
criar as solicitações de uso.
A carga útil da API é extensível para que você possa definir atributos de cobrança
para criar solicitações de uso que satisfaçam seus requisitos de negócios (e cobrança).
Essas especificações de solicitação podem ser estendidas (ou você pode criar novas
especificações) quando você executa a definição de evento no PDC. Consulte "Sobre
solicitações de uso" para obter informações sobre a construção de solicitação de uso
exigida pela ECE.
O Elastic Charging Client envia respostas de uso assíncronas de volta para aplicativos
cliente que enviam solicitações de uso. Ele pode enviar solicitações como um lote para
o Elastic Charging Server. O Elastic Charging Client também pode enviar solicitações
em lote que pertencem a um nó específico do servidor de carregamento no cluster.
O Elastic Charging Client sabe em qual nó do servidor de carregamento no cluster os
dados do cliente são armazenados em cache; Ele aproveita essas informações para
encaminhar solicitações de processamento para que o processamento das solicitações
possa ocorrer onde os dados estão localizados.
O Elastic Charging Client registra informações de rastreamento de latência de como
as solicitações foram tratadas no sistema.
O Oracle Communications Offline Mediation Controller integra-se ao ECE para enviar
solicitações de uso para carregamento offline. O Elastic Charging Client é instalado no
cartucho de distribuição do Controlador de Mediação Offline. Consulte o Guia do
Usuário do Oracle Communications Offline Mediation Controller Elastic Charging Engine
Cartridge Pack para obter instruções sobre como conectar o Offline Mediation
Controller à ECE e enviar solicitações à ECE para processamento.
Sobre o Elastic Charging Controller

O Elastic Charging Controller é usado para gerenciar os processos ou nós do servidor
ECE no cluster ECE. O Elastic Charging Controller lê seu arquivo de topologia para
saber onde todos os nós do cluster estão localizados.
O Controlador de Carregamento Elástico está instalado na máquina do driver.
A seguir estão alguns exemplos de tarefas que você pode executar usando o Elastic
Charging Controller:
■ Iniciando e parando nós ECE no cluster
■ Envio por push de alterações de configuração da máquina de driver para
todas as máquinas de servidor nas quais o cluster é implantado
■ Executar atualizações contínuas de determinados componentes em um sistema
About the Elastic Charging Client
ECE em execução, como alterar as propriedades de ajuste da JVM, alterar as
propriedades de configuração do JMS ou atualizar personalizações do módulo
de extensão (alterando arquivos JAR de extensão)

About Pricing Updater
Para obter informações sobre como usar o Elastic Charging Controller, consulte a
discussão sobre o gerenciamento de nós ECE no BRM Elastic Charging Engine System
Administrator's Guide.
Sobre o configLoader
Tanto o RADIUS Gateway quanto o Diameter Gateway devem ter acesso aos dados
de especificação de mediação para criar solicitações de autenticação, contabilidade ou
uso. configLoader é um utilitário que carrega o ECE com dados de especificação de
mediação que você configura em seu arquivo de especificação de mediação.
Para obter informações sobre como editar o arquivo de especificação de mediação
Diameter, consulte a discussão sobre integração de rede para carregamento on-line
usando o Diameter Gateway no BRM Elastic Charging Engine Implementation Guide.
Para obter informações sobre como editar o arquivo de especificação de mediação
RADIUS, consulte a discussão sobre como configurar e personalizar o gateway
RADIUS no Guia de implementação do BRM Elastic Charging Engine.
Sobre o Atualizador de Preços

A ECE deve ter acesso aos dados de preços para classificar as solicitações de uso que
recebe. O ECE usa dados de preços e dados de configuração relacionados a preços
definidos no PDC.
O Atualizador de Preços carrega dados de preços no ECE automaticamente quando
você publica dados de preços no PDC para ECE.
Quando você publica dados de preços no PDC, o Atualizador de Preços grava os
dados de preços em uma fila JMS. O PDC envia dados de preços em formato XML no
formato PDC.
O Pricing Updater ouve na fila. O Atualizador de Preços coloca os dados na fila JMS,
transforma o XML no formato compreendido pelo ECE (no formato de dados ECE
XML) e carrega os dados no ECE.
O Atualizador de Preços carrega os dados de especificação da solicitação no ECE. Os
dados de especificação de solicitação são exigidos pelos aplicativos cliente ECE para a
criação de solicitações de uso. O PDC gera automaticamente os dados de especificação
da solicitação que são necessários no formato XML no formato PDC. Semelhante ao
tratamento de dados de preços, o Pricing Updater descoloca os dados de especificação
de solicitação na fila JMS, transforma o XML no formato entendido pelo ECE (no
formato de dados ECE XML) e carrega os dados no ECE.
Você fornece as informações necessárias para configurar o Pricing Updater quando
instala o ECE. Você pode alterar essa configuração, se necessário. Consulte a discussão
sobre a implementação do ECE com PDC no Guia de implementação do BRM Elastic
Charging Engine para obter informações sobre como configurar o Pricing Updater.
Cuidado: O utilitário pricingLoader é usado para carregar dados

de preços de exemplo no ECE a partir de arquivos XML incluídos no
diretório de dados de preços de exemplo
(ECE_home/oceceserver/sample_data/pricing_data, onde ECE_home é o
diretório no qual o ECE está instalado). Dados de preços de exemplo
entram em conflito com dados de preços criados usando PDC.
Não use pricingLoader em uma implantação de produção.
Não execute pricingLoader e Pricing Updater na mesma implantação

About the Elastic Charging Client
ECE.

About BRM Gateway
Sobre o Customer Updater

O Customer Updater faz o seguinte:
■ Executa a extração inicial de dados de clientes, perfis de crédito, perfis de
oferta, objetos de configuração e dados de referência cruzada de preços do
BRM e carrega os dados no ECE
■ Lida com atualizações assíncronas do BRM para o ECE dos seguintes dados:
reclassificação, migração de conta, desconto e produto
Os dados de reclassificação, migração de conta, desconto e produto armazenados no
ECE devem permanecer atualizados com os dados correspondentes no banco de
dados BRM.
Quando ocorrem eventos que atualizam esses dados no banco de dados BRM, as
atualizações podem ser publicadas de forma assíncrona (não em tempo real) na ECE
por meio do Customer Updater. Para fazer isso, as atualizações são enviadas em
eventos de negócios para o DM (Account Synchronization Data Manager), que
publica os eventos de negócios em uma fila de banco de dados Oracle Advanced
Queuing (Oracle AQ). O Customer Updater recupera os eventos de negócios da fila e
atualiza o cache ECE de acordo.
Para garantir que o cache ECE seja sincronizado com o banco de dados BRM antes do
início do processamento de uso, o Customer Updater retira todas as solicitações da fila
do banco de dados antes de colocar o ECE em um estado usageProcessing.
A Figura 2–2 mostra o fluxo de dados da notificação de eventos para a atualização do
ECE por meio do Customer Updater:
Figura 2–2 Fluxo de dados da notificação de evento para a atualização do ECE por meio do Customer Updater
Para obter informações gerais sobre como configurar notificações de eventos,

sincronização de contas e cargas úteis de eventos de negócios, consulte a
documentação do BRM.
Para obter informações sobre como configurar a notificação de eventos ECE e cargas
úteis, consulte a discussão sobre como carregar os arquivos de configuração ECE em
seu sistema BRM em BRM Setting Up Pricing and Rating.

About Customer Updater
Para obter informações sobre como configurar o Customer Updater, consulte a
discussão sobre a implementação do ECE com BRM no Guia de Implementação do BRM

About BRM Gateway
Para obter informações sobre como atualizar dados de clientes em tempo real, consulte
"Sobre a sincronização de dados de clientes BRM e ECE".
Cuidado: A execução do utilitário customerLoader sem qualquer

parâmetro carrega dados de exemplo do cliente no ECE a partir de
arquivos XML incluídos no diretório de dados do cliente de exemplo
(ECE_ home/oceceserver/sample_data/customer_data). Exemplos de
dados de clientes entram em conflito com os dados de clientes criados
usando BRM. A execução do utilitário customerLoader com o
parâmetro incremental carrega os dados do cliente
incrementalmente, em lotes ou em massa, do BRM para o ECE.
Não execute customerLoader sem o parâmetro incremental em uma
implantação ECE de produção.
Sobre o External Manager Gateway

O Gateway do Gerente Externo (EM) é um processo Java Virtual Machine (JVM) que
atua como um cliente para o Elastic Charging Server, enviando solicitações para ECE
a partir do BRM.
O EM Gateway escuta em uma porta solicitações do BRM no formato flist de entrada
opcode. O EM Gateway converte as flists de entrada em solicitações ECE e converte
as respostas ECE subsequentes de volta em flists de saída.
O servidor BRM usa o EM Gateway para publicar atualizações de dados do cliente do
banco de dados BRM para o cache ECE. Para obter mais informações, consulte "Sobre a
sincronização de dados de clientes BRM e ECE".
O utilitário de reclassificação BRM usa o EM Gateway para enviar solicitações de
reclassificação do BRM para a ECE durante o processo de reclassificação. Consulte
"Sobre a reclassificação" para obter mais informações.
Os aplicativos BRM personalizados podem usar o EM Gateway para enviar
solicitações de consulta de saldo à ECE para consultar o saldo de uso em tempo real do
cliente gerenciado no ECE.
Para obter informações sobre como configurar o EM Gateway, consulte a discussão
sobre a implementação do ECE com BRM no BRM Elastic Charging Engine
Implementation Guide.
Sobre o BRM Gateway

O BRM Gateway lida com solicitações de atualização do ECE para o BRM (o ECE
envia solicitações ao BRM para atualizar os dados no banco de dados do BRM).
O BRM Gateway envia informações para o BRM quando os processos devem ser
acionados no BRM ou os dados devem ser atualizados no BRM devido ao
processamento de solicitação de uso da ECE.
O BRM Gateway se conecta e envia informações ao BRM para as seguintes finalidades:
■ Sincronize a validade do primeiro uso inicializada do ECE para
o BRM Consulte "Sobre a validade do primeiro uso".
■ Atualizar o estado do ciclo de vida do assinante no BRM
Quando ocorrem alterações no estado do ciclo de vida do assinante de um cliente
na ECE, a ECE publica um evento de serviço. O BRM Gateway usa o evento de
serviço para enviar as informações de estado do ciclo de vida do assinante para o

About Customer Updater
BRM para que o BRM possa atualizar o estado no banco de dados do BRM.

About ECE Request Types
Por exemplo, o estado do ciclo de vida do assinante pode passar de um estado

pré-ativo para um estado ativo na ECE quando um cliente ativa um cartão
telefônico pré-pago da rede. A ECE usa o BRM Gateway para enviar as novas
informações de estado para o BRM.
■ Acionar o faturamento no BRM
Se um cliente iniciar uma sessão imediatamente antes de a cobrança ser definida
para ser executada no BRM, a ECE enviará uma solicitação ao BRM para executar
o faturamento para esse cliente. Consulte "Sobre notificações de cobrança" para
obter mais informações.
■ Atualizar POIDs de item no ECE
A ECE obtém uma lista de POIDs do BRM, armazena-os em cache no ECE e os
define no evento classificado.
Para acompanhar os impactos do saldo de um cliente para um determinado tipo
de item faturável, a ECE mapeia as combinações de tipo de produto e tipo de
evento em uma solicitação de uso para seu tipo de item relevante. A ECE envia
informações ao BRM para atualizar os POIDs do item no banco de dados do BRM.
O BRM Gateway faz parte do cluster ECE, mas não está habilitado para
armazenamento; é um processo Java interagindo com ECE através de JMS. O
principal objetivo do BRM Gateway é interagir com o BRM para enviar solicitações
de atualização.
O BRM Gateway escuta na fila de notificações do ECE eventos de notificação que
disparam solicitações de atualização para o BRM. Quando esse evento de notificação
ocorre, o BRM Gateway se conecta ao BRM Connection Manager (CM) e envia os
dados relevantes do evento de notificação para o BRM. Ao enviar as informações, o
BRM Gateway chama os opcodes BRM necessários que usam os dados para acionar
processos no BRM.
Você deve configurar o BRM Gateway para se conectar ao BRM CM. Consulte a
discussão sobre a configuração do BRM Gateway no Guia de implementação do BRM
Sobre o Rated Event Publisher

O Rated Event Publisher obtém informações de eventos classificados no Elastic
Charging Server e publica essas informações no banco de dados Oracle NoSQL. O
Rated Event Publisher pega objetos ECE Java no Elastic Charging Server e os publica
no formato binário (Coerência) em um armazenamento de dados NoSQL.
Sobre o evento classificado Formatter

Rated Event Formatter traduz eventos classificados em um formato que pode ser
carregado pelo Rated Event Loader. O Carregador de Eventos Classificados carrega
eventos classificados no banco de dados BRM. Você pode configurar o Rated Event
Formatter para traduzir e enviar eventos classificados no formato necessário para
sistemas externos, como um data warehouse.
O Rated Event Formatter executa plug-ins para traduzir eventos classificados em
diferentes formatos. O plug-in BrmCdrPluginDirect transforma eventos do banco de
dados Oracle NoSQL em arquivos CDR no formato BRM CDR. Para um sistema não-
BRM, você pode configurar um plug-in personalizado para transformar eventos
classificados em diferentes formatos, como XML e JSON.
Quando você usa um plug-in personalizado, o plug-in personalizado e o plug-in
BrmCdrPluginDirect processam os eventos classificados simultaneamente. Quando

About Rated Event Publisher
os eventos classificados são processados pelo sistema não-BRM e pelo banco de
dados BRM, os eventos classificados são removidos do banco de dados BRM.
Para obter mais informações sobre o plug-in BrmCdrPluginDirect, consulte a
discussão sobre como configurar o plug-in BrmCdrPluginDirect no Guia de

Sobre a ECE como repositório de perfis de assinante

Ao integrar clientes de política e função de regras de cobrança (PCRF) com ECE, ECE
atua como o repositório de perfil de assinante (SPR) porque armazena as informações
de perfil do cliente usadas pelo PCRF. A ECE oferece uma interface combinada de Sp
(implementada como Sh) e Sy, que o PCRF usa para recuperar as preferências do
cliente e informações do contador de políticas. Para obter mais informações, consulte
"Sobre ECE e clientes de política" e consulte a discussão sobre clientes de política
PCRF no Guia de implementação do BRM Elastic Charging Engine.
Sobre os tipos de solicitação ECE

A ECE recebe vários tipos de pedidos de outras aplicações. A ECE processa os seguintes
tipos de pedidos:
■ Pedidos de utilização
■ Solicitações de políticas
■ Pedidos de carregamento (um tipo de pedido de atualização)
■ Pedidos de consulta
■ Pedidos de gestão
■ Pedidos de atualização
A ECE oferece serviços que expõem suas APIs de cliente que os aplicativos podem usar
para criar essas solicitações. Para obter mais informações, consulte o apêndice de
referência da API ECE no Guia de implementação do BRM Elastic Charging Engine.


3
Noções básicas sobre cenários de
carregamento
Este capítulo descreve os cenários de cobrança suportados pelo Oracle Communications

Billing and Revenue Management Elastic Charging Engine (ECE).
Visão geral de carregamento

Pode utilizar o ECE para efetuar apenas carregamento online, carregamento apenas
offline ou carregamento online e carregamento offline quando utilizado num sistema de
carregamento convergente.
Consulte os seguintes tópicos para obter informações sobre os cenários de carregamento
suportados pela ECE:
■ Sobre cenários de carregamento online
■ Sobre cenários de carregamento offline
A ECE cobra eventos de rede com base em vários atributos e nos componentes de
preços associados a eles. Consulte "Sobre atributos de cobrança de uso" e "Sobre
componentes de preços ".
A ECE suporta vários tipos de taxa ao carregar eventos de rede. Consulte "Sobre a
classificação" para obter mais informações.
O ECE SDK inclui programas de exemplo que demonstram como os aplicativos
cliente do sistema de mediação chamam as APIs ECE para cenários de cobrança
suportados. Consulte a discussão sobre o uso de ferramentas de desenvolvedor ECE
no Guia do administrador do sistema do BRM Elastic Charging Engine para obter
informações sobre os programas de exemplo.
Sobre cenários de carregamento online

A ECE suporta os seguintes cenários de carregamento online de eventos de rede,
conforme definido pelas normas 3GPP:
■ Carregamento baseado em eventos:
– Carregamento de eventos com reserva de unidade (ECUR)
– Carregamento imediato de eventos (IEC)
■ Carregamento baseado em sessão:
– Carregamento de sessão com reserva de unidade (SCUR), incluindo:
* Classificação inversa
* Distribuição de encargos
Understanding Charging Scenarios 3-1
■ Aconselhamento de Carga
(AoC) As capacidades
adicionais incluem:

About Rating
■ Alterações (normalmente chamadas de descontos no Billing and Revenue Management

(BRM))
■ Distribuições
■ Conselhos de Promoção (AoP)
■ Fiscalidade
■ Final Unit Indicator (pode ser usado para suportar recargas na
sessão) ECE fornece uma interface Java para carregamento on-line
de eventos de rede.
A ECE fornece uma interface Java para suportar operações a partir de mecanismos de
rede de política e controlo (a função de política e regras de cobrança (PCRF)). Para a
discussão sobre a cobrança relacionada a políticas, consulte "Sobre a cobrança
orientada por políticas".
Sobre cenários de carregamento offline

A ECE suporta os seguintes cenários de carregamento offline de eventos de rede:
■ Carregamento baseado em
eventos Os recursos adicionais
incluem:
■ Alterações
■ Fiscalidade
Sobre a sincronização de dados de clientes BRM e ECE

Quando o servidor BRM realiza transações de gerenciamento de clientes e
faturamento, ele armazena os resultados no banco de dados BRM. Para permitir que a
ECE classifique eventos de uso corretamente, todas as atualizações de dados do
cliente feitas no banco de dados BRM também devem ser feitas no cache da ECE.
As atualizações são aplicadas ao cache ECE de forma síncrona (em tempo real) da seguinte
maneira:
1. O servidor BRM executa a transação e, em seguida, envia as atualizações em
eventos de negócios para a ECE por meio do Gateway do Gerenciador Externo
(EM).
2. O EM Gateway processa os eventos de negócios e, em seguida, informa ao
servidor BRM se a atualização de cache ECE foi bem-sucedida.
3. Ocorre uma das seguintes situações:
■ Se a atualização de cache for bem-sucedida, as atualizações serão salvas no banco de
dados BRM.
■ Se a atualização do cache falhar, as atualizações do banco de dados serão revertidas.
Como o banco de dados e o cache são atualizados dentro da mesma transação, não
ocorre tempo de atraso e os dados BRM e ECE permanecem sincronizados
independentemente de a atualização do cache ser bem-sucedida ou falhar.
Para habilitar atualizações síncronas de dados do cliente, consulte a discussão
sobre como habilitar a sincronização em tempo real de atualizações de dados do
cliente BRM e ECE no Guia de implementação do BRM Elastic Charging Engine.

About Offline Charging Scenarios
Sobre atributos de cobrança de uso

Os atributos afetam a forma como a ECE implementa a classificação. Os atributos
podem ser associados ao evento, ao cliente ou ao produto.
A ECE pode classificar eventos de rede de forma diferente com base nos seguintes atributos:

About Rating
■ Atributos de classificação de evento carregável

■ Atributos de classificação do cliente
■ Atributos de classificação do produto
Por exemplo, um atributo de classificação de cliente pode ser a data de
nascimento de um cliente em que você fornece mensagens de texto gratuitas aos
clientes no aniversário deles.
Os atributos de classificação de evento carregável devem ser definidos na sua
definição de evento para que a ECE os identifique como atributos que impulsionam a
classificação.
Os atributos do cliente e do produto que impulsionam a classificação na ECE em
tempo de execução são atributos do modelo do cliente ECE. Esses atributos são
definidos no Oracle Communications Pricing Design Center (PDC) quando você
executa a definição de evento no PDC para que você possa definir regras de preços
com base neles.
Sobre os componentes de preços

Os componentes de preços são as taxas que a ECE usa para cobrar. Os componentes
de preços são definidos no PDC. A ECE usa os componentes de preços para
configurar o valor de um evento tributável recebido da rede. Consulte a Ajuda do
PDC para obter instruções sobre como criar componentes de preços para ECE.
A ECE suporta o Advice of Promotion como uma configuração ao nível do
sistema, não sendo configurável no PDC. Consulte "Sobre os conselhos de
promoção" para obter mais informações.
Sobre a classificação
Para calcular encargos e descontos durante a classificação em tempo de execução, a
ECE usa dados de configuração e dados de componentes de preços definidos no
PDC. A ECE pode usar atributos do evento cobrado recebido da rede, atributos dos
dados do cliente recebidos do BRM e atributos dos dados do produto recebidos do
BRM para determinar qual taxa aplicar.
A ECE suporta várias taxas para determinar o valor de um evento tributável. Você
define taxas no PDC, incluindo o seguinte:
■ Taxa zero
■ Taxa fixa
■ Taxa diferenciada
■ Taxa limite
■ Taxa baseada em zonas
■ Taxa baseada no tempo
■ Tarifa por dia
■ Tarifa especial por dia
Consulte a Ajuda do PDC para obter descrições dos tipos de taxa anteriores e como
defini-los em seus componentes de preços ECE.
Em tempo de execução, o ECE pode executar a classificação reversa para carregamento
baseado em sessão. Consulte " Sobre a classificação inversa" para obter mais
informações.

About Rerating
Sobre a reclassificação
Você pode reavaliar eventos com classificação ECE, se necessário. A
reclassificação de eventos pode ser necessária por vários motivos. Por exemplo,
se uma das suas ofertas de cobrança existentes tiver sido substituída entre o
último e o próximo ciclo de faturação.
Consulte a discussão sobre reclassificação na documentação do BRM para obter
informações sobre a reclassificação no sistema de cobrança do BRM.
A reclassificação é iniciada no BRM quando você executa o utilitário BRM pin_rerate . O
pin_rerate
O utilitário envia trabalhos de reclassificação para a ECE para eventos que foram
originalmente classificados pela ECE.
A ECE suporta uma classificação simultânea na qual a ECE pode continuar a avaliar a
eventos de utilização em tempo real ao efetuar a reclassificação na conta desse cliente.
A ECE também pode aplicar recargas provenientes de sistemas de carregamento de
terceiros enquanto realiza a reclassificação na conta desse cliente.
Uma solicitação de uso que vem da rede quando o cliente está em reclassificação é
chamada de solicitação simultânea. As solicitações de autorização e as solicitações de
reautorização (para solicitações simultâneas) são processadas e os resultados são
retornados ao programa de software de mediação de rede, mesmo quando a
reclassificação está ocorrendo para esse cliente.
A classificação simultânea aplica-se ao processamento de eventos de uso da ECE. A
ECE reprocessa qualquer solicitação simultânea recebida quando o cliente está no
modo de reclassificação. Os saldos para o cliente que foram modificados devido à
reclassificação BRM são recalculados novamente na ECE para que os saldos sejam
sincronizados.
O seguinte resume o processo geral de reclassificação de eventos com classificação
ECE em um sistema de cobrança BRM:
1. No BRM, o administrador do sistema executa pin_rerate para criar
trabalhos de reclassificação para reclassificar contas especificadas.
2. O BRM bloqueia as contas do cliente no BRM e envia uma mensagem de
preparação para reclassificação para a ECE por meio da fila do banco de dados
BRM Advanced Queuing (AQ).
Nota: pin_rerate envia todas as mensagens de reclassificação para a

ECE enviando eventos de negócios através do BRM Account
Synchronization Data Manager (DM). As mensagens de
reclassificação são convertidas em solicitações de atualização pelo EM
Gateway e enviadas para a ECE por meio do Customer Updater
como qualquer outra solicitação de atualização. As solicitações de
atualização para mensagens de reclassificação são chamadas de
solicitações de cobrança.
3. O ECE marca os clientes que fazem parte da solicitação de preparação para

reclassificação com um status de reclassificação e envia eventos classificados
para esses clientes do banco de dados Oracle NoSQL para o BRM, de modo
que os saldos no ECE e no BRM sejam sincronizados antes do início da
reclassificação.
4. A ECE usa a Fila de Confirmação para enviar uma confirmação de que a
reclassificação pode ser iniciada e o BRM inicia o processo de reclassificação.

About Advice of Promotion
5. O BRM envia os eventos a serem reclassificados através do EM Gateway para serem
classificados pela ECE.
Os saldos do cliente não são afetados pelos eventos classificados através
do EM Gateway.
6. A BRM envia solicitações de reclassificação à ECE contendo os impactos do saldo
nas contas patrocinadoras (para distribuição de encargos) como resultado da
reclassificação das contas.
7. A ECE reclassifica os eventos de uso de um cliente de acordo com as solicitações de
reclassificação.

About Advice of Promotion
Se a ECE receber solicitações simultâneas, como solicitações de uso simultâneo

ou solicitações de recarga simultâneas, ela classifica o uso e aplica recargas para
as solicitações simultâneas de acordo.
8. Quando o trabalho de reclassificação é concluído no BRM, o BRM envia uma
mensagem para a ECE através da fila do banco de dados BRM AQ.
9. A ECE realiza as atualizações de saldo e backouts necessários e sincroniza os
saldos para os clientes que estavam nas solicitações de reclassificação.
Para cenários de distribuição de encargos (compartilhamento de encargos no
BRM), os eventos para clientes que não estavam no trabalho de reclassificação,
mas que compartilham descontos ou cobranças com clientes que estavam no
trabalho de reclassificação, são processados posteriormente para que os saldos
sejam aplicados corretamente.
10. Depois que a ECE reclassifica os eventos, a ECE envia os resultados de cobrança
para o BRM gerando arquivos de registro de detalhes da chamada (CDR) para o
carregador de evento avaliado (RE) carregar no banco de dados BRM.
11. A ECE gera uma confirmação de que a reclassificação está concluída e a envia
para o BRM por meio da Fila de Confirmação.
O BRM armazena todos os eventos de assinatura que ocorrem no sistema BRM até que a
reclassificação seja concluída. Após a reclassificação, o BRM envia os eventos de
assinatura para a ECE como solicitações de atualização por meio do Customer Updater.
Da mesma forma, o ECE armazena todos os eventos de solicitação simultânea que
ocorrem no sistema ECE até que a reclassificação seja concluída.
Se a ECE não puder reclassificar eventos para um cliente, a ECE enviará uma
notificação ao BRM usando o BRM Gateway. O BRM usa as informações na
notificação para criar um trabalho de reclassificação para esse cliente. Se o processo
de reclassificação falhar durante o processo de reclassificação, o ECE registrará as
mensagens no arquivo de log do Customer Updater.
O ECE move solicitações de reclassificação com falha do Customer Updater para a
fila de suspense. Consulte a discussão sobre como lidar com solicitações de
atualização com falha do BRM no Guia do administrador do sistema ECE para obter
informações sobre como lidar com eventos com falha na fila de suspense.
Sobre o Advice of Charge

A ECE suporta o serviço suplementar 3GPP Advice of Charge (AoC), através do qual os
clientes podem ser informados sobre o custo de um serviço solicitado, quer em formato
monetário quer em formato não monetário. A AoC pode ser fornecida no início de uma
sessão, durante uma sessão ou no final de uma sessão.
Para dar suporte à AoC, a ECE calcula o custo do uso de um serviço e retransmite
essas informações de volta para o programa de software de mediação de rede, que
pode passar a mensagem para o cliente.
Para obter informações sobre como configurar a AoC no ECE, consulte a discussão
sobre a configuração de carregamento de uso no Guia do administrador do sistema do
Sobre Conselhos de Promoção

A ECE oferece a capacidade de fornecer informações de Aconselhamento de
Promoção (AoP) que permitem ao operador notificar o cliente de que poderia ser
obtido um preço melhor para o serviço que está prestes a utilizar. A ECE fornece as
informações de AoP conforme definido pelo 3GPP (TS22.086). O operador pode

About Rerating
optar por utilizar estas informações de qualquer forma que seja relevante para o
serviço específico oferecido. Por exemplo, um operador de rede pode enviar as
informações da AoP em um anúncio de pré-chamada de IVR para um serviço de
voz.

About Session-Based Charging
A função AoP pode ser usada para notificar um cliente de um preço preferencial que
estaria disponível dentro da janela de tempo configurada. Se estiver disponível uma
taxa reduzida nesta janela, a AoP é devolvida com uma indicação do preço ao qual a
nova taxa seria aplicável.
Para dar suporte à AoP, a ECE determina se uma taxa melhor para usar um serviço
está disponível perto do momento em que a solicitação de uso do cliente é recebida. A
ECE retransmite essas informações para o programa de software de mediação de rede,
que passa a mensagem para o cliente.
A ECE implementa a AoP da seguinte forma:
1. Um cliente faz uma solicitação para iniciar uma sessão, para debitar um valor
específico ou calculado de um recurso ou para gerar uma estimativa de preço
para usar um recurso.
2. O servidor de carregamento ECE calcula a cobrança para a solicitação.
3. Se a AoP estiver ativada, a ECE adiciona um deslocamento de tempo à hora de
início e término da solicitação e recalcula a cobrança usando o período de
tempo de deslocamento (a nova hora de início e fim).
Você configura quanto de um deslocamento de tempo usar.
Consulte a discussão sobre a configuração de carregamento de uso
no Guia do administrador do sistema do BRM Elastic Charging Engine
para obter instruções.
4. Se a taxa recalculada for menos dispendiosa para o cliente, a ECE envia as
informações sobre potenciais poupanças para o programa de software de
mediação de rede na resposta de utilização.
A ECE aplica a AoP quando a AoP é configurada no nível do sistema ECE. Configure
o AoP no nível do sistema usando o serviço de configuração. Ver a discussão de
configuração de carregamento de uso no Guia de implementação do BRM Elastic Charging Engine
para obter informações sobre como configurar a AoP.
Observe os seguintes detalhes sobre a AoP:
■ A AoP não é configurável no PDC.
■ AoP é uma configuração de todo o sistema (não é configurado em uma base
por oferta de carga).
■ Por padrão, a AoP dá conselhos com base no tempo.
■ Ao aplicar a AoP, a ECE usa as ofertas de cobrança e ofertas de desconto que são
elegíveis quando a solicitação é recebida para recalcular a cobrança para o
período de tempo de compensação. Se uma oferta de cobrança diferente ou uma
oferta de desconto diferente se aplicar ao período de tempo de compensação
futuro, a AoP pode aconselhar uma promoção quando nenhuma existir ou pode
não aconselhar uma promoção quando uma estiver disponível.
Ao usar a AoP, certifique-se de que seus planos de taxas tenham o consumo
hierárquico configurado com precisão para evitar uma violação de crédito de
elementos de saldo não monetários.
Sobre o Controle de Crédito de Serviços Múltiplos

O ECE suporta solicitações de controle de crédito de vários serviços (MSCC) nas quais
um aplicativo Diameter executa o controle de crédito para vários serviços na mesma
sessão.
Uma solicitação MSCC é uma lista de subsolicitações direcionadas ao mesmo cliente e
que compartilham o mesmo tipo de operação e ID de sessão, mas se aplicam

About Multiple-Service Credit Control
individualmente a produtos diferentes.

About Session-Based Charging
Quando a ECE recebe solicitações MSCC, ela atribui uma ID de sessão diferente a
cada uma de suas subsolicitações. Isso permite que a ECE distinga uma
subsolicitação de outra ao procurar a sessão ativa associada a cada subsolicitação.
Uma solicitação MSCC resulta em uma resposta MSCC contendo uma sub-
resposta para cada subsolicitação. Cada sub-resposta contém o status que indica
se a subsolicitação foi bem-sucedida ou falhou.
Quando o ECE salva informações de eventos classificados para solicitações MSCC
no banco de dados Oracle NoSQL, observe os seguintes pontos:
■ As informações de eventos classificados são salvas para cada subsolicitação.
■ A chave NoSQL para o evento classificado é baseada na ID de sessão que a ECE
atribuiu (não baseada na ID de sessão de solicitação MSCC original).
■ O ID de sessão ECE no banco de dados Oracle NoSQL é composto pelo ID de
sessão da solicitação de uso original, o tipo de produto e a identidade do
usuário, separados por caracteres de sublinhado. Por exemplo:
ID da solicitação MSCC original: 1313b2ab-d51e-4545-8bba-25c731daf10b
Tipo de produto do pedido de utilização: VOZ
Identidade do usuário da solicitação de uso: 650123555
ID da sessão ECE: 1313b2ab-d51e-4545-8bba-25c731daf10b_VOICE_650123555
O suporte MSCC aplica-se a solicitações de uso e solicitações de consulta.
O suporte MSCC não inclui suporte para grupos de classificação (Rating-Group
par atributo-valor (AVP)), pools de crédito (G-S-U-Pool-Reference AVP onde as
unidades do tipo de serviço são agrupadas em um pool de crédito) e controle de
crédito (conforme descrito na seção 5.1.2 do IETF RFC 4006).
Consulte o programa de exemplo SampleMultipleServicesLauncher no ECE SDK
para obter um exemplo de como enviar solicitações MSCC para ECE. Para obter mais
informações, consulte a discussão sobre os programas de exemplo ECE no Guia de
Sobre o carregamento baseado em eventos

Para carregamento baseado em eventos, a solicitação de uso é para uso que foi
renderizado em uma única operação. A solicitação de uso pode ser recebida antes do
uso, durante o uso ou após a ocorrência do uso. Os dados para solicitações baseadas em
eventos normalmente são mapeados para os tipos de operação de débito, reembolso,
Balance_Query e cobrança de Price_Enquiry da ECE.
Sobre o carregamento baseado em sessão

Para carregamento baseado em sessão, a solicitação de uso enviada pelo sistema de
mediação on-line são relatórios de uso para uma sessão. O sistema de mediação on-
line usa os dados de contabilidade START, INTERIM e STOP, que são mapeados para
os tipos de operação ECE Iniciar, Atualizar e Encerrar.

About Discounts
Sobre os eventos com classificação no meio da sessão

Para permitir que o BRM reconheça a receita gerada durante as sessões de rede on-
line, a ECE deve criar eventos classificados e enviá-los para o BRM.
Por padrão, o ECE gera um evento classificado para uma sessão de rede somente
quando a sessão é encerrada por uma operação de término de diâmetro.
Algumas sessões, no entanto, como streaming de dados, duram dias, semanas ou até
meses. Se você não quiser esperar até o final de uma sessão longa para reconhecer a
receita da parte da sessão que os assinantes já consumiram, você pode configurar o
ECE para gerar um evento classificado sempre que uma operação de atualização do
Diameter ocorrer durante uma sessão de rede. Esses eventos são chamados de eventos
classificados no meio da sessão.
Os eventos classificados no meio da sessão permitem que o BRM reconheça a receita
incrementalmente durante longas sessões de rede, evitando que grandes quantidades
de uso não avaliado e receita não reconhecida se acumulem. Eles também permitem
que você mostre aos assinantes seu saldo de corrida ao longo de uma sessão.
Cada evento classificado no meio da sessão:
■ É considerado um registro separado por processos a jusante, como reclassificação
(tratada como sessões individuais) e faturamento (tratada como registros
individuais em faturas discriminadas).
■ Marca o fim de uma subsessão da sessão de rede. Para a subsessão
subsequente, os contadores de volume e duração da sessão de rede são
redefinidos para 0. Portanto, se você habilitar esse recurso, não baseie seu
preço no volume ou duração acumulados em uma sessão de rede.
■ Contém uma referência ao ID da sessão de rede e à operação de atualização
na qual ele foi criado.
Para configurar o ECE para gerar eventos classificados no meio da sessão, consulte a
discussão sobre como configurar o ECE para gerar eventos classificados no meio da
sessão no Guia de implementação do BRM Elastic Charging Engine.
Sobre os Descontos
O ECE suporta os seguintes recursos de desconto:
Nota: Descontos é um termo BRM. Na ECE, são normalmente

referidas como alterações.
Nota: As alterações estão sempre limitadas a um máximo de cem por

cento dos encargos.
■ Descontos percentuais
■ Descontos de montante fixo
■ Descontos diferenciados
■ Descontos baseados em limiares
■ Incrementos de desconto (batidas)
■ Suporte para os modos de desconto paralelo (carga original), sequencial (carga
restante) e quantidade (em cascata)

About Reservation Validity
■ Prioridades de desconto
As ofertas de cobrança e as ofertas de desconto têm uma prioridade atribuída a
elas. Quando um evento é classificado, a ECE aplica as ofertas na ordem de
prioridade.
Sobre a Gestão de Saldo

A ECE armazena a visão atual do saldo do cliente no sistema de cobrança. Os saldos
ativos dos clientes são atualizados em tempo real quando ocorrem transações de
solicitação de uso no Elastic Charging Server.
A ECE publica informações de eventos classificados (o resultado da cobrança do
processamento de solicitação de uso). Outros aplicativos no sistema de cobrança que
também armazenam saldos de clientes usam as informações de eventos classificados
para atualizar seus saldos de clientes. A ECE publica informações de eventos
classificados no banco de dados Oracle NoSQL.
Os dados do saldo do cliente são mantidos atualizados pelo Customer Updater, que
sincroniza os dados do BRM para o ECE quando a atividade para a conta do cliente no
BRM pode afetar a correção dos dados do saldo do ECE. Por exemplo:
■ A classificação e o desconto na ECE resultam em impactos no equilíbrio que
devem ser refletidos na base de dados BRM. Por exemplo, se um desconto
resultar na redução de um saldo de minutos livres, essa alteração deve ser
refletida no banco de dados BRM para que o saldo possa ser exibido com
precisão na Central de Atendimento ao Cliente. Essas atualizações são feitas no
banco de dados BRM pelo RE Loader quando ele carrega CDRs de eventos
classificados no BRM.
■ A atividade no banco de dados BRM afeta os saldos usados na classificação ECE.
Por exemplo, um cliente pode comprar um desconto que fornece 500 minutos
gratuitos ou um representante de atendimento ao cliente (CSR) pode lançar um
débito em um saldo. Estas alterações do saldo devem refletir-se no saldo gerido
na CEE. Quando essas alterações de saldo ocorrem, o BRM usa o DM de
sincronização de conta para enviar o impacto do saldo para a ECE. A ECE usa o
Customer Updater para carregar o impacto do saldo em caches ECE.
Sobre a distribuição de encargos

A ECE suporta a distribuição de encargos (referida como partilha de encargos em BRM).
A ECE pode suportar sistemas de faturação que permitem a partilha de grupos:
clientes que partilham descontos ou encargos com outros clientes. Por exemplo, a
ECE suporta grupos de partilha de descontos e grupos de partilha de encargos
definidos no BRM.
Os acordos de alteração e partilha de encargos entre clientes permitem a aplicação de
descontos e partilha de encargos no módulo de classificação ECE. A ECE suporta a
partilha de descontos e a partilha de encargos ao nível da conta e também ao nível do
produto. A ECE suporta apenas produtos para participar num acordo de alteração ou
partilha de encargos.
Sobre a Validade da Reserva

A ECE autoriza e reserva um saldo ou reserva ativa para um pedido de sessão. A ECE
baseia a reserva ativa nas unidades de serviço solicitadas da solicitação de sessão
(tipos de solicitação Iniciar ou Atualizar). A ECE envia o tempo de validade da
reserva ativa ou da validade da reserva de volta para o cliente de mediação de rede. A

About Discounts
validade da reserva especifica por quanto tempo uma sessão pode continuar antes
que o cliente solicite uma nova autorização de recursos para uso posterior.
A ECE envia uma expiração de reserva de volta para o cliente de mediação de rede. A
expiração da reserva especifica por quanto tempo uma sessão pode continuar antes que
o cliente deva relatar o uso consumido à ECE (relatar as unidades de serviço usadas).

About Policy-Driven Charging
Para obter informações sobre como configurar a validade de reserva e os valores de

expiração de reserva que a ECE envia de volta ao cliente de mediação de rede,
consulte a discussão sobre a configuração de regras de negócios de cobrança no Guia
de implementação do BRM Elastic Charging Engine.
Sobre a validade do primeiro uso

O primeiro uso do item de saldo no impacto do saldo define a validade. Quando a
ECE recebe uma solicitação de uso para a qual um cliente usa pela primeira vez um
item de saldo, a hora de início da validade é definida como a hora de início da sessão
da solicitação.
Quando o período de validade de um primeiro item de saldo de uso é definido, o
período de validade também deve ser atualizado no banco de dados BRM. O BRM
Gateway usa a estrutura de notificação para enviar as informações ao BRM. Quando
uma primeira validade de uso é inicializada, o ECE gera o evento de serviço
FirstUsageValidityInitializationEvent. O BRM Gateway usa o evento de serviço e
aciona o opcode no BRM para atualizar a validade do item de saldo no banco de
dados BRM.
Concedendo recursos de primeiro uso durante a classificação

A ECE pode conceder impactos de equilíbrio durante a classificação que tenham um
modo de validade definido para o primeiro uso. Por exemplo, você pode criar uma
oferta de cobrança que inclua estes impactos de saldo:
■ Debite 5 cêntimos por minuto se não houver minutos incluídos.
■ Crédito de 1 minuto por cada minuto pago a 5 cêntimos por minuto. Estes
minutos são válidos na primeira utilização.
Neste exemplo, as cobranças ocorrem da seguinte forma:
1. Um assinante esgotou todos os seus minutos incluídos e está a ser cobrado 5
cêntimos por minuto.
2. Após 10 minutos, o assinante encerra a chamada. O assinante tem direito a 10
minutos.
3. A próxima chamada que o assinante faz usa os 10 minutos gratuitos,
concedidos como impactos do saldo de primeiro uso.
Você também pode conceder impactos no saldo de primeiro uso usando um desconto.
Por exemplo, você pode criar:
■ Uma oferta de cobrança que cobra 5 cêntimos por minuto
■ Um desconto que credita uma mensagem SMS para cada
minuto chamado Neste exemplo, as cobranças ocorrem da seguinte
maneira:
1. Um assinante faz uma chamada de 10 minutos.
2. O assinante encerra a chamada. O assinante recebe 10 mensagens SMS,
válidas no primeiro uso, com uma data de término de validade após 30 dias.
Para obter mais informações sobre como criar ofertas de produtos, consulte a documentação
do PDC.
Sobre a classificação reversa

About First-Usage Validity
A classificação inversa significa que a ECE usa o limite de crédito do cliente para
calcular a quantidade de uso que o cliente pode pagar por um serviço solicitado antes
que o serviço seja entregue. Para carregamento online baseado em sessão, o ECE
suporta classificação inversa. Para carregamento baseado em eventos, o ECE suporta
classificação reversa para solicitações de débito.

A ECE executa a classificação inversa da seguinte forma:

1. O ECE recebe uma solicitação de uso do tipo de operação Iniciar, Atualizar ou
Débito para uma quantidade de recurso solicitada.
2. A ECE calcula os encargos para o pedido de utilização com base na oferta de
produtos associada ao cliente. Uma oferta de produtos representa os produtos
disponíveis para os seus clientes e o preço desses produtos.
3. Quando o resultado nominal do cálculo da cobrança é aplicado ao saldo do
cliente, o impacto no saldo excede o limite de crédito do cliente para a
quantidade de recursos solicitada.
4. A ECE determina a quantidade do elemento de saldo que pode ser autorizado
com base no limite de crédito do cliente e devolve a quantidade na resposta de
utilização ao programa de software de mediação de rede.
Quando a ECE executa a classificação reversa para um serviço no qual os eventos são
classificados usando várias métricas de uso ratable (RUMs), você pode configurar
opções de arredondamento. Consulte a discussão sobre classificação reversa quando
a classificação é baseada em vários RUMs no Guia de implementação do BRM Elastic
Charging Engine para obter detalhes. A ECE também pode arredondar os resultados
dos seus cálculos de quantidade máxima para o número inteiro mais próximo.
Sobre o carregamento orientado por políticas

A ECE suporta o carregamento orientado por políticas. A cobrança orientada por
políticas implementa políticas de rede, cliente e serviço que podem ser usadas pelos
provedores de serviços para melhorar a experiência do cliente e fazer uso eficiente
dos recursos da rede. Os provedores de serviços podem usar políticas por vários
motivos, como controlar o uso de dados, definir a qualidade do serviço (QoS), alocar
quantidades de largura de banda para cada serviço, impor controles parentais,
implementar regras de cobrança e assim por diante.
As políticas podem ter reconhecimento de serviço e rede. Podem ser criadas políticas
com reconhecimento de rede para tecnologias de acesso específicas em que a condição
da rede pode alterar dinamicamente os preços. Políticas com reconhecimento de
serviço podem ser criadas para fornecer controle sobre como um cliente consome
recursos de rede.
O ECE suporta carregamento orientado por políticas com base no PCRF, definido na
especificação 3GPP TS 23.203 v9.9.0 (2011-06).
Para dar suporte ao carregamento orientado por políticas, a ECE expõe as seguintes
informações em seu
grade de dados na memória para clientes de política, como programas de software de
mediação de rede. Os clientes de política usam as APIs de gerenciamento de políticas
da ECE para recuperar as informações e enviá-las para o PCRF:
■ Informações sobre o rótulo da política
Os programas de imposição de políticas no PCRF usam rótulos de política, como
rótulos de status. Por exemplo, um rótulo de QoS pode ser definido como QoS
normal ou baixo, conforme mostrado abaixo:
<policy_label>
<label>Basic Subscription</label>
<resource_code>MBU</resource_name>
<resource_id>100012</resource_id>
<unidade>megabyte</unidade>
<camadas>
<camada>

About First-Usage Validity
<range_start>0</range_start>
<range_end>300</range_end>
<status_label>QoS normal</status_label>

Server Initiated Reauthorization Requests
</animal>
<camada> <range_start>301</range_start>
<status_label>baixa QoS</status_label>
</níveis>
</policy_label>
</policy_labels>
As informações do rótulo da política são armazenadas no objeto de perfil de

oferta no BRM. A ECE extrai essas informações em sua grade de dados quando
extrai dados do cliente do BRM e envia as informações do rótulo de status para
o programa PCRF quando solicitado.
Nota: O perfil da oferta é um objeto de preço reutilizável. Você cria

perfis de oferta no BRM e associa perfis de oferta a ofertas de cobrança
e ofertas de desconto no PDC usando tags de provisionamento. O
nome do rótulo definido no perfil da oferta é definido como um
parâmetro na conta do cliente.
■ Informações sobre o contador de políticas

A interface Sy da API de política Java da ECE transfere informações do contador
de políticas da ECE para clientes de políticas; Ele fornece relatórios de status do
contador de políticas e notificações de alteração de status do contador de
políticas.
Os contadores de políticas rastreiam o uso de um serviço por um cliente. Por
exemplo, o ECE rastreia quantos megabytes de dados um assinante baixou. O
cliente de política recupera os contadores de política da ECE e os envia para o
PCRF para avaliação.
■ Informações sobre as preferências do subscritor
A ECE armazena as preferências do assinante associadas à forma como o cliente
gostaria de receber notificações de políticas. Os clientes de política podem
recuperar esses dados do ECE usando a interface Sp (implementada como Sh) da
API de política Java da ECE. As preferências do assinante, como as seguintes,
podem ser enviadas para o PCRF:
– Informações relacionadas ao carregamento do cliente (por exemplo, se
o cliente comprou um pacote Gold, Platinum ou Bronze)
– Canal preferido do cliente para receber notificações (por exemplo, e-mail ou
SMS)
– Língua do cliente
Para dar suporte ao carregamento orientado por políticas, a ECE publica notificações
de políticas. Os perfis de oferta podem armazenar definições de limite para recursos
específicos. A ECE pode usar as definições de limite para publicar notificações quando
os limites são violados (notificações SpendingLimit). Além disso, quando as
preferências de assinante de um cliente mudam, a ECE publica notificações com as
informações de preferência novas ou alteradas (notificações SubscriberPreferences). A
ECE envia notificações para a fila de notificações JMS. O cliente de política, como o
Diameter Gateway, escuta na fila e usa os dados nas notificações para enviar
mensagens Sy e Sp para o PCRF.
A ECE publica notificações de políticas apenas para produtos com sessões de políticas
ativas. Quando o cliente de política inicia sessões de política, ele se inscreve para
receber as notificações de política em nome do PCRF.

Quando um cliente compra um novo produto, o PCRF consultará novamente o rótulo
e o contador de políticas (dados Sy) para que possa assinar os contadores adicionais
associados ao novo produto.

Server Initiated Reauthorization Requests
Para obter mais informações sobre notificações de política, consulte "Sobre

notificações usadas por clientes de política".
Para obter uma visão geral de como a ECE processa solicitações de sessões de
política, consulte "How ECE Processes Policy Requests for Online Network
Mediation Software".
Para obter informações sobre a API de gerenciamento de políticas ECE, consulte
a discussão sobre a integração de clientes de política com a ECE no Guia de
Sobre produtos de assinatura e produtos de sócio

A ECE suporta produtos de subscrição e produtos para membros (referidos como
serviços de subscrição e serviços para membros em BRM). A ECE pode avaliar a
utilização das subscrições dos clientes.
Consulte a discussão sobre o gerenciamento de serviços de nível de assinatura do
cliente na documentação do BRM para obter informações sobre como configurar
serviços para rastrear e classificar o uso e criar faturas para as assinaturas dos
clientes.
Carregamento de Eventos com Reserva de Unidade

Para carregamento on-line, a ECE está alinhada com o Diameter Credit Control
Application (DCCA) definido no RFC 4006 em apoio ao carregamento de eventos com
reserva de unidade (ECUR).
Carregamento de sessão com reserva de unidade

Para o carregamento on-line, o ECE está alinhado com o DCCA definido no RFC
4006 em suporte ao carregamento de sessão com reserva de unidade (SCUR).
Carregamento imediato de eventos

Para carregamento on-line, a ECE se alinha com o DCCA definido na RFC 4006 em
suporte ao carregamento imediato de eventos (IEC). Para IEC, a solicitação de uso é
para uma operação de débito direto. A operação de débito direto pode ser realizada
antes da entrega do serviço.
Solicitações de reautorização iniciadas pelo servidor

O ECE suporta solicitações de reautorização (RARs) iniciadas pelo servidor.
O ECE pode executar a reautorização iniciada pelo servidor durante uma sessão em
andamento. Isso permite que você atualize uma sessão em resposta a alterações que
ocorrem nas ofertas de produtos ou no saldo de um cliente (por exemplo, uma
alteração em uma oferta de cobrança ou em uma promoção de Amigos e Familiares).
Quando a ECE notifica a rede, a rede envia um pedido de reautorização e, se houver
uma alteração na carga, a ECE pode basear a reautorização na nova carga.
Uma reautorização iniciada pelo servidor pode ser acionada a partir das seguintes
condições:
■ Alterações às ofertas, tais como a criação, modificação ou eliminação de uma
oferta de cobrança ou oferta de alteração de um subscritor.
■ Alterações nos saldos que afetam a classificação (por exemplo, um recurso que

expira
no meio da sessão, um recurso que fica disponível a partir de uma recarga ou
alterações no saldo do cliente devido a uma ação de contas a receber).

About Processing Delayed Usage Requests
■ Alterações a promoções, como alterações a Amigos e Família ou uma oferta de

Dia Especial.
■ Alterações na partilha de encargos ou grupos de partilha de alterações. Por
exemplo, um novo membro é adicionado ao grupo ou um membro é
removido no meio da sessão.
Por exemplo:
1. Um assinante está em uma sessão de chamada. O subscritor adiciona o
número de chamada dessa sessão a uma lista de Amigos e Familiares.
2. Como um desconto para amigos e familiares pode alterar o valor da
cobrança, a ECE envia uma solicitação para a rede.
3. Em resposta, a rede envia um pedido de reautorização.
4. A ECE envia uma reautorização, utilizando o valor da cobrança de Amigos e Familiares.
Observação: uma solicitação de reautorização não é acionada por

uma recarga ou reclassificação quando recursos são adicionados à
conta do proprietário de um grupo de compartilhamento.
Para configurar a reautorização iniciada pelo servidor, habilite as notificações RAR

assíncronas. Você também define a variável offerEligibilitySelectionMode do
MBean charging.server. Para obter mais informações sobre como configurar a
reautorização iniciada pelo servidor, consulte a discussão sobre a configuração de
opções de tempo de execução no Guia de implementação do BRM Elastic Charging Engine.
Sobre o Apoio Fiscal

A ECE apoia um imposto de taxa fixa (uma tributação fixa também conhecida
como GST ou IVA). Você pode aplicar um imposto sobre encargos e
alterações (descontos).
As taxas de imposto são configuráveis através de configurações de parâmetros de
negócios ECE, os códigos fiscais criados em BRM devem ser configurados novamente
em ECE. Você pode usar o serviço de configuração para configurar parâmetros de
tributação. É necessário definir parâmetros obrigatórios para que a tributação
funcione no ambiente de tempo de execução ECE. Consulte a discussão sobre a
configuração de carregamento de uso no Guia de implementação do BRM Elastic
Charging Engine para obter instruções sobre como configurar a tributação.
A ECE não apoia a tributação baseada na jurisdição.
Sobre o uso de perfis de grupo de usuários fechados para determinar um preço

A ECE pode aplicar preços com base na participação de um assinante em um
grupo fechado de usuários. O grupo de utilizadores fechado deve estar na mesma
rede de operadores.
Os operadores podem criar grupos de utilizadores fechados ao nível do cliente ou ao
nível do produto, ou ambos. Os clientes tornam-se membros de um grupo de
utilizadores fechado quando compram uma oferta que tem um perfil de grupo de
utilizadores fechado associado à mesma.
As tarifas especiais para grupos de usuários fechados são determinadas por meio de

About Taxation Support
uma regra personalizada e seletor genérico que você configura em ofertas
responsáveis. Quando a ECE recebe um pedido para iniciar uma sessão de chamada
entre dois membros do mesmo grupo de utilizadores fechado, a ECE avalia os
encargos com base na configuração de regras personalizadas do seletor genérico e
determina o preço em conformidade.

About Processing Delayed Usage Requests
Quando os clientes chamados e os clientes que ligam têm mais de um grupo de

usuários fechado em comum, a ECE aplica o mesmo preço de grupo de usuários
fechados (a mesma tarifa ou desconto), independentemente do grupo. Para configurar
taxas diferentes para grupos diferentes, você pode usar extensões de pré-classificação
ECE. Os dados do perfil do cliente que efetua a chamada e do cliente chamado estão
acessíveis à extensão de pré-classificação ECE.
Para obter informações sobre como configurar uma regra personalizada para chamadas
de grupo de usuários fechados, consulte a discussão sobre a configuração de grupos de
usuários fechados no Guia do Usuário do PDC.
Para obter informações sobre como verificar se as chamadas de grupo de usuários
fechados são processadas pela ECE durante o teste, consulte a discussão sobre como
testar cenários de carregamento no Guia de implementação do BRM Elastic Charging
Engine.
Sobre a atribuição de impactos de saldo a itens de fatura

A ECE pode atribuir impactos de saldo para o mesmo evento a diferentes itens de
fatura com base nas regras configuradas.
Ao configurar como os impactos de saldo são atribuídos aos itens de fatura, os
operadores têm flexibilidade para classificar o uso em diferentes categorias de itens
de fatura (ou buckets). Por exemplo, se um operador definir itens de fatura
personalizados para chamadas internacionais e nacionais, o uso para cada tipo de
chamada pode ser contabilizado conforme necessário em itens de fatura separados.
Para atribuir impactos de saldo a diferentes itens de fatura, o ECE avalia uma regra
seletora de tipo de item em tempo de execução para derivar a quais tipos de item
atribuir impactos de saldo. A regra do seletor de tipo de item é uma expressão que
pode fazer referência a qualquer um dos seguintes atributos, ou a uma combinação
de:
■ Atributos do evento
■ Atributos do resultado da cobrança
As regras do seletor de tipo de item estão contidas nos seletores de tipo de item. Para
obter informações sobre como configurar seletores de tipo de item, consulte a
discussão sobre como configurar seletores de tipo de item no Guia do Usuário do PDC.
Sobre o processamento de solicitações de uso atrasado

Normalmente, a ECE recebe solicitações de uso durante o mesmo ciclo de contabilidade
em que o uso ocorreu. No entanto, algumas solicitações de uso são recebidas após o
final do ciclo contábil em que o uso ocorreu. Essas solicitações são chamadas de
solicitações de uso atrasado.
Se você configurou o faturamento atrasado no BRM, poderá configurar o ECE para
processar solicitações de uso atrasado para o ciclo de contabilidade no qual o uso
ocorreu se as solicitações de uso forem recebidas dentro do intervalo de tolerância de
atraso especificado. Isso estende a atribuição de item para esse ciclo contábil pelo
intervalo especificado para que os eventos nominais associados sejam atribuídos ao
item de fatura em aberto atual. Qualquer solicitação de uso atrasado recebida após o
intervalo especificado é processada somente para o próximo ciclo contábil e o evento
classificado associado é atribuído ao próximo item de fatura em aberto.
Para decidir a qual ciclo contábil a solicitação de uso atrasado pertence, a ECE
considera as seguintes datas:
■ A data em que o uso ocorreu.

About Taxation Support
■ A data atual do sistema.
■ A data em que o ciclo contabilístico corrente termina. É a chamada data do
próximo ciclo contabilístico.

■ O intervalo de tolerância de atraso, que é o número de dias após o término do
ciclo contábil atual durante o qual as solicitações de uso atrasado são
processadas para o ciclo contábil atual. Esse intervalo deve ser menor do que o
intervalo de faturamento atrasado (o valor da entrada config_billing_delay no
arquivo BRM_ home/sys/cm/pin.conf).
Por exemplo, considere as seguintes datas:
■ O uso ocorreu no dia 23 de outubro.
4
■ A data atual do sistema é 26 de outubro.
■ A data do próximo ciclo contabilístico é 25 de outubro.
■ O intervalo de tolerância ao atraso é de 4 dias (25 a 28 de outubro).
Nesse caso, se a solicitação de uso for recebida em 26 de outubro, a solicitação de uso
será processada para o ciclo contábil atual porque é recebida dentro do intervalo de
tolerância de atraso. Se a solicitação de uso for recebida em ou após 29 de outubro, ou
seja, após o intervalo de tolerância de atraso, a solicitação de uso será atribuída ao
próximo ciclo de contabilidade.
Para permitir que a ECE processe solicitações de uso atrasado para o ciclo de
contabilidade no qual o uso correspondente ocorreu, consulte a discussão sobre como
configurar a atribuição de itens no ECE para BRM no Guia de Implementação do BRM
Sobre o redirecionamento de sessões de assinante para um portal de serviços

Os prestadores de serviços podem redirecionar uma sessão de assinante para um
portal de serviços, um servidor fora do sistema de tarifação em linha, onde podem ser
oferecidos serviços específicos ao assinante. O ECE pode ser configurado para enviar
endereços de portal de serviço de volta aos clientes de controle de crédito em sua
resposta de uso. Os clientes de controle de crédito usam as informações para
redirecionar uma sessão (muitas vezes referida como redirecionamento) para o portal de
serviços aplicável ao cenário de negócios.
O redirecionamento é usado principalmente quando o assinante não tem mais um
saldo disponível para continuar a sessão sem uma recarga. O redirecionamento pode
ocorrer na última etapa de uma sessão em andamento onde não há mais saldo
disponível ou em quaisquer solicitações subsequentes para as quais nenhum saldo
está disponível (por exemplo, a conta está em um estado somente de recarga).
O redirecionamento também é usado para cenários de usuário em que o assinante
tem uma conta inativa.
Quando o cliente de controlo de crédito recebe da ECE a Indicação de Unidade Final
na resposta do CCA, o comportamento do cliente de controlo de crédito depende do
valor, TERMINATE ou REDIRECT, indicado no AVP de Final-Unit-Action. Se você
não configurar regras de redirecionamento no ECE, o ECE indicará uma Final-Unit-
Action de TERMINATE na resposta de uso.
Para obter informações sobre como configurar o ECE para redirecionar uma sessão
para um portal de serviços, consulte a discussão sobre a configuração de regras de
negócios para carregamento no Guia de implementação do BRM Elastic Charging Engine.

About Redirecting Subscriber Sessions to a Service Portal
Sobre solicitações de
uso
Este capítulo descreve como os programas cliente criam e enviam solicitações de uso
para o Oracle Communications Billing and Revenue Management (BRM) Elastic
Charging Engine (ECE).
Visão geral da solicitação de uso

A ECE pode processar solicitações de cobrança de rede de qualquer domínio de uso
(telco, pedágio, conteúdo e assim por diante). Os programas de software de mediação
de rede mapeiam atributos de uso que são relevantes para o carregamento das
solicitações de carregamento de rede para atributos de uso em solicitações de uso
ECE.
As solicitações de uso ECE contêm atributos fixos (obrigatórios) e uma carga útil
que contém atributos dinâmicos (configuráveis) para representar o uso do cliente.
Consulte a solicitação de uso Java API em BRM Elastic Charging Engine Java API
Reference para obter uma descrição detalhada dos atributos fixos e da carga útil.
Os programas cliente usam a API do Elastic Charging Client fornecida no ECE SDK
para criar e enviar solicitações de uso para o Elastic Charging Server.
Os programas cliente podem escolher entre o comportamento de contabilidade
incremental ou cumulativa ao instanciar o construtor de solicitações de uso. Consulte
a discussão dos conceitos de implementação no Guia de implementação do BRM
Elastic Charging Engine para obter mais informações.
Depois que os programas de software de mediação de rede criam solicitações de uso,
eles as enviam para o Elastic Charging Server (as instâncias do Elastic Charging
Server são chamadas de nós do servidor de carregamento ECE). Consulte a Referência
da API Java do BRM Elastic Charging Engine para obter informações sobre os métodos
que os programas de software de mediação de rede usam para enviar solicitações de
uso. Consulte os programas de exemplo ECE para obter exemplos de como as
solicitações de uso são criadas e enviadas ao Elastic Charging Server.
Os programas de software de mediação de rede criam pedidos de utilização quando
os pedidos de carregamento (online) ou CDRs (offline) são recebidos da rede. Os
programas chamam a API ECE para construir e enviar a solicitação de uso. Os
programas leem a resposta de uso retornada pelo Elastic Charging Server depois que
o Elastic Charging Server processa a solicitação de uso.
O Elastic Charging Server lê a solicitação de uso enviada, processa-a e envia uma
resposta de uso. O programa de mediação de rede chama a API ECE para ler a
resposta. Consulte "Sobre respostas de uso" para obter mais informações.

Como os sistemas de mediação de rede criam e enviam solicitações de uso
Os sistemas de mediação online e offline transformam os pedidos de carregamento
(carregamento online) e os CDRs (carregamento offline) recebidos da rede em
pedidos de utilização ECE.
Um programa chama a API ECE para construir e enviar a solicitação de uso. Para que
a ECE reconheça e possa processar os eventos carregáveis dentro das solicitações de
carregamento e CDRs, a solicitação de uso adere a um formato que serve para mapear
5
atributos da rede para definições de atributos descritas na linguagem ECE DSL. As
solicitações de uso contêm atributos fixos e dinâmicos. Consulte a discussão sobre
atributos fixos de solicitação de uso no Guia de implementação do BRM Elastic Charging
Engine para obter mais informações.
O ECE lê a solicitação de uso enviada, armazena-a em cache e envia uma resposta de
uso. O programa de software de mediação de rede chama a API ECE para ler a
resposta. Consulte "Sobre solicitações de uso" para obter mais informações.
Os atributos das solicitações de carregamento de rede ou CDRs que são relevantes
para o carregamento são mapeados para os campos na definição do evento. Esses
atributos ou cargas úteis são usados pela ECE para classificação.
Depois que a solicitação de uso é criada, o programa de software de mediação de rede usa o
método brs.submit() para enviar a solicitação de uso ao Elastic Charging Server.
About Usage Requests 4-1

How Network Mediation Systems Create and Submit Usage Requests
Sobre as respostas de
uso
Este capítulo descreve as respostas de uso que os servidores de carregamento do

Oracle Communications Billing and Revenue Management (BRM) Elastic Charging
Engine (ECE) podem retornar após o processamento de solicitações de uso.
Noções básicas sobre respostas de uso

Depois que a ECE processa uma solicitação de uso, a ECE envia uma resposta de uso
para o sistema que enviou a solicitação de uso.
O ECE retorna respostas de uso para o sistema de mediação de rede após o
processamento de solicitações de uso. As respostas de uso incluem códigos de motivo
para indicar como a solicitação foi processada no sistema. Para telecomunicações, a
resposta de uso é enviada de volta para o sistema de mediação de rede (ou para o
Diameter Gateway) após os cálculos de cobrança terem sido feitos e contém o
resultado da operação ChargingRequest.
Para carregamento offline, a ECE pode enviar uma resposta de uso negativa de volta
ao sistema de mediação de rede quando o CDR relacionado à solicitação de uso deve
ser suspenso. Uma resposta de uso negativa pode ocorrer se o cliente ainda não tiver
sido provisionado na ECE ou se o cliente não tiver uma oferta de preço que possa
classificar a solicitação.
Para carregamento online, a ECE pode enviar uma resposta de uso que contém uma
notificação na sessão sobre a sessão ativa do cliente. A notificação na sessão é um bloco
dentro da resposta de uso. Por exemplo, a ECE pode enviar uma notificação na sessão
sobre a elegibilidade de um cliente para uma tarifa melhor durante um período de
chamada (em apoio ao recurso Aconselhamento de Promoção) ou sobre as
informações de violação de limite de um cliente se ele violou um de seus limites de
crédito para um serviço específico. O FCE também pode enviar as informações de
saldo restante do cliente dentro da resposta de uso. O sistema de mediação de rede
pode usar os dados da notificação na sessão para enviar uma mensagem ao cliente.
Consulte "Sobre Conselhos de Promoção" para obter informações sobre os dados que
a ECE envia para o recurso Conselhos de Promoção. Consulte "Sobre notificações"
para obter mais informações sobre como configurar a estrutura de notificação ECE
para incluir notificações na sessão na resposta de uso.
Para obter informações sobre os diferentes códigos de motivo que a ECE retorna na
resposta de uso, consulte a documentação para
oracle.communication.brm.charging.messages.usage em BRM Elastic Charging
Engine Java API Reference.

6
About Usage Responses 5-1

6
Sobre as
notificações
A estrutura de notificação do Oracle Communications Billing and Revenue

Management (BRM) Elastic Charging Engine (ECE) publica eventos de notificação
que podem ser usados por sistemas externos. Por exemplo, para o carregamento
orientado por políticas,
programas de software relacionados a políticas (clientes de política) podem usar os
dados em eventos de notificação para enviar informações para a função de política e
regras de cobrança (PCRF). Este capítulo descreve a finalidade da publicação de
eventos de notificação e como o quadro de notificação os publica.
Consulte a discussão sobre a configuração de notificações no Guia de implementação
do BRM Elastic Charging Engine para obter informações sobre como configurar os
eventos de serviço que acionam a publicação de eventos de notificação.
Visão geral das notificações na ECE

A ECE suporta notificações na sessão e notificações assíncronas externas. Consulte os
tópicos a seguir para obter informações sobre cada tipo de notificação:
■ Sobre notificações na sessão
■ Sobre notificações externas
Você pode habilitar ou desabilitar a ECE de publicar notificações externas para vários
eventos que ocorrem no sistema ECE. Você pode ativar ou desativar o envio de ECE
notificações na sessão como parte da resposta de uso. Consulte a discussão sobre a
configuração de notificações no Guia de implementação do BRM Elastic Charging Engine
para obter mais informações.
Sobre notificações na sessão

As notificações na sessão são retornadas na resposta de uso ao sistema de mediação
de rede. O controlador de sessão de mediação online usa as informações de
notificação na sessão e as preferências do cliente para determinar as mensagens que
devem ser enviadas ao cliente.
O ECE suporta notificações na sessão para o cenário de cobrança de Advice of Charge
(AoC), além de suportar notificações externas assíncronas para AoC. As notificações
da AoC incluem os tipos de operação para indicar quando a notificação é acionada.
Para operações USAGE, as notificações AoC incluem o subtipo. Consulte "Sobre o
conselho de cobrança" para obter informações sobre a AoC. A ECE também suporta
notificações na sessão para cenários de violação de limite quando o saldo de um
cliente ultrapassa um valor de limite de crédito.
About Notifications 6-1

Overview of Notifications in ECE
Para obter detalhes sobre notificações na sessão retornadas na resposta de uso para
AoC, consulte a documentação para
oracle.communication.brm.charging.messages.usage em BRM Elastic Charging Engine
Java API Reference.
O ECE suporta notificações na sessão para cobrança orientada por políticas
publicando notificações externas assíncronas durante uma sessão de política. Os
clientes de política consomem os dados nessas notificações para enviar notificações na
sessão para o PCRF.
Para obter detalhes sobre as notificações na sessão retornadas na resposta
da política para cobrança orientada por política, consulte a documentação
para
oracle.communication.brm.charging.messages.policy na Referência da API Java do
Sobre notificações externas

Quando determinados eventos ou alterações de estado ocorrem no ECE, o ECE pode
publicar notificações externas assíncronas em uma fila JMS. As notificações externas
contêm as informações sobre o evento. Por exemplo, quando um cliente viola um dos
seus limites de crédito, a ECE publica o ThresholdBreachServiceEvent que contém as
informações sobre a violação, tais como o elemento de saldo (moeda ou não) e a
quantidade da violação (montante ou percentagem).
A carga útil de notificação externa publicada na fila JMS tem um formato XML bem
definido. Os sistemas externos analisam as cadeias de caracteres XML da carga útil
para obter as informações necessárias, como o elemento de balanço e o saldo atual e
assim por diante. As notificações externas são publicadas como cadeias de caracteres
XML na estrutura XML mostrada pelo arquivo
ECE_Home/oceceserver/config/Notification.xsd, onde ECE_Home é o diretório no qual
você instalou o ECE.
Para obter exemplos de cadeias de caracteres XML publicadas para diferentes tipos de
notificação, consulte a discussão sobre a configuração de notificações no Guia de
Exemplos de aplicativos clientes que obteriam informações de notificações externas
para seu próprio processamento são:
■ O sistema de mediação de rede pode usar dados na notificação externa com
dados de política do cliente para implementar o controle de diretiva de
rede.
■ O Oracle Communications Billing and Revenue Management (BRM) pode usar
dados na notificação externa para executar o faturamento de um cliente
específico. O BRM Gateway envia os dados relevantes para o BRM na notificação
externa para acionar o faturamento.
■ O BRM pode usar dados na notificação externa para atualizar o primeiro período
de validade de uso do item de saldo de um cliente. O BRM Gateway sincroniza
as configurações de validade de primeiro uso do ECE para o BRM quando as
notificações de primeiro uso são configuradas.
Eventos específicos do serviço ECE acionam a ECE para publicar notificações
externas. Você pode habilitar ou desabilitar cada um dos eventos de serviço para
acionar notificações externas. Consulte "Sobre eventos de serviço que acionam
notificações externas" para obter informações sobre os eventos de serviço para os
quais a ECE oferece suporte à publicação de notificações externas.
Você deve configurar as credenciais JMS para publicar notificações externas. Consulte
a discussão sobre a configuração de notificações no Guia de implementação do BRM
About Notifications Used by BRM
Elastic Charging Engine para obter instruções sobre como configurar as credenciais JMS
no ECE.
Consulte a discussão sobre a configuração de notificações no Guia de implementação do
BRM Elastic Charging Engine para obter informações sobre como ativar e desativar
notificações externas.

About Notifications Used by BRM
As notificações externas são publicadas pelo quadro de notificação. Consulte "Sobre a

estrutura de notificação" para obter informações sobre como configurar o ECE para
publicar notificações externas para vários eventos de serviço.
Sobre as notificações usadas pelo BRM

A ECE envia notificações ao BRM para sincronizar dados e acionar processos
necessários, como faturamento. Para obter mais informações, consulte a discussão
sobre a implementação do ECE com BRM no Guia de implementação do BRM Elastic
Charging Engine.
As seguintes notificações são normalmente ativadas como uma prática recomendada
ao integrar com o sistema BRM:
■ Notificações de faturação
Acionar o faturamento no BRM para um cliente específico (BillingServiceEvent).
Quando um assinante inicia uma sessão de cobrança perto do horário em que o
faturamento está definido para ser executado no BRM, a ECE cria o evento de
serviço BillingNotificationServiceEvent. Se as notificações estiverem habilitadas
para esse evento de serviço, quando esses eventos ocorrerem, a estrutura de
notificação publicará a notificação BillingNotificationServiceEvent na fila de
notificações JMS.
Quando uma notificação BillingNotificationServiceEvent é publicada na fila de
notificações JMS, o BRM Gateway, que escuta na fila, usa os dados do evento
para criar uma solicitação BRM. A solicitação BRM chama um opcode no BRM
para acionar o faturamento no BRM para o cliente.
Acionar o faturamento para um cliente quando o cliente inicia uma sessão de
cobrança perto do horário em que o faturamento está definido para ser executado
permite que o BRM aplique novas concessões de ciclo ao saldo do cliente e
processe quaisquer descontos ou dobras aplicados durante o faturamento.
Em seguida, o BRM envia as informações para a ECE, que atualiza o saldo do
cliente na ECE. Desta forma, os recursos associados a estas operações são repostos
na ECE, o que diminui o risco de terminar a sessão de cobrança por falta de
recursos se os recursos estavam baixos na conta quando a sessão de cobrança
começou. É uma prática recomendada habilitar notificações para esse evento de
serviço (configuração como ASSÍNCRONO).
Para o carregamento off-line, quando um assinante inicia uma sessão de cobrança
durante o período de cobrança atrasado, a ECE rejeita a solicitação de cobrança e
envia uma notificação ao BRM para acionar a cobrança parcial. Se novas
notificações de cobrança forem acionadas para o mesmo ciclo contábil, a ECE
detetará notificações duplicadas e enviará as notificações somente se elas não
forem enviadas anteriormente para o mesmo ciclo contábil.
As notificações externas são publicadas como cadeias de caracteres XML na
estrutura XML mostrada pelo arquivo
ECE_home/oceceserver/config/Notification.xsd.
■ Reabastecer notificações POID
Para acompanhar os impactos do saldo de um cliente para um determinado tipo
de item faturável, a ECE mapeia as combinações de tipo de produto e tipo de
evento em uma solicitação de uso para o tipo de item relevante. A ECE envia
informações para o BRM para que ele possa obter os POIDs quando não tem o
suficiente que pode ser usado (ReplenishPoidIDNotificationEvent).
■ Notificações de transição do ciclo de vida

Overview of Notifications in ECE
Quando o estado do ciclo de vida muda no ECE, essa notificação é usada para
sincronizar o estado com o BRM. Se o gerenciamento do ciclo de vida estiver
habilitado no ECE, isso notificará o BRM sobre quaisquer alterações no estado do
ciclo de vida do assinante (LifeCycleTransitionServiceEvent).

About Service Events that Trigger External Notifications
■ Primeiras notificações de inicialização de validade de uso

Sincronize a validade dos recursos de primeiro uso do ECE para o BRM
(FirstUsageValidityInitServiceEvent).
■ Notificações de recarga externa
Atualize os saldos no ECE e envie notificações para BRM
(ExternalTopUpNotificationEvent).
Sobre notificações usadas por clientes de política

Quando ocorrem alterações em contadores de política (saldos) ou preferências de
assinante relacionadas a políticas associadas a produtos que têm uma sessão de
política ativa, a ECE publica notificações assíncronas na fila de notificações JMS. Um
cliente de política que interage com a ECE se inscreve para receber as notificações de
política quando inicia as sessões de política. O cliente de política usa as informações
nas notificações para enviar mensagens Sy e Sp para o PCRF.
A ECE publica notificações de política para produtos que têm uma sessão Sy ativa se o
limite de saldo for violado devido a uma sessão de uso, a uma recarga de saldo ou a
uma atividade de assinatura. A ECE não gera notificações para violações de limite que
ocorrem fora de uma sessão Sy (quando o cliente não está usando o produto), pois
essas violações podem gerar notificações desnecessárias. Por exemplo, seria um
desperdício de recursos do sistema para a ECE publicar notificações de violações
causadas por redefinições mensais de licenças de recursos para produtos que não
estão a ser utilizados pelos clientes.
Para obter descrições da API Java dos objetos de evento de serviço publicados como
notificações de política, consulte a documentação para
oracle.communication.brm.charging.messages.policy em BRM Elastic Charging
Engine Java API Reference.
Para obter informações sobre a estrutura de dados XML das notificações de política
ECE, consulte a discussão sobre a integração da ECE com clientes de política no Guia
de implementação do BRM Elastic Charging Engine.
Notificações de limite de gastos

A ECE publica notificações do SpendingLimit quando deteta uma violação do limite
de política. A ECE gera uma notificação SpendingLimit quando o uso resulta em
uma violação de limite de níveis de política predefinidos. Uma violação de limite faz
com que a ECE envie um rótulo marcando essa condição para o PCRF. Com base
nesse rótulo, o PCRF tomará uma ação de política (como solicitar que o PCEF limite a
largura de banda, bloqueie um serviço e assim por diante).
A alteração do saldo do cliente pode ocorrer devido a qualquer um dos seguintes motivos:
■ Solicitações de uso provenientes do sistema de mediação de rede
■ Solicitações de atualização provenientes do BRM (como o sistema de gerenciamento de
clientes)
■ Recargas provenientes de sistemas de carregamento
A ECE verifica se há violações do limite de gastos e gera notificações para quaisquer
violações de produtos que tenham uma sessão de política ativa (sessão Sy).
A ECE administra verificações de limite durante o fluxo de processamento de uso (na
sessão) e durante o fluxo de atualização de saldo (fora da sessão) com base no saldo
atual e na reserva consumida do saldo do cliente.

About Service Events that Trigger External Notifications
Notificações de preferência do assinante

A ECE publica notificações de SubscriberPreference durante uma atualização do BRM
para as preferências do cliente presentes em um determinado produto. Por exemplo,
se um CSR adiciona uma preferência ao perfil de um cliente, modifica uma
preferência existente ou adiciona um novo tipo de preferência de cliente. A ECE
publica notificações SubscriberPreference apenas para subscrições ativas de dados do
Sp (SubscribeNotificationRequest).
Sobre eventos de serviço que disparam notificações externas

Quando determinadas alterações de estado ocorrem no sistema ECE, os eventos de
serviço são criados. Quando configurados, os eventos de serviço podem acionar a
publicação de eventos de notificação (notificações externas assíncronas). Consulte a
discussão sobre a configuração de notificações no Guia de implementação do BRM
Quando os seguintes eventos de serviço ocorrem, eles podem acionar a estrutura de
notificação para publicar notificações externas associadas a uma fila de notificações
JMS.
■ AdviceOfChargeServiceEvent
Consulte "Sobre o conselho de cobrança" para obter informações.
■ FirstUsageValidityServiceEvent
Consulte "Sobre a validade de primeiro uso" para obter informações.
■ ThresholdBreachServiceEvent
Consulte "Sobre notificações do tipo violação" para obter informações.
■ TopUpNotificationServiceEvent
Consulte "Sobre notificações de recarga" para obter informações.
■ BillingNotificationServiceEvent
Consulte "Sobre notificações de cobrança" para obter informações.
■ ReabastecerPoidId
Consulte "Sobre notificações usadas pelo BRM" para obter informações.
Sobre notificações de recarga

O ECE cria notificações de recarga em suporte a solicitações de reautenticação
iniciadas pelo servidor (RAR). Consulte "Solicitações de reautorização iniciadas pelo
servidor" para obter detalhes sobre como a ECE pode oferecer suporte ao RAR.
BRM Elastic Charging Engine para obter informações sobre como configurar essa
notificação.
Sobre notificações de cobrança

Quando um cliente inicia uma sessão de cobrança perto do horário em que a
cobrança está definida para ser executada no BRM, a ECE publica o evento de serviço
BillingNotificationServiceEvent. Se as notificações estiverem habilitadas para esse
evento, quando esses eventos ocorrerem, a estrutura de notificação publicará a
notificação BillingNotificationServiceEvent na fila de notificações JMS.

About Notifications Used by Policy Clients
BRM Elastic Charging Engine para obter informações sobre como configurar essa
notificação.

About the Notification Framework
Sobre notificações de tipo de violação

Ao realizar a cobrança de uso, a ECE pode gerar notificações relacionadas a violações
de limites e limites de crédito. Um aplicativo cliente pode usar essas informações
para enviar uma notificação de volta ao cliente de acordo com as preferências do
usuário do cliente. Por exemplo, pode ser enviado um e-mail ou um SMS para
informar o cliente de que um limite de crédito foi ultrapassado.
Se as notificações forem configuradas para violações nos limites e limites de crédito,
quando os eventos ocorrerem, a estrutura de notificação publicará uma notificação
para cada tipo de evento na fila de notificações JMS.
Consulte a discussão sobre a configuração de notificações no Guia de implementação
do BRM Elastic Charging Engine para obter informações sobre como configurar
notificações.
Para obter informações sobre notificações de limite orientadas por políticas, consulte
"Sobre notificações usadas por clientes de política".
Sobre as notificações de violação de limite

Quando o saldo de um cliente ultrapassa um valor de limite de crédito, a ECE publica
a notificação ThresholdBreachServiceEvent com informações sobre a violação, como o
valor do limite ou a percentagem do limite que foi violada.
Sobre as notificações de violação do teto de crédito

Quando o saldo de um cliente viola um limite máximo de crédito, a ECE publica a
notificação CreditCeilingBreachServiceEvent com informações sobre a violação, tais
como o código do elemento de saldo e o identificador de saldo correspondente à
violação.
Sobre as notificações de violação do piso de crédito

Quando o saldo de um cliente viola um limite mínimo de crédito, a ECE publica a
notificação CreditFloorBreachServiceEvent com informações sobre a violação, como o
código do elemento de saldo e o identificador de saldo correspondente à violação.
Sobre o Quadro de Notificação

A estrutura de notificação publica notificações na sessão e notificações externas
assíncronas. Quando determinadas alterações de estado ocorrem no sistema ECE, os
eventos de serviço são criados pelo Elastic Charging Server. A estrutura de
notificação, com base em como você configura o ECE, coloca os dados desses eventos
na resposta de uso (para uma notificação na sessão) ou em um evento de notificação
(para uma notificação externa) ou faz as duas coisas.
O quadro de notificação publica notificações externas de forma assíncrona. Para
publicar notificações externas, a estrutura de notificação transforma a carga Java de
eventos do serviço ECE em eventos de notificação que têm uma carga XML bem
definida. Esses eventos de notificação podem ser consumidos por outros sistemas para
processamento posterior.
A estrutura de notificação publica notificações externas para um tópico JMS em um
servidor JMS remoto. Você deve configurar um tópico de notificação em um servidor
JMS remoto e configurar as credenciais JMS no ECE para acessar esse servidor.
BRM Elastic Charging Engine para obter instruções sobre como configurar as
credenciais JMS no ECE.

About Breach-Type Notifications
A estrutura de notificação não é usada para receber mensagens de sistemas externos.

Transformando a carga útil Java do evento de serviço em XML

A estrutura de notificação transforma a carga Java do evento de serviço ECE em
XML. As cargas úteis publicadas na fila de notificação JMS (tópico JMS) são cadeias
de caracteres XML na estrutura XML mostrada pelo arquivo ECE_
Home/oceceserver/config/Notification.xsd.
Para obter exemplos de cadeias de caracteres XML publicadas na fila de notificações
do JSM para diferentes tipos de notificação, consulte a discussão sobre a configuração
de notificações no Guia de implementação do BRM Elastic Charging Engine.


U
m
Especificações e Conformidade com
Normas em
ECE
Este apêndice descreve as especificações e os padrões usados no Oracle

Communications Billing and Revenue Management (BRM) Elastic Charging Engine
(ECE).
Sobre especificações e conformidade com normas

A API de carregamento ECE está alinhada com as especificações RFC (Remote
Authentication Dial In User Service) Accounting Request for Comments (RFC) e com
as normas descritas nas Especificações Técnicas (TS) do Projeto de Parceria de 3ª
Geração (3GPP). O carregamento ECE suporta qualquer subdomínio 3GPP; alguns são
listados aqui como exemplos:
■ Conexões PS (Comutação de Pacotes)
■ Conexões CS (Circuit Switched)
■ WLAN (rede local sem fio)
■ IMS (Subsistema IP-Multimédia)
■ Interfaces PCRF (Policy and Charging Rules Function) e Sy/Sp (Sh)
A API de carregamento ECE é extensível; ele pode acomodar extensões proprietárias
das normas.
A API Java ECE alinha-se com os formatos de mensagem Diameter Ro, Diameter
CCA, Diameter Rf e RADIUS. Os programas de software de mediação de rede
(aplicações cliente) que suportam estes protocolos podem enviar pedidos de utilização
para a ECE.
As seguintes Especificações Técnicas (TS) 3GPP referem-se à funcionalidade de
carregamento ECE.
■ "3GPP TS 32.240 Gestão de Telecomunicações; Gestão de tarifação;
Arquitetura e princípios de carregamento" em:
http://www.3gpp.org/ftp/Specs/html-info/32240.htm
Para carregamento online, o ECE expõe uma API Java baseada no Diameter
Ro, que é extensível para suportar qualquer extensão ou variação. Os sistemas
Specifications and Standards Compliance in ECE A-1

de mediação online utilizam esta interface para enviar pedidos de utilização

para a ECE. O sistema de mediação on-line processa as solicitações Diameter e
mapeia o conteúdo das solicitações Diameter em solicitações de uso ECE.
A ECE implementa a seguinte funcionalidade para carregamento online,
conforme descrito no 3GPP TS 32.240:
– Módulos da função de carregamento online:
A-2 BRM Elastic Charging Engine Concepts

* Função de carregamento baseado em sessão (SBCF)
* Função de carregamento baseada em eventos (EBCF)
– Função de classificação (RF)
– Função de Gestão do Saldo de Conta (ABMF)
Carregamento do subsistema multimédia IP (IMS)":
Aplicações de carregamento de diâmetro":
Para carregamento offline, o ECE expõe uma API Java baseada em DIAMETER Rf,
que pode ser chamada a partir do sistema de mediação offline. A interface Java
tem funcionalidade próxima à da interface Rf descrita em 3GPP 32.299 e é
extensível para suportar qualquer extensão ou variação.
O Oracle Communications Offline Mediation Controller usa essa interface para
carregar CDRs no ECE para carregamento.
■ Os documentos do GB922 TM Forum Information Framework (SID) podem ser
descarregados a partir da seguinte localização:
https://www.tmforum.org/resources/suite/gb922-information-framework-r14
-5-1-pdf/
As RFCs RADIUS a seguir estão relacionadas à funcionalidade de carregamento ECE.
■ RFC 2865, "Remote Authentication Dial In User Service (RADIUS)," junho de
2000, RADIUS. Atualizado por: RFC 2868, RFC 3575, RFC 5080.
■ RFC 2866, RFC 2867, RFC 2868, RFC 2869, RFC 3579
O ECE está alinhado com a funcionalidade de carregamento de aplicativos de controle
de crédito de diâmetro descrita no Internet Engineering Task Force (IETF) Network
Working Group RFC 4006.
As seguintes Especificações Técnicas (TS) 3GPP referem-se à Função de Política e
Regras de Carregamento (PCRF) e ECE.
■ "3GPP TS 29.219 Policy and charging control: Spending limit reporting over
Sy reference point":
A interface Sy está localizada entre o PCRF e o Controlador de Mediação de Rede
Online. Permite a transferência de informações de gastos do cliente.
■ "Interface 3GPP TS 29.329 Sh baseada no protocolo Diameter":
A interface Sp (implementada como Sh) está localizada entre o SPR
(Subscription Profile Repository) e o PCRF. Ele permite a recuperação de
identidades de clientes e informações de perfil.
Specifications and Standards Compliance in ECE A-1

Glossário
conselho de responsabilidade (AoC)

Um serviço suplementar que informa os clientes sobre o custo de um serviço
solicitado em formato monetário ou não monetário.
aconselhamento de promoção (AoP)

Uma função de carregamento online através da qual pode informar os clientes de
uma possível promoção se estes solicitarem um serviço no futuro; por exemplo,
quando uma chamada cobraria menos em um período fora do horário de pico.
BRM Gateway
Um componente ECE que permite à ECE enviar dados para o servidor BRM para vários
fins; por exemplo, acionar a cobrança e atualizar os estados do ciclo de vida do
assinante.
protocolo de autenticação de handshake de desafio (CHAP)

Um protocolo de autenticação que autentica um usuário em uma entidade de rede;
por exemplo, a Web. Esse protocolo garante que o servidor envie um desafio para o
cliente depois que o cliente estabelece uma conexão de rede para acessar o servidor
Web.
nó de carregamento
Uma JVM (Java Virtual Machine) executando o Coherence que é membro do cluster
Coherence. Pode haver vários nós em um cluster de coerência. Um aplicativo cliente que
se torna um membro do cluster Coherence torna-se um nó no cluster. O Elastic
Charging Controller monitora e gerencia todos os nós definidos no arquivo de
topologia ECE.
Grupo de coerência
A grade de dados em uma máquina física da qual os nós ECE são membros. Os
aplicativos cliente que precisam enviar solicitações para a ECE devem ingressar no
cluster Coherence para acessar os dados em caches ECE e acessar outros serviços
necessários para enviar solicitações. Os aplicativos cliente usam a API do Elastic
Charging Client para ingressar no cluster Coherence.
Atualizador de clientes
Um componente ECE que mantém os dados do cliente no ECE sincronizados
com os dados do cliente no BRM.
Quando ocorrem alterações nos dados do cliente no BRM, o Customer Updater
atualiza automaticamente o cache do cliente ECE. O Customer Updater atualiza o
cache adicionando, modificando ou removendo dados conforme exigido pela
atualização.
Glossary-1
customerLoader
O Customer Updater é um componente que escuta em uma fila solicitações de

atualização do BRM. O Customer Updater é separado do customerLoader, que é
um utilitário para carregar dados do cliente no ECE a partir do arquivo.
customerLoader
Um utilitário usado para carregar dados do cliente no ECE a partir do arquivo. O
utilitário customerLoader carrega dados que foram extraídos anteriormente do BRM
pelo Oracle Data Integrator. customerLoader carrega os dados dos arquivos de dados
XML do cliente ECE no cache do cliente do Elastic Charging Server.
Solicitação de uso atrasado

Uma solicitação de uso recebida após o final do ciclo contábil no qual o uso ocorreu.
Por exemplo, se o ciclo contábil atual terminar em 25 de outubro, a solicitação de uso
recebida após 25 de outubro para o uso que ocorreu antes de 25 de outubro (suponha
23 de outubro) será chamada de solicitação de uso atrasado.
Gateway de diâmetro
Um componente ECE que serve como servidor front-end do Sistema de Carregamento
Online (OCS) para o sistema BRM. Ele processa solicitações de rede para interfaces
Gy, Sy e Sh Diameter. Atua como um Servidor de Diâmetro e apresenta o BRM Elastic
Charging Engine à rede como uma Aplicação de Controlo de Crédito de Diâmetro. Ele
traduz solicitações Diameter recebidas de clientes Diameter (por exemplo, servidores
de aplicativos, servidores de políticas ou IMS-GWFs) em solicitações de API Java do
Elastic Charging Engine. Ele traduz a resposta do Elastic Charging Server de volta em
solicitações Diameter e responde de volta ao Diameter Client solicitante.
máquina de driver
A máquina de driver é a máquina na qual você instalou o ECE e a máquina usada
para administrar o sistema ECE. A máquina do driver é o servidor configurado para
ser a máquina do administrador principal. Como prática recomendada, você não
instala nós ECE na máquina do driver; Instalá-los em máquinas remotas separadas
(máquinas de servidor).
Cliente de carregamento elástico

A biblioteca de cliente que permite que os aplicativos cliente se conectem ao cluster e
criem solicitações de uso para envio ao Servidor de Carregamento Elástico. O Elastic
Charging Client é usado para enviar todos os tipos de solicitações: solicitações de uso,
solicitações de consulta, solicitações de atualização e solicitações de gerenciamento.
Quando os aplicativos cliente iniciam o Elastic Charging Client, eles se juntam
automaticamente ao cluster. Como membro do cluster, os aplicativos têm acesso aos
caches de dados do nó ECE e aos serviços necessários para enviar solicitações.
Controlador de carregamento elástico

O aplicativo de linha de comando ECE usado para gerenciamento operacional de nós
ECE no cluster.
Protocolo de autenticação extensível (EAP)

Um protocolo de autenticação que suporta vários mecanismos de autenticação usados
para RADIUS; por exemplo, EAP-Tunneled Transport Layer Security.
Gateway do Gerente Externo

O componente ECE que converte uma flist de entrada de opcode BRM em uma
solicitação ECE e converte a resposta ECE subsequente de volta em uma flist de
saída de opcode BRM. O Gateway do Gerente Externo (EM) atua como um cliente
para o Servidor de Carregamento Elástico, enviando
Glossary-2
Oracle NoSQL Database
solicita-lhe da BRM. Por exemplo, o EM Gateway é usado para enviar solicitações de

reclassificação e solicitações de consulta de saldo do BRM para a ECE.
Cache de identidade
O cache de identidade armazena as informações públicas de identidade do usuário
dos clientes; por exemplo, o número de telefone do cliente, a Identidade Internacional
de Assinante Móvel (IMSI) e o endereço SIP (Session Initiation Protocol).
JConsole
A interface gráfica do usuário JConsole é uma ferramenta de monitoramento que está
em conformidade com a especificação Java Management Extensions (JMX). Você pode
usar JConsole e outros editores JMX para editar MBeans ECE.
Nó habilitado para gerenciamento JMX

Um nó ECE que tem uma porta JMX especificada e tem o parâmetro start CohMgt
definido como true no arquivo de topologia ECE. Quando esse nó é iniciado, ele
fornece um serviço de gerenciamento JMX no host e na porta especificados, que é
usado para expor MBeans de configuração ECE. Isso permite que você edite os
atributos MBean usando um editor JMX, como JConsole. Você designa apenas um nó
como um nó habilitado para gerenciamento JMX para cada endereço IP exclusivo em
sua topologia.
evento classificado no meio da sessão

Um evento nominal gerado quando ocorre uma operação de atualização do Diameter
durante uma sessão de rede. Por padrão, o ECE gera eventos classificados para uma
sessão de rede somente quando uma operação de encerramento de diâmetro termina
a sessão. Para evitar esperar até o final de uma sessão longa para reconhecer a receita
da parte da sessão que os assinantes já consumiram, no entanto, você pode configurar
o ECE para gerar eventos classificados no meio da sessão sempre que uma operação
de atualização do Diameter ocorrer em uma sessão em andamento.
servidor de acesso à rede (NAS)

Consulte servidor de terminal.
Quadro de notificação
Uma estrutura ECE que publica notificações assíncronas para uma fila de banco de
dados quando determinados eventos, ou alterações de estado, ocorrem no servidor de
carregamento ECE. Por exemplo, quando um cliente viola um limite de crédito, os
detalhes da violação do limite são publicados. Outras aplicações podem utilizar as
informações contidas nas notificações para o seu próprio processamento.
Integrador de dados Oracle (ODI)

ODI é usado para gerar arquivos de dados XML do cliente ECE. A ODI extrai dados
do cliente do banco de dados BRM e os transforma em formato de dados ECE XML.
Os dados extraídos do cliente BRM são carregados no ECE pelo utilitário
customerLoader.
Banco de dados Oracle NoSQL

O ECE usa o Oracle NoSQL Database para armazenar temporariamente informações
de eventos classificados. Os componentes ECE que interagem com o Oracle NoSQL
Database são Rated Event Publisher e Rated Event Formatter. O Rated Event
Publisher publica dados no armazenamento de dados NoSQL. O Rated Event
Formatter formata informações de eventos classificados para outros aplicativos
usarem; ele também exclui os eventos classificados do banco de dados NoSQL uma
vez que esses eventos classificados são processados.
Glossary-3
payload
carga útil
Os campos na especificação de solicitação que são relevantes para o carregamento de
uso. Os campos são usados para criar expressões de plano de taxa que a ECE usa para
processar o carregamento de uso. operações.
protocolo de autenticação de senha (PAP)

Um protocolo de autenticação que usa o nome de usuário e a senha para validar usuários.
Atualizador de preços
Um processo que carrega dados de preços do Centro de Design de Preços e atualiza o
cache de preços do ECE quando alterações nos dados de preços são publicadas do
Centro de Design de Preços.
preçosLoader
Um utilitário que carrega dados de preços de um arquivo XML no ECE.
pricingLoader só é usado em instalações de teste ou autônomas nas quais o
Oracle Communications Pricing Design Center (PDC) não é usado.
O Atualizador de Preços carrega dados de preços no ECE automaticamente quando
você publica dados de preços no PDC para ECE. Não misture a execução de
pricingLoader e Pricing Updater na mesma implantação ECE.
RADIUS Gateway
Um componente ECE que serve como servidor front-end do OCS para o sistema BRM
que processa solicitações de autenticação e contabilidade de clientes RADIUS. Atua
como um servidor RADIUS e apresenta o BRM Elastic Charging Engine à rede como
uma aplicação RADIUS. Ele traduz solicitações RADIUS recebidas de clientes
RADIUS em solicitações de API Java ECE. Ele traduz a resposta do Elastic Charging
Server de volta em solicitações RADIUS e responde de volta ao cliente RADIUS
solicitante.
Evento classificado Formatter

Um processo ECE que lê informações de eventos classificados do Banco de Dados
Oracle NoSQL e formata as informações conforme exigido por outros aplicativos que
precisam usar as informações. Ele também exclui os eventos classificados do Banco de
Dados NoSQL assim que os eventos são processados.
Editor de eventos avaliado

Um processo ECE que publica informações de eventos classificados no banco de dados Oracle
NoSQL.
Serviço de Discagem de Usuário de Autenticação Remota (RADIUS)

Um protocolo padrão do setor para processar solicitações de autenticação, autorização
e contabilidade (AAA). Os servidores de terminal usam o protocolo RADIUS para
comunicar solicitações AAA e retornar resultados de um banco de dados de
informações do cliente. A ECE implementa protocolos RADIUS para autenticação e
contabilização usando o Gateway RADIUS.
solicitar dados de especificação

Dados que definem a carga útil de uso (atributos de classificação) que a ECE pode
aceitar ao processar solicitações de uso. As cargas úteis são campos relevantes para o
carregamento de utilização. Os campos são usados para criar expressões de plano de
taxa que a ECE usa para processar operações de cobrança de uso. As cargas úteis e os
atributos de rede compõem a definição de evento dos seus eventos. Você executa a
definição de evento no PDC. Quando você publica sua definição de evento na ECE (do
Glossary-4
usage response
PDC por meio do Atualizador de preços), os dados de especificação da solicitação são
gerados e publicados automaticamente na ECE.
Glossary-5
usage response
simulador
A ferramenta ECE usada para emular a função de um programa de software de
mediação de rede (aplicativo cliente) enviando solicitações para ECE.
máquina de estado
O aplicativo que monitora todos os estados da ECE.
servidor de terminal
Um servidor ao qual seus clientes se conectam ao discar para seus serviços IP.
Também conhecido como Servidor de Acesso à Rede (NAS).
arquivo de topologia
O arquivo (ECE_Home/oceceserver/config/eceTopology.conf, onde ECE_Home é o
diretório no qual você instalou o ECE) que descreve todos os nós ECE no cluster
Coherence. O arquivo de topologia define o nome, a função, o host físico e a preferência
do arquivo de ajuste da JVM para cada nó. O Elastic Charging Controller (ECC) lê seu
arquivo de topologia para saber onde todos os nós do cluster estão localizados.
pedido de utilização
Uma solicitação no formato de idioma específico do domínio ECE enviada à ECE a
partir de aplicativos cliente, como programas de software de mediação de rede, para
cobrar o uso de um produto por um cliente.
Os aplicativos cliente constroem solicitações de uso e as enviam para a ECE. Por
exemplo, um programa de software de mediação de rede envia solicitações de uso para
a ECE para que o carregamento on-line ou off-line do uso da rede possa ser executado.
As solicitações de uso contêm cargas úteis exigidas pela ECE para calcular encargos,
como a duração da chamada, o volume de dados usado e assim por diante. As
solicitações de uso seguem o formato definido pelos dados de especificação de
solicitação ECE.
Resposta de uso
Uma resposta do Elastic Charging Server ao aplicativo cliente que enviou uma
solicitação de uso para a ECE.
Glossary-5
usage response
Glossary-6

Conceitos Do Oracle Communications Billing and Revenue Management Elastic Charging Engine

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Conceitos Do Oracle Communications Billing and Revenue Management Elastic Charging Engine

Enviado por

Direitos autorais:

Formatos disponíveis

Oracle® Communications Billing e Gestão de

1 Visão geral do motor de carregamento elástico

2 Arquitetura do sistema ECE

4 Sobre solicitações de uso

5 Sobre as respostas de uso

Um Conformidade com especificações e normas na ECE

Acesso ao Suporte Oracle

Acessando a documentação do Oracle Communications

Histórico de Revisões de Documentos

Versão Data Descrição

Sobre o Elastic Charging Engine

Overview of Elastic Charging Engine 1-1

1-2 BRM Elastic Charging Engine Concepts

1. O sistema de mediação de rede online recebe eventos de carregamento da rede.

Figura 1–2 Sistema de mediação on-line e ECE

Overview of Elastic Charging Engine 1-3

3. O sistema de mediação de rede offline transforma os CDRs em solicitações

Figura 1–3 Sistema de mediação offline e ECE

Sobre ECE e PDC

1-4 BRM Elastic Charging Engine Concepts

Overview of Elastic Charging Engine 1-5

Sobre ECE e BRM

Sobre os clientes ECE e Policy

1-6 BRM Elastic Charging Engine Concepts

Overview of Elastic Charging Engine 1-7

Figura 1–4 ECE e integração do cliente de políticas

1-8 BRM Elastic Charging Engine Concepts

Solicita os contadores de política para um produto específico e se inscreve

Overview of Elastic Charging Engine 1-9

1-10 BRM Elastic Charging Engine Concepts

9. A ECE publica notificações de políticas para o seguinte:

Integração de aplicações de carregamento com ECE

1-8 BRM Elastic Charging Engine Concepts

Overview of Elastic Charging Engine 1-9

solicitações no Guia de implementação do BRM Elastic Charging Engine para obter

1-10 BRM Elastic Charging Engine Concepts

Overview of Elastic Charging Engine 1-11

Este capítulo descreve a arquitetura do sistema Oracle Communications Billing and

Visão geral da arquitetura do sistema ECE

ECE System Architecture 2-1

automaticamente no cluster que fornece acesso aos caches de dados do nó ECE e

2-2 BRM Elastic Charging Engine Concepts

Consulte "Sobre o cliente de carregamento elástico" para obter mais informações.

ECE System Architecture 2-3

2-4 BRM Elastic Charging Engine Concepts

Um operador de sistemas que deseja monitorar o sistema ECE e executar tarefas

Sobre os principais componentes ECE no cluster

ECE System Architecture 2-3

Sobre o Diameter Gateway

Sobre o gateway RADIUS

Importante: O Gateway RADIUS é um componente opcional que

O Gateway RADIUS converte solicitações RADIUS recebidas de clientes RADIUS em

2-4 BRM Elastic Charging Engine Concepts

ECE System Architecture 2-5

O RADIUS Gateway fornece interfaces personalizadas para processar solicitações de

Sobre o Elastic Charging Server

Sobre a alta disponibilidade com o Elastic Charging Server

2-6 BRM Elastic Charging Engine Concepts

■ Armazenamento de informações em vários nós em vários servidores físicos e

Sobre o cliente de carregamento elástico

Sobre o Elastic Charging Controller

2-8 BRM Elastic Charging Engine Concepts

Sobre o Atualizador de Preços

Cuidado: O utilitário pricingLoader é usado para carregar dados