Efficiënt dragerbeheer voor E911 met behulp van LWR voor PCRF met meerdere clusters

Inleiding

In dit document wordt een efficiënte afhandeling aan toonder beschreven voor noodoproepen zoals E911-oproepen met LWR- en UDC-VM's, waarbij de installatie, betrouwbaarheid en het gebruik van netwerkbronnen met prioriteit worden gegarandeerd.

Architectuuroverzicht

E911-noodoproepen vereisen een prioritair beheer aan toonder om de kwaliteit van de oproep en de beschikbaarheid van het netwerk te garanderen. De oplossing maakt gebruik van Lightweight Replication (LWR) en User Data Cache (UDC) VM's. LWR gebruikt intern Kafka DB voor replicatie. Kafka biedt snelle replicatie over meerdere PCRF-clusters, waardoor gecoördineerde dragercontrole tijdens noodoproepen mogelijk is.

Deze functie helpt PCRF om de abonnee-informatie te delen, zoals het aantal aangesloten APN's, de meldingsstatus en tussenliggende toestanden (zoals update en bearer release).

LWR-clusteronderdelen

• Zookeeper: Het wordt gebruikt om een controller te selecteren, ervoor te zorgen dat er slechts één is en een nieuwe te selecteren als deze crasht.Het beheert clusterlidmaatschap (welke makelaars actief zijn en deel uitmaken van het cluster) en houdt toezicht op de onderwerpconfiguratie (welke onderwerpen er zijn, hoeveel partities elk heeft, waar de replica's zijn, wie de voorkeursleider is en welke configuratieoverschrijvingen zijn ingesteld voor elk onderwerp).

• Makelaar: LWR maakt gebruik van makelaarsservices die berichtwachtrijen zijn die op de host worden uitgevoerd. Kafka broker ontvangt berichten van producenten en slaat deze op schijf gesleuteld door unieke offset.Het stelt consumenten in staat om berichten op te halen per onderwerp, partitie, offset en kan een Kafka-cluster maken door informatie direct of indirect met elkaar te delen met behulp van Zookeeper.
• MirrorMaker: Kafka MirrorMaker wordt gebruikt om gegevens tussen Kafka-clusters te spiegelen. Dit helpt bij het maken van replica's van gegevens van het ene datacenter naar het andere datacenter. Meerdere mirroring processen kunnen gelijktijdig worden uitgevoerd om de doorvoer en fouttolerantie te verhogen.

PCRF - LWR-regio en onderwerpconfiguratie

In de productie kunt u PCRF groeperen in meerdere regio's, zoals west, zuidoost en noordoost. In elke regio kunnen er ongeveer vijf tot zes PCRF-knooppunten zijn die via LWR met elkaar zijn verbonden. PCRF schrijft of actualiseert de gegevens op LWR wanneer sommige gebeurtenissen zich voordoen voor een abonnee. Enkele voorbeelden van deze evenementen kunnen zijn:

• Bevestigen aan netwerk

• Creatie van service/drager
• Loskoppelen van netwerk

Plug-inconfiguratie

Onder 'cluster-udc' is de configuratie 'lwr client plugin' toegevoegd, die het volgende omvat:

• Naam van de regio: Naam van de regio waartoe deze PCRF behoort.
• Front End Id: Front End Id van de PCRF. Deze waarde moet gelijk zijn aan de bestaande Front End Id-waarden die worden gebruikt in de UDC-configuratie.
• Front End ID in regio's: Front End ID van alle PCRF in die regio.
• Onderwerptabel: Lijst met onderwerpnamen die zijn toegewezen aan dierenverzorgers en makelaars en vertelt welk onderwerp lokaal is en welk niet. In deze tabel moeten alle drie de regio-onderwerpen zijn geconfigureerd. Lokale onderwerpen moeten op true worden ingesteld; de resterende twee onderwerpen zijn ingesteld op false voor lokale onderwerpen.

Invoegtoepassingen configureren: LWR Client-invoegtoepassingen configureren

LWR-serviceoptie

Er wordt een nieuwe serviceoptie toegevoegd om het schrijven van de LWR te ondersteunen; deze serviceconfiguratie moet worden gebruikt in de UDC-service.

De LWR-serviceoptie gebruikt de onderwerpnaam om te kiezen op welke onderwerpgegevens moeten worden geschreven en een lijst met kenmerken die op LWR moeten worden geschreven. De onderwerpnaam moet worden gekozen uit de CRD-tabel op basis van de Front End-ID.

Serviceoptie: LWR

CRD-wijzigingen - LWR-APN-mapping

Deze tabel geeft de controle over het schrijven van het attribuut (lwrpcreferab) op LWR en ook over het al dan niet vrijgeven van de drager voor E911 dragerbeheer.

Zoektabelgroep > CRD: Lwr-apn-mapping

UDC schrijft het attribuut 'lwrpcreferab' alleen naar LWR als 'enable_lwr_write' waar is. Dit biedt dus de controle aan het operatieteam om LWR-schrijven voor APN's mogelijk te maken. In eerste instantie was LWR-schrijven bijvoorbeeld alleen ingeschakeld voor sommige test-APN's en uitgeschakeld voor alle andere APN's. Hierdoor kan het operatieteam controleren of de LWR-functionaliteit en -replicatie goed werken.

Evenzo, als 'bearer_release' waar is, dan kan alleen PCRF die APN-drager vrijgeven bij het ontvangen van de SOS-oproep; als 'bearer_release' vals is voor een APN, dan kan E911-dragerbeheer niet inschakelen voor die APN.

Aangepaste referentiegegevenstabel: LWR-APN-mapping

Topic-lookup

Deze CRD-tabel wordt gebruikt om de onderwerpnaam af te leiden op basis van de Front End-ID. Deze informatie wordt gebruikt door de LWR-serviceoptie om verbinding te maken met een bepaald onderwerp waarvoor PCRF is geconfigureerd.

Aangepaste tabel met referentiegegevens: onderwerp opzoeken

Belangrijkste concepten en gegevensstroom

Attribuutreplicatie

• Het primaire gerepliceerde attribuut is 'larpcreferab', dat de toestand van de drager codeert die relevant is voor E911.

• PCRF schrijft dit attribuut naar de UDC, die het vervolgens via LWR verspreidt.

• LWR repliceert het attribuut op verschillende sites, waarbij lokale UDC en PCRF worden bijgewerkt om gesynchroniseerde dragertoestanden te behouden.

Updates van domeinen en services

• Een nieuw domein ondersteunt SOS APN attribuutbeheer via UDC en LDAP.

• Bestaande SOS-domeinen gebruiken nu het attribuut 'lwrpcrerab'.

• De acceptatie van SOS-oproepen uitstellen om de vrijgave aan toonder mogelijk te maken.

• Het afwijzen van aanvragen voor nieuwe dragers/sessies tijdens SOS-oproepen.

• IMS- en MCPTT-dragers vrijgeven bij initiatie SOS-oproep.

• Pauzeren en later herstellen van dragers tijdens SOS-oproepen.

veronderstellingen

• LWR-schrijfmogelijkheden worden per APN geregeld om gefaseerde implementatie en testen mogelijk te maken.

• PCRF schrijft het attribuut 'lwrpcrerab' alleen op nieuwe sessieverzoeken of als het attribuut al bestaat, waardoor overmatige schrijfbewerkingen worden voorkomen.

• Een standaardvertraging (bijvoorbeeld 600 ms) in SOS-oproepacceptatie stelt PCRF in staat dragers met lagere prioriteit vrij te geven voordat de noodoproep wordt ingesteld.

• Verouderde attribuut bewakingstimers zorgen voor een tijdige opschoning van verouderde SOS-sessies of attributen.

oproepstroom

• Stuur 'attach' voor APN-gegevens naar PGW en vervolgens stuurt PGW CCR-I naar PCRF A en krijgt een succesvolle reactie.
• Stuur 'attach' voor hotspot APN naar PGW en dan stuurt PGW CCR-I naar PCRF A en krijgt een succesvolle respons.
• Stuur 'Emergency call' naar PGW en dan stuurt PGW CCR-I naar PCRF B en krijgt een succesvolle reactie.
• De PCRF werkt een attribuut bij genaamd 'lwrpcreferab', waarbij de fase wordt ingesteld op 'Start' en de prioriteit op '1'. Dit betekent waarschijnlijk het begin van de afhandeling van noodoproepen en kent het de hoogste prioriteit toe.
• De PCRF schrijft dit bijgewerkte 'larpcreferab' attribuut naar de UDC.
• De UDC schrijft vervolgens het 'lwrpcreferab' attribuut naar de LWR. Het attribuut 'lwrpcreferab' wordt gerepliceerd over alle nodes en regio's binnen het LWR-cluster om consistentie en beschikbaarheid te garanderen.
• Elke node in het PCRF-multicluster werkt de lokale UDC- en PCRF-instanties bij met de informatie over de gerepliceerde kenmerken.
• De PCRF laat dan dragers met een lagere prioriteit vrij. Voorbeelden van deze diensten met lagere prioriteit zijn hotspot, IMS-video en IPME. Met deze actie worden netwerkmiddelen vrijgemaakt voor de noodoproep met hoge prioriteit.
• Er is een geconfigureerde vertraging (standaard tot 600 ms) voor het SOS CCA-I-bericht. Dit is om de toewijzing of synchronisatie van bronnen te garanderen voordat u doorgaat.
• Ten slotte wijst het systeem alle nieuwe bearer- of sessieverzoeken voor specifieke APN's zoals hotspot af, waarbij de prioriteit van de noodoproep verder wordt bepaald door nieuwe verbindingen met een lage prioriteit te voorkomen.
• Wanneer CCR-T door GW wordt verzonden om de SOS-oproep te verwijderen, accepteert PCRF nieuwe verzoeken voor het maken van gegevens aan toonder voor APN.

Voordelen en impact

• Hoge beschikbaarheid en schaalbaarheid: op Kafka gebaseerde LWR zorgt voor realtime replicatie en fouttolerantie in meerdere datacenters.

• Priority Handling: maakt het mogelijk dragers met een lagere prioriteit dynamisch uit te schakelen of te pauzeren tijdens noodoproepen.

• Operationele besturing: ondersteunt gefaseerde functionaliteit en fijnkorrelig dragerbeheer per APN.

• Verbeterde kwaliteit van noodoproepen: efficiënt bronnenbeheer aan toonder ondersteunt betrouwbare installatie en onderhoud van E911-oproepen.

Conclusie

De oplossing voor dragerbeheer met LWR biedt een robuust, schaalbaar en efficiënt mechanisme om LTE-dragers tijdens E911-oproepen te prioriteren en te beheren. Door gebruik te maken van Kafka-gebaseerde replicatie en gesynchroniseerd attribuutbeheer, zorgt het voor hoge beschikbaarheid, operationele flexibiliteit en verbeterde betrouwbaarheid van noodoproepen.