Service Based Interfaces

The 5G core network is a Service Based Architecture (SBA), which consists of multiple Network Functions (NFs). Each interface in the Service Based Interfaces (SBI) consists of one or more services that are used for the communication between the functions.

Introduction to Service Based Architecture

The 5G core network is a Service Based Architecture (SBA), which consists of multiple Network Functions (NFs) communicating using a common service-based protocol. This protocol is based on OpenAPI v3 using JSON signaled over HTTP/2. Multiple instances of Network Functions can exist (for example, multiple SMFs) and each instance is identified by a Network Function Instance ID (NFInstanceID), which is modeled as a Unique Universal Identifier (UUID).

Communication between functions is based on services offered by each function. Each service consists of a service producer (server) and a service consumer (client). Each service is typically oriented at executing a very specific function. An interface can consist of multiple services, as shown in Relationship between service and interface for the N11 interface. The N11 interface consists of at least the Nsmf_PDUSession service where the SMF acts as server, and the Namf_Communication service where the AMF acts as server. This concept is called Service Based Interfaces (SBI), where each interface (such as N11) consists of one or more services. Services can be reused over interfaces; for example, the Nudm_SDM service is used both on the N8 interface by AMF and N10 interface by SMF.

Figure 1. Relationship between service and interface

In general, any consumer can consume a service, subject to access control. This allows for easy extensibility and re-use. Examples of this are the Nnrf_NFDiscovery and Nnrf_NFManagement services, both of which are served by the NRF. These services are used by other NFs to discover other NFs and register themselves for discovery respectively. For this reason, a 5G core architecture is often presented in an alternative form where the focus is not on interfaces such as shown in Basic 5G FWA network but on the provided services. An example of such a representation is shown Basic 5G network with service representation. This representation also makes it clear that the SBA is focused on the control plane functions.

Figure 2. Basic 5G network with service representation

NF peer discovery

When acting as a client, the MAG-c performs the following steps to establish a peer to host the NF service:

Discover the list of NF instances identified by UUIDs and select one NF instance:
- The NF instance with highest priority is usually selected.
  Note: A lower priority value means a higher priority.
- When multiple NF instances have the same priority, the UPF does hash-based selection per session.
- In some cases, a specific UUID may already be signaled and picked from the list of discovered instances, ignoring the priority. For example, the AMF signals in the Nsmf_PDUSession operations the AMF UUID to use for the related Namf_Communication service.
Determine a list of IP addresses associated with the selected NF instance and select one IP address to use.

For the discovery of NF instances, the MAG-c supports both NRF-based discovery using the Nnrf_NFDiscovery service (see NRF-based discovery for more information) and a locally configured NF ID list (see Enabling discovery based on a local NF ID list for more information). When configured, NRF-based discovery has precedence and the NF ID list is only used if the NRF lookup fails or does not return any NF instances. The following figure shows the NF instance discovery.

Figure 3. NF-instance discovery flowchart

NRF-based discovery

To enable NRF-based discovery, perform the procedure Enabling NRF-based discovery.

When NRF discovery is provisioned, it is automatically enabled for AMF, CHF, PCF, and UDM. Use the following command to suppress discovery for any of these functions.

configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc suppress-discovery

The following query options are included when discovering PCF, CHF, or UDM as follows:

S-NSSAI
S-NSSAI is included by default for PCF and UDM discovery, however, you can use one of the following commands to disable it.
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc exclude-snssais
configure mobile-gateway pdn apn pcf-selection exclude-snssais
```

SUPI

SUPI is included by default, however, you can disable it for each function using the following commands:

for the UDM

configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc chf-selection-options exclude-supi

for the CHF

configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc udm-selection-options exclude-supi

for the PCF

configure mobile-gateway pdn apn pcf-selection exclude-supi

preferred-locality

This option is included if the following commands are configured.

configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc use-locality
configure mobile-gateway pdn nf-profile-attributes locality

GPSI
GPSI is included by default for PCF and CHF discovery. You can disable it using the following commands:
- for the CHF
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc chf-selection-options exclude-gpsi
```
- for the PCF
```
configure mobile-gateway pdn apn pcf-selection exclude-gpsi
```
DNN
DNN is included by default for the PCF.
Serving scope

