Bei der Fehlersuche an Service-Based Interfaces in einem 5G Core stoßen viele Ingenieure auf dasselbe Problem. Der Request-Body, den ein AMF an ein SMF sendet, kann vertraute Felder wie SUPI, DNN, S-NSSAI, TAI, PDU Session ID und 5QI enthalten, trotzdem ist es oft schwierig zu beurteilen, ob die Nachricht tatsächlich gültig ist. Muss ein Feld als Zeichenkette oder als Ganzzahl codiert werden? Gibt es einen festgelegten Wertebereich? Darf jeder beliebige Wert verwendet werden, oder muss er aus einer vordefinierten Enumeration stammen? Kann ein Objekt weitere verschachtelte Parameter enthalten?

Die Antworten werden durch die gemeinsamen SBI-Datentypen festgelegt. Service-Based Interfaces verbinden Netzwerkfunktionen wie AMF, SMF, UDM, PCF und NRF, doch viele der zugrunde liegenden Parameter sind nicht auf eine einzelne NF beschränkt. Würde jeder Dienst diese Werte eigenständig definieren, enthielten die Spezifikationen unnötige Wiederholungen, und dieselbe Teilnehmerkennung oder derselbe QoS-Parameter könnte in verschiedenen APIs unterschiedlich dargestellt werden. Deshalb reicht es bei der Analyse von SBI-Verkehr nicht aus, HTTP-Methoden und Ressourcen-URIs zu prüfen. HTTP/2 legt fest, wie Requests transportiert werden, JSON legt fest, wie Daten dargestellt werden, und gemeinsame Datentypen beantworten eine grundlegendere Frage: welches Format und welche Validierungsregeln jeder JSON-Parameter einhalten muss.

Welche Probleme lösen gemeinsame Datentypen?

Sie lassen sich als gemeinsamer „Datenwortschatz“ für die gesamte servicebasierte API-Umgebung des 5GC verstehen. Ein Datentyp kann in einem AMF-Request vorkommen und zugleich von SMF, UDM oder PCF referenziert werden. Er gehört nicht zu einer einzelnen Schnittstelle, sondern stellt eine standardisierte Definition bereit, die in mehreren Diensten wiederverwendet werden kann.

Betrachten wir eine IPv4-Adresse. Nicht jede NF sollte selbst festlegen, wie diese Adresse als Zeichenkette dargestellt wird. Dasselbe gilt für PLMN-Informationen, bei denen MCC und MNC bestimmte Längen und Formate besitzen, sowie für Teilnehmer- und Gerätekennungen wie SUPI, GPSI und PEI, die jeweils eigenen Codierungsregeln folgen. Einheitliche Definitionen ermöglichen RESTful APIs zwischen verschiedenen NFs einen zuverlässigen Informationsaustausch.

Gemeinsame Datentypen müssen außerdem von NF-spezifischen Typen unterschieden werden. Gemeinsame Typen beschreiben Objekte, die wiederholt in verschiedenen Schnittstellen auftreten, während Geschäftsobjekte, die nur zu einer bestimmten Netzwerkfunktion gehören, in den jeweiligen Spezifikationen der 29er-Reihe definiert sind. In der Praxis referenziert eine einzelne SBI-API häufig beide Arten von Datentypen.

Ihr Umfang reicht weit über Netzwerkadressen hinaus. Gemeinsame Definitionen decken allgemeine Parameter, Teilnehmer- und Identitätsinformationen, 5G-Netzdaten, QoS, Abrechnung, Trace-Informationen und weitere wiederverwendbare Objekte ab. Zusammen bilden sie ein grundlegendes Datenmodell für SBI-Nachrichtenparameter.

Wie unterscheiden sich die drei grundlegenden Datenstrukturen?

Strukturell lassen sich SBI-Parameter im Allgemeinen in drei Kategorien einteilen: einfache Datentypen, Enumerationstypen und strukturierte Datentypen. Diese drei Kategorien zu verstehen ist nützlicher, als einzelne Parameternamen auswendig zu lernen, denn die meisten Felder in Wireshark-Mitschnitten, API-Dokumentationen und OpenAPI-Definitionen passen in dieses Modell.

