Der 5G Core ist längst nicht mehr nur für die Kommunikation zwischen Menschen ausgelegt. Vernetzte Fahrzeuge, Smart Factories, Smart Campuses, Telemedizin, Drohnen und viele weitere Anwendungen vertikaler Branchen müssen zunehmend Netzressourcen abhängig von den Dienstbedingungen dynamisch beeinflussen oder vom Betreiber autorisierte Informationen über den Netzzustand erhalten. Müsste der Betreiber für jede neue Anforderung die Konfiguration von AMF, SMF, PCF, UDM und weiteren Netzfunktionen manuell anpassen, wäre ein großflächiger 5G-Einsatz in vertikalen Branchen äußerst schwer umzusetzen.

Hier kommt der NEF, die Network Exposure Function, ins Spiel. Er befindet sich zwischen dem 5GC und den Application Functions, kurz AFs, und wandelt interne Fähigkeiten des Core-Netzes in standardisierte Schnittstellen um, die externe Anwendungen nutzen können. Gleichzeitig übernimmt er Sicherheitskontrolle, Informationsübersetzung und Parameterübermittlung. Für Drittanbieteranwendungen ist der NEF damit kein einfacher API-Gateway, sondern ein kontrollierter Zugang zum Fähigkeitsrahmen des 5G Core des Betreibers.

Warum der 5GC den NEF benötigt

Das Geschäftsmodell von 4G war weitgehend B2C-orientiert: Das Netz stellte Konnektivität bereit, und Teilnehmer nutzten das mobile Internet für den Zugriff auf verschiedene Anwendungen. Mit 5G hat sich das Modell in Richtung B2B2X erweitert. Das Netz muss nun nicht nur einzelne Nutzer unterstützen, sondern auch tiefere, automatisierte Interaktionen mit Plattformen in Fertigung, Verkehr, Campusumgebungen, Gesundheitswesen und anderen vertikalen Branchen ermöglichen.

Daraus ergibt sich eine wichtige Frage: Wie können Branchenanwendungen die Netzwerkfähigkeiten des Betreibers zugleich sicher und standardisiert nutzen?

Betrachten wir ein Industrieunternehmen, das Produktionsendgeräten in einem bestimmten Bereich eine besser vorhersehbare QoS bieten oder Anwendungstraffic zu einem lokalen Datennetz näher am Werk lenken möchte. Ohne einen einheitlichen Mechanismus zur Bereitstellung von Netzwerkfähigkeiten müsste die Anwendungsplattform möglicherweise direkt mehrere Core-Netzfunktionen anbinden und für unterschiedliche Anbieter verschiedene Konfigurationen umsetzen. Das würde die Integrationskomplexität erhöhen und mehr interne Core-Schnittstellen offenlegen.

Der NEF schafft eine gemeinsame Grenze zwischen Branchenanwendungen und dem 5GC. Ein externer AF muss nicht jedes interne Detail von AMF, SMF, PCF, UDM oder UPF verstehen. Er muss lediglich über den NEF eine standardkonforme Dienstanforderung senden. Anschließend interagiert der NEF mit den geeigneten 5GC-Netzfunktionen und gibt das Ergebnis an die Anwendungsseite zurück.

Dieser Ansatz überführt Anforderungen, die sonst von manueller Abstimmung und statischer Konfiguration abhängen würden, teilweise in standardisierte Service-Aufrufe. Dadurch können Betreiber Netzwerkfähigkeiten automatisierter für Partner bereitstellen.

Position des NEF im 5GC

Der NEF wird zwischen den 5GC-Netzfunktionen und den AFs eingesetzt. Ein AF ist eine Funktionseinheit der Anwendungsschicht, die für die Geschäftslogik verantwortlich ist. Er kann eine vertrauenswürdige Anwendung sein, die dem Betreiber gehört oder von ihm verwaltet wird, oder eine Drittanbieterplattform außerhalb der Vertrauensdomäne des Betreibers. Drittanbieteranwendungen dürfen keinen uneingeschränkten Zugriff auf interne Core-Netzfunktionen erhalten; kontrollierte Interaktionen werden daher über den NEF abgewickelt.