This option is included by default for the PCF.

The NRF keeps a cache of discovered NF instances per query. This cache expires based on the validityPeriod IE returned from the NRF. Use the following command to override this value.

configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc nrf-cache-interval

When a valid cache entry is discovered, it is used instead of contacting the NRF. When an NRF cannot be reached or returns an error, it is temporarily blocked for discovery.

Enabling NRF-based discovery

Enable NRF-based discovery using the Nnrf_NFDiscovery service for the discovery of NF instances.

Configure and enable a client service instance to enable NRF-based discovery.

Configure a client service instance.

configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc

Within the NNRF client service, configure the following:
1. Specify the interface that MAG-c uses to communicate with the NRF.
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc interface
```
2. Specify that NF instances can be used for the discovery service; see Enabling discovery based on a local NF ID list for more information.
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc nf-id-list
```
Provision an optional HTTP/2 profile to change generic HTTP/2 and SBI functionality, such as HTTP/2 level retries, or enable Python. See HTTP/2, OpenAPI, and Python for more information.

Enable the client service instance.

configure mobile-gateway pdn sba-service-realm client-service

Enabling discovery based on a local NF ID list

Use this task to configure an NF ID list for local discovery.

Use the commands in the following context to configure an NF ID list with multiple NF profile ID entries, each identifying an NF instance and its profile.
```
configure mobile-gateway profile list nf-id-list nf-prof-id 
```
Configure the following per NF instance:
- Configure a mandatory UUID to globally identify the NF instance.
```
configure mobile-gateway profile list nf-id-list nf-prof-id uuid
```
- Configure one or both of the following commands:
  - Configure an FQDN to retrieve a list of IP addresses using a DNS client (see Enabling DNS-based IP lookup for more information).
```
configure mobile-gateway profile list nf-id-list nf-prof-id fqdn
```
  - Configure a prioritized address to directly determine a list of IP addresses.
```
configure mobile-gateway profile list nf-id-list nf-prof-id prioritized-address-list
```
- Configure an NF priority to determine the priority of this NF Instance compared to other NF instances. A lower value has a higher priority.
```
configure mobile-gateway profile list nf-id-list nf-prof-id nf-priority 
```
- Configure a custom API prefix to insert in the URI for the service calls, as specified in TS 29.501.
```
configure mobile-gateway profile list nf-id-list nf-prof-id api-prefix
```
- Activate this NF instance for selection. For this, the UUID and either the FQDN or prioritized address list must be configured.
```
configure mobile-gateway profile list nf-id-list nf-prof-id enable
```
To use the NF ID list for NF discovery, configure the nf-id-list command for any of the following services:
Note: If enabled for the service, the NRF-based discovery takes precedence over the NF ID list configuration. However, the NF ID list may still be used as a fallback, or for cases where the NRF returns a UUID but not an FQDN or IP address. See NF peer discovery and NRF-based discovery for more information.
- Nnrf_NFDiscovery service
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc nf-id-list
```
  Note: This service does not support NRF-based discovery.
- Nnrf_NFManagement service
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-nfm nf-id-list
```
  Note: This service does not support NRF-based discovery.
- Namf_Communication service
```
configure mobile-gateway pdn sba-client-services amf-client namf-comm nf-id-list
```
- Nudm_SDM service
```
configure mobile-gateway pdn sba-client-services udm-client nudm-sdm nf-id-list
```
- Nudm_UECM service
```
configure mobile-gateway pdn sba-client-services udm-client nudm-uecm nf-id-list
```
- Npcf_SMPolicyControl service
```
configure mobile-gateway pdn apn pcf-selection nf-id-list
configure mobile-gateway pdn sba-client-services pcf-client npcf-smpolicycontrol nf-id-list
```
  Note: If both are present, the APN-level configuration has priority over the SBA client-level configuration.
