Warum ist die 5GC-SBI um HTTP/2-Serviceaufrufe herum aufgebaut?

Die Beziehung zwischen Netzfunktionen hat sich deutlich verändert, seit das 5G-Kernnetz eine servicebasierte Architektur eingeführt hat. Funktionen wie AMF, SMF, UDM, PCF, NSSF und AUSF sind nicht mehr darauf beschränkt, Nachrichten über feste Punkt-zu-Punkt-Protokollschnittstellen auszutauschen. Stattdessen stellt jede NF ihre Fähigkeiten als Dienste bereit, die andere Netzfunktionen bei Bedarf nutzen können.

In diesem Modell kann eine NF eine Ressource von einer anderen NF abrufen, einen neuen Kontext erstellen, eine vorhandene Ressource aktualisieren oder eine nicht mehr benötigte Ressource löschen. Das Kommunikationsmuster wird damit ganz natürlich zu Anfrage → Ressourcenoperation → Antwort. HTTP-Methoden, URIs, Statuscodes und JSON bieten eine praktische Möglichkeit, diese Art von Serviceinteraktion abzubilden.

Ein vereinfachter SBI-Protokollstapel lässt sich wie folgt darstellen:

Anwendung/JSON → HTTP/2 → TCP → IP → Ethernet

JSON definiert, wie Anwendungsdaten dargestellt werden. HTTP/2 organisiert Anfragen und Antworten für den Transport. TCP stellt eine zuverlässige Übertragung bereit, IP übernimmt Adressierung und Routing, und Ethernet transportiert die Frames über das zugrunde liegende Netz.

Das unterscheidet sich deutlich von Schnittstellen wie N2, N3 und N4. N2 verwendet NGAP, N4 verwendet PFCP und die Benutzerebene nutzt üblicherweise GTP-U. Die servicebasierte Schnittstelle verwendet HTTP/2 als Transportgerüst für die Servicekommunikation. Das ist nicht nur ein Protokollwechsel, sondern spiegelt einen umfassenderen Wandel in der 5GC-Entwurfsphilosophie wider: weg vom Austausch vordefinierter Schnittstellennachrichten, hin zum Aufruf von Diensten.

Wenn die AMF beispielsweise Zugangsverwaltungs-Abonnementdaten eines Teilnehmers benötigt, agiert die AMF als NF-Verbraucher und fordert eine Ressource von der UDM an, die als NF-Anbieter arbeitet. Der Verbraucher muss im Wesentlichen wissen, auf welche Ressource zugegriffen werden soll, welche Operation auszuführen ist und welches Ergebnis zurückgegeben wird. Für jeden einzelnen Servicevorgang ist kein vollständig separater Transportmechanismus erforderlich.

HTTP/2 bietet in dieser Umgebung außerdem einen sehr praktischen Vorteil: Mehrere Serviceanfragen können dieselbe TCP-Verbindung gemeinsam nutzen. SBI-Interaktionen zwischen Netzfunktionen treten häufig auf; für jeden API-Aufruf eine neue TCP-Verbindung aufzubauen, würde unnötigen Aufwand für das Verbindungsmanagement verursachen.

Welche Transportprobleme löst HTTP/2 gegenüber HTTP/1.1?

HTTP/2 hat nicht das gesamte Anwendungsmodell von HTTP/1.1 ersetzt. Methoden wie GET und POST gibt es weiterhin, und auch das grundlegende Anfrage-Antwort-Modell bleibt vertraut. Die wesentlichen Änderungen betreffen die Organisation und Übertragung der Daten.

Für 5GC ist eine schnellere Ladezeit von Webseiten nicht der entscheidende Punkt. Der eigentliche Nutzen liegt darin, dass HTTP/2 ein effizienteres Verbindungsmodell für viele gleichzeitige API-Aufrufe zwischen Netzfunktionen bereitstellt.

Eine Verbindung kann mehrere Streams gleichzeitig tragen

