Why Is the 5GC SBI Built Around HTTP/2 Service Calls?

The relationship between network functions changed significantly when the 5G Core adopted a Service-Based Architecture. Functions such as the AMF, SMF, UDM, PCF, NSSF, and AUSF are no longer limited to exchanging messages over fixed point-to-point protocol interfaces. Instead, each NF exposes capabilities as services that other network functions can consume when required.

In this model, one NF may retrieve a resource from another NF, create a new context, update an existing resource, or delete one that is no longer needed. The communication pattern naturally becomes request → resource operation → response. HTTP methods, URIs, status codes, and JSON provide a practical way to represent this type of service interaction.

A simplified SBI protocol stack can be represented as:

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

JSON defines how application data is represented. HTTP/2 organizes requests and responses for transport. TCP provides reliable delivery, IP handles addressing and routing, and Ethernet carries the frames across the underlying network.

This is very different from interfaces such as N2, N3, and N4. N2 uses NGAP, N4 uses PFCP, and the user plane commonly uses GTP-U. The Service-Based Interface uses HTTP/2 as the transport framework for service communication. This is not simply a protocol replacement. It reflects a broader change in 5GC design philosophy—from exchanging predefined interface messages to invoking services.

For example, when the AMF needs access-management subscription data for a subscriber, the AMF acts as an NF Consumer and requests a resource from the UDM acting as an NF Producer. The consumer mainly needs to know which resource to access, which operation to perform, and what result is returned. There is no need to design a completely separate transport mechanism for every individual service procedure.

HTTP/2 also provides a very practical advantage for this environment: multiple service requests can share a single TCP connection. SBI interactions between network functions are frequent, and repeatedly establishing new TCP connections for every API call would create unnecessary connection-management overhead.

What Transport Problems Does HTTP/2 Solve Compared with HTTP/1.1?

HTTP/2 did not replace the entire application model of HTTP/1.1. Methods such as GET and POST still exist, and the basic request-response model remains familiar. The major changes are in how data is organized and transmitted.

For 5GC, faster web-page loading is not the important point. The real value is that HTTP/2 provides a more efficient connection model for large numbers of concurrent API calls between network functions.

One Connection Can Carry Multiple Streams

HTTP/1.1 supports persistent connections, but concurrency on a single connection still has limitations. In many traditional deployments, multiple TCP connections are opened to increase parallelism, which adds connection-management overhead on both the client and server sides.

HTTP/2 introduces multiplexing. A single TCP connection can contain multiple independent Streams at the same time. Requests do not have to wait for a previous transaction to fully complete before additional traffic can be transmitted. Frames from multiple Streams can be interleaved across the same connection.

In a 5GC SBI environment, once an AMF establishes an HTTP/2 connection with another NF, that connection is not limited to processing only one API request at a time. Multiple service operations can use different Streams, each carrying its own request and response.

Fewer TCP connections mean less connection-management overhead, which is well suited to the high-frequency service interactions that occur between 5G Core network functions.

HTTP Messages Are Transported as Binary Frames

HTTP/1.x is largely text oriented. Request lines, headers, and message bodies are clearly represented as textual structures. HTTP/2 changes the wire format and carries protocol information in binary Frames.

HTTP headers are commonly carried in HEADERS Frames, while the actual application payload can be carried in DATA Frames. The receiving side uses information in the Frame header, including the Stream Identifier, to determine which Stream a particular Frame belongs to and then reconstruct the complete HTTP message.

This is why an HTTP/2 packet capture in Wireshark often does not look like one complete block of HTTP text. Instead, engineers see a sequence of HEADERS, DATA, and other Frame types.

Repeated Headers Do Not Need to Be Sent in Full Every Time

HTTP headers appear repeatedly in SBI API traffic. If every request carried the same header fields in full, the duplicated overhead would quickly become significant.

HTTP/2 uses HPACK for header compression. In simplified terms, both sides maintain header tables, allowing frequently repeated fields to be represented by indexes instead of retransmitting the full text every time.

The more repetitive the headers are, the more useful compression becomes. When network functions repeatedly invoke similar APIs, fields such as methods, paths, and common headers may appear again and again, making HPACK especially effective at reducing redundant transmission.

HTTP/2 Also Defines Server Push

HTTP/2 includes a Server Push mechanism and defines the PUSH_PROMISE Frame, allowing a server to proactively provide related resources before a client explicitly requests each one.

For understanding 5GC SBI, however, Server Push is not the main concept to focus on. Connection reuse, multiplexing, Streams, Frames, header compression, and the API request-response model are much more important for practical SBI analysis.

How Should Connection, Stream, Message, and Frame Be Understood?

One of the most confusing parts of HTTP/2 is that the terms Connection, Stream, Message, and Frame often appear together. Understanding them as a hierarchy is much easier than memorizing each definition independently.