- Nchf_ConvergedCharging service
```
configure mobile-gateway pdn apn charging nchf chf-selection nf-id-list
```
- Note: See CHF peer discovery for more information about CHF peer selection priority.

Enabling DNS-based IP lookup

Configure and apply a DNS profile to enable DNS-based IP lookup.

Configure a DNS profile.
```
configure mobile-gateway profile dns-profile
```
The following parameters can be configured for the DNS profile:
- IP DSCP and IP TTL
  These parameters determine the DSCP and TTL values in the IP headers of outgoing DNS request packets.
- Message retransmit
  This parameter determines how often and how quickly an unanswered DNS request is retransmitted.
- Primary, secondary, and tertiary DNS
  These parameters determine the DNS servers to attempt. At least a primary DNS must be configured.

Apply the configured DNS profile.

configure mobile-gateway pdn dns-client dns-profile

Configure an interface to send DNS requests.

configure mobile-gateway pdn dns-client dns-interface

URI construction

When acting as a client, the MAG-c constructs SBI URIs as specified in clause 4.4 in 3GPP TS 29.501. The following table lists the URI scheme.

Table 1. URI scheme
apiRoot			apiName	apiVersion	apiSpecificResource
Scheme	Authority	Deployment-specific prefix
http://	IP endpoint or FQDN, and an optional port	API prefix	Service name	API version

The IP Endpoint, FQDN, API prefix, Service name, and API version are either found in the NF profiles or they are hard coded. The NF profiles are discovered either from the NRF or from the local NF ID list; see NRF-based discovery and Enabling discovery based on a local NF ID list for more information.

NF registration

The MAG-c can register itself as an SMF with the NRF using the Nnrf_NFManagement service.

To configure an Nnrf_NFManagement client service instance, do the following:

Use the following command to configure the client service.
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-nfm
```
Within the client service, configure the following:
- Use the following command to configure the interface the MAG-c uses to communicate with the NRF.
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-nfm interface
```
- Use the following command to configure the NF instances to use for the registration service; see Enabling discovery based on a local NF ID list for more information.
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-nfm nf-id-list
```
- Use the following command to configure an optional HTTP/2 profile to change generic HTTP/2 and SBI functionality such as HTTP/2 level retries, or to enable Python. See HTTP/2, OpenAPI, and Python for more information.
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-nfm http2-profile
```
Use the following command option to enable the client service.
```
configure mobile-gateway pdn sba-service-realm client-service service-instance
```
The MAG-c automatically registers itself as an SMF, if the Nsmf_PDUSession service is enabled using the following command.
```
configure mobile-gateway pdn no shutdown
```
For registration to succeed, use the following command to provision at least one slice.
```
configure mobile-gateway pdn slices slice-list
```
To verify the registration, use the following command to check if the NF Status is registered.
```
tools dump mobile-gateway nf-profile
```

The MAG-c updates its registration when relevant configuration changes are applied; for example, adding or removing an APN, changing a slice list, or changing FQDNs.

Use the commands in the following context to configure many of the NF profile attributes that are sent to the NRF when the MAG-c is registered as the SMF.

configure mobile-gateway pdn nf-profile-attributes

If an attribute is dependent on a configuration that is not present, the attribute is not included.

The following table describes the NF profile attributes that are sent to the NRF during the MAG-c registration as the SMF, including the commands used to configure the attributes. When no command context is specified, the nf-profile-attributes context is used.

The MAG-c can include the smfInfo or the smfInfoList attribute when registering. The smfInfoList is used when multiple sets of smfInfo attributes are discovered and they cannot be merged. For example, if a tai-list is used with multiple priorities configured, a separate smfInfo object is created for each priority, and each smfInfo object only includes the TAIs or TAI ranges configured with that priority.

