Die eigentliche Herausforderung in einer Multi-PCF-Bereitstellung besteht nicht darin, dass mehrere PCF-Instanzen vorhanden sind. Das Problem ist vielmehr, dass dasselbe UE während unterschiedlicher Dienstabläufe leicht zu verschiedenen PCFs geroutet werden kann. Beim Aufbau einer PDU-Sitzung kann die SMF bereits eine Policy-Zuordnung zu einer PCF hergestellt haben. Später, wenn ein IMS-Sprachdienst ausgelöst wird und die AF eine neue Policy-Anfrage startet, kann das Load Balancing diese Anfrage an eine andere PCF senden. Dadurch wird der Policy-Kontext zwischen den beiden Phasen unterbrochen, was zu Inkonsistenzen bei VoNR-QoS-Flows, PCC-Regeln und Sitzungsrichtlinien führen kann.

Die BSF, also die Binding Support Function, ist genau dafür ausgelegt, dieses Problem zu lösen: Anfragen desselben Benutzers über unterschiedliche Schnittstellen müssen dieselbe PCF erreichen. Die BSF erzeugt keine PCC-Regeln und ersetzt die PCF nicht bei Policy-Entscheidungen. Ihre Hauptaufgabe ist es, die Bindungsbeziehung zwischen einer UE-Sitzung und der zugehörigen PCF zu verwalten, damit Dienstkonsumenten bei späteren Anfragen die PCF finden können, die bereits an der Policy-Steuerung für diesen Benutzer beteiligt war.

Warum Multi-PCF-Netze die falsche PCF auswählen können

Um den Nutzen der BSF zu verstehen, lohnt sich ein Blick auf ein ähnliches Problem aus 4G. In der EPC-Architektur kommuniziert das PGW über die Gx-Schnittstelle mit dem PCRF, während das P-CSCF im IMS-Domänenbereich Policy-Autorisierungsanfragen über Rx sendet. Sind mehrere PCRFs im Einsatz, müssen die Gx- und Rx-Signalisierungspfade letztlich bei demselben PCRF enden. Andernfalls können spätere IMS-Dienstanfragen den zuvor aufgebauten Policy-Kontext der Sitzung nicht übernehmen.

In 4G-Netzen wird dafür häufig ein DRA für Diameter-Routing und Sitzungsbindung eingesetzt. Ein typisches Beispiel: Wenn das PGW für den IMS-APN eine PDN-Verbindung aufbaut, wird die Gx-Anfrage über DRA1 zu PCRF1 geroutet. DRA1 speichert die Beziehung zwischen IMSI, UE-IP-Adresse und PCRF1. Wird eine spätere Rx-Nachricht vom P-CSCF aufgrund von Load Balancing an DRA2 gesendet und von dort an PCRF2 weitergeleitet, kennt PCRF2 den zuvor auf der PGW-Seite aufgebauten Sitzungs-Kontext nicht.

Die Auswirkungen gehen deutlich über die Auswahl des falschen Servers hinaus. PCRF2 kennt den bestehenden Zustand der PCC-Regeln nicht, sodass neue über Rx empfangene Medien-Policy-Anfragen nicht korrekt mit den zuvor über Gx aufgebauten Richtlinien korreliert werden können. In 4G-Bereitstellungen lässt sich das durch eine Echtzeitsynchronisation der Bindungsinformationen zwischen mehreren DRAs lösen. Solche Lösungen sind jedoch häufig herstellerspezifisch und erschweren Multi-Vendor-Bereitstellungen sowie den langfristigen Betrieb erheblich.

Auch in 5GC bleibt die Anforderung an Policy-Konsistenz bestehen, obwohl sich Netzfunktionen und Schnittstellen geändert haben. Die SMF kommuniziert über N7 mit der PCF, während die AF über N5 eine Policy-Autorisierung anfordert. In einem vollständigen VoNR-Policy-Ablauf liefert die AF zunächst Anforderungen für den Anwendungsfluss und die QoS, die PCF erzeugt die entsprechenden PCC-Regeln, und anschließend setzen SMF und UPF diese Regeln um. Erreichen unterschiedliche Anfragen desselben UE verschiedene PCFs, kann die Policy-Kontinuität weiterhin verloren gehen.

Die BSF standardisiert damit eine Bindungsfunktion, die früher von proprietären Synchronisationsmechanismen abhing. Sie verwaltet die Beziehung zwischen der aktuellen UE-Sitzung und der verantwortlichen PCF und trägt dazu bei, dass spätere Policy-Anfragen wieder an die PCF-Instanz geroutet werden, die bereits an der Sitzung beteiligt war.

