Service Based Interfaces

This section provides basic information about Service Based Interfaces (SBI), where each interface (such as N11) consists of one or more services.

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:

  1. 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.
  2. 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 all, 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.

  1. Configure a client service instance.
    configure mobile-gateway pdn sba-client-services nrf-client nnrf-disc
  2. 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
  3. 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.
  4. 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.

  1. 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 
  2. Configure the following per NF instance:
    • Use the following command to 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:

      • Use the fqdn command to 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
      • Use the prioritized-address-list command to 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
    • Use the following command to 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 
    • Use the following command to 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
    • Use the following command to 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
  3. 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.
  1. 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.
  2. Apply the configured DNS profile.
    configure mobile-gateway pdn dns-client dns-profile
  3. 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:

  1. Use the following command to configure the client service.
    configure mobile-gateway pdn sba-client-services nrf-client nnrf-nfm
  2. 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
  3. 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
  4. For registration to succeed, use the following command to provision at least one slice.
    configure mobile-gateway pdn slices slice-list
  5. 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.

Table 2. Attributes sent during NRF registration
NFProfile attribute Source
nfInstanceID Based on the configured nf-instance-id command
nfType Always the 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

smfInfo

/priority

Based on the configured priority command
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

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
Alternatively, it is based on the following command, for all APNs that are in an enabled state. The signaled list is the superset of all configured slice lists.
configure mobile-gateway pdn apn slices slice-list

smfInfo

/sNssaiSmfInfoList

/sNssai

S-NSSAI identifying this slice in the list

smfInfo

/sNssaiSmfInfoList

/dnnSmfInfoList

List of DNNs applicable to this slice; applicability depending on the presence of a DNN-specific slice list configured in the following context
configure mobile-gateway pdn apn slice-list

If a DNN-specific slice list exists, the DNN is included if the slice is part of the list.

If no DNN-specific slice list exists, the DNN is included if 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

The DNN configured using the following command
configure mobile-gateway pdn apn
The APN and DNN are synonymous in this context, so the APN name is signaled as-is.

smfInfo

/taiList

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.

Figure 4. HTTP/2 stack

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 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.