Table 2. Attributes sent during NRF registration
NFProfile attribute	Source
nfInstanceID	Based on the configured nf-instance-id command
nfType	Always SMF
nfStatus	NF status is as follows: suspend, if the following command is configured `configure mobile-gateway pdn suspend` registered, if not
plmn	Based on the configuration of the following command `configure mobile-gateway pdn home-plmn-list`
sNssais	Based on the superset of all configured slice-lists, as determined by the configuration of the following command `configure mobile-gateway pdn slices slice-list configure mobile-gateway pdn apn slices slice-list`
nsiList	Based on the configuration of the following command `configure mobile-gateway pdn slices slice-instance-list`
capacity nfServiceList /capacity	Based on the configured capacity command
priority nfServiceList /priority	Based on the configured priority command
smfInfo /priority smfInfoList/smfInfo /priority	Based on the priority configured in the linked tai-list. If no such list is linked or if the list does not specify a priority, this IE is not included. If multiple priorities are configured in the list, an smfInfo object is created for each different priority.
recoveryTime	Included and automatically generated after a service restart
locality	Based on the configured locality command
fqdn	Based on the configured fqdn command
nfServiceList	List of services provided by the SMF, each entry of which is created based on all the SBA server service instances configured in the following context `configure mobile-gateway pdn sba-server-services`
ipv4Addresses ipv6Addresses nfServiceList /ipEndPoints	IP addresses configured under the interface referenced in the following command `configure mobile-gateway pdn sba-server-services nsmf-pdusession interface`
nfServiceList /serviceInstanceId	Name of the SBA service instance configured using the following command `configure mobile-gateway pdn sba-server-services nsmf-pdusession`
nfServiceList /fqdn	FQDN configured using the following command `configure mobile-gateway pdn sba-server-services nsmf-pdusession` If not provisioned, the FQDN configuration is used in the following context `configure mobile-gateway pdn sba-server-services`
nfServiceList /serviceName	Always nsmf-pdusession
nfServiceList /version/apiVersionInUri	Always v1
nfServiceList /version/apiFullVersion	Always 1.0.2
nfServiceList /scheme	Always http
nfServiceList /nfServiceStatus	Always REGISTERED
nfServiceList /allowedPlmns	Based on the configuration using the following command `configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-plmns`
nfServiceList /allowedNssais	Based on the configuration using the following command `configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-slices`
nfServiceList /allowedNfTypes	Based on the configuration of the following command `configure mobile-gateway pdn sba-server-services nsmf-pdusession allowed-nf-types`
nfServiceList /allowedNfDomains	Based on the configuration of the following command `configure mobile-gateway pdnsba-server-services nsmf-pdusession allowed-nf-domains`
smfInfo /sNssaiSmfInfoList smfInfoList/smfInfo /sNssaiSmfInfoList	List of SMF-specific information for all slices available on this SMF, based on the configuration of the following command `configure mobile-gateway pdn slices slice-list` Or, based on the following command for all APNs that are in an enabled state, where the signaled list is the superset of all configured slice lists `configure mobile-gateway pdn apn slices slice-list`
smfInfo /sNssaiSmfInfoList /sNssai smfInfoList/smfInfo /sNssaiSmfInfoList /sNssai	S-NSSAI identifying this slice in the list
smfInfo /sNssaiSmfInfoList /dnnSmfInfoList smfInfoList/smfInfo /sNssaiSmfInfoList /dnnSmfInfoList	List of DNNs applicable to this slice, depending on the presence of a DNN-specific slice list configured in the following context `configure mobile-gateway pdn apn slice-list` Includes the DNN if the slice is part of the existing DNN-specific slice list Includes the DNN if no DNN-specific slice exists, and the slice is part of the slice list at the PDN level configured in the following context `configure mobile-gateway pdn slice-list configure mobile-gateway pdn apn slices slice-list`
smfInfo /sNssaiSmfInfoList /dnnSmfInfoList /dnn smfInfoList/smfInfo /sNssaiSmfInfoList /dnnSmfInfoList /dnn	The DNN configured using the following command `configure mobile-gateway pdn apn` APN name signaled as-is, with APN and DNN synonymous in this context
smfInfo /taiList smfInfo /taiRangeList smfInfoList/smfInfo /taiList smfInfoList/smfInfo /taiRangeList	Based on the configuration of the tai-list command

