When troubleshooting Service-Based Interfaces in a 5G Core, many engineers run into the same problem. The request body sent from an AMF to an SMF may contain familiar fields such as SUPI, DNN, S-NSSAI, TAI, PDU Session ID, and 5QI, yet determining whether the message is actually valid can still be difficult. Should a field be encoded as a string or an integer? Does it have a defined value range? Can any value be used, or must it come from a predefined enumeration? Can an object contain other nested parameters?

The answers are defined by SBI common data types. Service-Based Interfaces span network functions such as the AMF, SMF, UDM, PCF, and NRF, but many of the underlying parameters are not specific to any one NF. If every service defined these values independently, the specifications would contain unnecessary duplication, and the same subscriber identifier or QoS parameter could be represented differently across APIs. That is why analyzing SBI traffic requires more than checking HTTP methods and resource URIs. HTTP/2 defines how requests are transported, JSON defines how the data is represented, and common data types answer a more fundamental question: what format and validation rules each JSON parameter must follow.

What Problems Do Common Data Types Solve?

They can be thought of as a shared "data vocabulary" for the entire 5GC service-based API environment. A data type may appear in an AMF request and also be referenced by the SMF, UDM, or PCF. It does not belong to a single interface. Instead, it provides a standardized definition that can be reused across multiple services.

Consider an IPv4 address. Each NF should not define its own way of representing the address as a string. The same applies to PLMN information, where MCC and MNC have specific lengths and formats, and to subscriber and equipment identifiers such as SUPI, GPSI, and PEI, which follow their own encoding rules. Consistent definitions allow RESTful APIs between different NFs to exchange information reliably.

Common data types should also be distinguished from NF-specific types. Common types cover objects that appear repeatedly across interfaces, while business objects unique to a particular network function are defined in the corresponding 29-series specifications. In practice, a single SBI API often references both kinds of data types.

Their scope extends far beyond network addresses. Common definitions cover generic parameters, subscription and identity information, 5G network data, QoS, charging, Trace information, and other reusable objects. Together, they form a foundational data model for SBI message parameters.

How Are the Three Basic Data Structures Different?

From a structural perspective, SBI parameters can generally be grouped into three categories: simple data types, enumerations, and structured data types. Understanding these three categories is more useful than memorizing individual parameter names, because most fields seen in Wireshark captures, API documentation, and OpenAPI definitions fit into this model.

Simple data types are the lowest-level building blocks. They include string, integer, number, date, date-time, and boolean. In 5GC, these basic types are usually combined with additional constraints such as value ranges, encoding formats, or regular-expression patterns.

An IPv4 address, for example, is technically represented as a string, but not every arbitrary string is valid. It must follow the required IPv4 format. IPv6 addresses, IPv6 prefixes, and MAC addresses each have their own formatting requirements. Uint16, Uint32, and Uint64 define ranges for unsigned integers. A URI must follow URI formatting rules, while DateTime values must use the specified date-time format.

Specifications also frequently define types with an Rm suffix, such as Ipv4AddrRm, DateTimeRm, and Uint32Rm. These types use the same underlying format as their corresponding base types but include the OpenAPI nullable property, which allows the field to carry a null value.

Enumeration types work like multiple-choice fields: the value must be selected from a predefined set. AccessType, for example, distinguishes between 3GPP_ACCESS and NON_3GPP_ACCESS. PduSessionType can take values such as IPV4, IPV6, IPV4V6, UNSTRUCTURED, or ETHERNET. CoreNetworkType can indicate either 5GC or EPC.

The purpose of an enumeration is to remove ambiguity. A consumer cannot invent a different string that happens to mean the same thing. It must use one of the values explicitly defined by the specification. This is a common troubleshooting scenario: the field name is correct, but the enumeration value is invalid, so the API still rejects or misinterprets the request.

Structured data types combine multiple attributes into a complete object. Those attributes may themselves reference simple types, enumerations, or other structured objects, creating a hierarchical model.