Aus Schnittstellensicht verbindet der NEF effektiv zwei unterschiedliche Umgebungen. In Richtung Norden bedient er AFs wie Videoplattformen, Plattformen für vernetzte Fahrzeuge und industrielle Steuerungssysteme. In Richtung Süden bindet er interne 5GC-Netzfunktionen an und kommuniziert je nach angefordertem Dienst mit Instanzen wie SMF, PCF und UDM.

Der NEF entwickelte sich aus dem in 4G verwendeten SCEF, besitzt jedoch einen deutlich größeren Umfang. SCEF war hauptsächlich mit bestimmten IoT-Anwendungsfällen verbunden, während der NEF im 5GC ein wesentlich breiteres Spektrum menschen- und maschinenzentrierter Anwendungen unterstützt und zu einem wichtigen Bestandteil des servicebasierten Rahmens zur Bereitstellung von Netzwerkfähigkeiten geworden ist.

Vom Design her leistet der NEF weit mehr als bloße Nachrichtenweiterleitung. Zu seinen Kernaufgaben gehören die Bereitstellung von Netzwerkfähigkeiten und Ereignissen, das sichere Provisionieren von Informationen externer Anwendungen in das 3GPP-Netz, die Übersetzung zwischen externen und internen Informationsformaten sowie der Empfang von Daten anderer Netzfunktionen zur Speicherung oder späteren erneuten Bereitstellung.

Ein Teil der vom NEF empfangenen Informationen kann im UDR gespeichert werden und muss damit nicht an eine einzelne NEF-Instanz gebunden bleiben. Der NEF kann außerdem PFD-Funktionen unterstützen und so die Grundlage für eine präzisere Anwendungserkennung und Richtlinienverarbeitung schaffen.

Wie fünf zentrale Fähigkeiten bereitgestellt werden

Der Wert des NEF ergibt sich letztlich aus den Diensten, die er bereitstellen kann. In praktischen 5GC-Implementierungen lassen sich seine wichtigsten Fähigkeiten in fünf Bereiche gliedern: QoS-Bereitstellung, Abonnements von Netzereignissen, Traffic Steering, Parameterbereitstellung und PFD-Management. Diese Funktionen entsprechen einigen der häufigsten Interaktionsanforderungen zwischen Branchenanwendungen und Betreibernetzen.

Bereitstellung von QoS-Fähigkeiten

Die Bereitstellung von QoS-Fähigkeiten ermöglicht einer Partneranwendung, eine bestimmte Dienstqualität für einen konkreten Service-Flow anzufordern. Beispielsweise kann eine Videoanwendung bereits über eine bestehende PDU-Session laufen. Wählt der Nutzer eine höherwertige Videoqualität, kann der AF über den NEF eine verbesserte QoS für diesen Traffic-Flow anfordern.

Nach Eingang der Anforderung koordiniert sich der NEF mit Core-Netzfunktionen wie dem PCF. Der PCF wendet anschließend Richtlinienlogik an und arbeitet mit dem SMF sowie weiteren Netzressourcen zusammen, um die passende QoS-Behandlung für den Service-Flow einzurichten.

Entscheidend ist nicht, dem Endgerät einfach mehr Bandbreite zuzuweisen. Vielmehr soll eine Anwendung ihre Dienstanforderungen über eine standardisierte Schnittstelle ausdrücken können, während Richtlinienentscheidungen und die Durchsetzung von Netzressourcen unter Kontrolle des 5GC bleiben.

Mobilität und Abonnements von Netzereignissen

Ein Drittanbieter-AF kann über den NEF auch UE-bezogene Netzereignisse abonnieren, etwa ob ein UE die Verbindung verloren hat, wieder erreichbar geworden ist, seinen aktuellen oder zuletzt bekannten Standort, den Roaming-Status, Gründe für Kommunikationsfehler sowie den Status der Downlink-Datenzustellung.