A Connection is the underlying TCP connection. Once the TCP session has been established, HTTP/2 traffic is carried across that connection.

A Stream is a logical bidirectional channel inside the Connection. Each Stream has its own integer identifier. Multiple Streams can exist simultaneously inside one TCP connection, which is the foundation of HTTP/2 multiplexing.

A Message represents a logical HTTP request or response. For example, an AMF may send a GET Request Message to the UDM, and the UDM returns a corresponding Response Message.

A Frame is a smaller unit used by HTTP/2 for actual transmission. One Message may consist of one or more Frames. Common examples include:

• HEADERS Frame: carries HTTP header information.

• DATA Frame: carries application payload data.

• Other Frame types: support connection management, flow control, and other HTTP/2 functions.

The relationship can therefore be summarized as:

           One Connection contains multiple Streams. A Stream carries Request and Response Messages, and each Message is composed of one or more Frames.        

The HTTP/2 Frame header contains fields such as Length, Type, Flags, reserved bits, and the Stream Identifier. The Stream Identifier is particularly important because it tells the receiver which logical Stream the Frame belongs to.

Even when Frames from several Streams arrive in an interleaved order, the receiver can use the Stream ID to associate and reassemble the correct data. This is the core mechanism that allows HTTP/2 to efficiently carry multiple concurrent transactions over one TCP connection.

For 5G Core engineers, this concept is especially important during packet analysis. SBI traffic should not be grouped simply because packets appear next to each other in a capture. Stream ID, URI, HTTP method, and response status should all be considered together.

How Do JSON and RESTful APIs Turn 5GC Capabilities into Resources?

HTTP/2 answers the question of how service traffic is transported efficiently. What actually defines the application model of 5GC SBI is the combination of RESTful APIs and resource-oriented design.

REST is an architectural style. One of its main ideas is to represent business objects as resources, assign each resource a unique URI, and then use HTTP methods to perform operations on those resources.

A “resource” in 5GC is not limited to the kind of object commonly associated with websites. It can represent subscriber data, an SM Context, a PDU Session-related object, or another piece of state maintained by a network function.

For example, access-management subscription data for a subscriber can have one specific URI, while session-management subscription data can use another. From the consumer's point of view, the operation is no longer simply:

“Call a particular UDM signaling procedure.”

Instead, it becomes:

           Perform a GET, POST, PUT/PATCH, or DELETE operation on a specific resource.        

HTTP Methods Define What Happens to a Resource

Common operations can be understood as follows:

• GET: retrieve or read a resource.

• POST: create a resource or invoke a defined operation.

• PUT / PATCH: update an existing resource.

• DELETE: remove a resource.

After processing the request, the server returns an HTTP Status Code to indicate the result.

A 200 response generally indicates successful processing and returned data. A 201 response commonly indicates that a resource was successfully created. A 204 response can indicate that an operation succeeded without returning a response body. 4xx responses usually point to request, resource, or authorization issues, while 5xx responses generally indicate server-side processing problems.

These status codes are extremely useful during 5GC troubleshooting. An established HTTP/2 connection does not mean that the service operation itself succeeded. Engineers still need to check the requested URI, the HTTP Method, and the status code returned by the NF Producer.

JSON Carries the Actual Business Data

SBI application payloads are commonly represented in JSON. JSON is a lightweight data-interchange format based on Key-Value structures. It can represent strings, numbers, Boolean values, arrays, objects, and nested data structures.

In other words, the HTTP/2 DATA Frame is responsible for transporting the payload, while the JSON inside that Frame defines what the application data actually means.

From an engineering perspective, HTTP/2 and JSON should not be treated as the same protocol layer. HTTP/2 organizes transport, JSON represents application data, and RESTful APIs define resources and the operations that can be performed on them.

How Is a 5GC SBI Resource URI Structured?

Once the concept of a resource is clear, the structure of an SBI URI becomes much easier to understand. Resource paths are not arbitrary. They follow a structured hierarchy.

A typical format can be represented as:

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

Each part has a specific role:

• apiRoot:   the root address used to access the service, typically in the form http(s)://host(:port).

• apiName:   the name of the specific SBI API or service exposed by the network function.

• apiVersion: the API version, such as v1.

• apiSpecificResourceUriPart: the path identifying the specific resource or operation.

For example, access-management subscription data and session-management subscription data may both be provided by the UDM, but they use different resource paths. The URI therefore makes it possible to clearly identify exactly which resource the consumer is requesting.

SMF PDU Session services follow the same general idea. Different SM Contexts and PDU Session-related resources have their own URIs, and different HTTP methods are used to create, retrieve, modify, or release them.