ProblemDetails is a typical example. It can include fields such as type, title, status, detail, instance, cause, and invalidParams. TAI is another example, combining a PLMN ID with a TAC. GUAMI goes one level further by combining a PLMN ID with an AMF ID. At this level, SBI analysis can no longer focus on individual fields alone; the relationships between the attributes inside the object also matter.

How Are Identity and Network Parameters Built Up?

In real packet captures, subscription, identity, and 5G network-related data are among the most common SBI parameters. SUPI identifies a subscriber, GPSI represents an external subscriber identity, PEI represents a permanent equipment identifier, DNN identifies a data network, and an NF Instance ID uniquely identifies an NF instance.

Most of these fields may appear to be simple strings, but the important part is the encoding rule inside the string. A SUPI may contain an IMSI or NAI representation, while a GPSI may contain an MSISDN or External Identifier. In other words, being defined as a string does not mean that any string is valid.

5G network-related types build on these basic identifiers to represent session and location information. PduSessionId identifies a PDU Session. MCC and MNC form part of a PLMN identity. TAC identifies a Tracking Area Code, while NrCellId and EutraCellId identify NR and E-UTRA cells respectively.

Structured objects then combine these basic parameters into higher-level data models. S-NSSAI uses an SST and an optional SD to represent a network slice. TAI combines a PLMN ID and TAC. NCGI combines a PLMN ID with an NR Cell ID to identify an NR cell, while ECGI performs a similar role for E-UTRA.

UserLocation is an even higher-level abstraction. Depending on the access type, it can carry an NR Location, E-UTRA Location, or Non-3GPP Access Location. An NR Location can itself contain TAI, NCGI, a location timestamp, and geographical information.

This illustrates the modular design of SBI data models. Basic elements such as MCC, MNC, TAC, and Cell ID are standardized first, then combined into higher-level objects such as PLMN ID, TAI, NCGI, and UserLocation. APIs can reuse these objects directly instead of redefining an entire set of location parameters for every service.

Why Must QoS, Charging, and Trace Data Be Standardized Too?

SBI traffic carries much more than subscriber identities and network location. QoS policies, usage information, and network Trace data also move between multiple NFs, so these values require consistent data definitions as well.

Among QoS parameters, QFI identifies a QoS Flow, 5QI represents the 5G QoS Identifier, BitRate represents a rate using a value and unit, Packet Delay Budget expresses a delay budget, and Packet Error Rate and Packet Loss Rate describe transmission quality.

QoS policies also use many enumeration types. PreemptionCapability indicates whether a service can pre-empt resources assigned elsewhere. PreemptionVulnerability indicates whether existing resources can be taken away by a higher-priority service. QosResourceType distinguishes values such as NON_GBR, NON_CRITICAL_GBR, and CRITICAL_GBR.

These basic fields are then combined into structured objects such as ARP, AMBR, Dynamic 5QI, and Non-Dynamic 5QI. This allows the SMF, PCF, and other related network functions to use the same representation when exchanging concepts such as priority, bit rate, delay, and pre-emption behavior.

Charging data follows the same design principle. ChargingId, RatingGroup, and ServiceId are relatively straightforward simple data types, while QoSFlowUsageReport can include QFI, collection start and end timestamps, and uplink and downlink traffic volumes. VolumeTimedReport can represent PDU Session usage over a defined time interval.

Trace-related types standardize network tracing information. TraceDepth uses enumerated values to describe different trace levels, while TraceData combines parameters such as Trace Reference, Trace Depth, and NE Type. This prevents every NF from defining its own incompatible set of Trace fields.

These examples show that common data types do more than standardize "a few JSON fields." They standardize how different core-network services understand the same business and network concepts. If QoS, location, charging information, or subscriber identifiers must move between multiple NFs, they first need a consistent data model.

How Can Data Types Be Used in Practical Troubleshooting?

One of the most common engineering mistakes is to inspect a JSON message only to see whether a field is present, without checking the data type and associated constraints. A more effective troubleshooting method is to examine the HTTP layer and the data model together.

