Gestion efficace du support pour E911 avec LWR sur PCRF multicluster

Introduction

Ce document décrit la gestion efficace du support pour les appels d'urgence tels que les appels E911 utilisant des machines virtuelles LWR et UDC, garantissant une configuration prioritaire, une fiabilité et une utilisation optimisée des ressources réseau.

Présentation de l'architecture

Les appels d'urgence E911 nécessitent une gestion prioritaire du support afin de garantir la qualité des appels et la disponibilité du réseau. La solution tire parti des machines virtuelles Lightweight Replication (LWR) et User Data Cache (UDC). LWR utilise en interne la base de données Kafka pour la réplication. Kafka assure une réplication à haut débit sur plusieurs clusters PCRF, ce qui permet un contrôle coordonné du support lors des appels d'urgence.

Cette fonctionnalité permet à PCRF de partager les informations de l'abonné, telles que le nombre d'APN connectés, l'état de notification et les états intermédiaires (comme la mise à jour et la libération du support).

Composants du cluster LWR

• Zookeeper : il est utilisé pour sélectionner un contrôleur, s'assurer qu'il n'y en a qu'un, et en sélectionner un nouveau s'il tombe en panne.Il gère l'appartenance au cluster (quels courtiers sont actifs et font partie du cluster) et supervise la configuration du sujet (quels sujets existent, combien de partitions chacun a, où sont les réplicas, qui est le leader préféré et quelles remplacements de configuration sont définis pour chaque sujet).

• Courtier : LWR utilise des services de courtage qui sont des files d'attente de messages s'exécutant sur l'hôte. Kafka broker reçoit des messages de producteurs et les stocke sur un disque dont la clé est un décalage unique.Il permet aux consommateurs de récupérer des messages par sujet, partition, décalage, et peut créer un cluster Kafka en partageant des informations entre eux directement ou indirectement en utilisant Zookeeper.
• MirrorMaker : Kafka MirrorMaker est utilisé pour mettre en miroir les données entre les clusters Kafka. Cela permet de créer des duplications de données d'un data center vers un autre. Plusieurs processus de mise en miroir peuvent être exécutés simultanément afin d'augmenter le débit et la tolérance aux pannes.

PCRF - Région LWR et configuration du sujet

En production, vous pouvez regrouper les PCRF dans plusieurs régions telles que l'ouest, le sud-est et le nord-est. Dans chaque région, il peut y avoir environ cinq à six noeuds PCRF qui sont interconnectés via LWR. PCRF écrit ou met à jour les données sur LWR chaque fois que certains événements se produisent pour un abonné. Voici quelques exemples de ces événements :

• Connexion au réseau

• Création de service/support
• Se détacher du réseau

Configuration du plug-in

Sous 'cluster-udc', la configuration 'lwr client plugin' a été ajoutée, qui comprend :

• Nom de la région : Nom de la région à laquelle appartient ce PCRF.
• ID frontal : ID frontal du PCRF. Cette valeur doit être identique aux valeurs d'ID de serveur frontal existantes utilisées dans la configuration UDC.
• ID frontal dans les régions : ID frontal de tous les PCRF de cette région.
• Table des sujets : Liste des noms de sujet mappés aux gardiens de zoo et aux courtiers et indique quel sujet est local et lequel ne l'est pas. Les trois rubriques de région de ce tableau doivent être configurées. Les rubriques locales doivent être définies sur true ; les deux autres rubriques sont définies sur false pour les rubriques locales.

Configuration du plug-in : Configuration du plug-in client LWR

Option de service LWR

Une nouvelle option de service est ajoutée pour prendre en charge l'écriture LWR ; cette configuration de service doit être utilisée dans le service UDC.

L'option de service LWR utilise le nom de rubrique pour choisir sur quelles données de rubrique doivent être écrites et la liste des attributs à écrire sur LWR. Le nom du sujet doit être choisi dans la table CRD en fonction de l'ID frontal.

Option de service : LWR

Modifications CRD - Lwr-Apn-Mapping

Ce tableau fournit le contrôle d'écriture de l'attribut (lwrpcrferab) sur LWR et indique également s'il faut libérer le support ou non pour la gestion du support E911.

Groupe de tables de recherche > CRD : Lwr-Apn-Mapping

UDC écrit l'attribut « lwrpcrferab » dans LWR uniquement si « enable_lwr_write » a la valeur true. Ainsi, l'équipe d'exploitation peut contrôler l'écriture LWR pour les APN. Par exemple, au départ, l'écriture LWR n'était activée que pour certains APN de test et désactivée pour tous les autres APN. Cela permet à l'équipe d'exploitation de vérifier que la fonctionnalité LWR et la réplication fonctionnent correctement.

De même, si 'carrier_release' est vrai, alors seul PCRF peut libérer ce porteur APN à la réception de l'appel SOS ; si 'carrier_release' est false pour un APN, alors la gestion du support E911 ne peut pas démarrer pour cet APN.

