By adopting cloud-native technology, the 5GC will be reorganized into individual services called Network Functions (NFs) that are coming together to dynamically discover each other, utilize the services offered by each other and interact which each other in order to fulfill the required 5G service. For the communication between NFs, 3GPP has defined four modes encompassing direct and indirect scenarios between a Consumer NF and a Producer NF:
- A and B modes : for Direct communication without any proxy in the middle
- C and D modes : for Indirect communication with the use of SCP (Service Communication proxy)
In this paper, we will go through the four modes and discuss which configuration is recommended in a production environment.
Direct modes
In their first release of 5G specifications (Release 15), 3GPP has adopted the direct mode for the interaction between NFs Consumers and Producers. This model of communication does not necessitate any proxy between NFs (no SCP is used).
In the direct mode, there are two options: option A without NRF (Network Repository Function) and option B with NRF. The NRF is the NF that is responsible for the service discovery (a new concept that is related to the adoption of micro-service architecture in 5G); it is used by NFs for the discovery of other NFs and their services. Resulting in off-loading NFs from handling complex connection configuration and management.
Model A: As you can see in the figure 1 below, neither NRF nor SCP are used. Consumers are statically configured with producers’ “NF profiles” and directly communicate with a producer of their choice. The selection process of service producers is performed by consumers. This kind of deployment can be used in a test environment for example, but not in production.
Model B: Before sending the request to the producer, the NF consumer interacts directly with the NRF for service discovery (producers’ discovery). Based on the discovery result, the consumer does the selection and sends the request to the selected producer. In this option, the NF consumer need to support discovery result caching and selection process.
Model B has typically been used by operators for early 5GC deployments based on Release 15 and also for Release 16 small networks.
Indirect modes
Indirect communication between NFs was introduced in 3GPP Release 16 to offload discovery and selection tasks from consumers so that they can become lighter and focus on the business logic. In contrast to direct modes, the new models of communication are indirect via SCP that mediates messages between service consumers and producers. The use of an SCP is similar to the use of a STP/DRA in 2G-3G/4G mobile core networks.
Model C: Indirect communication without delegated discovery
Allows NFs to communicate directly with NRF for profile registration and discovery, while adding the SCP on communication path for some service selections and routing processes.
Model D: Indirect communication with delegated discovery
Unlike C model, consumers do not do any discovery or selection. Discovery is delegated to the SCP, which performs the discovery via NRF and select the suitable producer instance based on the parameters sent the consumer.
Summary: Table 1 summarizes the communication models and how they relate to the usage of an SCP.
Models C and D comparison
In a previous post, we discussed the advantages of indirect mode compared to the direct one and detailed the critical role that an SCP plays in optimizing discovery, selection and routing of the traffic. In what follows, we will be trying to further explain what’s the difference between the two indirect modes and what’s the best scenario an operator should consider when planning to introduce an SCP solution.
Both model C and model D add the SCP on communication path. The SCP aggregates signaling links, and provides centralized signaling controlling. In model C, NF consumers continue to own the responsibility of NF producer discovery and selection but delegate the routing logic to SCP. In model D, however the NF producer discovery and selection are delegated to the SCP. Therefore, the difference between model C and D is mainly the responsibility of discovery and selection of producers.
Call flow
In model C and as you can see from the call flow below (PCF selection by SMF), the whole process of NF discovery is performed by the NF consumer (SMF in our case). For the selection process however, the NF consumer has the choice to handle it by itself (figure 5: Selection process case1) or delegate a part of it to the SCP (figure 5: Selection process case2).
Description: In model C, a new header added in R16 called 3gpp-Sbi-target-apiRoot, which is used by SCP to route the HTTP request to the producers.
- SMF do the service discovery
- SMF fill Authority field with SCP destination, and fill the 3GPP-SBI-TARGET-APIROOT with real destination.
Case 1: SMF do the instance selection (PCF1) and SCP do the indirect routing only.
Case 2 : SMF picks PCF Set 2, allowing SCP to perform the instance selection
- SCP will replace the Authority value with 3GPP-SBI-TARGET-APIROOT real destination and route the request to the selected PCF
Model D shares all the characteristics of model C. Besides, the SCP in Model D takes over the whole process of NF discovery and selection. In addition, the discovery and selection processes are processed by using one request; unlike model C that necessitate two separate requests.
Description: In the model D flow, a new header is added in R16 called 3GPP-SBI-DISCOVERY. The use of the 3gpp-Sbi-Discovery enables indirect communication mode for discovery and selection.
- SMF includes Discovery Parameters and directly sends the service request to SCP with 3GPP-SBI-DISCOVERY:
+ Authority = SCP
+ 3GPP-SBI-DISCOVERY = PCF Discovery Parameters
- SCP do the delegated discovery and selects the best PCF to address the request based on location, load, capacity, priority and health of the PCF.
Load-balancing and re-selection
Delegating the discovery and selection process to the SCP is in accordance with service based architecture (SBA) and cloud native requirements for decoupling the end-user service from the underlying network. By doing so, NFs consumers will be relieved from handling those routine complex tasks and allow them to focus on the application.
In model D, the whole process of discovery and selection is delegated to the SCP, which takes responsibility for harmonization of load balancing and reselection mechanisms across the network.
In model C and depending on the NF consumer configuration; the SCP can handle routing based on location, load, capacity, priority and health of the NF. Therefore, Load-balancing and re-selection processes could be delegated to the SCP and this delegation will help to harmonize and uniform load balancing and reselection mechanisms.
Caching & storing producer’s information
Since discovery and selection are the responsibility of the consumer, NFs in model C need to support:
- Discovery result caching.
- Store the producer’s status and information.
- Routing selection policies.
Model D however, offloads those tasks from NFs consumers so that they can become lighter, focus on the business logic and handle more traffic.
SCP dimensioning
Unlike model C where discovery and selection are performed using two different requests, there is only one request that is used for discovery and selection from the consumer side in model D (see figure 6). Therefore, the adoption of model D will simplify the call flow and reduce the number of transactions that a NF consumer should handle, but on the other hand will increase the number of transaction that the SCP should manage.
When dimensioning an SCP solution, you should take into account the type of model you will deploy. A model D SCP needs more capacity and resources than a model C one. Communication service providers must consider this when planning to introduce an SCP solution.
Which mode to deploy?
As already explained in a previous post, the indirect modes of communication offer a range of benefits such as simplifying network topology, centralizing discovery/selection and routing, harmonizing load balancing, etc. The table below give a comparison between C and D models in terms of benefits:
Considering all of the benefits that the SCP offers, an operator which plans to deploy a 5G signaling controller solution will likely choose between model D and model C or a mix of both. To choose the appropriate communication model, an operator should consider the capability of the 5GC (its NFs) and operational needs.
If all NFs composing the 5GC support the model D and all APIs are supported in both sides SCP and NFs, so it’s recommended to start with model D. This the case for operators who are planning to start their 5GC deployment with Release 16, or operators who are planning to upgrade their existing R15 5GC while introducing the SCP. By implementing model D, they get the maximum benefit from the SCP.
If there are some existing NFs that support only the model C or some APIs are not supported in D mode, in this case a C mode or a mix of C and D could be implemented.
So depending on the 5GC capabilities (NFs and SCP), network topology and use cases that will be fulfilled, operators may choose hybrid deployments where model C and model D are both implemented and coexist in the same network. This is because the SCP is able to support them simultaneously, moreover all the SCP vendors provide configuration for model C or model D at per NF service level. And it’s up to the NF consumer to decide which mode to use for a service request. Coexistence of communication modes also facilitates an easy migration from one mode to the other by changing corresponding configurations in the NF consumer.