Einfache Datentypen sind die elementarsten Bausteine. Dazu gehören Zeichenkette, Ganzzahl, Zahl, Datum, Datum-Uhrzeit und Boolesch. Im 5GC werden diese Basistypen üblicherweise mit zusätzlichen Einschränkungen kombiniert, etwa Wertebereichen, Codierungsformaten oder Mustern regulärer Ausdrücke.

Eine IPv4-Adresse wird beispielsweise technisch als Zeichenkette dargestellt, aber nicht jede beliebige Zeichenkette ist gültig. Sie muss dem vorgeschriebenen IPv4-Format entsprechen. IPv6-Adressen, IPv6-Präfixe und MAC-Adressen besitzen jeweils eigene Formatvorgaben. Uint16, Uint32 und Uint64 definieren Wertebereiche für vorzeichenlose Ganzzahlen. Eine URI muss den URI-Formatregeln entsprechen, während DateTime-Werte das festgelegte Datums-/Zeitformat verwenden müssen.

Spezifikationen definieren außerdem häufig Typen mit dem Suffix Rm, beispielsweise Ipv4AddrRm, DateTimeRm und Uint32Rm. Diese Typen verwenden dasselbe zugrunde liegende Format wie ihre jeweiligen Basistypen, enthalten aber die OpenAPI-Eigenschaft nullable, sodass das Feld den Wert null enthalten darf.

Enumerationstypen funktionieren wie Auswahlfelder: Der Wert muss aus einer vordefinierten Menge gewählt werden. AccessType unterscheidet beispielsweise zwischen 3GPP_ACCESS und NON_3GPP_ACCESS. PduSessionType kann Werte wie IPV4, IPV6, IPV4V6, UNSTRUCTURED oder ETHERNET annehmen. CoreNetworkType kann 5GC oder EPC angeben.

Der Zweck einer Enumeration besteht darin, Mehrdeutigkeit zu vermeiden. Ein Consumer darf nicht einfach eine andere Zeichenkette erfinden, die vermeintlich dasselbe bedeutet. Er muss einen der in der Spezifikation ausdrücklich festgelegten Werte verwenden. Das ist ein häufiges Fehlerszenario: Der Feldname stimmt, aber der Enumerationswert ist ungültig, sodass die API den Request trotzdem ablehnt oder falsch interpretiert.

Strukturierte Datentypen kombinieren mehrere Attribute zu einem vollständigen Objekt. Diese Attribute können wiederum einfache Typen, Enumerationen oder andere strukturierte Objekte referenzieren und so ein hierarchisches Modell bilden.

ProblemDetails ist ein typisches Beispiel. Es kann Felder wie type, title, status, detail, instance, cause und invalidParams enthalten. TAI ist ein weiteres Beispiel und kombiniert eine PLMN ID mit einem TAC. GUAMI geht noch eine Ebene weiter und kombiniert eine PLMN ID mit einer AMF ID. Auf dieser Ebene kann sich die SBI-Analyse nicht mehr nur auf einzelne Felder konzentrieren; auch die Beziehungen zwischen den Attributen innerhalb des Objekts sind wichtig.

Wie werden Identitäts- und Netzparameter aufgebaut?

In realen Paketmitschnitten gehören Teilnehmer-, Identitäts- und 5G-Netzdaten zu den häufigsten SBI-Parametern. SUPI identifiziert einen Teilnehmer, GPSI steht für eine externe Teilnehmeridentität, PEI für eine permanente Gerätekennung, DNN bezeichnet ein Datennetz, und eine NF Instance ID identifiziert eine NF-Instanz eindeutig.

