Indirect communication for service-based architecture in 5G core

5G core networks are based on service-based architecture (SBA), which is centered around network function (NF) services. Each NF can register itself and its supported services to a Network Repository Function (NRF), which is used by other NFs for the discovery of NF instances and their services.

Any NF can use the services another NF provides, and it is also possible to connect to other NFs without introducing specific new protocols or interfaces. This enables a more flexible development of services as well as a more flexible way to connect to a new NF type; thus, 3GPP core networks have gone from 4G telecom-style protocol interfaces to 5G web-based APIs.

3GPP Release 16 introduced indirect communication with new modes of communication to SBAs. In contrast to the modes of communication specified in Release 15, where service consumer and producer interact directly, the new modes of communication are indirect via a Service Communication Proxy (SCP) that mediates messages between service consumer and producer.

In this paper, we outline the benefits of indirect communication and explain why Communication Service Providers (CSP) should opt for it in the near future. We discuss the pros and cons of the different modes of indirect communication and provide guidance for the introduction of indirect communication to 5G core networks.

In contrast to the modes of communication specified in Release 15, where service consumer and producer interact directly, the new modes of communication from Release 16 are indirect via an SCP. The use of an SCP in 5G core networks is comparable to the use of a diameter routing agent in 4G mobile core networks and shares some similar benefits.

Let us have a closer look at the network operational challenges that indirect communication addresses:

1. Structuring of networks and enforcement of signaling policies

When connecting different domains or sites (for example, when connecting an enterprise site to a core network or connecting regions of a sub-structured core network to each other), a communication service provider might want to enforce policies on the domain or site border. Such policies may include the checking and setting of message priorities, protection against inbound signaling peaks by enforcing rate limits, or the filtering of unallowed and malicious service requests using a Layer 7 application firewall. An SCP placed at the domain border can enforce such signaling policies. Another reason to place an SCP between domains is to hide the internal structures of a domain.

2. Monitoring of network functions

Detecting and tracking interoperability issues during network operations is a common problem that network management teams face. Network probes have been traditionally used in monitoring solutions, but with increased security awareness and greater demand to use Transport Layer Security (TLS) on all service-based interfaces, the industry is moving towards application-level tracing solutions. The SCP operates above the TLS layer and, when brought into a signaling path, can provide application-level traces contributing to the communication service provider tracing solution in addition to, for example, probes provided in network functions.

3. Solving inter-vendor operability issues

Certain classes of inter-vendor operability issues can be addressed by manipulating HTTP headers or by mapping HTTP statuses and reason codes. When an SCP is in the signaling path, it can address such an issue without requiring software updates from the involved network functions.

4. Harmonization of load balancing and failover algorithms

Load balancing and failover behaviors are not standardized in 3GPP, leading to different behaviors among NF consumer and NF producer implementations. When an SCP takes the responsibility for load balancing and failover between NF producer instances, network configurations and behaviors can be harmonized.

3GPP Release 16 defines two indirect communication modes: indirect communication without delegated discovery (also known as “mode C”) and indirect communication with delegated discovery (also known as “mode D”). No industry consensus on which of the different communication modes to use exists today, causing confusion on how to proceed with the introduction of indirect communication.

A natural question to ask when selecting a communication mode is whether it addresses the operational challenges’ indirect communication targets. Before we can answer this question, we must take a closer look at the technical details of NF producer selection and how to delegate selection capabilities to an SCP.

NF producer selection

In the 3GPP service-based architecture, NF consumers create and operate on resources provided by NF producer services. Those resources may have been created by the NF consumer or by the operations and maintenance system. When an NF consumer creates a resource, an initial service request triggers the resource creation in the NF producer.
Examples of resources are a charging reference in the Charging Function (CHF) or a session context in the Session Management Function (SMF). Subsequent requests refer to the created resources and operate on them.

An NF consumer needs to select an NF producer instance in the network before sending a service request. The corresponding selection process can be divided into three phases.

In the first phase of selecting an NF producer for an initial request, the NF consumer must determine a suitable set of NF producers fulfilling the required functions (for example, an NF instance serving a specific data network that a subscriber wants to connect to) and serving the tracking areas the user equipment (UE) currently resides in or other subscription data demanding specific producer capabilities. A service request sent to an NF producer outside of this set of candidates would result in a failure to deliver the desired function to the service consumer. In this paper, we refer to this selection type as “functional selection.”

