Open-source 5G: Service Based Architecture: HTTP/2 & OpenAPI

Introduction

5G Core Network functions communicate with one another via a Service Based Interface (SBI) when utilizing the Service Based Architecture (SBA). These services use the HTTP/2 protocol, which is carried over TCP and is a “request/response” protocol that allows client/server communication. In the 5GC, the clients and servers are the Network Functions whose primary goal is to retrieve a “resource.”

Resources in the 5GC are services that Network Functions provide and are identified by a Uniform Resource Indicator (URI). HTTP Methods such as GET, PUT, and POST are used by the client to define the actions they are attempting to perform. We will cover this more in-depth in the following sections.

3GPP has designated HTTP/2 for 5GC to utilize JSON as a serialization format to carry 3GPP-specific information elements from Network Function to Network Function. 5GC services are defined using the RESTful API design, which uses HTTP methods to interact with its resources. 5GC uses OpenAPI version 3 as the specification for designing the RESTful APIs and is known as the Interface Definition Language (IDL) which utilizes YAML. All of this will be the focus of this article.  

5GC Service Based Architecture

When two Network Functions communicate using the SBA, one function acts as the Service Consumer and the other is the Service Provider. One service or function that requires another service requires a method to “discover” that service, which is known as “service discovery.” Network functions are expected to register their services as available with one or more Network Repository Functions (NRF), which stores services available to connected NFs.

nrf.log showing registered network functions

amg.log showing registering namf-comm service with NRF

5gc pcap showing each NF updating their subscription with NRF when 5GC is turned on

Each NF registers with the NRF and creates a unique Instance ID

Each NF becomes Registered with the NRF and the NF IP address is also stored
5G API Reference

5G API Reference

Open5GS API services are defined in the /lib/sbi/types.h file

AMF

• Namf-comm
  • communication
• Namf-loc
  • location
• Namf-evts
  • events
• Namf-mt
  • mobile terminated services

AUSF

• Nausf-auth
  • Authentication
• Nausf-sorprotection
  • SoR protection
• Nausf-upuprotection
  • UE parameter update protection

BSF

• Nbsf-management

NRF

• Nnrf-nfm
  • network function management
• Nnrf-disc
  • discovery
• Nnrf_oauth2

PCF

• Npcf-am-policy-control
  • Access and Mobility policy control
• Npcf-smpolicycontrol
  • Session Management policy control
• Npcf-policyauthorization
  • Policy Authorization
• Npcf-bdtpolicycontrol
  • Background data transfer policy control
• Npcf-eventexposure
  • event exposure
• Npcf-ue-policy-control
  • user equipment policy control

SMF

• Nsmf-pdusession
  • pdu session
• Nsmf-event-exposure
  • event exposure
• Nsmf-nidd
  • Non IP data delivery

UDM

• Nudm-sdm
  • Subscriber data management
• Nudm-uecm
  • UE context management
• Nudm-ueau
  • UE Authentication
• Nudm-ee
  • event exposure
• Nudm-pp
  • parameter provision
• Nudm-niddau
  • Non IP data delivery Authorization
• Nudm-mt
  • mobile termination

UDR

• Nudr-dr
  • data repository
• Nudr-group-id-map
  • Group ID map

Logging Levels

You can view the OpenAPI service messages in the 5G Core logs per network function if you set the logging levels to either DEBUG or TRACE. DEBUG will capture the service message exchanges, and TRACE will include additional detail about the information being passed between Network Functions.

amf.log with DEBUG and TRACE logs

OpenAPI Dissector

My suggestion is to use the OpenAPI Dissector. You can download and configure this at https://github.com/telekom/OpenAPI-Dissector

I ran into issues on my Ubuntu computer, but it seemed to work just fine on my MacBook Pro. I captured the pcap from the 5GC on the Ubuntu laptop and transferred the file to my MacBook and opened it in Wireshark, and used the “openapi” filter.

Wireshark with ‘openapi’ filter