Die meisten dieser Felder wirken wie einfache Zeichenketten, doch entscheidend ist die Codierungsregel innerhalb der Zeichenkette. Eine SUPI kann eine IMSI- oder NAI-Darstellung enthalten, während eine GPSI eine MSISDN oder einen External Identifier enthalten kann. Anders gesagt: Die Definition als Zeichenkette bedeutet nicht, dass jede beliebige Zeichenkette gültig ist.

5G-netzbezogene Typen bauen auf diesen Basiskennungen auf, um Sitzungs- und Standortinformationen darzustellen. PduSessionId identifiziert eine PDU Session. MCC und MNC bilden Bestandteile einer PLMN-Identität. TAC bezeichnet einen Tracking Area Code, während NrCellId und EutraCellId jeweils NR- beziehungsweise E-UTRA-Zellen identifizieren.

Strukturierte Objekte kombinieren diese Basisparameter anschließend zu höherwertigen Datenmodellen. S-NSSAI verwendet eine SST und eine optionale SD zur Darstellung eines Network Slices. TAI kombiniert eine PLMN ID und einen TAC. NCGI kombiniert eine PLMN ID mit einer NR Cell ID, um eine NR-Zelle zu identifizieren, während ECGI eine ähnliche Funktion für E-UTRA übernimmt.

UserLocation ist eine noch höher angesiedelte Abstraktion. Abhängig vom Zugriffstyp kann sie eine NR Location, eine E-UTRA Location oder eine Non-3GPP Access Location enthalten. Eine NR Location kann wiederum TAI, NCGI, einen Standort-Zeitstempel und geografische Informationen enthalten.

Dies zeigt den modularen Aufbau der SBI-Datenmodelle. Grundelemente wie MCC, MNC, TAC und Cell ID werden zunächst standardisiert und anschließend zu höherwertigen Objekten wie PLMN ID, TAI, NCGI und UserLocation zusammengesetzt. APIs können diese Objekte direkt wiederverwenden, statt für jeden Dienst einen vollständigen Satz von Standortparametern neu zu definieren.

Warum müssen auch QoS-, Abrechnungs- und Trace-Daten standardisiert werden?

SBI-Verkehr transportiert weit mehr als Teilnehmeridentitäten und Netzwerkstandorte. Auch QoS-Richtlinien, Nutzungsinformationen und Netzwerk-Trace-Daten werden zwischen mehreren NFs ausgetauscht, weshalb auch diese Werte einheitliche Datendefinitionen benötigen.

Unter den QoS-Parametern identifiziert QFI einen QoS Flow, 5QI steht für den 5G QoS Identifier, BitRate stellt eine Datenrate mit Wert und Einheit dar, Packet Delay Budget beschreibt ein Verzögerungsbudget, und Packet Error Rate sowie Packet Loss Rate beschreiben die Übertragungsqualität.

QoS-Richtlinien verwenden ebenfalls zahlreiche Enumerationstypen. PreemptionCapability gibt an, ob ein Dienst anderweitig zugewiesene Ressourcen verdrängen darf. PreemptionVulnerability gibt an, ob vorhandene Ressourcen durch einen höher priorisierten Dienst entzogen werden können. QosResourceType unterscheidet Werte wie NON_GBR, NON_CRITICAL_GBR und CRITICAL_GBR.

Diese Basisfelder werden anschließend zu strukturierten Objekten wie ARP, AMBR, Dynamic 5QI und Non-Dynamic 5QI zusammengeführt. Dadurch können SMF, PCF und andere beteiligte Netzwerkfunktionen beim Austausch von Konzepten wie Priorität, Bitrate, Verzögerung und Preemption-Verhalten dieselbe Darstellung verwenden.

Abrechnungsdaten folgen demselben Konstruktionsprinzip. ChargingId, RatingGroup und ServiceId sind relativ einfache Datentypen, während QoSFlowUsageReport QFI, Start- und Endzeitstempel der Erfassung sowie Uplink- und Downlink-Datenvolumen enthalten kann. VolumeTimedReport kann die Nutzung einer PDU Session über ein festgelegtes Zeitintervall darstellen.

