Deep-Dive into SCP Model-D Based Communication

Introduction

This document describes the deep dive of SCP Model-D Communication approach between Cisco AMF/SMF and third party NF.

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• Functionality of Access and Mobility Management Function (AMF)
• Functionality of Session Management Function (SMF)
• Functionality of Service Communication Proxy (SCP)

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

Operators around the world can choose between multiple communication models using SCP for the Network Function (NF) discovery and subsequent NF to NF communications. This topic touches upon concepts around various communication models and the call flow/configuration changes required at Subscriber Microservices Infrastructure (SMI), AMF/SMF in order to have SCP Model-D based communication.

Architecture and Solution Overview

In the Service based architecture (SBA), the SCP acts as an intermediary, facilitating indirect communication between NFs by handling routing, load balancing, and service discovery, ultimately streamlining the service-based architecture.

3GPP 23.501 Annex-E details the four communication models between NF in a 5GC deployment.

Figure A: (Different communication Models involving SCP)

Model-A - Direct communication without Network Repository Function (NRF) interaction: Consumers are configured with the 'NF profiles' of the producers and directly communicate with a producer of their choice. This is type of static selection and neither NRF nor SCP are used.

Model-B - Direct communication with NRF interaction: Consumers do discovery by querying the NRF. Based on the discovery result, the consumer does the selection. The consumer sends the request to the selected producer.

Model-C - Indirect communication without delegated discovery: Consumers discover by querying the NRF. Based on discovery result, the consumer does the selection of an NF set or a specific NF instance of NF set. The consumer sends the request to the SCP containing the address of the chosen service producer pointing to a NF service instance or a set of NF service instances. In the latter case, the SCP chooses an NF Service instance. If possible, the SCP interacts with NRF in order to get selection parameters such as location, capacity, and so on. The SCP routes the request to the chosen NF service producer instance.

Model-D - Indirect communication with delegated discovery: Consumers are not involved in discovery or selection. The consumer adds any necessary discovery and selection parameters required to find a suitable producer to the service request. The SCP uses the request address and the discovery and selection parameters in the request message in order to route the request to a suitable producer instance. The SCP can perform discovery with an NRF and obtain a discovery result.

Deep dive on Model-D based Communication: When Call Model-D is used, the NF consumer does not directly send a request to the NRF but delegate to the SCP this discovery. The NF client sends a message to the SCP and concatenate for each of these discovery factors the string '3gpp-sbi-discovery' with the name of the Discovery factor which will be used if NF discovery will be done via the NRF.

For a scenario, where SMF will be looking for Unified Data Management (UDM) with service-names nudm-sdm, the discovery factors will be passed to the SCP:

•  Authority Header: the authority carries either the Fully Qualified Domain Name (FQDN) or the IP address, with priority given to the IP address configuration.
• 3gpp-sbi-discovery-requester-nf-type: SMF
• 3gpp-sbi-discovery-target-nf-type: UDM
• 3gpp-Sbi-discovery-service-name: nudm-sdm

Figure B: ( SMF-UDM Communication via SCP model D)

Note: The 3gpp-sbi-discovery-service name format is in plain string format and not in array format as per 3gpp 29.510 and open API definitions (4.7.12.4 Style). In the 29.510 3gpp-sbi-discovery-service-name is mentioned as an array format.

Figure C: (Snapshot from 29.510 Spec)

However the style:form and explode:false converts the array into a plain string which is explained by taking an example from OpenAPI.

Figure D: (Snapshot from Open API: (4.7.12.4 Style Examples) )

You have CLI control in both AMF and SMF to send the parameter 3gpp-sbi-discovery-service as this is optional (can be done depending upon deployment environment).

In case of Model-B, if you take the example of AMF and Authentication Server Function (AUSF) communication, then once AUSF is discovered, the AMF sends the POST to AUSF with AUSF IP/FQDN and Port.

POST http://<ausf-fqdn>:<port>/nausf-auth/v1/ue-authentications.

Figure E: (AMF-AUSF Communication via Model B)

In Model-D, as the discovery is performed by the SCP, instead of POST http(s)://<ausf-fqdn>:<ausf-port>/nausf-auth/v1/ue-authentications the AMF sends the modified POST request which is:

POST http(s)://<scp-fqdn>:<scp-port>/nausf-auth/v1/ue-authentications

Or

POST http(s)://<scp-fqdn>:<scp-port>/nscp-route/nausf-auth/v1/ue-authentications(if apiroot=nscp-route)

With

3gpp-Sbi-Discovery-target-nf-type: AUSF

3gpp-Sbi-Discovery-Preferred-locality: LOC1

3gpp-Sbi-Discovery-service-name

Where you can see that AMF has replaced the api-root (<ausf-fqdn>:<ausf-port>) of the AUSF with the api-root of the SCP.