In the second phase the NF consumer selects one NF producer instance within the set of candidates determined by functional-selection. Even though any producer instance in this set is able to provide the desired function, certain producer instances will be preferred based on non-functional criteria such as the location, capacity, load, priority and health of the different NF producer instances in the candidate set. In this paper we refer to this selection type as “non-functional selection”.

For a subsequent service request on a previously created resource that may be unhealthy or overloaded, a reselection towards a different producer instance should be performed. This is the third selection phase. It is a nonfunctional selection (like the second phase).

With the introduction of indirect communication in 3GPP Release 16, an NF consumer can delegate any of the selection phases to the SCP. The decision on which selection phases are delegated to the SCP can vary across different services and is based on NF consumer policy.

Delegation of selection to SCP

In the simplest case, there is no delegation of selection to the SCP, and the NF consumer performs all selection phases and informs the SCP of the selected NF instance by signaling the selected target using a custom header in HTTP.

Figure 1. Selection is not delegated to SCP

The second selection phase can be delegated to the SCP by signaling the set of candidates using other 3GPP-defined custom headers in the initial service requests. The functional selection remains in the NF consumer, and SCP takes over the responsibility of the nonfunctional selection of an NF instance. SCP uses several parameters in the selection process including but not limited to preferred locality of the NF producer, NF priority, message priority, observed NF producer load/overload, health status, and availability of NF producers.

With the delegation of nonfunctional selection to the SCP, the subsequent reselections are handled by the SCP (in other words, selection phase 3).

Figure 2. Delegation of nonfunctional selection to SCP

Finally, an NF consumer might choose to delegate, in addition to the nonfunctional selection, the functional selection to the SCP. To enable the SCP to perform the functional selection, additional information needs to be transferred to the SCP. For this purpose, 3GPP Release 16 allows NF consumers to send network function (NF) discovery parameters to the SCP in 3GPP HTTP custom headers within service requests.

Figure 3. Delegation of functional and nonfunctional selection to SCP

As described, there are three different possibilities for delegation of selection to the SCP. No delegation to the SCP or a delegation of nonfunctional selection to the SCP is called “indirect communication without delegated discovery” (or “mode C”) in 3GPP, while delegation of functional selection and nonfunctional selection to the SCP is called “indirect communication with delegated discovery” (or “mode D”).

In this section, we discuss how the different delegation modes relate to targeted benefits. An overview of this relationship is depicted in the table below. For more detail, please see the following sections.

Now that we have established this relationship, we will look into the benefits of each delegation mode in more detail and explore as well their coexistence.

No delegation of selection to SCP

When there is no delegation of selection, the SCP is still in the signaling path and is able to provide structuring of signaling networks, enforcement of signaling policies, and monitoring of network functions as well as being able to solve inter-vendor operability issues.

Many challenges can be addressed in this communication mode despite not having an NF consumer delegate any selection capabilities to the SCP.

Delegation of nonfunctional selection to SCP

When nonfunctional (re)selection is delegated to the SCP, the same benefits apply, but, now in addition, the SCP can also help to harmonize load balancing and failover algorithms in the network. Load balancing and failover behaviors are not standardized, and, therefore, capabilities and implementation choices vary across different vendor implementations.
Load balancing algorithms take a large number of parameters into account, such as NF priority, NF preferred locality, NF capacity, message priority, load/overload statuses as observed from NRF, HTTP status codes or load parameters sent by producers, TCP connection statuses, rate limits, and circuit breaker services. Performing nonfunctional selection is, therefore, a highly complex task.

Though many parameters influence the load balancing and failover algorithm, it is worth noting that the type of information involved is the same for all producer types. When the nonfunctional selection is delegated to the SCP, it allows harmonization not only of the load balancing and failover behavior but also its configuration across the different NF consumer and producer combinations.

Another benefit of delegating nonfunctional selection to the SCP is that it creates the possibility of performing the selection of an NF producer instance in an NF set close to the producers in case they (together with consumers) are spread across regions. Indirect communication allows for SCPs to be distributed across regions, and so an SCP close to the NF producers can take responsibility for load balancing and reselection, which can help to keep errors inside the producer region.

Full delegation of selection to SCP

Functional candidate selection is delegated to the SCP with the help of 3GPP-defined discovery parameters. In contrast to nonfunctional selection, the selection criteria for functional selection varies a lot for the different consumer and producer type pairs and, therefore, requires producer type-specific configuration in the SCP. The same level of configuration harmonization as for nonfunctional selection cannot be done.

