Contents

Introduction

Prerequisites

Requirements

Components Used

Background Information

Architecture and Solution Overview

Configurations Required at AMF/SMF

Sample Snap of Packets

Core DNS PODs and Configuration Required at SMI Layer

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