Actualmente, cada vez mais empresas gostariam de utilizar a classificação em tempo real AAA GW, mas deparam-se com muitas questões. Neste artigo, algumas delas serão respondidas, a notação convencional por lotes será comparada com a notação em tempo real e serão apresentadas algumas vantagens desta última.
Na classificação convencional por lotes, todos os dados de eventos são lidos a partir de ficheiros CDR/EDR depois de os eventos já terem terminado. Os dados do evento são processados, classificados e carregados.
Na classificação em tempo real, os dados são processados quando os eventos são tentados ou mesmo em curso. Os eventos são autorizados, reautorizados e, no final, cobrados.
Ao planear um sistema em tempo real, este tem de ser concebido de forma a minimizar a possibilidade de interrupção dos serviços ou de perdas de receitas. Para minimizar essas perdas, é necessário ter em consideração a latência, a arquitectura de alta disponibilidade, a separação cm/dm por serviço para facilitar a manutenção da produção e a monitorização eficiente.
Com a classificação em tempo real, os utilizadores pré-pagos e pós-pagos podem ser acomodados num único sistema - um sistema deste tipo é designado por facturação convergente. A facturação em tempo real oferece ainda mais vantagens, tais como limites de crédito pós-pagos e feedback em tempo real após a utilização pelo cliente.


Num dos próximos artigos, serão apresentados mais detalhes sobre o AAA GW, o fluxo de trabalho de interacção para chamadas (mbi,) e gprs/mms/sms (diameter.) Siga-nos no Twitter e fique atento.
Hi,
Sou eu outra vez. Estou interessado na sua classificação em tempo real. Estou actualmente a avaliar a arquitectura estabelecida pelo nosso SI. Não vou mencionar nomes. Como é que classifica uma arquitectura como de alta disponibilidade? Qualquer pessoa pode declarar que a sua é HA, mas quanto HA é realmente uma boa HA? Há alguma variável que precise de ser considerada? Há alguma fórmula específica a que possa recorrer?
Outra questão, relacionada com o AAA que utiliza o protocolo diameter. Estamos a utilizar o pipeline para processar os pacotes diameter, o Diameter manager não está a ser implementado aqui. Onde posso encontrar o ficheiro de registo, porque na altura, quando o gestor do IPT ainda existia, pode encontrar os ficheiros de registo dos pacotes em $PIN_HOME/apps/radius_ipt/radius_ipt.log, mas para o pacote diameter, não tenho ideia.
Aconselhe-se.
Agradecemos-lhe desde já.
Cumprimentos,
-Ayazul
Olá Ayazul,
A nossa descrição de alta disponibilidade é a capacidade de um sistema manter o desempenho após a avaria de um ou mais servidores. Um dos principais componentes da alta disponibilidade é a transferência em caso de falha de um servidor, ou seja, a capacidade de as ligações dos clientes serem transferidas de um servidor inoperante para outro em funcionamento, permitindo assim que as aplicações dos clientes continuem a funcionar.
Concordamos com a sua afirmação de que qualquer pessoa pode declarar que a sua arquitectura é HA. No entanto, não é possível dar uma resposta simples às suas perguntas. Primeiro, teríamos de analisar a arquitectura HA do cliente e, em seguida, efectuar os testes necessários.
Quanto à segunda pergunta, em geral pode encontrar os registos de diâmetro no directório /opt/portal/pre_dia/log.
Se desejar obter mais informações, não hesite em contactar-nos directamente.
Com os melhores cumprimentos,
Cervejas
Hi,
Já passou algum tempo desde que este artigo foi publicado. Gostaria de saber se ainda está a utilizar o Oracle BRM AAA GW ou o Oracle BRM ECE? Caso utilize ECE, por favor partilhe a sua abordagem, desafios e lições aprendidas.
Obrigado e cumprimentos,
Khan
Num ambiente de classificação em tempo real, o pipeline AAA GW falha devido ao despejo do núcleo da memória após o processamento de pedidos de utilização.
O problema é reproduzido com os seguintes passos:
1.Inicie um sistema de classificação em tempo real com os seguintes componentes: AAA GW, CM, Realtime Pipeline e DM_ORACLE
2. Envie o pedido para o pipeline AAA GW. Estes pedidos são processados sem problemas.
3. Após alguns minutos, um core dump é produzido pelo processo IFW do pipeline.
Alguém pode ajudar neste problema do Oracle BRM?
Para implementar a solução, execute os seguintes passos:
1. Descarregue e reveja o readme do conjunto de patches mais recente
2. Certifique-se de que efectuou uma cópia de segurança do seu sistema antes de aplicar o conjunto de correcções recomendado.
3. Aplique a correcção num ambiente de teste.
4. Volte a testar o problema.