For complicated producer selection cases where the needed information for functional selection is not covered by discovery parameters standardized by 3GPP, delegation of functional selection to the SCP will not be an option unless NF consumer and SCP fall back to proprietary mechanisms, which makes functional delegation less general than nonfunctional selection; for example, Access and Mobility Management Function (AMF) selection of SMF may include several parameters, such as Data Network Name (DNN), Single Network Slice Selection Assistance Information (S-NSSAI), PDN gateway (PGW) indicator, the UE’s current location, and more. Especially for mobility cases when (for example) using Enhancing Topology of SMF and UPF in 5G Networks (ETSUN) for regionalization, the AMF needs to keep track of the SMF’s coverage area when a new Intermediate Session Management Function (I-SMF) — and, consequently, a new Intermediate User Plane Function (I-UPF) — need to be inserted for coverage reasons, or simply when it is more appropriate to insert another I-SMF and, consequently, another I-UPF for edge computing. To do this, the AMF needs to continuously compare the UE’s location with the SMF’s coverage area given in the SMF NF profile. If all levels of selection of the SMF are delegated to the SCP, there is no proper way for the AMF to perform the monitoring of UE location versus the SMF coverage area, and the SCP cannot take over this functionality from the AMF.

Despite the given drawbacks, delegation of functional selection works for simple selection cases — for example, AMF selection of Authentication Server Function (AUSF) and Unified Data Management (UDM), which is based on a few parameters, such as public land mobile network identity (PLMN ID), routing indicator, and subscription permanent identifier (SUPI).

Coexistence of communication modes

The different communication modes can coexist in a network because the SCP is able to support them simultaneously. Which communication mode is chosen for a service invocation is determined by the NF consumer policies and then signaled towards the SCP using the 3GPP-defined parameters; for example, an NF consumer could include only a target NF set as an HTTP custom header in an initial service request towards the SCP, which indicates that the SCP is responsible for nonfunctional selection of producer instances.

Based on NF consumer policies and with SCP support, one NF consumer can use (for example) no delegation towards one NF producer type and nonfunctional delegation towards another at the same time. Coexistence of communication modes also facilitates an easy migration from one delegation mode to the other by changing corresponding policies in the NF consumer.

SCP usage considerations

While there are a number of operational benefits in introducing indirect communication between NFs, communication service providers must also be aware that doing so comes at a cost. Depending on how SCPs are deployed (including geographical location) and how the signaling is routed from NF consumer to NF producer through the SCPs, the signaling may pass through several SCPs along the way.

Passing through an SCP alone may not be a significant problem from a key performance indicator (KPI) perspective, but given a long distance between NFs and the need to pass through several SCPs, some latency-sensitive KPIs (UE idle to active transitions, for example) may be affected. Communication service provider must be aware of the trade-offs in introducing indirect communication and must take these into account when planning signaling networks.

Indirect communication can help with day-to-day operational challenges in mobile networks by having the SCP in the signaling path. The NF consumer decides whether a service request should be routed via the SCP and which level of NF producer selection capability is delegated to the SCP.

To what extent NF producer selection should be delegated to the SCP depends on the operational needs and can vary per NF service. We have shown that indirect communication modes can coexist in networks, enabling service providers to choose the communication modes best suited for solving a given problem. The coexistence capability also helps with the migration towards indirect communication as well as with the migration between communication modes.

We have discussed how the delegation of functional selection cannot be generalized to a common NF consumer functional selection, since functional selection criteria vary significantly for the different consumer and producer type pairs. Functional selection can only be delegated to the SCP if the selection data is defined by 3GPP discovery parameters. This is not always possible, as the example of SMF selection by an AMF has shown. Despite the given shortcomings, delegation of functional selection is certainly an acceptable deployment for simple parameter-based selections (for example).

In contrast, nonfunctional delegation is based on parameters common to all NF consumer/ producer type pairs and, therefore, allows for the harmonization of nonfunctional selection configurations and behaviors in a network. Restrictions as for delegation of functional selection do not exist; in other words, one can apply nonfunctional selection to all NF consumer/producer type pairs.

We conclude that delegation of nonfunctional selection addresses all of the operational challenges outlined in the “Indirect communication challenges” section above and, therefore, qualifies as a proper default delegation model to opt for when introducing indirect communication for any NF consumer/producer pair.

1. 3GPP TS 23.501 v17.0.0 System architecture for the 5G System; Stage 2
2. 3GPP TS 29.500 v17.2.0 5G System; Technical Realization of Service Based Architecture; Stage 3