Table de données de référence personnalisée : Lwr-Apn-Mapping

Recherche par sujet

Cette table CRD est utilisée pour dériver le nom de rubrique en fonction de l'ID frontal. Ces informations sont utilisées par l'option de service LWR afin de se connecter à une rubrique particulière pour laquelle PCRF est configuré.

Table de données de référence personnalisée : Recherche par sujet

Concepts clés et flux de données

Réplication des attributs

• L'attribut répliqué principal est 'lwrpcrferab', état de support de codage correspondant à E911.

• PCRF écrit cet attribut dans l'UDC, qui le propage ensuite via LWR.

• LWR réplique l'attribut sur plusieurs sites, mettant à jour les UDC et PCRF locaux pour maintenir des états de support synchronisés.

Mises à jour du domaine et du service

• Un nouveau domaine prend en charge la gestion des attributs SOS APN via UDC et LDAP.

• Les domaines SOS existants utilisent désormais l'attribut « lwrpcrferab ».

• Retarder l'acceptation des appels SOS afin de permettre la libération du support.

• Rejet des nouvelles requêtes support/session pendant les appels SOS.

• Libération des supports IMS et MCPTT lors de l'établissement d'un appel SOS.

• Suspension et restauration ultérieure des supports pendant les appels SOS.

Hypothèses

• L'activation de l'écriture LWR est contrôlée par APN afin de permettre un déploiement et des tests progressifs.

• PCRF écrit l'attribut « lwrpcrferab » uniquement sur les nouvelles demandes de session ou, si l'attribut existe déjà, empêche les écritures excessives.

• Un délai par défaut (par exemple, 600 ms) dans l'acceptation d'un appel SOS permet à PCRF de libérer les supports de priorité inférieure avant d'établir l'appel d'urgence.

• Les minuteurs de protection des attributs obsolètes assurent le nettoyage en temps opportun des sessions ou des attributs SOS obsolètes.

Flux d’appels

• Envoyez « attach » pour l'APN de données à PGW, puis PGW envoie CCR-I à PCRF A et obtient une réponse positive.
• Envoyez « attach » pour l'APN de point d'accès à chaud à PGW, puis PGW envoie CCR-I à PCRF A et obtient une réponse positive.
• Envoyez un « appel d'urgence » à PGW, puis PGW envoie CCR-I à PCRF B et obtient une réponse positive.
• Le PCRF met à jour un attribut appelé « lwrpcrferab », définissant sa phase sur « Start » et sa priorité sur « 1 ». Cela signifie probablement le début du traitement des appels d'urgence et lui attribue la priorité la plus élevée.
• Le PCRF écrit cet attribut « lwrpcrferab » mis à jour sur le contrôleur de domaine unifié.
• L'UDC écrit ensuite l'attribut « lwrpcrferab » dans le LWR. L'attribut « lwrpcrferab » est répliqué sur tous les noeuds et toutes les régions du cluster LWR pour garantir la cohérence et la disponibilité.
• Chaque noeud du multicluster PCRF met à jour ses instances UDC et PCRF locales avec les informations d'attribut répliquées.
• Le PCRF libère alors des supports de priorité inférieure. Parmi ces services de moindre priorité, citons les points d'accès sans fil, la vidéo IMS et l'IPME. Cette action libère des ressources réseau pour l'appel d'urgence prioritaire.
• Un délai est configuré (par défaut, 600 ms) pour le message SOS CCA-I. Cela permet de garantir l'allocation ou la synchronisation des ressources avant de continuer.
• Enfin, le système rejette toute nouvelle requête de support ou de session pour des APN spécifiques tels que des points d'accès sans fil, ce qui permet de hiérarchiser davantage l'appel d'urgence en empêchant de nouvelles connexions à faible priorité.
• Lorsque CCR-T est envoyé par GW afin de supprimer l'appel SOS, PCRF accepte les nouvelles demandes de création de support pour l'APN de données.

Avantages et impact

• Haute disponibilité et évolutivité : Le LWR basé sur Kafka assure la réplication en temps réel et la tolérance aux pannes sur plusieurs data centers.

• Traitement des priorités : Active la libération dynamique ou la mise en pause des supports de priorité inférieure pendant les appels d'urgence.

• Contrôle opérationnel : Prend en charge l'activation progressive des fonctionnalités et la gestion précise des supports par APN.

• Qualité des appels d'urgence améliorée : Une gestion efficace des ressources du support assure une configuration et une maintenance fiables des appels E911.

Conclusion

La solution Bearer Management utilisant LWR fournit un mécanisme robuste, évolutif et efficace afin de hiérarchiser et de gérer les supports LTE pendant les appels E911. Grâce à la réplication basée sur Kafka et à la gestion synchronisée des attributs, il garantit une disponibilité élevée, une flexibilité opérationnelle et une meilleure fiabilité des appels d'urgence.