Trace-bezogene Typen standardisieren Informationen zur Netzverfolgung. TraceDepth verwendet Enumerationswerte für unterschiedliche Trace-Tiefen, während TraceData Parameter wie Trace Reference, Trace Depth und NE Type zusammenfasst. Dadurch wird verhindert, dass jede NF einen eigenen inkompatiblen Satz von Trace-Feldern definiert.

Diese Beispiele zeigen, dass gemeinsame Datentypen weit mehr leisten als nur „einige JSON-Felder“ zu standardisieren. Sie standardisieren, wie verschiedene Core-Netz-Dienste dieselben Geschäfts- und Netzkonzepte verstehen. Müssen QoS, Standort, Abrechnungsinformationen oder Teilnehmerkennungen zwischen mehreren NFs ausgetauscht werden, benötigen sie zunächst ein konsistentes Datenmodell.

Wie lassen sich Datentypen bei der praktischen Fehlersuche einsetzen?

Ein häufiger technischer Fehler besteht darin, bei einer JSON-Nachricht nur zu prüfen, ob ein Feld vorhanden ist, ohne den Datentyp und die zugehörigen Einschränkungen zu kontrollieren. Effektiver ist es, HTTP-Schicht und Datenmodell gemeinsam zu untersuchen.

Identifizieren Sie zunächst den aufgerufenen Dienst und die Ressourcen-URI. Suchen Sie danach das Zielfeld im Request- oder Response-Body. Sobald das Feld gefunden ist, sollten Sie nicht beim Wert stehen bleiben. Prüfen Sie, welchen Datentyp es referenziert, ob es obligatorisch oder optional ist, welche Cardinality gilt, ob es sich um eine Enumeration handelt und ob Format- oder Pattern-Einschränkungen bestehen.

Ein IPv4-Feld kann für einen Menschen wie eine IP-Adresse aussehen, ist aber dennoch ungültig, wenn es nicht dem definierten Format entspricht. Ebenso kann ein PduSessionType-Wert sprachlich verständlich sein; gehört er jedoch nicht zu den festgelegten Enumerationswerten, entspricht er nicht der API-Definition.

Strukturierte Daten sollten rekursiv aufgelöst werden. Wenn UserLocation vorkommt, ist zu prüfen, ob das Objekt NR-, E-UTRA- oder Non-3GPP-Standortinformationen enthält. Bei TAI sind PLMN ID und TAC zu untersuchen. Bei S-NSSAI sind SST und die optionale SD zu prüfen. Nur durch das schrittweise Verfolgen der Typreferenzen lässt sich feststellen, ob das JSON-Objekt dem API-Modell entspricht.

Wenn ein Server einen Request ablehnt, sollte auch ProblemDetails genau betrachtet werden. Zusätzlich zum HTTP-Statuscode kann es Informationen in detail, cause und invalidParams liefern. Sind diese Felder vorhanden, kann die Fehlersuche direkt beim konkreten Parameter beginnen, der gegen die API-Vorgaben verstoßen hat, statt bei einer allgemeinen HTTP-4xx-Antwort stehen zu bleiben.

Warum ist ein Datenmodell-Denken nützlicher als das Auswendiglernen von Parametertabellen?

Die Zahl der gemeinsamen SBI-Datentypen im 5GC ist groß genug, dass das Auswendiglernen jedes Feldes, jedes regulären Ausdrucks und jedes Wertebereichs schnell ineffizient wird. Sinnvoller ist ein Datenmodell-Denken: Einfache Typen definieren die kleinsten Dateneinheiten, Enumerationen begrenzen gültige Zustände, und strukturierte Typen kombinieren diese Einheiten zu Objekten, die von 5GC-Diensten direkt genutzt werden können.

In diesem Rahmen sind SUPI, MCC, TAC und QFI keine isolierten Parameter mehr. Sie werden zu Bausteinen für Teilnehmer-, Standort-, Sitzungs-, QoS-, Abrechnungs- und Trace-Modelle. Dass verschiedene NFs Dienste über SBI konsistent aufrufen können, liegt unter anderem daran, dass diese gemeinsamen Typen stabile und wiederverwendbare Datensemantik bereitstellen.