HTTP/1.1 unterstützt persistente Verbindungen, die Parallelität innerhalb einer einzelnen Verbindung ist jedoch weiterhin eingeschränkt. In vielen klassischen Implementierungen werden mehrere TCP-Verbindungen geöffnet, um die Parallelität zu erhöhen, was auf Client- und Serverseite zusätzlichen Verwaltungsaufwand erzeugt.

HTTP/2 führt Multiplexing ein. Eine einzelne TCP-Verbindung kann gleichzeitig mehrere unabhängige Streams enthalten. Neue Anfragen müssen nicht warten, bis eine vorherige Transaktion vollständig abgeschlossen ist. Frames aus mehreren Streams können innerhalb derselben Verbindung verschachtelt übertragen werden.

In einer 5GC-SBI-Umgebung ist eine von der AMF zu einer anderen NF aufgebaute HTTP/2-Verbindung nicht darauf beschränkt, jeweils nur eine API-Anfrage zu verarbeiten. Mehrere Serviceoperationen können unterschiedliche Streams nutzen, wobei jeder Stream seine eigene Anfrage und Antwort trägt.

Weniger TCP-Verbindungen bedeuten weniger Verwaltungsaufwand und passen daher gut zu den häufigen Serviceinteraktionen zwischen Netzfunktionen des 5G-Kernnetzes.

HTTP-Nachrichten werden als binäre Frames übertragen

HTTP/1.x ist weitgehend textorientiert. Anfragezeilen, Header und Nachrichteninhalte werden klar als Textstrukturen dargestellt. HTTP/2 verändert das Übertragungsformat und transportiert Protokollinformationen in binären Frames.

HTTP-Header werden üblicherweise in HEADERS-Frames übertragen, während die eigentliche Anwendungsnutzlast in DATA-Frames transportiert werden kann. Die Empfangsseite verwendet Informationen aus dem Frame-Header, einschließlich des Stream-Identifier, um festzustellen, zu welchem Stream ein bestimmter Frame gehört, und setzt daraus anschließend die vollständige HTTP-Nachricht zusammen.

Deshalb sieht ein HTTP/2-Paketmitschnitt in Wireshark häufig nicht wie ein vollständiger Block aus HTTP-Text aus. Stattdessen sehen Ingenieure eine Folge aus HEADERS, DATA und weiteren Frame-Typen.

Wiederholte Header müssen nicht jedes Mal vollständig gesendet werden

HTTP-Header treten im SBI-API-Verkehr immer wieder auf. Wenn jede Anfrage dieselben Headerfelder vollständig übertragen würde, würde der doppelte Overhead schnell erheblich werden.

HTTP/2 verwendet HPACK zur Headerkomprimierung. Vereinfacht gesagt führen beide Seiten Headertabellen, sodass häufig wiederkehrende Felder über Indizes dargestellt werden können, anstatt den vollständigen Text jedes Mal erneut zu übertragen.

Je stärker sich Header wiederholen, desto größer ist der Nutzen der Komprimierung. Wenn Netzfunktionen immer wieder ähnliche APIs aufrufen, erscheinen Felder wie Methoden, Pfade und gemeinsame Header häufig erneut, wodurch HPACK redundante Übertragungen besonders wirksam reduziert.

HTTP/2 definiert auch Server Push

HTTP/2 enthält einen Server-Push-Mechanismus und definiert den PUSH_PROMISE-Frame. Dadurch kann ein Server zugehörige Ressourcen proaktiv bereitstellen, bevor der Client jede einzelne Ressource ausdrücklich anfordert.

Für das Verständnis der 5GC-SBI ist Server Push jedoch nicht das wichtigste Konzept. Verbindungswiederverwendung, Multiplexing, Streams, Frames, Headerkomprimierung und das Anfrage-Antwort-Modell der API sind für die praktische SBI-Analyse deutlich wichtiger.

Wie sind Connection, Stream, Message und Frame zu verstehen?

