Aujourd'hui, de plus en plus d'entreprises souhaitent utiliser la notation en temps réel AAA GW, mais elles sont confrontées à de nombreuses questions. Dans cet article, nous répondrons à certaines d'entre elles, nous comparerons la notation conventionnelle par lots à la notation en temps réel et nous présenterons certains avantages de cette dernière.
Dans le cas d'une tarification par lots classique, toutes les données relatives aux événements sont lues à partir des fichiers CDR/EDR une fois les événements terminés. Les données relatives aux événements sont traitées, évaluées et facturées.
Dans la notation en temps réel, les données sont traitées lorsque des événements sont tentés ou même en cours. Les événements sont autorisés, réautorisés et, à la fin, facturés.
Lors de la planification d'un système en temps réel, celui-ci doit être conçu de manière à minimiser la possibilité d'interrompre les services ou d'encourir des pertes de revenus. Pour minimiser ces risques, il faut tenir compte de la latence, de l'architecture à haute disponibilité, de la séparation cm/dm par service pour faciliter la maintenance de la production, et d'une surveillance efficace.
Avec la tarification en temps réel, les utilisateurs de services prépayés et postpayés peuvent être pris en charge par un seul système - ce système est appelé facturation convergente. La facturation en temps réel offre encore plus d'avantages, tels que des limites de crédit postpayées et un retour d'information en temps réel sur l'utilisation du service par le client.
Dans l'un des prochains articles, plus de détails seront présentés concernant AAA GW, le flux d'interaction pour les appels (mbi,) et gprs/mms/sms (diameter.) Suivez-nous sur Twitter, et restez à l'écoute.
Bonjour,
C'est encore moi. Je suis intéressé par votre évaluation en temps réel. Je suis en train d'évaluer l'architecture mise en place par notre SI. Je ne citerai aucun nom. Comment classez-vous une architecture comme étant à haute disponibilité ? N'importe qui peut déclarer que son architecture est à haute disponibilité, mais quelle quantité de haute disponibilité est réellement une bonne haute disponibilité ? Y a-t-il des variables à prendre en compte ? Y a-t-il une formule spécifique à laquelle je puisse me référer ?
Une autre question concernant l'utilisation du protocole Diameter par AAA. Nous utilisons un pipeline pour traiter les paquets de diamètre, le gestionnaire de diamètre n'est pas mis en œuvre ici. Où puis-je trouver le fichier journal, car à l'époque, lorsque le gestionnaire IPT existait encore, vous pouviez trouver les fichiers journaux des paquets dans $PIN_HOME/apps/radius_ipt/radius_ipt.log, mais pour les paquets de diamètre, je suis désemparé.
Veuillez nous conseiller.
Merci d'avance.
Avis,
-Ayazul
Bonjour Ayazul,
Notre description de la haute disponibilité est la capacité d'un système à maintenir ses performances après la panne d'un ou de plusieurs serveurs. Une composante majeure de la haute disponibilité est le basculement, c'est-à-dire la capacité des connexions clients à passer d'un serveur en panne à un serveur en état de marche en cas de défaillance du serveur, ce qui permet aux applications clients de continuer à fonctionner.
Nous sommes d'accord avec vous pour dire que n'importe qui peut déclarer que son architecture est HA. Cependant, il n'est pas possible de donner une réponse simple à vos questions. Nous devrions d'abord analyser l'architecture HA du client, puis effectuer les tests nécessaires.
En ce qui concerne la deuxième question, vous pouvez généralement trouver les journaux des diamètres dans le répertoire /opt/portal/pre_dia/log.
Si vous souhaitez obtenir plus de détails, n'hésitez pas à nous contacter directement.
Je vous prie d'agréer, Madame, Monsieur, l'expression de mes salutations distinguées,
Ales
Bonjour,
Cela fait un certain temps que cet article a été publié. J'aimerais savoir si vous utilisez toujours Oracle BRM AAA GW ou Oracle BRM ECE ? Si vous utilisez ECE, veuillez partager votre approche, les défis et les leçons apprises.
Merci et meilleures salutations,
Khan
Dans un environnement de notation en temps réel, le pipeline AAA GW se bloque en raison d'un vidage du cœur de la mémoire après le traitement des demandes d'utilisation.
Le problème est reproduit en suivant les étapes suivantes :
1. démarrez un système de notation en temps réel avec les composants suivants : AAA GW, CM, Realtime Pipeline et DM_ORACLE.
2. Envoyez une demande au pipeline AAA GW. Ces demandes sont traitées sans problème.
3. Après quelques minutes, un core dump est produit par le processus pipeline IFW.
Quelqu'un peut-il nous aider à résoudre ce problème lié à Oracle BRM ?
Pour mettre en œuvre la solution, veuillez suivre les étapes suivantes :
1. Téléchargez et lisez le fichier readme du dernier ensemble de correctifs.
2. Assurez-vous d'avoir effectué une sauvegarde de votre système avant d'appliquer l'ensemble des correctifs recommandés.
3. Appliquez le correctif dans un environnement de test.
4. Testez à nouveau le problème.