This resource-oriented design changes how engineers should think about SBI interfaces. Instead of memorizing only a traditional sequence such as “Message A → Message B,” an SBI interaction can be analyzed as:

           Service → Resource → Method → URI → Status Code → JSON Body        

If 5GC SBI is approached purely with the traditional telecom mindset of matching request-message names with response-message names, the architecture can feel fragmented. Once it is viewed as an API-based resource model, the logic becomes much clearer.

How Should Engineers Trace an SBI Transaction in Wireshark?

Once the HTTP/2 concepts are understood, the next step is applying them to real packet analysis. Because a single TCP connection can carry multiple HTTP/2 Streams at the same time, filtering only by source and destination IP addresses may still leave several unrelated SBI transactions mixed together in the same trace.

A practical approach is to first identify the IP addresses of the NF Consumer and NF Producer, then narrow the analysis using the relevant Stream ID.

For example, if a specific request is using Stream ID 1, the server address and that Stream ID can be used together to isolate the Frames that belong to the corresponding request-response transaction.

After filtering the traffic, focus on the following information:

• Stream ID: confirms whether the Frames belong to the same logical Stream.

• HEADERS:  reveals the HTTP Method, Path, and other header fields.

• DATA: shows whether the transaction carries a JSON application payload.

• Status Code: indicates how the NF Producer processed the request.

• URI: identifies the exact service, API version, and resource being accessed.

A useful troubleshooting sequence is to start at the transport layer and move upward. First, confirm that the TCP connection is established. If TCP is not available, there is no foundation for HTTP/2 or RESTful API communication.

Next, verify that the HTTP/2 layer contains normal HEADERS and DATA Frames and use the Stream ID to associate them with the correct transaction.

Then check whether the HTTP Method and URI match the expected operation. Many SBI problems are not caused by network connectivity at all. They may result from an incorrect resource path, API version, or HTTP Method.

After that, inspect the HTTP Status Code. A 4xx response should direct the investigation toward the request syntax, missing resources, authorization, or application parameters. A 5xx response points more strongly toward processing inside the NF Producer.

Only after the HTTP request has been confirmed as correctly delivered should the JSON payload be examined in detail.

The complete SBI troubleshooting path can therefore be summarized as:

           TCP → HTTP/2 Connection → Stream → HEADERS → Method/URI → DATA/JSON → Status Code        

This approach turns what can initially look like a highly “Internet-style” 5GC protocol into a familiar layered engineering problem. Verify connectivity at the bottom, HTTP/2 transport behavior in the middle, and API resources and business data at the top. The fault boundary becomes much easier to identify.

From a broader 5GC architecture perspective, SBI does not use HTTP/2 simply because it is newer than HTTP/1.1. The deeper reason is that the 5G Core organizes NF capabilities as services and therefore needs a communication model that can support frequent API calls, concurrent service interactions, and resource-oriented access efficiently.

HTTP/2 provides Connections, Streams, and Frames. Multiplexing improves connection utilization, HPACK reduces repeated header overhead, and binary framing provides a structured transport format. JSON carries the application data, while RESTful APIs define the resources and the operations performed on them. Together, these elements form the complete communication model used by the 5GC Service-Based Interface.

FAQ

Are HTTP/2 and RESTful APIs the Same Thing?

No. HTTP/2 is an HTTP transport protocol that defines mechanisms such as Connections, Streams, and Frames. REST is an API architectural style that defines how application objects are represented as resources and how those resources are accessed through URIs and HTTP Methods. 5GC SBI uses RESTful-style APIs over HTTP/2.

Can Stream ID 0 Carry a Normal SBI Application Request?

No. Stream ID 0 has a special protocol-level role and is not used as a normal application Stream. When analyzing actual SBI requests, engineers should focus on the non-zero Stream IDs assigned to business transactions.

Does the SBI apiRoot Have to Contain an IP Address?

Not necessarily. The logical form of apiRoot is http(s)://host(:port). The host identifies the relevant service endpoint according to the network architecture and service discovery mechanism. When analyzing a URI, it is useful to separate apiRoot from apiName, apiVersion, and the resource-specific path.

If HTTP/2 Uses Binary Framing, Why Can JSON Still Be Seen Inside DATA Frames?

Binary framing refers to how HTTP/2 organizes and transports protocol data. It does not require the application-layer payload itself to use a binary data format. A DATA Frame can still carry JSON. JSON defines the 5GC application fields, while HTTP/2 places that payload into the appropriate Stream for transport.

Does an HTTP 200 Response Prove That the Entire 5GC Procedure Was Successful?

No. HTTP 200 only indicates that the specific HTTP request was successfully processed at that point. A complete 5GC procedure may involve multiple service calls between several network functions. Engineers still need to evaluate the URI, JSON content, and surrounding signaling sequence before concluding that the entire end-to-end procedure completed successfully.