Diese Ereignisse werden von unterschiedlichen Core-Netzfunktionen erkannt. Der AMF kann die Erreichbarkeit eines UE, Verbindungsverlust und bestimmte Kommunikationsfehler erkennen. Der UDM kann Informationen wie Roaming-Status oder bestimmte Änderungen bei Identitätszuordnungen bereitstellen, während der SMF Zustände im Zusammenhang mit der Downlink-Datenzustellung melden kann.

Der AF muss sich nicht direkt mit jeder Netzfunktion verbinden. Stattdessen erstellt er über den NEF ein Ereignisabonnement. Der NEF richtet dann das erforderliche interne Abonnement bei der zuständigen Netzfunktion ein. Tritt das Zielereignis ein, benachrichtigt das Core-Netz den NEF, der die Ereignismeldung gemäß dem Abonnement an den externen AF weiterleitet.

Dieser Mechanismus ist besonders für Branchenanwendungen nützlich, die abhängig vom Gerätestatus automatisierte Geschäftslogik auslösen müssen. Anstatt den UE-Status fortlaufend abzufragen, kann die externe Plattform genau dann eine Benachrichtigung erhalten, wenn das relevante Ereignis tatsächlich eintritt.

Traffic Steering

Der NEF kann auch Traffic-Influence-Anforderungen eines AF entgegennehmen und den Traffic eines bestimmten UE oder Dienstes zu einem Local DN, also einem Local Data Network, lenken. Ein Local DN wird durch einen DNAI identifiziert und ist häufig mit Edge-Computing oder regional bereitgestellten Diensten verbunden.

In einer automatisierten Fabrik kann beispielsweise ein industrieller Steuerungsserver in einem lokalen Netz nahe dem Produktionsstandort betrieben werden. Die Anwendungsplattform kann über den NEF anfordern, dass der 5GC den User-Plane-Pfad anpasst, damit der relevante Geräte-Traffic zum passenden Local DN geroutet wird.

Der NEF steuert den UPF nicht direkt. Stattdessen übergibt er die Anforderung an den Richtliniensteuerungsprozess. PCF und SMF übernehmen anschließend Richtlinie und User-Plane-Konfiguration. Abhängig von der Situation kann der SMF den UPF neu auswählen oder UPFs im bestehenden Pfad hinzufügen, ersetzen oder entfernen, um das Traffic Steering umzusetzen.

Sichere Parameterbereitstellung

Ein externer AF kann über den NEF auch bestimmte benutzerbezogene Parameter an den 5GC liefern. Das bedeutet jedoch nicht, dass die Anwendung Core-Netzparameter frei ändern darf. Der Umfang der bereitstellbaren Informationen ist streng kontrolliert.

Typische Beispiele sind Expected UE Behaviour und ausgewählte Network Configuration Parameters. Expected UE Behaviour kann erwartete Mobilitätseigenschaften eines Geräts beschreiben. Netzwerk-Konfigurationsparameter können unter anderem maximale Antwortzeit, zulässige Verzögerung bei der Downlink-Datenübertragung oder die empfohlene Anzahl zu puffernder Downlink-Pakete umfassen, wenn das UE nicht erreichbar ist.

Der NEF leitet autorisierte Parameteranforderungen an den UDM weiter, der zusammen mit dem UDR die entsprechenden Daten liest und aktualisiert. Der AMF oder andere Netzfunktionen, die diese Datenänderungen abonniert haben, können anschließend die aktualisierten Parameter für die weitere Netzverarbeitung erhalten.

PFD-Management

PFD, oder Packet Flow Description, kann als Regelwerk zur Anwendungserkennung verstanden werden. Ein Drittanbieter-AF kann über den NEF Informationen zur Anwendungsidentifikation anlegen. Die daraus entstehenden Regeln können im UDR gespeichert, vom SMF über den NEF abgerufen und anschließend zur Anwendungserkennung an den UPF übermittelt werden.

Im Vergleich zur Traffic-Erkennung nur anhand grundlegender Ports oder Adressen können PFDs spezifischere Anwendungseigenschaften beschreiben. Ein Videodienst kann beispielsweise anhand eines bestimmten URL-Musters oder anderer Traffic-Merkmale erkannt werden, sodass das Netz den Traffic genauer den passenden Richtlinienregeln zuordnen kann.