When an NRF cannot be reached or returns an error, it is temporarily blocked for registration as described in Failure handling. The registration proceeds with a different NRF if a backup NF instance or NF peer IP is configured.

HTTP/2, OpenAPI, and Python

SBI communication uniformly uses an HTTP/2 stack as shown in HTTP/2 stack . Messages are sent over this HTTP/2 stack OpenAPI v3. Most of these messages use JSON encoding, but a few exceptions exist. For example, N1 NAS and N2 AP messages are signaled directly as binary format using the application/vnd.3gpp.5gnas and application/vnd.3gpp.ngap content types respectively.

Use the commands in the following context to change the common HTTP/2 and SBI behavior.

configure mobile-gateway profile http2

Note: The following profile can be applied in multiple specific service instances. The commands in this topic are in the context of this HTTP/2 profile, unless stated otherwise.

Use the following command to configure a Python policy to apply Python scripts to any JSON-encoded messages. See Python support for more information.

configure mobile-gateway profile http2 python-policy

The MAG-c maintains multiple HTTP/2 connections to a peer, but does not use these equivalently. This is to ensure that if one connection fails, for example, because of stream ID exhaustion, a backup connection is available. When not enough connections are available, the MAG-c tries to periodically set up a new connection as determined by the following configuration, until enough connections are available.

configure mobile-gateway profile http2 connection-timer

While a connection is established, the MAG-c periodically sends an HTTP/2 PING message as determined by the configuration of the ping-period command.

HTTP/2 messages are sent out with the configured IP dscp command value in the IP header, which defaults to 56.

When acting as an SBI client, the MAG-c creates a new stream for each SBI message sent, subject to the maximum number of outstanding streams. When HTTP/2 messages are unacknowledged, the MAG-c retransmits these messages periodically based on the following command.

configure mobile-gateway profile http2 fail-retry-interval

The default interval is applied (default 5s) until a maximum number of attempts (default 0) has been reached based on the configuration of the following command.

configure mobile-gateway profile http2 fail-num-retries

Additionally, an outstanding message is also subject to the configuration of the following command (default 20s).

configure mobile-gateway profile http2 request-timeout

After the request timeout, the message is canceled. The reason for the request timeout, in addition to the fail-retry-interval and the fail-num-retries command configurations, is that the latter only takes effect from the moment the message is sent on a stream. The configured request-timeout value is started from the moment the client service wants to send the message, including any time the message is queued if the maximum number of outstanding streams is reached.

Note: The client services can override a request timeout. For example, the transaction-timer configuration in the following context acts as an override to this configuration.

configure mobile-gateway profile namf-profile transaction-timer

Failure handling

The MAG-c supports flexible and consistent failure handling over multiple SBI applications such as UDM, AMF, PCF, and CHF. Use the following commands to configure failure handling for these applications:

For timeout of SBI operations, use the fh-session-no-response command in the applicable context.
To modify timeout actions for SBI operations, use the retry-count and transaction-timer commands in the applicable context.
For specific HTTP and application error codes, use the http-status-code command in the applicable context.

Use these commands to configure the following services in the contexts indicated:

Namf_Communication service

configure mobile-gateway profile amf-profile