Welche Informationen bindet die BSF?

Aus Implementierungssicht kann die BSF als dynamisch gepflegte Tabelle betrachtet werden, die ein UE der zuständigen Policy-Instanz zuordnet. Sobald eine PCF an der Policy-Steuerung einer PDU-Sitzung des UE beteiligt ist, registriert sie die erforderlichen Bindungsinformationen bei der BSF. Andere Netzfunktionen können die BSF später anhand von UE-Kennungen und Sitzungsmerkmalen abfragen, um die zugehörigen Adressierungsinformationen der PCF zu erhalten.

Ein typischer Bindungseintrag kann die UE-IP-Adresse, SUPI, DNN, S-NSSAI und die Adresse der zugehörigen PCF enthalten. In Bereitstellungen, die mit klassischen Diameter-Schnittstellen zusammenarbeiten müssen, kann der Eintrag zusätzlich den Diameter-Hostnamen oder FQDN der PCF enthalten.

Diese Felder werden nicht nur der Vollständigkeit halber gesammelt. Jedes davon hat eine konkrete Funktion beim Filtern und Identifizieren der richtigen Bindung:

• UE IP: Ermöglicht die direkte Suche nach der Bindung anhand der aktuellen User-Plane-Adresse und gehört zu den häufigsten Abfrageparametern.

• SUPI: Identifiziert den Teilnehmer auf Benutzeridentitätsebene und stellt sicher, dass die Bindung dem richtigen UE zugeordnet ist.

• DNN: Unterscheidet verschiedene Datennetze, die dasselbe UE nutzt, beispielsweise IMS und reguläre Internetdienste.

• S-NSSAI: Kennzeichnet in einer 5G-Slicing-Bereitstellung zusätzlich den Netzslice, dem die Sitzung zugeordnet ist.

• PCF-Adresse: Liefert die tatsächlichen Adressierungsinformationen, die ein Dienstkonsument benötigt, um die ausgewählte PCF zu erreichen.

• Diameter-Hostname/FQDN: Dient als Zuordnungsreferenz für klassisches Diameter-Routing in Umgebungen, in denen SBI und Diameter parallel betrieben werden.

Aus diesem Grund darf eine BSF-Bindung nicht auf eine einfache Eins-zu-eins-Zuordnung zwischen UE-Adresse und PCF-Adresse reduziert werden. Ein UE kann mehrere PDU-Sitzungen besitzen und auf unterschiedliche DNNs oder Netzslices zugreifen. Sind die Abfragebedingungen zu allgemein, kann die zurückgegebene PCF nicht zum aktuellen Dienstkontext passen.

In der Praxis sollte die Granularität der Bindung der Granularität der Policy-Steuerung entsprechen. Das ist insbesondere bei IMS-Diensten wichtig, bei denen Policy-Kontinuität entscheidend ist. Verfügt das UE über mehrere Slices oder mehrere Datennetz-Kontexte, sollten DNN und S-NSSAI in den Bindungskriterien nicht fehlen.

Wie sollte Nbsf_Management verwendet werden?

Die BSF stellt den Dienst Nbsf_Management über die SBI bereit. Dieser Dienst besteht nicht aus einer großen Sammlung unabhängiger APIs, sondern bietet vier Kernoperationen für den vollständigen Lebenszyklus eines Bindungseintrags: Registrierung, Discovery, Aktualisierung und Deregistrierung. In realen Bereitstellungen entsprechen diese vier Vorgänge direkt der Erstellung, Nutzung, Pflege und Entfernung einer PCF-Bindung.

Register: Zuerst die Bindung anlegen

Sobald eine PCF ausgewählt wurde und an der Policy-Steuerung für das UE beteiligt ist, muss sie die Bindung bei der BSF registrieren. Eine typische Anfrage lautet:

POST .../pcfBindings

Der Request-Body kann zentrale Felder wie UE-IP-Adresse, SUPI, DNN, S-NSSAI, PCF-Adresse und den zugehörigen FQDN enthalten. Nachdem die BSF den Bindungseintrag erfolgreich erstellt hat, antwortet sie mit:

201 Created

Das richtige Timing ist in dieser Phase eine der häufigsten Implementierungsfallen. Die Bindung muss registriert sein, bevor eine spätere dienstseitige Abfrage gestartet wird. Andernfalls kann eine AF-seitige oder Diameter-kompatible Anfrage das Netz erreichen, bevor die BSF die passende PCF-Bindung gespeichert hat, wodurch die Suche fehlschlägt.