Figure F: ( AMF-AUSF Communication via SCP-Model D)

The 3gpp-sbi-discovery parameters allows the SCP to retrieve the best NF and then forward the POST request where it replaces the api-root of the SCP with the api-root received from the NRF after having received the response to its discovery request.

Configurations Required at AMF/SMF

In order to indicate for each NF (for example, UDM) which call-model must be used, the nf-selection-model configuration is used within the associated 'profile network-element'.

profile network-element udm prf-udm-scp

 [...]




nf-selection-model priority <>[local | nrf-query | nrf-query-peer-input | nrf-query-and-scp | scp]

exit

Once Model-D is chosen, the query-params configured for the associated network-element are still used and are passed to the SCP in the format '3gpp-Sbi-Discovery-<query-param>'.

[smf] smf(config)# profile network-element udm prf-udm-scp

[smf] smf(config-udm-udm1)# query-params

Possible completions:

 [  chf-supported-plmn  dnn  requester-snssais  tai  target-nf-instance-id  target-plmn ]

Eventually the profile network-element is mapped to the profile Data Network Name (dnn).

profile dnn ims

 network-element-profiles udm prf-udm-scp

 network-element-profiles scp prf-scp

exit

SCP(s) are defined as network-element.

nf-client-profile and a failure-handling profile is mapped with network-element.

profile network-element scp <>

 nf-client-profile        <>

 failure-handling-profile <>

exit

The nf-client-profile of type scp-profile details the characteristics of the SCP endpoint.

Here nscp-route can be added in api-root.

profile nf-client nf-type scp

 scp-profile <>

  locality LOC1

   priority 30

   service name type <>

    responsetimeout 4000

    endpoint-profile EP1

     capacity   30

     api-root   nscp-route

     priority   10

     uri-scheme http

     endpoint-name scp-customer.com

      priority 10

      capacity 50

      primary ip-address ipv4 

      primary ip-address port 

      fqdn name <>

      fqdn port <>

      exit
  

SMF FQDN is configured in endpoint southbound interface (SBI).

endpoint sbi

relicas 2

nodes 2

fqdn <>

Sample Snap of Packets

Figure G: ( AMF- SMF nsmf-pdusession communication via SCP Model D)

You need from the profile dnn to refer to the SCP network element just configured.

profile dnn <>

 network-element-profiles udm <>

 network-element-profiles scp <>

exit

If SCP failure-handling is configured with action as retry, SMF attempts alternate SCP based on SCP configuration and retry count.

If SCP failure-handling is configured with action as retry-and-fallback for a particular service name and message type then the fallback to Model-A happens.

This ailure Handling Profile for SCP (FHSCP) is used if the error is trigerred from the SCP (server header indicating SCP) and the NF-client configuration for the peer is present.

profile nf-client-failure nf-type scp

   profile failure-handling <>

   service name type npcf-smpolicycontrol

    responsetimeout 1800

    message type PcfSmpolicycontrolCreate

    status-code httpv2 0,307,429,500,503-504

     retry  1

     action retry-and-fallback

     exit

Example of the nf-client profile for Policy Control Function (PCF) for the scenario where action retry and falback is configured for the message type PcfSmpolicycontrolCreate:

profile nf-client nf-type pcf

 pcf-profile <>

  locality LOC1

   priority 1

   service name type npcf-smpolicycontrol

    endpoint-profile epprof

     capacity   10

     priority   1

     uri-scheme http

     endpoint-name ep1

      priority 1

      capacity 10

      primary ip-address ipv4 <>

      primary ip-address port <>

     exit

     endpoint-name ep2

      priority 1

      capacity 10

      primary ip-address ipv4 <>

      primary ip-address port <>

     exit

Core DNS PODs and Configuration Required at SMI Layer

CoreDNS pods, which are part of the kube-system namespace, are deployed as a 2-pod replicaset. These pods can be scheduled on any of the two master/control nodes and are not dependent on where the nameserver IP is configured in cluster manager.

However, it is recommended to configure the nameserver IP in all of the control/master nodes as you do not have a labelling control to spin the CoreDNS pods as per your wish. If the route to nameservers are not present on any of the master where CoreDNS is deployed then the SMF/AMF cluster sync gets failed.

Currently, CoreDNS forwards DNS requests to the nameserver specified in the nodes resolv.conf file.

'kubectl edit configmap coredns -n kube-system' you have:

 {      

forward ./etc/resolv.conf{

     max_concurrent 1000

  }

When checking /etc/resolv.conf on the master node where service is started, it must contain:

     name server <>

     name server <>

Sample nameserver configuration in master/control node:

nodes <>

initial-boot netplan vlans <>

dhcp4 false

dhcp6 false

addresses [<>]

nameserver addresses [<>]

id <>

link <>

exit