Der tatsächliche technische Wert des NEF

Aus architektonischer Sicht besteht die wichtigste Aufgabe des NEF nicht darin, einen weiteren Weiterleitungsknoten hinzuzufügen. Sein eigentlicher Zweck ist die Schaffung einer verwaltbaren Schicht zur Bereitstellung von Netzwerkfähigkeiten. Externe AFs sehen serviceorientierte Schnittstellen, während die eigentliche Arbeit im 5GC weiterhin durch Funktionen wie PCF-Richtliniensteuerung, SMF-Sitzungsverwaltung, UDM-Datenverwaltung und UPF-User-Plane-Verarbeitung ausgeführt wird.

Deshalb sollte der NEF nicht als gewöhnlicher API-Gateway betrachtet werden. Er muss die Beziehung zwischen externen Geschäftsanforderungen und den 3GPP-Core-Netzfähigkeiten verstehen und zugleich Sicherheitskontrolle, Informationsübersetzung und Prozesskoordination zwischen beiden Seiten übernehmen.

Der NEF ersetzt auch keine anderen Netzfunktionen. Die QoS-Durchsetzung hängt weiterhin von Richtliniensteuerung und der Konfiguration von Sitzungsressourcen ab. Netzereignisse werden weiterhin von der jeweils zuständigen NF erkannt. User-Plane-Pfade werden weiterhin von Funktionen wie dem SMF angepasst, und benutzerbezogene Daten bleiben beim UDM und UDR. Die Rolle des NEF besteht darin, diese internen Fähigkeiten kontrolliert und standardisiert bereitzustellen.

Diese Fähigkeit ist besonders wichtig für 5G-B2B2X-Dienste. Branchenanwendungen müssen weder die vollständige interne Topologie des 5GC kennen noch proprietäre Schnittstellen zu jeder Netzfunktion aufbauen. Sie können ihre Netzanforderungen über standardisierte Bereitstellungsmechanismen übermitteln. Gleichzeitig behält der Betreiber die Kontrolle über die Grenze des Core-Netzes und kann ausgewählte Netzfähigkeiten in Dienste umwandeln, die vertrauenswürdige Partner nutzen dürfen.

Praktisch hilft der NEF dem 5G Core, sich von einem Netz, das primär Konnektivität bereitstellt, zu einer Plattform zu entwickeln, die Netzwerkfähigkeiten direkt für Branchenanwendungen bereitstellen kann.

Häufig gestellte Fragen

Müssen alle AFs außerhalb des Betreibernetzes bereitgestellt werden?

Nein. Ein AF kann eine vertrauenswürdige Anwendung sein, die dem Betreiber gehört oder von ihm verwaltet wird, oder eine Drittanbieteranwendung außerhalb seiner Vertrauensdomäne. Zugriffsverfahren und Sicherheitsbehandlung können je nach AF-Typ unterschiedlich sein.

Werden Geschäftsdaten immer lokal im NEF gespeichert?

Nein. Ein Teil der vom NEF empfangenen Informationen kann im UDR gespeichert und später von anderen Netzfunktionen oder nachfolgenden Verfahren verwendet werden. Die Datenspeicherung muss daher nicht dauerhaft an eine einzelne NEF-Instanz gebunden sein.

Ist ein Local DN dasselbe wie ein UPF?

Nein. Ein Local DN ist ein lokales Datennetz, das bestimmte Anwendungen oder Datendienste bereitstellt, während der UPF eine User-Plane-Netzfunktion des 5GC ist. Traffic kann über einen geeigneten UPF-Pfad zu einem bestimmten Local DN geleitet werden, beide erfüllen jedoch unterschiedliche Rollen.

Erstellt der UPF PFD-Regeln selbst?

Nein. PFD-Regeln können von einem AF bereitgestellt und über den NEF verwaltet werden. Der SMF ruft die entsprechenden Regeln ab und übermittelt sie an den UPF, damit im User Plane eine genauere Anwendungserkennung erfolgen kann.