Discovery: Vorhandene PCF aus dem Sitzungs-Kontext ermitteln

Bei der Discovery-Operation wird der praktische Nutzen der BSF besonders deutlich. Ein Dienstkonsument sendet eine Abfrage mit den aktuell verfügbaren UE-Informationen:

GET .../pcfBindings?query_parameters

Die Abfrageparameter können UE-IP-Adresse, SUPI oder GPSI, DNN, S-NSSAI und weitere relevante Kennungen enthalten. Wird eine passende Bindung gefunden, antwortet die BSF mit:

200 OK

Die Antwort enthält die zugehörige PCF-Adresse und bei Bedarf den Diameter-Hostnamen oder FQDN. In der standardisierten Architektur können Dienstkonsumenten unter anderem NEF, AF und NWDAF sein. In Bereitstellungen, die weiterhin klassisches Rx-Routing unterstützen müssen, können die zurückgegebenen Bindungsinformationen außerdem verwendet werden, um für die nachfolgende Signalisierung die richtige PCF auszuwählen.

Update und Deregister: Lebenszyklus der Bindung pflegen

Ändern sich Bindungsinformationen, kann ein vorhandener Eintrag per PATCH aktualisiert werden:

PATCH .../pcfBindings/{bindingId}

Eine erfolgreiche Aktualisierung liefert 200 OK zurück. Wird die Sitzung freigegeben, bedient die PCF das UE nicht mehr oder wird die Bindung ungültig, sollte der Eintrag mit folgendem Aufruf gelöscht werden:

DELETE .../pcfBindings/{bindingId}

Eine erfolgreiche Löschung liefert üblicherweise 204 No Content. In realen Netzen darf die Deregistrierung nicht vernachlässigt werden. Bleiben veraltete Bindungseinträge zu lange in der BSF, kann derselbe Teilnehmer später eine neue Sitzung aufbauen und versehentlich einer alten PCF zugeordnet werden. Solche Fehler sind oft schwerer zu diagnostizieren als eine schlicht fehlende Bindung.

Fehlersuche bei N7- und Rx-Bindungen

Über den gesamten Signalisierungspfad lässt sich der BSF-Ablauf in drei Phasen unterteilen: zuerst die Bindung registrieren, anschließend die Bindung abfragen und schließlich die nachfolgende Policy-Signalisierung zurück zur ursprünglichen PCF routen. Ist diese Reihenfolge klar, lassen sich VoNR-Policy-Probleme wesentlich gezielter analysieren, als große Mengen Signalisierung ohne klare Fragestellung zu sammeln.

Phase eins: PDU-Sitzung aufbauen und PCF registrieren

Nachdem eine BSF-Instanz online gegangen ist, registriert sie zunächst ihre Fähigkeiten und Adressierungsinformationen bei der NRF. Anschließend baut das UE eine PDU-Sitzung für den IMS-DNN auf, und die SMF fordert Policy-Steuerung von einer PCF an. Nach Auswahl der PCF ruft diese Nbsf_Management_Register auf, um die UE-zu-PCF-Bindung in der BSF zu speichern.

Zu diesem Zeitpunkt kann die BSF Bindungseinträge enthalten wie:

UE IP1 + DNN1 + S-NSSAI1 + SUPIxx → PCF1
UE IP2 + DNN2 + S-NSSAI2 + SUPIyy → PCF2

Phase zwei: Ein VoNR-Anruf löst eine Policy-Abfrage aus

Wenn das UE einen VoNR-Anruf startet, löst die IMS-Domäne eine neue Policy-Autorisierungsanfrage aus. In der standardisierten 5GC-Architektur tauschen AF und PCF Policy-Informationen über N5 aus. In einigen Bereitstellungen, die weiterhin klassische IMS-Diameter-Signalisierung verwenden, kann das P-CSCF weiterhin das Rx/AAR-Verfahren einsetzen.

Die entscheidende Frage in dieser Phase lautet: Welche PCF soll die Policy-Anfrage erhalten?

Der Anfragende sollte nicht einfach gemäß normaler Load-Balancing-Logik eine andere PCF auswählen. Stattdessen fragt er zunächst die BSF mit Informationen wie UE-Adresse, DNN und S-NSSAI ab. Die BSF gleicht den vorhandenen Bindungseintrag ab und gibt die PCF-Instanz zurück, die bereits für die UE-Sitzung verantwortlich ist.