get operation of the Nudm_SubscriberDataManagement service
```
configure mobile-gateway profile udm-sdm-profile get-sm-subscription-data
```
subscribe operation of the Nudm_SubscriberDataManagement service
```
configure mobile-gateway profile udm-sdm-profile create-subscription
```
registration operation of the Nudm_UEContextManagement service
```
configure mobile-gateway profile udm-uecm-profile register-smf
```
Npcf_SMPolicyControl service
```
configure mobile-gateway profile pcf-profile
```
Specify per-operation values in the sbi-srvc-operation context of this profile.

Applications support two or more of the following actions when there is a failure:

terminate
Terminate the session.
attempt-continue
Continue the triggering procedure and terminate the session if the failure cannot be handled. For example, a failure on Namf_Communication terminates the session when an update of F-TEID programming upon mobility fails. However, the session continues a failing QoS update by rejecting the triggering procedure.
ap-continue
Take fallback actions to continue the session, known as assume positive (AP) mode. In rare cases the session may still terminate, usually when the fallback action is not properly configured. The fallback option depends on the service or the operation:
- Npcf_SMPolicyControl
  The SMPolicy association is removed and all communication with the PCF stops for the remainder of the session lifetime. The session can keep working with the latest PCF rules supplied, or fall back to local rules only. See PCF failure handling for more information.
- Get operation of the Nudm_SubscriberDataManagement
  The session setup continues with local configuration. A default QoS (5QI/ARP/session-AMBR) must be provisioned separately from the UDM. See Configuring a 5G QoS profile for the UDM failure handling for more information.
- Subscribe operation of Nudm_SubscriberDataManagement
  The session continues without UDM subscription.
- Registration operation of the Nudm_UEContextManagement service
  The session continues without UECM registration.
- Nchf_ConvergedCharging
  Charging is paused and removed from the FWA UP. See CHF failure handling for more information.

The following alternative actions are also available. These behave the same as the main variants. However, after the initial failure, the operation is first retried for a maximum of two alternative NF peers, if any are available:

Note: For Npcf_SMPolicyControl, the retry options only apply to the create operation.

retry-and-terminate
retry-and-attempt-continue
retry-and-ap-continue

See NF peer discovery for more information about how to discover multiple NF Peers.

NRF failure handling

NRF services use a different mechanism for failure handling, because the NRF services are usually used system-wide instead of per session. Instead of per-operation failure handling, a failed NRF operation puts the NRF peer in a blocklist. Use the following command to configure the duration of the block for the applicable service:

Nnrf_NFManagement service
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-nfm blocklist-duration
```
For the Nnrf_NFManagement service the behavior is granularly configurable using the following commands:
- The heartbeat-nrf-blocklist command configures how often to retry and wait for a heartbeat NFUpdate operation before blocklisting.
- The nfm-nrf-blocklist command configures how often to retry and wait for any other operation before blocklisting. This includes non-heartbeat NFUpdate operations, for example when updated SMF parameters have to be sent to the NRF.
The following specific status codes immediately block a peer, without retrying the Nnrf_NFManagement operation:
- For the NFRegister operation, any HTTP status code in the range 400 to 499, and HTTP status code 501 (Not Implemented)
- For the NFUpdate operation, including the heartbeat, HTTP status code 400 (Bad Request) and 501 (Not Implemented).
For the NFUpdate operation, including heartbeat, if an HTTP status code 404 (Not Found) is received, the MAG-c locally removes the registration and trigger a new NFRegister operation toward the same NRF peer.
If the MAG-c is registered with an NRF peer that is blocklisted, the MAG-c triggers a new NFRegister operation to the next peer, taking into account any configured NF Instance or IP priority.
Nnrf_NFDiscovery service
```
configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc blocklist-duration
```
For the Nnrf_NFDiscovery service, the peer is blocklisted immediately if a single operation is rejected or times out and the discovery procedures use other configured NRF peers.

When an HTTP 429 (Too Many Requests) status code is received, the blocklist duration is set to the value of the retry-after command header.