Start by identifying the service being called and the resource URI. Then locate the target field in the request or response body. Once the field is found, do not stop at the value itself. Check which data type it references, whether it is mandatory or optional, its Cardinality, whether it is an enumeration, and whether it has any formatting or Pattern restrictions.

An IPv4 field may look like an IP address to a human reader, but if it does not satisfy the defined format, it is still invalid input. Likewise, a PduSessionType value may be understandable in plain language, but if it is not one of the specified enumeration values, it does not conform to the API definition.

Structured data should be expanded recursively. When UserLocation appears, determine whether the object contains NR, E-UTRA, or Non-3GPP location information. When TAI appears, inspect the PLMN ID and TAC. When S-NSSAI appears, check the SST and the optional SD. Only by following the type references layer by layer can an engineer determine whether the JSON object matches the API model.

When a server rejects a request, ProblemDetails is also worth examining closely. In addition to the HTTP status code, it can provide detail, cause, and invalidParams information. When these fields are present, troubleshooting can begin with the specific parameter that violated the API requirements instead of stopping at a generic HTTP 4xx response.

Why Is a Data-Model Mindset More Useful Than Memorizing Parameter Tables?

The number of 5GC SBI common data types is large enough that memorizing every field, regular expression, and value range quickly becomes inefficient. A better approach is to build a data-model mindset: simple types define the smallest data units, enumerations restrict legal states, and structured types combine those units into objects that can be used directly by 5GC services.

With this framework, SUPI, MCC, TAC, and QFI are no longer isolated parameters. They become building blocks for subscriber, location, session, QoS, charging, and Trace models. One of the reasons different NFs can invoke services consistently through SBI is that these common types provide stable and reusable data semantics.

When reading an unfamiliar 5GC API, the most useful first question is therefore not "How many fields are in this message?" Instead, determine which types those fields reference, how the objects are nested, and which constraints decide whether the resulting JSON is valid. Once this method becomes familiar, even an SBI service that has never been seen before can be analyzed by following the OpenAPI and data-type definitions layer by layer rather than memorizing an entirely new parameter table.

FAQ

Which 3GPP Specification Defines SBI Common Data Types?

They are mainly defined in TS 29.571, 5G System; Common Data Types for Service Based Interfaces. This specification defines reusable data structures shared across SBI services. NF-specific services and data types are defined in the corresponding 29.5xx specifications, such as TS 29.502 for SMF services and TS 29.503 for UDM services.

How Does the OpenAPI Nullable Property Appear in an Actual JSON Message?

A field defined as nullable, commonly through an Rm-suffixed type, may explicitly carry a null value in the JSON body to indicate that no valid value is currently assigned. This is different from the field being completely absent. An absent field may mean that the parameter is not applicable or was not provided, while an explicit null can carry a specific semantic meaning, such as clearing a previously configured value.

Can SBI Common Data Types Differ Between Vendors?

The definitions are standardized at the specification level, but implementation differences can still appear in real products. Some vendors may implement only a subset of optional fields, certain APIs may include vendor-specific extensions, and the strictness of enumeration validation can vary. These differences are common points to investigate during interoperability testing.

How Can You Quickly Tell Whether a Field Uses a Common Type or an NF-Specific Type?

The most direct method is to inspect the $ref path in the OpenAPI definition. If the reference points to a common schema defined for TS 29.571, it is normally a shared SBI data type. If it points to a schema defined inside the current service specification, it is generally NF-specific. Familiarity with commonly reused types such as SUPI, TAI, S-NSSAI, and ProblemDetails also makes them easier to recognize during packet analysis.

What Is the Difference Between an Rm Type and a Regular Type in a Packet Capture?

When the value is non-null, the JSON representation is effectively the same because both types use the same underlying format. The difference exists at the OpenAPI model level: an Rm type allows the field to contain null. If a captured field explicitly carries a null value, it must be using a nullable definition. If it contains a normal valid value, the value alone is not enough to determine whether the schema references the regular type or the corresponding Rm type.