Phase drei: Nachfolgende Signalisierung zurück zur ursprünglichen PCF routen

Nachdem die richtige PCF identifiziert wurde, werden nachfolgende Policy-Anfragen an dieselbe PCF gesendet. Dadurch bleiben sowohl der beim Aufbau der PDU-Sitzung erzeugte Policy-Kontext als auch die neuen Policy-Anfragen aus der VoNR-Medienphase auf derselben Policy-Control-Instanz. Die PCF kann anschließend PCC-Regeln auf Basis des vollständigen Sitzungs-Kontexts erzeugen und verwalten.

Wenn ein VoNR-Anruf aufgebaut werden kann, das QoS-Policy-Verhalten jedoch auffällig ist, IMS-Medienregeln inkonsistent sind oder nur einzelne Teilnehmer sporadische Fehler erleben, sollte der BSF-Bindungspfad überprüft werden, bevor das Problem vorschnell dem Funknetz zugeschrieben wird.

Eine praktische Fehlersuche lässt sich in vier Schritte gliedern. Erstens ist zu prüfen, ob nach dem Aufbau der PDU-Sitzung tatsächlich eine BSF-Register-Operation erfolgt ist. Zweitens müssen UE-IP-Adresse, SUPI, DNN und S-NSSAI in der BSF korrekt sein. Drittens ist zu prüfen, ob die Abfragebedingungen der späteren Discovery-Anfrage die ursprüngliche Bindung eindeutig treffen. Viertens muss verifiziert werden, dass die zurückgegebene PCF-Adresse oder Diameter-Kennung exakt zu der PCF gehört, die ursprünglich an der N7-Policy-Steuerung beteiligt war.

Auch die Bereitstellungsarchitektur ist zu berücksichtigen. In manchen Netzen kann die BSF gemeinsam mit der SMF betrieben werden. Dann können sich Paketmitschnittpunkte und interne Aufrufabläufe von einer eigenständigen BSF-Bereitstellung unterscheiden. Das Grundprinzip bleibt jedoch gleich: Das Netz muss eine stabile Bindung zwischen UE-Sitzung und verantwortlicher PCF aufrechterhalten.

Häufig gestellte Fragen

Führen BSF und NRF beide eine Auswahl von Netzfunktionen durch?

Nein. Ihre Aufgaben unterscheiden sich. Die NRF unterstützt Netzfunktionen dabei, verfügbare NF-Instanzen und deren Fähigkeiten zu entdecken und wirkt damit eher wie ein Dienstregister. Die BSF speichert dagegen eine bereits bestehende Bindung zwischen einer konkreten UE-Sitzung und einer PCF. Vereinfacht gesagt beantwortet die NRF die Frage „Welche PCFs sind verfügbar?“, während die BSF beantwortet „Welche PCF ist bereits für diese UE-Sitzung zuständig?“

Kann ein UE nur eine einzige PCF-Bindung haben?

Nicht unbedingt. Eine Bindung wird nicht allein durch die UE-Identität bestimmt. Sie kann auch vom DNN, S-NSSAI und dem konkreten PDU-Sitzungs-Kontext abhängen. Greift dasselbe UE auf unterschiedliche Datennetze oder Netzslices zu, müssen die jeweiligen Bindungen gegebenenfalls getrennt gepflegt werden.

Können BSF und SMF in derselben Netzfunktionsinstanz bereitgestellt werden?

Ja. Eine Co-Location ist möglich. In diesem Fall kann sich die von außen sichtbare Signalisierungsreihenfolge von einer eigenständigen BSF-Bereitstellung unterscheiden, die UE-zu-PCF-Bindung muss jedoch weiterhin gespeichert und verwendet werden. Bei der Fehlersuche sollte daher zuerst die tatsächliche Herstellerarchitektur bestätigt werden.

Was sollte zuerst geprüft werden, wenn eine BSF-Abfrage fehlschlägt?

Beginnen Sie mit drei Punkten: Wurde der Bindungseintrag erfolgreich erstellt, stimmen die Abfrageparameter mit den bei der Registrierung verwendeten Werten überein, und ist die Bindung möglicherweise abgelaufen oder zu früh gelöscht worden? Liefert die BSF einen Eintrag zurück, sollte zusätzlich geprüft werden, ob die zurückgegebene PCF-Adresse, der FQDN oder die Diameter-Kennung auf die erwartete PCF-Instanz verweist.