Effizientes Trägermanagement für E911 mit LWR für Multi-Cluster-PCRF

Download-Optionen

PDF (1.0 MB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (844.3 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (482.9 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:25. März 2026

Dokument-ID:225631

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einleitung

In diesem Dokument wird die effiziente Bearbeitung von Notfallanrufen wie E911-Anrufen mithilfe von LWR- und UDC-VMs beschrieben, um eine priorisierte Einrichtung, Zuverlässigkeit und eine optimierte Nutzung der Netzwerkressourcen sicherzustellen.

Architekturübersicht

E911-Notrufe erfordern ein priorisiertes Bearer-Management, um die Anrufqualität und die Netzwerkverfügbarkeit zu gewährleisten. Die Lösung nutzt Lightweight Replication (LWR) und User Data Cache (UDC) VMs. LWR verwendet intern Kafka DB für die Replikation. Kafka ermöglicht die Hochgeschwindigkeits-Replikation über mehrere PCRF-Cluster und damit eine koordinierte Trägersteuerung bei Notrufen.

Diese Funktion unterstützt PCRF bei der gemeinsamen Nutzung von Teilnehmerinformationen wie Anzahl der angeschlossenen APNs, Benachrichtigungsstatus und Zwischenstatus (wie Aktualisierung und Trägerfreigabe).

LWR-Cluster-Komponenten

Zookeeper: Es wird verwendet, um einen Controller zu wählen, sicherzustellen, dass es nur einen gibt, und wählen Sie einen neuen, wenn es abstürzt.Es verwaltet die Cluster-Mitgliedschaft (welche Broker am Leben sind und Teil des Clusters) und überwacht die Themenkonfiguration (welche Themen existieren, wie viele Partitionen jeder hat, wo die Replikate sind, wer der bevorzugte Leader ist und welche Konfigurationsüberschüsse für jedes Thema festgelegt werden).

Broker: LWR verwendet Brokerdienste, die Nachrichtenwarteschlangen sind, die auf dem Host ausgeführt werden. Kafka Broker empfängt Nachrichten von Produzenten und speichert sie auf der Festplatte, die durch einen eindeutigen Offset verschlüsselt ist.Sie ermöglicht es Verbrauchern, Nachrichten nach Thema, Partition, Offset abzurufen und kann einen Kafka-Cluster erstellen, indem sie Informationen direkt oder indirekt über Zookeeper austauschen.
MirrorMaker: Kafka MirrorMaker wird verwendet, um Daten zwischen Kafka-Clustern zu spiegeln. Dies erleichtert die Erstellung von Datenreplikaten von einem Rechenzentrum zu einem anderen. Mehrere Spiegelungsprozesse können gleichzeitig ausgeführt werden, um Durchsatz und Fehlertoleranz zu erhöhen.

LWR Cluster Components

PCRF - Konfiguration der Region und des Themas für LWR

In der Produktion können Sie PCRF in mehrere Regionen wie West, South-East und North-East gruppieren. In jeder Region können etwa fünf bis sechs PCRF-Knoten vorhanden sein, die über LWR miteinander verbunden sind. PCRF schreibt oder aktualisiert die Daten auf dem LWR, wann immer ein Ereignis für einen Teilnehmer auftritt. Hier einige Beispiele für diese Ereignisse:

Mit Netzwerk verbinden

Erstellung von Services/Inhabern
Vom Netzwerk trennen

Plug-in-Konfiguration

Unter 'cluster-udc' wurde die Konfiguration 'lwr client plugin' hinzugefügt, die Folgendes beinhaltet:

Name der Region: Name der Region, zu der diese PCRF-Instanz gehört
Front-End-ID: Front-End-ID der PCRF-Instanz. Dieser Wert muss mit den vorhandenen Front-End-ID-Werten übereinstimmen, die in der UDC-Konfiguration verwendet werden.
Front-End-ID in Regionen: Front-End-ID aller PCRFs in dieser Region.
Thementabelle: Liste der Themennamen, die Zookeepern und Brokern zugeordnet sind, und gibt an, welches Thema lokal ist und welches nicht. Für diese Tabelle müssen alle drei Regionenthemen konfiguriert sein. Lokale Themen müssen auf true festgelegt werden. Die verbleibenden beiden Themen werden für lokale Themen auf false festgelegt.

Plugin-Konfiguration: Konfiguration des LWR-Client-Moduls

LWR Client Plugin Configuration

LWR-Serviceoption

Es wird eine neue Serviceoption hinzugefügt, um das LWR-Schreiben zu unterstützen. Diese Servicekonfiguration muss im UDC-Service verwendet werden.

Die LWR-Serviceoption verwendet den Themennamen, um auszuwählen, auf welche Themendaten geschrieben werden soll, und eine Liste der Attribute, die in LWR geschrieben werden sollen. Der Themenname muss anhand der Front-End-ID aus der CRD-Tabelle ausgewählt werden.

Service-Option: Niederschrift

Service Option

CRD-Änderungen - Lwr-APN-Zuordnung

Diese Tabelle bietet die Kontrolle über das Schreiben des Attributs (lwrpcrferab) in LWR und darüber, ob der Träger für die E911-Trägerverwaltung freigegeben wird oder nicht.

Tabellengruppe durchsuchen > CRD: LWR-APN-Zuordnung

Search Table Group for Lwr-Apn-Mapping

UDC schreibt das Attribut "lwrpcrferab" nur dann in LWR, wenn "enable_lwr_write" wahr ist. Dadurch erhält das Betriebsteam die Kontrolle, LWR-Schreibvorgänge für APNs zu aktivieren. Beispielsweise wurde das LWR-Schreiben anfangs nur für einige Test-APNs aktiviert und für alle anderen APNs deaktiviert. Auf diese Weise kann das Betriebsteam überprüfen, ob die LWR-Funktionalität und die Replikation ordnungsgemäß funktionieren.

Wenn "bearer_release" den Wert "true" hat, kann nur die PCRF-Instanz den APN-Bearer beim Empfang des SOS-Anrufs freigeben. Wenn 'bearer_release' für einen APN falsch ist, kann das E911-Bearer-Management für diesen APN nicht starten.

Benutzerdefinierte Referenzdatentabelle: LWR-APN-Zuordnung

Custom Reference Data Table for Lwr-Apn-Mapping

Themensuche

Diese CRD-Tabelle wird verwendet, um den Themennamen basierend auf der Front-End-ID abzuleiten. Diese Informationen werden von der LWR-Dienstoption verwendet, um eine Verbindung zu einem bestimmten Thema herzustellen, für das PCRF konfiguriert ist.

Benutzerdefinierte Referenzdatentabelle: Themensuche

Custom Reference Data Table for Topic-Lookup

Schlüsselkonzepte und Datenfluss

Attributreplikation

Das primäre replizierte Attribut ist "lwrpcrferab", wobei der Trägerstatus für E911 codiert wird.

PCRF schreibt dieses Attribut in den UDC, der es dann über LWR weiterleitet.

LWR repliziert das Attribut standortübergreifend und aktualisiert lokales UDC und PCRF, um den synchronisierten Trägerstatus zu erhalten.

Domänen- und Service-Updates

Eine neue Domäne unterstützt die SOS APN-Attributverwaltung über UDC und LDAP.

Vorhandene SOS-Domänen verwenden jetzt das Attribut "lwrpcrferab".

Verzögerung der Annahme des SOS-Anrufs, um die Freigabe durch den Träger zu ermöglichen.

Ablehnung von neuen Träger-/Sitzungsanforderungen während SOS-Anrufen.

Freigabe von IMS- und MCPTT-Trägern bei SOS-Anrufinitiierung.

Anhalten und späteres Wiederherstellen von Trägern während SOS-Aufrufen.

Annahmen

Die LWR-Schreibaktivierung wird pro APN gesteuert, um eine schrittweise Bereitstellung und Tests zu ermöglichen.

PCRF schreibt das Attribut "lwrpcrferab" nur auf neue Sitzungsanforderungen oder wenn das Attribut bereits vorhanden ist, um übermäßige Schreibvorgänge zu verhindern.

Eine Standardverzögerung (z. B. 600 ms) bei der SOS-Anrufabnahme ermöglicht es der PCRF-Instanz, Träger mit niedrigerer Priorität freizugeben, bevor der Notruf getätigt wird.

Veraltete Attributschutz-Timer sorgen für eine zeitnahe Bereinigung veralteter SOS-Sitzungen oder -Attribute.

Anrufablauf

Call Flow

Senden Sie "Attach" für Daten-APN an PGW, und das PGW sendet CCR-I an PCRF A und erhält eine erfolgreiche Antwort.
Senden Sie die "Attach"-Nachricht für den Hotspot-APN an den PGW, und das PGW sendet CCR-I an PCRF A und erhält eine erfolgreiche Antwort.
Senden Sie einen Notruf an den PGW, und das PGW sendet dann CCR-I an die PCRF-Instanz B und erhält eine erfolgreiche Antwort.
Die PCRF-Instanz aktualisiert ein Attribut mit der Bezeichnung "lwrpcrferab", wobei die Stufe auf "Start" und die Priorität auf "1" gesetzt wird. Dies bedeutet wahrscheinlich den Beginn der Bearbeitung von Notrufen und weist ihr die höchste Priorität zu.
Die PCRF-Instanz schreibt dieses aktualisierte Attribut "lwrpcrferab" in das UDC.
Das UDC schreibt dann das Attribut "lwrpcrferab" in den LWR. Das Attribut "lwrpcrferab" wird über alle Knoten und Regionen innerhalb des LWR-Clusters repliziert, um Konsistenz und Verfügbarkeit zu gewährleisten.
Jeder Knoten im PCRF-Multi-Cluster aktualisiert seine lokalen UDC- und PCRF-Instanzen mit den replizierten Attributinformationen.
Die PCRF-Instanz gibt dann Träger mit niedrigerer Priorität frei. Beispiele für Services mit geringerer Priorität sind Hotspot, IMS-Video und IPME. Dadurch werden Netzwerkressourcen für Notrufe mit hoher Priorität freigesetzt.
Für die SOS CCA-I-Nachricht besteht eine konfigurierte Verzögerung (standardmäßig 600 ms). Auf diese Weise wird die Ressourcenzuweisung oder -synchronisierung sichergestellt, bevor Sie fortfahren.
Schließlich lehnt das System alle neuen Träger- oder Sitzungsanfragen für bestimmte APNs wie Hotspot ab und priorisiert den Notruf weiter, indem neue Verbindungen mit niedriger Priorität verhindert werden.
Wenn CCR-T von GW gesendet wird, um den SOS-Anruf zu löschen, akzeptiert PCRF Anfragen zur Erstellung neuer Träger für Daten-APN.

Vorteile und Auswirkungen

Hohe Verfügbarkeit und Skalierbarkeit: Kafka-basiertes LWR sorgt für Echtzeit-Replikation und Fehlertoleranz über mehrere Rechenzentren hinweg.

Prioritätsbehandlung: Ermöglicht die dynamische Freigabe oder Unterbrechung von Trägern mit niedrigerer Priorität während Notrufen.

Betriebssteuerung: Unterstützt die phasenweise Aktivierung von Funktionen und eine feinstufige Trägerverwaltung pro APN.

Verbesserte Notrufqualität: Effizientes Träger-Ressourcenmanagement unterstützt die zuverlässige Einrichtung und Wartung von E911-Anrufen.

Schlussfolgerung

Die Bearer Management-Lösung mit LWR bietet einen robusten, skalierbaren und effizienten Mechanismus zur Priorisierung und Verwaltung von LTE-Trägern bei E911-Anrufen. Durch die Nutzung der Kafka-basierten Replikation und des synchronisierten Attributmanagements wird eine hohe Verfügbarkeit, eine hohe betriebliche Flexibilität und eine verbesserte Zuverlässigkeit bei Notrufen sichergestellt.