Beim Lesen einer unbekannten 5GC-API lautet die nützlichste erste Frage daher nicht „Wie viele Felder enthält diese Nachricht?“. Stattdessen sollte geklärt werden, welche Typen diese Felder referenzieren, wie die Objekte verschachtelt sind und welche Einschränkungen bestimmen, ob das entstehende JSON gültig ist. Sobald dieses Vorgehen vertraut ist, kann selbst ein bisher unbekannter SBI-Dienst durch schrittweises Nachverfolgen der OpenAPI- und Datentypdefinitionen analysiert werden, ohne eine völlig neue Parametertabelle auswendig zu lernen.

FAQ

Welche 3GPP-Spezifikation definiert die gemeinsamen SBI-Datentypen?

Sie sind hauptsächlich in TS 29.571, 5G System; Common Data Types for Service Based Interfaces, definiert. Diese Spezifikation beschreibt wiederverwendbare Datenstrukturen, die von SBI-Diensten gemeinsam genutzt werden. NF-spezifische Dienste und Datentypen sind in den entsprechenden 29.5xx-Spezifikationen definiert, beispielsweise TS 29.502 für SMF-Dienste und TS 29.503 für UDM-Dienste.

Wie erscheint die OpenAPI-Eigenschaft nullable in einer tatsächlichen JSON-Nachricht?

Ein als nullable definiertes Feld, typischerweise über einen Typ mit Rm-Suffix, kann im JSON-Body ausdrücklich den Wert null enthalten, um anzuzeigen, dass derzeit kein gültiger Wert zugewiesen ist. Das unterscheidet sich davon, dass das Feld vollständig fehlt. Ein fehlendes Feld kann bedeuten, dass der Parameter nicht anwendbar ist oder nicht übermittelt wurde, während ein ausdrücklich gesetztes null eine konkrete semantische Bedeutung haben kann, etwa das Löschen eines zuvor konfigurierten Werts.

Können sich gemeinsame SBI-Datentypen zwischen Herstellern unterscheiden?

Die Definitionen sind auf Spezifikationsebene standardisiert, dennoch können in realen Produkten Implementierungsunterschiede auftreten. Manche Hersteller implementieren möglicherweise nur einen Teil der optionalen Felder, bestimmte APIs können herstellerspezifische Erweiterungen enthalten, und die Strenge der Enumerationsvalidierung kann variieren. Solche Unterschiede gehören zu den typischen Prüfpunkten bei Interoperabilitätstests.

Wie lässt sich schnell erkennen, ob ein Feld einen gemeinsamen oder einen NF-spezifischen Typ verwendet?

Am direktesten ist es, den $ref-Pfad in der OpenAPI-Definition zu prüfen. Verweist die Referenz auf ein gemeinsames Schema aus TS 29.571, handelt es sich normalerweise um einen gemeinsam genutzten SBI-Datentyp. Verweist sie auf ein Schema innerhalb der aktuellen Servicespezifikation, ist der Typ in der Regel NF-spezifisch. Vertrautheit mit häufig wiederverwendeten Typen wie SUPI, TAI, S-NSSAI und ProblemDetails erleichtert ihre Erkennung auch bei der Paketanalyse.

Was ist in einem Paketmitschnitt der Unterschied zwischen einem Rm-Typ und einem regulären Typ?

Ist der Wert nicht null, ist die JSON-Darstellung praktisch identisch, da beide Typen dasselbe zugrunde liegende Format verwenden. Der Unterschied besteht auf Ebene des OpenAPI-Modells: Ein Rm-Typ erlaubt dem Feld den Wert null. Enthält ein erfasstes Feld ausdrücklich null, muss es eine nullable-Definition verwenden. Enthält es einen normalen gültigen Wert, reicht dieser Wert allein nicht aus, um festzustellen, ob das Schema den regulären Typ oder den entsprechenden Rm-Typ referenziert.