You can also use the filter “sctp || openapi” to see NAS/NGAP messages simultaneously. This can be helpful when determining when certain events are taking place and the 5GC is interacting with the gNB and/or UE.

You can also filter to “http2” or “json” to make the results more or less granular.

Wireshark with ‘sctp || openapi’ filter

I enjoy using Wireshark’s “Flow Graph” feature when I have a data set that is narrow enough. You can access this feature by navigating to “Statistics” > “Flow Graph” and then selecting “Limit to display filter.”

Wireshark openapi flow graph

Open5GS Networking

My setup for this analysis was having Open5GS and srsRAN running on the same laptop. The default networking configuration for Open5GS is used.

Not pictured, but also important to note are…

• Service Communication Proxy (SCP): 127.0.0.200
• Binding Support Function (BSF): 127.0.0.15

Open5GS architecture and network configuration

URI

Resources in the 5GC are services that Network Functions provide, such as a PDU or Policy Session, subscription data, etc., and are identified by a Uniform Resource Indicator (URI). The structure of the URI is as follows…

apiRoot/apiName/apiVersion/apiSpecificResourceUriParts

From the amf.log – the AMF is sending

01/22 13:57:19.319: [sbi] DEBUG: [200:PUT] http://127.0.0.200:7777/nudm-uecm/v1/imsi-001010000560124/registrations/amf-3gpp-access (../lib/sbi/client.c:675)

• apiRoot
  • Scheme: “http”
  • String: “://”
  • Authority: 127.0.0.200:7777
  • API Prefix: “/”
• apiName: “nudm-uecm”
• apiVersion: “v1”
• apiSpecificResourceUriParts: “imsi-001010000560124/registrations/amf-3gpp-access”

Initial Registration and Authentication analysis

I will focus primarily on the messages directly communicated with a specific network function (AUSF, UDM, UDR). There are many instances of the same messaging that goes to the SCP (127.0.0.200) and the NRF (127.0.0.10). There are also two messages associated with nearly every message: a HEADER and a DATA frame. Data frames are not always necessary, but header frames are required. Header frames define some of the following information.

• Method: “GET”, “POST”, etc.
• Scheme: “http”
• Path: “/5g-aka-confirmation”
• Status: “200 OK”
• Server: “Open5GS”
• Content-Length:
• Content-type: “application/json”
• Location: “http://127.0.0.12:7777/nudm-ueau/v1/imsi-001010000560124/auth-events/1

1. (675) The AMF requests the UE Authentications resource from the nausf-auth service. Note the frame numbers for the response messages.

2. (676) The following message includes a JSON with the OpenAPI request information.

3. (682) The AUSF queries the UDM for Security Information and to Generate Authentication Data based on the subscribers SUCI/SUPI

4. (694) the UDM queries the UDR for Authentication data and Authentication Subscription

5. (707) The UDR responds with the authenticationMethod, encPermanentKey, sequenceNumber, and encOpcKey values.

6. (714) the UDM responds with the avType, rand, autn, xresStar, kausf, and supi.

7. (721) The AUSF responds with the Authentication Information. Once this information makes it to the AMF, it is forwarded to the UE via the gNB in the NAS AUTHENTICATION REQUEST message.

More on SCP

SCP is the Service Communication Proxy, an HTTP/2-specific Network Function. SCP is responsible for working with the Network Repository Function (NRF) for Network Function discovery requests. This is also called “delegated discovery,” where the consumer NF relies on the SCP to discover the required service and NF.

There are many ways that SCP can be configured to work within a network, and this is detailed more in this article from Ericsson.

Conclusion

HTTP/2 and OpenAPI are another way to analyze 5G networks internal to the 5G Core. I installed the OpenAPI Dissector today and started going through the data I could pull from my personal network. The example is just a snapshot of messages sent between Network Functions. This is helpful in understanding 5G at a low level with each of its communication procedures and protocols, network configurations, services, and 5G core architectures.