Zu den verwirrendsten Aspekten von HTTP/2 gehört, dass die Begriffe Connection, Stream, Message und Frame häufig gemeinsam auftreten. Es ist deutlich einfacher, sie als Hierarchie zu verstehen, als jede Definition isoliert auswendig zu lernen.

Eine Connection ist die zugrunde liegende TCP-Verbindung. Sobald die TCP-Sitzung aufgebaut wurde, wird der HTTP/2-Verkehr über diese Verbindung transportiert.

Ein Stream ist ein logischer bidirektionaler Kanal innerhalb der Connection. Jeder Stream besitzt eine eigene ganzzahlige Kennung. Mehrere Streams können gleichzeitig innerhalb einer TCP-Verbindung bestehen; das ist die Grundlage des HTTP/2-Multiplexings.

Eine Message stellt eine logische HTTP-Anfrage oder HTTP-Antwort dar. Beispielsweise kann eine AMF eine GET-Anfragenachricht an die UDM senden, woraufhin die UDM eine entsprechende Antwortnachricht zurückgibt.

Ein Frame ist eine kleinere Einheit, die HTTP/2 für die tatsächliche Übertragung verwendet. Eine Message kann aus einem oder mehreren Frames bestehen. Typische Beispiele sind:

• HEADERS-Frame: transportiert HTTP-Headerinformationen.

• DATA-Frame: transportiert Anwendungsnutzdaten.

• Weitere Frame-Typen: unterstützen Verbindungsmanagement, Flusssteuerung und weitere HTTP/2-Funktionen.

Die Beziehung lässt sich daher wie folgt zusammenfassen:

Eine Connection enthält mehrere Streams. Ein Stream trägt Anfrage- und Antwort-Messages, und jede Message besteht aus einem oder mehreren Frames.

Der HTTP/2-Frame-Header enthält Felder wie Length, Type, Flags, reservierte Bits und den Stream Identifier. Der Stream Identifier ist besonders wichtig, weil er dem Empfänger mitteilt, zu welchem logischen Stream der Frame gehört.

Selbst wenn Frames aus mehreren Streams verschachtelt eintreffen, kann der Empfänger die Daten anhand der Stream-ID korrekt zuordnen und wieder zusammensetzen. Das ist der Kernmechanismus, durch den HTTP/2 mehrere gleichzeitige Transaktionen effizient über eine einzige TCP-Verbindung transportieren kann.

Für 5G-Kernnetz-Ingenieure ist dieses Konzept bei der Paketanalyse besonders wichtig. SBI-Verkehr sollte nicht allein deshalb zusammengefasst werden, weil Pakete im Mitschnitt direkt nebeneinander erscheinen. Stream-ID, URI, HTTP-Methode und Antwortstatus müssen gemeinsam betrachtet werden.

Wie machen JSON und RESTful-APIs aus 5GC-Fähigkeiten Ressourcen?

HTTP/2 beantwortet die Frage, wie Serviceverkehr effizient transportiert wird. Das eigentliche Anwendungsmodell der 5GC-SBI wird durch die Kombination aus RESTful-APIs und ressourcenorientiertem Design definiert.

REST ist ein Architekturstil. Eine seiner zentralen Ideen besteht darin, Geschäftsobjekte als Ressourcen darzustellen, jeder Ressource eine eindeutige URI zuzuweisen und dann HTTP-Methoden zu verwenden, um Operationen auf diesen Ressourcen auszuführen.

Eine „Ressource“ im 5GC ist nicht auf Objekte beschränkt, die üblicherweise mit Webseiten verbunden werden. Sie kann Teilnehmerdaten, einen SM Context, ein PDU-Session-bezogenes Objekt oder einen anderen von einer Netzfunktion gehaltenen Zustand darstellen.

Beispielsweise können Zugangsverwaltungs-Abonnementdaten eines Teilnehmers eine bestimmte URI besitzen, während Sitzungsverwaltungs-Abonnementdaten eine andere URI verwenden. Aus Sicht des Verbrauchers lautet die Operation dann nicht mehr einfach:

„Einen bestimmten UDM-Signalisierungsvorgang aufrufen.“

Stattdessen lautet sie:

Eine GET-, POST-, PUT/PATCH- oder DELETE-Operation auf einer bestimmten Ressource ausführen.

HTTP-Methoden legen fest, was mit einer Ressource geschieht

Häufige Operationen lassen sich wie folgt verstehen:

• GET: eine Ressource abrufen oder lesen.

• POST: eine Ressource erstellen oder eine definierte Operation aufrufen.

• PUT / PATCH: eine vorhandene Ressource aktualisieren.

• DELETE: eine Ressource entfernen.

Nach der Verarbeitung der Anfrage gibt der Server einen HTTP-Statuscode zurück, der das Ergebnis angibt.

Eine Antwort 200 weist in der Regel auf eine erfolgreiche Verarbeitung mit zurückgegebenen Daten hin. Eine Antwort 201 bedeutet üblicherweise, dass eine Ressource erfolgreich erstellt wurde. Eine Antwort 204 kann bedeuten, dass eine Operation erfolgreich war, ohne einen Antwortkörper zurückzugeben. 4xx-Antworten deuten normalerweise auf Probleme mit Anfrage, Ressource oder Berechtigung hin, während 5xx-Antworten meist auf serverseitige Verarbeitungsprobleme hinweisen.

Diese Statuscodes sind bei der 5GC-Fehlersuche äußerst hilfreich. Eine bestehende HTTP/2-Verbindung bedeutet nicht, dass die Serviceoperation selbst erfolgreich war. Ingenieure müssen weiterhin die angeforderte URI, die HTTP-Methode und den vom NF-Anbieter zurückgegebenen Statuscode prüfen.

JSON transportiert die eigentlichen Geschäftsdaten

SBI-Anwendungsnutzlasten werden üblicherweise in JSON dargestellt. JSON ist ein leichtgewichtiges Datenaustauschformat auf Basis von Schlüssel-Wert-Strukturen. Es kann Zeichenketten, Zahlen, boolesche Werte, Arrays, Objekte und verschachtelte Datenstrukturen abbilden.

Mit anderen Worten: Der HTTP/2-DATA-Frame transportiert die Nutzlast, während das JSON innerhalb dieses Frames festlegt, welche Bedeutung die Anwendungsdaten tatsächlich haben.

Aus technischer Sicht dürfen HTTP/2 und JSON nicht als dieselbe Protokollschicht betrachtet werden. HTTP/2 organisiert den Transport, JSON stellt die Anwendungsdaten dar, und RESTful-APIs definieren Ressourcen und die darauf möglichen Operationen.

Wie ist eine 5GC-SBI-Ressourcen-URI aufgebaut?

Sobald das Ressourcenkonzept klar ist, lässt sich auch der Aufbau einer SBI-URI viel leichter verstehen. Ressourcenpfade sind nicht willkürlich, sondern folgen einer strukturierten Hierarchie.

Ein typisches Format lässt sich so darstellen:

{apiRoot}/{apiName}/{apiVersion}/{apiSpecificResourceUriPart}

Jeder Teil hat eine bestimmte Aufgabe:

• apiRoot: die Stammadresse für den Zugriff auf den Dienst, üblicherweise in der Form http(s)://host(:port).

• apiName: der Name der konkreten SBI-API oder des Dienstes, den die Netzfunktion bereitstellt.

• apiVersion: die API-Version, zum Beispiel v1.

• apiSpecificResourceUriPart: der Pfad, der die konkrete Ressource oder Operation identifiziert.

Beispielsweise können sowohl Zugangsverwaltungs- als auch Sitzungsverwaltungs-Abonnementdaten von der UDM bereitgestellt werden, verwenden aber unterschiedliche Ressourcenpfade. Dadurch lässt sich anhand der URI eindeutig erkennen, welche Ressource der Verbraucher tatsächlich anfordert.

SMF-PDU-Session-Dienste folgen derselben Grundidee. Unterschiedliche SM Contexts und PDU-Session-bezogene Ressourcen besitzen eigene URIs, und unterschiedliche HTTP-Methoden werden verwendet, um sie zu erstellen, abzurufen, zu ändern oder freizugeben.

Dieses ressourcenorientierte Design verändert die Art, wie Ingenieure SBI-Schnittstellen betrachten sollten. Statt nur eine klassische Folge wie „Nachricht A → Nachricht B“ auswendig zu lernen, kann eine SBI-Interaktion so analysiert werden:

Dienst → Ressource → Methode → URI → Statuscode → JSON-Body

Wenn 5GC-SBI ausschließlich mit der traditionellen Telekommunikationslogik betrachtet wird, Anfrage- und Antwortnachrichten nach Namen zuzuordnen, kann die Architektur fragmentiert wirken. Als API-basiertes Ressourcenmodell wird die Logik deutlich klarer.

Wie sollten Ingenieure eine SBI-Transaktion in Wireshark verfolgen?

Sind die HTTP/2-Konzepte verstanden, besteht der nächste Schritt darin, sie auf reale Paketanalysen anzuwenden. Da eine einzige TCP-Verbindung gleichzeitig mehrere HTTP/2-Streams tragen kann, können bei einer Filterung nur nach Quell- und Ziel-IP mehrere voneinander unabhängige SBI-Transaktionen im selben Mitschnitt vermischt bleiben.

Ein praktisches Vorgehen besteht darin, zunächst die IP-Adressen von NF-Verbraucher und NF-Anbieter zu ermitteln und die Analyse anschließend anhand der relevanten Stream-ID einzugrenzen.

Verwendet eine bestimmte Anfrage beispielsweise Stream-ID 1, können Serveradresse und diese Stream-ID gemeinsam genutzt werden, um die Frames der entsprechenden Anfrage-Antwort-Transaktion zu isolieren.

Nach dem Filtern des Verkehrs sollten folgende Informationen im Mittelpunkt stehen:

• Stream-ID: bestätigt, ob die Frames zum selben logischen Stream gehören.

• HEADERS: zeigt HTTP-Methode, Pfad und weitere Headerfelder.

• DATA: zeigt, ob die Transaktion eine JSON-Anwendungsnutzlast trägt.

• Statuscode: zeigt, wie der NF-Anbieter die Anfrage verarbeitet hat.

• URI: identifiziert den genauen Dienst, die API-Version und die aufgerufene Ressource.

Eine sinnvolle Fehlersuchreihenfolge beginnt auf der Transportschicht und arbeitet sich nach oben. Zuerst sollte geprüft werden, ob die TCP-Verbindung besteht. Ohne TCP gibt es keine Grundlage für HTTP/2 oder RESTful-API-Kommunikation.

Danach sollte geprüft werden, ob die HTTP/2-Schicht normale HEADERS- und DATA-Frames enthält; über die Stream-ID werden sie der richtigen Transaktion zugeordnet.

Anschließend ist zu kontrollieren, ob HTTP-Methode und URI zur erwarteten Operation passen. Viele SBI-Probleme werden gar nicht durch Netzkonnektivität verursacht, sondern durch einen falschen Ressourcenpfad, eine falsche API-Version oder eine ungeeignete HTTP-Methode.

Danach wird der HTTP-Statuscode geprüft. Eine 4xx-Antwort lenkt die Fehlersuche auf Anfragesyntax, fehlende Ressourcen, Berechtigungen oder Anwendungsparameter. Eine 5xx-Antwort weist eher auf Probleme bei der Verarbeitung innerhalb des NF-Anbieters hin.

Erst wenn bestätigt ist, dass die HTTP-Anfrage korrekt zugestellt wurde, sollte die JSON-Nutzlast im Detail untersucht werden.

Der vollständige SBI-Fehlersuchpfad lässt sich daher so zusammenfassen:

TCP → HTTP/2-Verbindung → Stream → HEADERS → Methode/URI → DATA/JSON → Statuscode

Mit diesem Vorgehen wird ein zunächst sehr „Internet-artig“ wirkendes 5GC-Protokoll zu einem vertrauten, schichtweisen Engineering-Problem. Unten wird die Konnektivität geprüft, in der Mitte das HTTP/2-Transportverhalten und oben die API-Ressourcen und Geschäftsdaten. Die Fehlergrenze lässt sich dadurch wesentlich leichter eingrenzen.

Aus einer breiteren 5GC-Architekturperspektive verwendet SBI HTTP/2 nicht einfach deshalb, weil es neuer als HTTP/1.1 ist. Der tiefere Grund liegt darin, dass das 5G-Kernnetz NF-Fähigkeiten als Dienste organisiert und daher ein Kommunikationsmodell benötigt, das häufige API-Aufrufe, gleichzeitige Serviceinteraktionen und ressourcenorientierten Zugriff effizient unterstützt.

HTTP/2 stellt Connections, Streams und Frames bereit. Multiplexing verbessert die Verbindungsauslastung, HPACK reduziert den Overhead wiederholter Header und binäres Framing liefert ein strukturiertes Transportformat. JSON transportiert die Anwendungsdaten, während RESTful-APIs die Ressourcen und die darauf ausgeführten Operationen definieren. Zusammen bilden diese Elemente das vollständige Kommunikationsmodell der servicebasierten 5GC-Schnittstelle.

Häufig gestellte Fragen

Sind HTTP/2 und RESTful-APIs dasselbe?

Nein. HTTP/2 ist ein HTTP-Transportprotokoll, das Mechanismen wie Connections, Streams und Frames definiert. REST ist ein API-Architekturstil, der festlegt, wie Anwendungsobjekte als Ressourcen dargestellt und über URIs und HTTP-Methoden angesprochen werden. Die 5GC-SBI verwendet RESTful-artige APIs über HTTP/2.

Kann Stream-ID 0 eine normale SBI-Anwendungsanfrage tragen?

Nein. Stream-ID 0 hat eine besondere Rolle auf Protokollebene und wird nicht als normaler Anwendungs-Stream verwendet. Bei der Analyse realer SBI-Anfragen sollten sich Ingenieure auf die von null verschiedenen Stream-IDs konzentrieren, die Geschäftstransaktionen zugeordnet sind.

Muss der SBI-apiRoot eine IP-Adresse enthalten?

Nicht zwingend. Die logische Form von apiRoot lautet http(s)://host(:port). Der host identifiziert den relevanten Service-Endpunkt entsprechend der Netzarchitektur und dem Service-Discovery-Mechanismus. Bei der Analyse einer URI ist es sinnvoll, apiRoot von apiName, apiVersion und dem ressourcenspezifischen Pfad zu trennen.

Wenn HTTP/2 binäres Framing verwendet, warum ist JSON trotzdem in DATA-Frames sichtbar?

Binäres Framing beschreibt, wie HTTP/2 Protokolldaten organisiert und transportiert. Es verlangt nicht, dass auch die Nutzlast der Anwendungsschicht ein binäres Datenformat verwendet. Ein DATA-Frame kann weiterhin JSON transportieren. JSON definiert die 5GC-Anwendungsfelder, während HTTP/2 diese Nutzlast für den Transport in den passenden Stream einordnet.

Beweist eine HTTP-200-Antwort, dass der gesamte 5GC-Vorgang erfolgreich war?

Nein. HTTP 200 zeigt lediglich an, dass die konkrete HTTP-Anfrage an diesem Punkt erfolgreich verarbeitet wurde. Ein vollständiger 5GC-Vorgang kann mehrere Serviceaufrufe zwischen verschiedenen Netzfunktionen umfassen. Ingenieure müssen weiterhin URI, JSON-Inhalt und die umgebende Signalisierungsfolge bewerten, bevor sie feststellen, dass der gesamte Ende-zu-Ende-Vorgang erfolgreich abgeschlossen wurde.