Roaming Support

Feature Summary and Revision History

Summary Data

Applicable Product(s) or Functional Area

SMF

Applicable Platform(s)

SMI

Feature Default Setting

Enabled – Always-on

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 1. Revision History

Revision Details

Release

SMF supports the following Roaming functionalities:

  • N3 and N9 Separation for Homer and Roamer calls

  • Support for Allowed PLMN list and Requester PLMN list through CLI configuration

  • Roaming status on N4 messages

  • SMF supports the failure handling for N16 hSMF or vSMF and SEPP.

2023.03.0

The following enhancements were introduced:

  • Home Routed (HR) Roaming Support

  • Security Edge Protection Proxy (SEPP) Support

  • Handover Support in HR Roaming

2021.02.3

First introduced.

2021.01.0

Feature Description

This chapter provides an overview of the roaming features that are supported on SMF. Mobile network operators form roaming partnerships to provide seamlessl services to subscribers in geographies beyond network reach. PLMN designates the operator network boundaries. hPLMN denotes the home network of subscribers. vPLMN denotes the visited network from where the services are rendered.

Roaming support for SMF can be classified as follows:

  • LBO (local breakout) roaming – vPLMN locally provides packet core services and access to data network.

  • HR (home routed) roaming – vPLMN provides packet core services and hPLMN provides access to data network.

Local Breakout Roaming Support

Feature Description


Important


The PGW-C term used in this chapter denote the EPS interworking functionality supported by SMF and must not be assumed as a standalone P-GW that is used in the LTE network.


VPLMN provides packet core services and access to data network. This feature enables the SMF to support the flavour of routing that is termed as the local breakout (LBO) roaming.

This feature provides the following functionalities:

  • Roaming for 5G sessions connected via NR

  • Roaming for 4G and Wi-Fi sessions connected via E-UTRAN

  • LI support

  • Deployment model without SEPP

For more details on the serving PLMN, see Multiple PLMN Support chapter.

Architecture

This section describes the architecture for the LBO roaming feature.

EPC LBO Scenario

The following diagram shows the LBO roaming architecture for the 4G sessions connected to the SMF and PGW-C in EPC.

Figure 1. Local Breakout Roaming Architecture for 4G Sessions

During LBO roaming for 4G sessions, the SGW and the SMF with PGW-C both reside in VPLMN. The SGW and SMF exchange messages through S5-C interface. All northbound SBI interfaces are common for 4G and 5G. The SMF interacts with vPCF, vCHF, and UDM.

ePDG LBO Scenario

The following diagram shows the LBO roaming architecture for the Wi-Fi sessions connected to the SMF and PGW-C in EPC.

Figure 2. Local Breakout Roaming Architecture for Wi-Fi Sessions

SMF resides in VPLMN and interacts with vPCF, vCHF, and UDM. SMF doesn’t support S6b toward the 3GPP AAA server, but uses the N10 interface.

5G NR LBO Scenario

The following diagram shows the LBO roaming architecture for the 5G sessions connected through NR.

Figure 3. LBO Roaming Architecture for 5G Sessions

As shown in the preceding diagram, the SMF resides in the VPLMN. Only AUSF and UDM are the NFs in the HPLMN. The PCF in the VPLMN communicates with PCF in the HPLMN over N24 interface. The PCFs communicate with each other to get the policies related to the subscriber session and pass them to SMF.

SMF Functionalities During LBO

The SMF supports the following functionalities related to LBO for in-roamers.

  • Detection of in-roamers based on local configuration and MCC and MNC in the SUPI received

  • N11

    • Determination of LBO for the in-roamers

    • If the SMF receives the session setup request for a visitor without the support for LBO, then the SMF sends an error to the AMF. Then, the AMF reattempts the session setup with the SMF that supports Home Routed (HR) roaming.

    • Support of PCF ID that is vPCF from the AMF

  • N2

    • The SMF provides Single Network Slice Selection Assistance Information (S-NSSAI) of VPLMN in the N2 SM Information.

  • N7

    • Selection of PCF in VPLMN

    • vPCF interacts with AF in HPLMN for PCC rule generation (for example, IMS). However, PCC rules are generated using roaming policies and the subscribed policies in HPLMN are inaccessible by vPCF. Also, vPCF doesn’t interact with CHF for spending limits. The PCC rules in LBO have limited capabilities.

  • N40

    • Selection of CHF in VPLMN. vSMF considers additional parameters of the HPLMN ID that CHF has to service the roamer status (in-roamer) of the UE.

  • N10

    • Selection of UDM in HPLMN

  • NRF

    • The SMF uses the chf-supported-plmn query parameter while discovering the vCHF servicing HPLMN.

    • During EPS procedures, if the SMF supports more than one S-NSSAI and the APN is valid for more than one S-NSSAI, then it performs the Nnssf_NSSelection_Get service operation. This operation is in effect before the SMF provides an S-NSSAI to the UE. This operation helps to retrieve the mapping of the subscribed S-NSSAIs to the serving PLMN S-NSSAI values.

  • Emergency services on SMF are supported only in LBO model. For LBO roaming, the SMF does not register with UDM for an emergency session.

    For emergency calls, the SMF ignores the UE PLMN ID and relays the serving PLMN ID across all the interfaces.

Network Slicing

The SMF supports the following functionalities related to network slicing:

  • The SMF can be configured with a list of allowed NSSAI.

  • When the SMF acts as a vSMF during roaming, the S-NSSAI of the UE used in the VPLMN must be the value that is configured on the SMF.

  • In the case of LBO, the SMF performs mapping of S-NSSAI received from UDM to the NSSAI of HPLMN received during PDU connection setup. The received NSSAI must be configured on vSMF as the supported NSSAI.

Node Selection Considerations

The following criteria are applied for selecting the nodes in the LBO roaming:

  • When roaming is enabled, each SMF registers the inter-PLMN FQDN value with the NRF. This operation helps the AMF to select the hSMF in a different PLMN.

  • The SMF treats target-plmn-list and requester-plmn-list as the query parameters.

  • The NRF in the serving PLMN handles all the discovery requests from the NFs.

PDU Establishment During LBO

The following conditions are considered for PDU session establishment in LBO roaming case:

  • If the SMF receives the session setup request for a visitor without support for LBO, then the SMF sends SM Context Create error to the AMF with the cause HOME_ROUTED_ROAMING_REQUIRED. Then, the AMF reattempts the session setup with the SMF that supports Home Routed (HR) roaming. An example scenario is when the NAS PDU Session Establishment Request has requested SSC mode as 3 and the allowed SSC mode in vSMF does not support the SSC mode 3.

  • The SMF receives both HPLMN S-NSSAI and S-NSSAI. The SMF uses S-NSSAI to validate NSSAI against the vSMF supported NSSAI.

  • On N40 interface:

    • vSMF sends the roamerInOut attribute to CHF through the CDR message. The roamerInOut attribute includes PDUSessionChargingInformation and userInformation. This attribute value is either IN_BOUND for in-roamers or OUT_BOUND for out-roamers.

    • vSMF sends the PDUSessionInformation and chargingCharacteristicsSelectionMode IE with appropriate value (HOME_DEFAULT, ROAMING_DEFAULT, and VISITING_DEFAULT) for non-roaming and roaming cases.

    • The hPlmnId and servingCNPlmnId fields in the PDUSessionInformation IE carry the value as per the roaming status of the UE.

  • During N1N2 Message Transfer, the S-NSSAI provided in N2 content should be the same as the VPLMN S-NSSAI.

  • For LBO roaming scenario, the PDU Session Establishment Accept message includes the S-NSSAI from the allowed NSSAI for the VPLMN. It also includes the corresponding S-NSSAI of the HPLMN from the mapping of allowed NSSAI that the SMF received from AMF.

  • The SMF uses HPLMN for UDM discovery during LBO roaming.

PDN Establishment During LBO

The S-GW sends Serving Network IE to the PGW-C with the PLMN ID where the S-GW belongs. The SMF uses that PLMN as VPLMN for validation, node selection, and passing on the VPLMN to other north bound interfaces.

The N40 interface related requirements and the emergency session-related requirements applicable for 5G session creation, also apply for the 4G and Wi-Fi sessions.

PLMN Usage

The following table shows an example of how the PLMN values configured in SMF service profile are relayed across all the interfaces.

Interface

Attribute

Homer

In-roamer (LBO)

Out-roamer (HR)

In-roamer (HR)

UE PLMN

310-240

262-06

310-310

302-610

NRF

plmn-list in nrf Discover to discover UDM (queryParam = target-plmn)

UE PLMN

UE PLMN

UE PLMN

Not applicable

NRF

plmn-list in nrf Discover to discover PCF/CHF(queryParam = target-plmn)

UE PLMN

Serving PLMN

UE PLMN

Serving PLMN

N10

PLMN in smfRegistration IE in N10 registration

Serving PLMN

Serving PLMN

Primary home PLMN

Not applicable

N10

PLMN in GET subscription URI

Serving PLMN

Serving PLMN

Primary home PLMN

Not applicable

N10

PLMN in sdmSubscription IE in N10 subscribe ToNotification

Serving PLMN

Serving PLMN

Primary home PLMN

Not applicable

N40

PLMN in NfConsumer identification IE in N40 charging data request

Primary home PLMN

Primary home PLMN

Primary home PLMN

Primary home PLMN

N40

hPlmnId in PDUSession Information IE in pduSession Charging Information in chargingData Request

UE PLMN

UE PLMN

UE PLMN

UE PLMN

N40

Serving PLMN in PDU Session Information IE in pduSession ChargingInformation in chargingData Request

Serving PLMN

Serving PLMN

Primary home PLMN

Serving PLMN

N7

PLMN in PCF notify for AC_TY_CH/ SAREA_CH/ RAT_TY_CH trigger

Serving PLMN

Serving PLMN

Primary home PLMN

Not applicable

N7

PLMN in create request to PCF

Serving PLMN

Serving PLMN

Primary home PLMN

Not applicable

RADIUS

PLMN in 3GPP UE location IE RADIUS authentication

Serving PLMN

Serving plmn

Not applicable

RADIUS

PLMN in 3GPP GGSN MCC MNC in RADIUS authentication

Primary home PLMN

Primary home PLMN

Not applicable

N4

PLMN in X-header of N4 requests

Serving PLMN

Serving PLMN

Primary home PLMN

Not applicable

Roaming Status Determination

The SMF extracts the UE PLMN from SUPI. The SMF compares the UE PLMN and the serving PLMN with the configured PLMN list. The SMF determines the roaming status of subscribers based on the HPLMN values.

If the UE PLMN and the serving PLMN both belong to the PLMN list configured in SMF, then it is a home subscriber. If the UE PLMN does not belong to the configured PLMN list and the serving PLMN belongs to the configured PLMN list, then it is a visitor. If the UE PLMN belongs to the configured PLMN list and the serving PLMN does not belong to the configured PLMN list, then it is a roamer.

Handover Scenarios

Once the roaming status is determined, there will be no change to the status even if the configuration of PLMN values changes after the handover (HO).

Local Policies

In HO scenarios, vSMF supports local policy to enable vPLMN operators to override the signaled parameter from hPLMN domain as per the roaming agreements. The SMF uses the local policies to—

  • allow always-on session requests.

  • perform paging policy differentiation

  • allow PDU session setup in HR or LBO mode

  • support subscriber QoS as per the roaming agreement

  • allow ARP priority levels 1-8 for HO roaming sessions.

Other Procedures

Paging Policy Differentiation (PPD)

The SMF needs a configuration per PLMN to allow different PPD profiles for different roaming partners. The vSMF picks the appropriate configuration for the HPLMN and applies the same for the roaming session.

PCF and UDM Selection

During roaming, the AMF selects both vPCF and hPCF and sends the vPCF ID and hPCF ID to the SMF and vPCF respectively during policy association. The SMF selects the PCF using the received vPCF ID. During AMF relocation, target AMF selects a new vPCF and hPCF. The SMF receives a redirection indication with PCF ID from the existing PCF for the PDU session. The SMF terminates the current SM Policy Control association and reselects a PCF based on the received PCF ID. The SMF then establishes an SM Policy Control association with the reselected PCF.

For selection of PCF and UDM based on local configuration, the locally configured addresses map to the VPLMN and HPLMN respectively since the PCF is in VPLMN and the UDM is in HPLMN for roaming with LBO case.

For NRF-based discovery of PCF and UDM, the query criteria includes VPLMN for PCF discovery and HPLMN for UDM discovery. The AMF sends the UDM group ID to enable the SMF to select UDM. The S-NSSAI used by SMF to select PCF should be the VPLMN S-NSSAI received from AMF.

Lawful Interception

During roaming scenario, the SMF uses S-NSSAI of the VPLMN to generate IRI events. The S-NSSAI information is sent to the mediation device through the IRI event message.

Home Routed Roaming Support

Feature Description

The VPLMN provides access network services and packet routing to the packet core, whereas the HPLMN provides data network access to the subscriber. This feature enables the SMF to support the flavour of routing that is termed as the Home Routed (HR) roaming.

This feature provides the following functionalities:

  • Support home routed roaming traffic for 5G sessions connected through NR.

  • Support QoS flow Based Charging (QBC) on the UPF.

Architecture

This section describes the architecture for the HR roaming support feature.

EPC HR Roaming Scenario

The following diagram shows the architecture for an EPC HR roaming scenario.

Figure 4. EPC HR Roaming Architecture

The 3GPP reference point for nodes in the VPLMN and HPLMN in an EPC HR roaming scenario, are as follows:

  • SMF+IWK resides in the HPLMN.

  • SMF-IWK interacts with the hPCF, hCHF and UDM.

  • SMF-IWK supports S8-C with the S-GW (in VPLMN).

  • vSMF interacts with the vCHF.

5G NR HR Roaming Scenario

The following diagram shows the architecture for a 5G NR HR roaming scenario.

Figure 5. 5G NR HR Roaming Architecture

The 3GPP reference point for nodes in the VPLMN and HPLMN in a 5G NR HR roaming scenario, are as follows:

  • SMF resides in both the VPLMN and HPLMN.

  • vSMF and hSMF support the N16 interface.

  • hSMF interacts with UDM, h-PCF and h-CHF.

  • vSMF interacts with the vCHF.

  • When SEPP appears in the network, vSMF communicates to cSEPP for hSMF messaging.

  • When SCP appears in the home network, hSMF communicates to SCP for UDM, hPCF and hCHF messaging.

vSMF

The SMF supports the following functionalities related to HR roaming for visitors:

  • N1

    • The NAS SM information is of two parts, one is visible to vSMF (for example, PDU session type, Session AMBR, UE address). The other one that is not visible to vSMF (for example, SSC Mode, PCO, QoS rules, and so on), which it transparently relays to the hSMF.

    • The vSMF transfers the NAS signalling messages information, which is not visible to the vSMF, in a container toward the hSMF.

    • The vSMF transfers the NAS signalling messages information, which it does not comprehends, these are unknown IEs or IEs with an unknown value not set to "reserved" according to the release to which the vSMF complies, in a different container toward the hSMF.

    • The vSMF appends unknown NAS signalling messages information received in the N16 container at the end of the NAS signalling message it sends to the UE.

  • N40

    • Assignment and transfer of Charging ID of VPLMN to the hSMF.

    • Negotiation of roaming charging profile.

    • When NRF is used, the vCHF is selected based on the UE identified as an in-bound roamer and the PLMN id of the HPLMN.

  • N4

    • V-CN-Tunnel lifecycle management.

  • N16

    • Support for the N16 interface (between vSMF and hSMF).

    • Support for Always-on PDU Session Granted indication.

  • EPS interworking procedures for home routed roaming, are as follows:

    • Caching of EPS bearer IDs and mapped QoS parameters received in hSMF. AMF retrieves the PDN contexts from the vSMF during the 5G to 4G handover. Also, the vSMF supports the release PDN context and not the forward to hSMF context.

    • During the 4G to 5G handover.

    • Support for indirect data forwarding tunnels.

  • Does not interact with PCF or UDM.

hSMF

The SMF supports the following functionalities related to HR roaming for roamers:

  • N1

    • The entire NAS SM information must be interpreted by the hSMF.

    • The hSMF transfers NAS SM information which the vSMF does not need to interpret in one container toward the vSMF.

  • N10

    • Registers with UDM with the S-NSSAI value defined in the HPLMN.

  • N4

    • User-plane inactivity detection is not performed during roaming (does not provide inactivity timer to hUPF).

    • H-CN-tunnel lifecycle management.

  • N40

    • Negotiation of “roaming charging profile.

    • Generate a "home provided charging identifier"

    • When the NRF is used, the hCHF is selected based on a UE identified as an out-bound roamer and the PLMN ID of the VPLMN.

  • N7

    • N7 interaction for the hSMF is similar to the non-roaming case.

  • N16

    • Support for the N16 interface (between vSMF and hSMF).

  • If the UE uses IPv6, IPv4v6, it generates router advertisements Secondary authorization or authentication.

Network Slicing

The SMF supports the following functionalities related to network slicing:

  • The SMF can be configured with a list of allowed NSSAI.

  • When the SMF acts as a vSMF during roaming, the S-NSSAI sent by the UE used in the VPLMN must be the value that is configured on the SMF.

  • In HR, the vSMF sends the PDU Session Establishment Request message to the hSMF along with NSSAI valued used in HPLMN.

Node Selection Considerations

The following criteria are applied for selecting the nodes in the HR roaming:

  • When roaming is enabled, each SMF registers the interPlmnFqdn value with the NRF. This helps the AMF to select the hSMF in a different PLMN.

  • The SMF supports target-plmn-list and requester-plmn-list query parameters.

  • The NRF in the serving PLMN handles all the discovery requests from the NFs.

Lawful Intercept

The SMF provides the IRI-POI functions in the following network topology cases:

  • Non-roaming case.

  • Roaming case, in VPLMN.

  • Roaming case, in HPLMN.

The SMF generates the following IRI events during the roaming scenarios:

  • PDU session establishment

  • PDU session modification

  • PDU session release

  • Start of interception with an established PDU session

Session Management

With roaming considerations, the SMF sessions are categorized into the following flavors:

  • Non-roaming

  • LBO

  • vSMF-HO

  • hSMF-HO

How it Works

This section provides details about the session create, release, modify procedures, and the different call handover scenarios for both vSMF and hSMF.

vSMF Create Session Procedure

This section provides details about the create session procedure for vSMF.

Figure 6. vSMF Create Session Call Flow
Table 2. vSMF Create Session Call Flow Description

Step

Description

1

The AMF receives a request from a UE. Based on the local configuration, the AMF locates a vSMF and a list of possible hSMFs to handle the UE request. It creates a CreateSmContext request, and POSTs the message to the vSMF. In the vSMF, based on the presence of an hSMF URI that is not its own, and the SUPI policy configuration of , the vSMF creates a PDU Context for valid UE requests.

2

The vSMF locates and creates a charging association with the appropriate CHF.

3

The vSMF responds to the AMF request with a reference to the created PDU Session.

4

The vSMF sends a PFCP Session Creation request to the vUPF. The vUPF responds with the CN tunnel Information of the created tunnel.

5

The vSMF creates a PDU Session Create Request to send to the hSMF. The CN tunnel information of the vUPF is an IE that is sent to the hSMF. Most of the request parameters from the AMF are copied on to the request to the hSMF. The following parameters from the N1 Message are removed from the request before it's sent to the hSMF:

  • Always-On Indication - If the UE requested an Always-On PDU session, and by policy the vSMF is ready to provide this service, this indication is set in the PDU Session Create request.

  • Any IE that is not identified by the vSMF is stripped off from the message and sent in a different payload to the hSMF.

The UE request from the vSMF to the hSMF is sent asynchronously. This method enables the hSMF to start the EBI assignment procedures through the vSMF when it's processing the create request from the VSMF.

6

If a secondary authentication is required, the hSMF uses the callback URI for the vSMF session and the modify method to send an authentication request payload for the UE.

7

The vSMF sends this message to the AMF, and the AMF responds to the vSMF.

8

The UE responds to the authentication request, which is conveyed by the AMF to the vSMF.

9

The vSMF sends the update to the hSMF.

10

The vSMF responds to the AMF for the Modify Request.

11

If this session can be moved to EPC, the hSMF starts the EBI allocation procedure by invoking the modify method on the vSMF callback URI.

12

The vSMF invokes the assign-ebi method on the AMF, and the AMF sends back the assigned EPS bearer ID to the vSMF.

13

The vSMF responds to the hSMF.

14

If the request is acceptable to the hSMF, it responds with a 201 Created response which includes the subscription information required for the setup of the PDU session in the GNB. The response also contains an N1 payload.

15

The SMF updates the CHF with the parameters from the response from hSMF, including the charging profile setup by the hSMF.

16

The vSMF creates an N1N2MessageTransferRequest to the AMF.

  • The N2 payload is created by the using the parameters that are sent in the PDU Session Created Data, and the CN tunnel information from the vUPF.

  • The N1 payload is created by using the binary payload from the hSMF. The always-on indicator is set based on the value that is received in the PDU Session Created Data.

17

The AMF responds to the N1N2MessageTranfer Request.

18

The GNB responds with an N2 response to the ERAB RESOURCE SETUP REQUEST to the AMF, which the AMF sends in an SmContext Update message to the vSMF.

19

The vSMF requests the vUPF to update the tunnel information of the GNB, the tunnel and other information sent by the hSMF in step 6. The vUPF responds to the vSMF.

20

If required, the vSMF updates the CHF with any additional information.

21

The vSMF responds to the Update request from the AMF.

22

If there are any flows that have failed to setup, the vSMF notifies the hSMF accordingly.

23

The hSMF responds to the vSMF.

hSMF Create Session Procedure

This section provides details about the create session procedure for hSMF.

Figure 7. hSMF Create Session Call Flow
Table 3. hSMF Create Session Call Flow Description

Step

Description

1

The hSMF receives a request to create a PDU Session from the vSMF. The request has a JSON part and also a binary part, which has the list of IEs that the vSMF did not process, or could not process.

2

The hSMF retrieves the subscription data for the UE from the UDM.

3

If based on the subscription data, the session can be established, then the SMF subscribes to changes for the subscription data to the UDM.

4

The hSMF creates a policy association with the PCF. The PCF can either be one that has been selected by the AMF and signaled to the hSMF, or an NRF based or policy based selection on the hSMF.

5

A Charging Data association is created with the CHF.

6

Using the CN tunnel information provided by the vSMF in step 1, the hSMF creates CN tunnels on the hUPF. The hUPF responds with the CN tunnel information on the hUPF.

7

The hSMF registers with the UDM for any notifications for the UE in this DNN.

8

The hSMF responds to the request from the vSMF, with the CN tunnel information of the hUPF, and N1 information elements that need to be sent to the UE. If the UE has requested always-on session, and this is acceptable to the hSMF, then it's indicated to the vSMF in the response.

9 If IPV6 router advertisements are required to be transmitted, then the hSMF requests the UPF to perform that task.

vSMF Modify Session Procedure

This section provides details about the modify session procedure for vSMF.

Figure 8. vSMF Modify Session Call Flow
Table 4. vSMF Modify Session Call Flow Description

Step

Description

1

The AMF sends the request from the UE as an Sm Context Update message to the vSMF.

2

The vSMF uses the reference that the hSMF returned during creation of the message. It posts the relevant parts of the message to the hSMF. The hSMF responds to the message.

3

The hSMF sends an update request to the vSMF. This message contains the N1 and N2 messages that is sent to the gNB or UE as a part of the request message.

4

The vSMF combines the information from the hSMF and creates the N1 and N2 payloads for the UE and gNB. It then adds these to the response for the original request from the AMF.

5

The AMF relays the N2 response to the gNB.

6

If there are changes to the UPF due to the modification requested by the UE and accepted by the network, for example, addition or deletion of flows, the vSMF updates the UPF with these changes.

7

The vSMF notifies the CHF of any charging triggers for the changes applied to the UPF.

8

The vSMF acknowledges the N2 message from the AMF with a 200 OK message.

9 The AMF transfers the N1 payload from the UE and the vSMF acknowledges it.
10

The vSMF responds to the request from the hSMF for session modification.

hSMF Modify Session Procedure

This section provides details about the modify session procedure for hSMF.

Figure 9. hSMF Modify Session Call Flow
Table 5. hSMF Modify Session Call Flow Description

Step

Description

1

The UE request reaches the hSMF from the vSMF.

2

If any hPCF trigger criteria is met, the hSMF sends an update request to the hPCF.

3

The hSMF responds to the UE request and handles any exceptions.

4

The vSMF notifies the CHF of any charging triggers for the changes applied to the UPF.

5

If there are changes to the UPF due to the modification requested by the UE and accepted by the network, for example, addition or deletion of flows, the vSMF updates the UPF with these changes.

6

The UE request to update the PDU session reaches the hSMF from the vSMF..

7

If there are changes to the UPF due to the modification requested by the UE and accepted by the network, for example, addition or deletion of flows, the vSMF updates the UPF with these changes.

8

The vSMF notifies and updates the CHF of any charging triggers for the changes applied to the UPF.

9

If there are changes to the UPF due to the modification requested by the UE and accepted by the network, for example, addition or deletion of flows, the vSMF updates the UPF with these changes.

vSMF Release Session Procedure

This section provides details about the release session procedure for vSMF.

Figure 10. vSMF Release Session Call Flow
Table 6. vSMF Release Session Call Flow Description

Step

Description

1

The UE will initiate a release of the PDU session.

2

The vSMF receives the release request response from the hSMF.

3

The hSMF responds with a request to release the request in the form of a modify request with release indication set to true.

4

The vSMF releases the PFCP session.

5

The vSMF releases the charging session.

6

The vSMF responds to the AMF with a 200 OK response message.

7

The AMF responds with an N2 modification request.

8

The vSMF responds to the request with a 200 OK response message.

9 The AMF sends an N1 modification request to the vSMF.
10

The vSMF responds with a 200 OK message.

11

The vSMF responds to the hSMF PDU session modification request.

12

The vSMF forwards this notification to the AMF.

13

The hSMF sends an Sm context status notification that the release is complete.

14 The vSMF acknowledges the receipt of the notification.

hSMF Release Session Procedure

This section provides details about the release session procedure for hSMF.

Figure 11. hSMF Release Session Call Flow
Table 7. hSMF Release Session Call Flow Description

Step

Description

1

The vSMF forwards the release request to the hSMF.

2

The hSMF responds with a 204 No Content message.

3

The hSMF releases the PFCP session.

4

The hSMF releases the charging session.

5

The hSMF sends a request to vSMF to release the request in the form of a modify request with release indication set to true.

6

The vSMF responds with a 204 No Content message.

7

The hSMF releases the associated Sm policies.

8

The hSMF forwards this notification to the vSMF.

vSMF Clear Subscriber Release Session Procedure

This section provides details about the release session procedure for vSMF by using an Ops Center.

Figure 12. vSMF Clear Subscriber Release Session Call Flow
Table 8. vSMF Clear Subscriber Release Session Call Flow Description

Step

Description

1

The Ops Center or the vUPF issues a clear subscriber release request.

2

The vSMF acknowledges the receipt of the message.

3

The vSMF receives a release request response from the hSMF.

4

The vSMF releases the PFCP session for the vUPF.

5

The vSMF releases the charging session and updates the CHF.

6

The AMF receives an N1/N2 transfer request.

7

The vSMF receives information regarding the N2 status and acknowledges with a 204 No Content message.

8

The vSMF receives an N1 release complete notification from the AMF and responds with a 204 No Content message.

9

The vSMF updates the AMF with an Sm Context Status Notification message, which indicates that the session is released.

EPS to 5G Handover Using N26 Interface

This section describes the call flow for the EPS to 5G handover procedure using the N26 interface.

Figure 13. Call Flow for the EPS to 5G Handover Using the N26 Interface
Table 9. Call Flow Description for the EPS to 5G Handover Using the N26 Interface
Step Description
1 Call handover initiation starts from UE and E-UTRAN toward each other, proceeds from E-UTRAN to the S-GW. Then for roaming calls, call handover initiation proceeds from S-GW to the UPF+P-GW-U.
2 The E-UTRAN sends the Handover Call Request to the MME.
3 The MME forwards the Relocation Request to the AMF.
4 The AMF invokes the NsmfPDUSessionCreateSMContext service operation on SMF. The PGW-C+SMF address identifies this service operation. The service operations can be UE EPS PDN Connection, AMF ID, or Direct Forwarding Flag. The AMF then indicates the handover preparation to avoid switching the UP path. The SMF searches for the corresponding PDU session that is based on EPS Bearer Contexts. The AMF includes Direct Forwarding Flag to inform the SMF of the applicability of indirect data forwarding.
5

If you have deployed the dynamic PCC, the SMF+PGW-C initiates the SMF-initiated SM Policy Modification toward the PCF.

6 The PGW-C+SMF sends the N4 Session Modification to PGW-U+UPF to establish the CN tunnel for a PDU Session. The PGW-U+UPF receives the uplink packets from NG-RAN. This step involves creating uplink PDRs and FARs for the 5G session along with the QFIs that are mapped from the existing 4G bearers.
7

The PGW-C+SMF sends a NsmfPDUSessionCreateSMContext Response to the AMF. This response includes PDU Session ID, S-NSSAI, and N2 SM Information.

The N2 SM Information includes PDU Session ID, S-NSSAI, QFIs, QoS Profiles, EPS Bearer Setup List, mapping between EBIs and QFIs, CN Tunnel information, and cause code details.

The SMF includes mapping between EBIs and QFIs as the N2 SM Information container. If the P-GW-C+SMF determines that session continuity from EPS to 5GS is not supported for the PDU session, then the P-GW-C+SMF does not provide the Session Manager information for the corresponding PDU session. However, the P-GW-C+SMF includes the cause code details for rejecting the PDU session transfer in the N2 SM information.

8 The V-SMF and V-UPF establish an N4 session with each other.
9 The AMF sends the Handover Request to NG-RAN.
10 The NG-RAN sends an acknowledgment for the received Handover Request to the AMF.
11

The AMF sends a NsmfPDUSessionUpdateSMContext Request, T-RAN SM N3 forwarding information list message to the SMF for updating the N3 tunnel information.

The NsmfPDUSessionUpdateSMContext request includes a PDU Session ID, S-NSSAI, and N2 SM Information. The tunnel information exists in the NGAP IE DL Forwarding UP TNL Information of the Handoff Request Acknowledgment that is received from NG-RAN.

12 The SMF+PGW-C performs the N4 session modification toward UPF+PGW-U to create the indirect tunnel to forward the DL data from eNodeB to NG-RAN. This step includes creating UL PDRs for the redirected DL data and associating FARs with them to forward the FARs to NG-RAN. The mapping of these PDRs and FARs is based on QFI and the corresponding bearer ID.
13 The PGW-C+SMF sends the NsmfPDUSessionUpdateSMContext Response to the AMF. This response includes PDU Session ID, EPS Bearer Setup List, and CN tunnel information for data forwarding. At this point, the indirect tunnels are established for DL data forwarding.
14 The AMF sends the Forward Relocation Response to the MME.
15 The MME sends the creation request for the indirect data forwarding tunnel to the S-GW. The S-GW sends the response for the indirect data forwarding tunnel to the MME.

5GS to EPS Handover for Single Registration Mode with N26 Interface

Figure 14. Call flow for the 5GS to EPS Handover for Single Registration Mode with N26 Interface

Important


The IP address preservation cannot be supported if PGW-C+SMF in the HPLMN doesn't provide the mapped QoS parameters.


Table 10. Call Flow Description for the 5GS to EPS Handover for Single Registration Mode with N26 Interface
Step Description
1 The NG-RAN sends a Handover Required (Target eNB ID, Source to Target Transparent Container, inter-system handover indication) message to the AMF.
2a AMF sends Nsmf_PDUSession_ContextRequest requests the V-SMF to provide SM Context that also includes the mapped EPS Bearer Contexts.

Note

 

The AMF knows the MME capability to support non-IP PDN type or not through local configuration.

Note

 

In a home routed roaming scenario, the UE's SM EPS Contexts is obtained from the V-SMF.

2b The PGW-C+SMF send N4 Session modification to PGW-U+UPF to establish the CN tunnel for each EPS bearer and provide EPS Bearer Contexts to AMF.
2c PGC+SMF sends Nsmf_PDUSession_ContextResponse requests the V-SMF to provide SM Context that also includes the mapped EPS Bearer Contexts.
3

The AMF sends a Forward Relocation Request with modifications and clarifications.

4 MME sends Create_Session_Request to S-GW.
5

S-GW sends Create_Session_Response to MME.

6 MME sends Handover Request(may contain information Handover Restriction List with information about PLMN IDs) to E-UTRAN.
7 E-UTRAN sends Handover Request Acknowledgment to MME.
8 Creates indirect data forwarding tunnel request or response between MME and S-GW.
9

MME sends Relocation Response to AMF.

10a AMF sends the Nsmf_PDUSession_UpdateSMContext Request (Serving GW Addresses and Serving GW DL TEIDs for data forwarding) to the PGW-C+SMF, for creating indirect data forwarding tunnel.
10b N4 Session modification request is sent between PGW-C+SMF and PGW-U+UPF.

10c

The PGW-C+SMF returns an Nsmf_PDUSession_UpdateSMContext Response (Cause, CN tunnel Info for Data Forwarding, QoS flows for Data Forwarding) to AMF for creating indirect data forwarding. Based on the correlation between QFIs and Serving GW Addresses and TEIDs for data forwarding, the PGW-U+UPF maps the QoS flows into the data forwarding tunnels in EPC.

11a

The AMF sends the Handover Command to the source NG-RAN.

11b

The NG-RAN sends the Handover Command to the source UE.

12a

The UE sends the Handover Complete Command to the source UE NG-RAN.

12b

The E-UTRAN sends the Handover Notify to the source UE MME.

12C

The MME sends Relocation Complete Notification to AMF.

12d

The AMF acknowledges MME with Relocation Complete Acknowledge message. A timer in AMF is started to supervise when the resources in the NG-RAN and PGW-C+SMF are released.

13

MME sends Modify Bearer Request to S-GW.

14

S-GW sends Modify Bearer to PGW-C+SMF.

15

The PGW-C+SMF initiates a N4 Session Modification procedure in the direction of UPF+PGW-U to update the User Plane path downlink User Plane, for the indicated PDU Session is switched to E-UTRAN. The PGW-C+SMF releases the resource of the CN tunnel for PDU Session in UPF+PGW-U.

16

PGW-C+SMF sends Modify Bearer Response to S-GW.

17

S-GW sends Modify Bearer Response to MME.

18

The UE initiates a Tracking Area Update procedure(TAU).

19

The PGW-C+SMF initiates dedicated bearer activation procedure for non-GBR QoS Flows.

20

Indirect Data Forwarding Tunnel Request and Response deleted in MME and S-GW

21a

Indirect Data Forwarding Tunnel Request and Response deleted in AMF and PGW-C+SMF.

21b

N4 Session modification request is sent between PGW-C+SMF and PGW-U+UPF.

EPS to 5G Handover Without Using N26 Interface

This section describes the call flow for the EPS to 5G handover procedure without using the N26 interface.

Figure 15. Call Flow for the EPS to 5G Handover Without Using the N26 Interface
Table 11. Call Flow Description for the EPS to 5G Handover Without Using the N26 Interface
Step Description
1 The UE initiates a registration request to the NG-RAN.
2 The NG-RAN selects an AMF.
3 The NG-RAN forwards the Registration Request with the N2 message parameters to the new AMF.
4 Refer to the General Registration procedure in TS 23.502.
5

The new AMF registers with the UDM using Nudm_UECM_Registration for the access to be registered.

6 Refer to the General Registration procedure in TS 23.502.
7

The new AMF sends the Registration Accept message to the UE.

The AMF includes an "Interworking without N26" indicator to the UE.

8

The UE responds with a Registration Complete message to the new AMF.

9 The UE initiates a PDU Session establishment procedure.
10 The PGW-C+SMF performs release of the resources in EPC for the PDN connections(s) transferred to 5GS by performing the PDN GW initiated bearer deactivation procedure.

5G to EPS Handover Without Using N26 Interface

This section describes the call flow for the 5G to EPS handover procedure without using the N26 interface.

Figure 16. Call Flow for the 5G to EPS Handover Without Using N26 Interface
Table 12. Call Flow Description for the 5G to EPS Handover Without Using N26 Interface
Step Description
1 - 2 The UE initiates the TAU procedure by sending, to the eNodeB, a TAU Request.
3 The eNodeB forwards the TAU Request message to the new MME.
4 If the MME determines that the old node is an AMF based on UE's GUTI mapped from 5G-GUTI and the MME is configured to support 5GS-EPS interworking without N26 procedure, the MME sends a TAU Reject to the UE.
5 The UE initiates an Attach Request to the eNodeB.
6

The eNodeB relays the Attach Request to the new MME.

7 Refer to the E-UTRAN Initial Attach procedure in TS 23.401.
8

If the MME has changed since the last detach, or if there is no valid subscription context for the UE in the MME, or if the UE provides an IMSI or the UE provides an old GUTI which doesn't refer to a valid context in the MME, or for some network sharing scenario if the PLMN-ID of the TAI supplied by the eNodeB is different from that of the GUTI in the UE's context, the MME sends an Update Location Request message to the HSS.

9 The HSS acknowledges the Update Location message by sending an Update Location Ack (IMSI, Subscription data) message to the new MME.
10 Refer to the E-UTRAN Initial Attach procedure in TS 23.401.
11 After the MME receives the Modify Bearer Response (EPS Bearer Identity) message, it sends a Notify Request including the APN and PDN GW identity to the HSS for mobility with non-3GPP accesses. The message includes information that identifies the PLMN in which the PDN GW is located.
12

In the case of non-emergency services, the HSS stores the APN and PDN GW identity pair. In the case of emergency services, the HSS stores the "PDN GW currently in use for emergency services". The HSS then sends a Notify Response to the MME.

13 If the UE has remaining PDU Sessions in 5GS, which it wants to transfer to EPS and maintain the same IP address/prefix, the UE performs the UE requested PDN Connectivity Procedure and sets the Request Type to "handover". UE provides an APN and the PDU Session ID corresponding to the PDU Session it wants to transfer to EPS.
14 The PGW-C+SMF initiates release of the PDU Session(s) in 5GS transferred to EPS.

Standards Compliance

The Home Routing roaming support feature complies with the following standards:

  • 3GPP TS 23.501 v15.4.0

  • 3GPP TS 23.502 v15.4.0

  • 3GPP TS 23.503 v15.4.0

  • 3GPP TS 33.501 v15.4.0

  • 3GPP TS 33.128 v15.4.0

  • 3GPP TS 33.127 v15.4.0

  • 3GPP TS 32.240 v15.4.0

  • 3GPP TS 29.244 v15.4.0

  • 3GPP TS 32.291 v15.3.0

  • 3GPP TS 29.500, Version 16.8.0

  • 3GPP TS 29.502, Release 16

  • 3GPP TS 29.502 v15.7.0, April 2020

Limitations

In this release, the Home Routing roaming support feature has the following limitations:

  • No support for unknown NAS SM information (unknown IE).

  • VPLMN-ID is not embedded within the Charging-ID.

Charging Support for HR Roaming

This section describes the charging support for the HR roaming feature.

This feature supports the following functionalities:

  • QBC charging.

  • Roaming QBC profiles configuration.

  • Relay roaming QBC profiles to the CHF.

  • Receive roaming QBC profiles from the CHF.

  • Relay roaming QBC profiles from the vSMF to hSMF.

  • hSMF relays roaming vSMF QBC profiles to hCHF.

  • vSMF relays roaming hSMF QBC profiles to vCHF.

  • In the vSMF, UPServ in collaboration with charging, creates PDRs for QFI on the N4 interface and associated corresponding URR, which are derived from the roaming QBC profile.

  • Relay URR usage reports derived from the QBC profile to the respective CHF in QFi containers, which are meant for QosFlow reporting.

  • Disable QBC for the sessions for which the corresponding QBC charging profiles could not be identified.

  • Support Fail-Open from the CHF.

  • Configuration to enable QBC on the hSMF, vSMF and non-roaming SMF.

Using the Roaming QBC Profile

The SMF determines the QBC profile based on the local interface. The QBC URR is created based on the limits present in the profile.

The following triggers are applicable for HR charging:

  • Triggers armed at Session Level

    • Reports the QBC in the session level URR.

    • Reports the QBC for the CC events.

  • Triggers armed at the QBC profile

    • Limits are used in QBC URRs.

    • Reports all the QBC URRs for an event armed at the QBC profile.

The following sample code shows the different triggers and their corresponding values.

Sess trigger []
Vol  100
time  100
RAT

Rg X trigger[]
Vol  10
time  10
PLMN

RoamignQbcprofile trigger[]
Vol    20
time  20
ULI


Sess URR
Vol 100
tim 100

RGX_URR
vol  10
tim 10

QBCURR1
Vol 20
tim 20

QBCURR2
Vol 20
tim 20



When RTA happens
Query all RG and all QBC urr

when PLMN change
Query RG X URR


when ULI changes
Query all QBC

Accounting Static or Predefined URR Usage to Session Level URR

In the previous release, the CHF driven session limits were controlled by the PCF, dynamic in nature and applicable for the online and offline charging service. As a result, all the dynamic URRs were reported when a session level URR was reported. Also, the offline URR associated with the static or predefined rules were reported when a separate URR was met.

In the current release, the reporting mechanism is streamlined on the N4 interface for the session limits to report the following URRs:

  • The online and offline URRs associated with dynamic rules.

  • The offline URR associated with static or predefined rules.

  • All the QBC URRs.

NOTES:

  • In this release, the SMF does not report the online static or predefined URRs when a session limit is met.

  • In this release, rulebase ECGDR configuration is not required to get the static or predefined accumulated report for offline services.

    When QBC is enabled, the SMF associates SessLevelUrr to the default UL or DL PDR, which carries the rulebase name. The UPF associates this URR to every SDF PDR or URR for all the static predefined rules.

  • During setup, the Sess Urr is associated with the default PDR. If the SMF does not have input during the setup time for creating the Sess level URR and later post setup, the CHF sets limits. These URRs are not honored.

MaxChangeinCC, MaxDeferredUrr and OOO Config

MaxChangeinCC

The HR roaming feature supports reporting of the QBC usage data when Max CC is met.

The MaxCC value can be controlled at the config level apart from it coming from the CHF. The priority order of selecting the MaxCC values, are as follows:

  • The CHF armed MaxCC.

  • The ChargingProfile when it's associated to a session.

  • If a session is enabled for QBC charging, use QbcProfile .

MaxDeferredUrr

The local config is used to configure the MaxDeffered value present in Charging-Profile. This is extended to ChargingQbcProfile. The priority order of selecting, are as follows:

  • The ChargingProfile when it's associated to a session.

  • If a session is enabled for QBC charging, use QbcProfile .

The MaxDeferred count is met when the combined value of UUC and QFICOntainer crosses the configured threshold value.

OOO Config

The OOO config is referred from Charg-Profile, which is associated to a session.

If it's not associated to a session, then it's referred from the QBC profile on the condition that the QBC charging is enabled for the session.

Configure Charging for HR Roaming

This section describes how to configure the charging for the HR roaming feature.

Configure the QBC Charging Profile

Use the following sample code to configure the QBC charging profile:

[unknown] smf(config)# profile charging-qbc test 
[unknown] smf(charging-qbc-test)# ?
Possible completions:
  limits							List of threshold
  triggers 						List of Triggers to be configured
  
[unknown] smf(charging-qbc-test)# limits ?
Possible completions:
  duration       Duration threshold for Charging, range [60..40000000]
  volume         Volume threshold for Charging, range [10000..4000000000]

[unknown] smf(charging-qbc-test)#  limit duration ?
Description: Duration threshold for Charging, range [60..40000000]
Possible completions:
  <unsignedInt, 60 .. 40000000>

[unknown] smf(charging-qbc-test)#  limit volume ?
Possible completions:
  downlink   	in bytes, range [10000..4000000000]
  total      	in bytes, range [10000..4000000000]
  uplink     	in bytes, range [10000..4000000000]

[unknown] smf(charging-qbc-test)#  triggers ?
Description: List of Triggers
Possible completions:
  3gpp-ps-change                 
  ambr-change         
  max-number-of-changes-in-charging-conditions  
  plmn-change       
  qos-change          
  rat-change
  serv-node-change  
  ue-pra-change                                 
  ue-time-change    
user-loc-change
Associate the QBC Charging Profile to Charging Characteristics

Use the following sample code to configure and associate the QBC charging profile to the Charging-Characteristics profile:

[unknown] smf(config)# profile charging-characteristics 16 
[unknown] smf(config-charging-characteristics-16)# ?
Possible completions:
  charging-profile               			Charging Profile configuration
  network-element-profile-list   		Network element profile list
  charging-qbc-profile 			Associate said QBC ChargignProfile 

[unknown] smf(config-charging-characteristics-16)#associate-qbc-charg-profile test
Associate the QBC Charging Profile to DNN Profile

Use the following sample code to configure and associate the QBC charging profile to the DNN-Profile:

unknown] smf(config)# profile dnn test 
[unknown] smf(config-dnn-test)# ?
Possible completions:
  ---
  ---
  charging-profile                                              Charging Profile configuration
  charging-qbc-profile                                      QBC ChargignProfile  
Configure the QoS Profile

The QoS profile is enhanced to configure per qi5 arp combination for the flow parameters, MFBR and GFBR.

Use the following sample code to configure the QoS profile:

[smf] smf(config-qos-abc)# qosflow?
Possible completions:
  qosflow   Configure Qosflow params for 5QI/Arp values
[smf] smf(config-qos-abc)# qosflow ?
Possible completions:
  qi5   Standard 5QI value (range 1 to 255)
[smf] smf(config-qos-abc)# qosflow qi5 ?
Possible completions:
  <qci-value:unsignedInt, 1 .. 255>  range
[smf] smf(config-qos-abc)# qosflow qi5 1 ?
Possible completions:
  arp-priority-level   Configures the ARP Priority Level [1-255]
  flow-parameter       
  <cr>                 
[smf] smf(config-qos-abc)# qosflow qi5 1 flow-parameter ?
Possible completions:
  gfbr   Guaranted Bit Rate (GFBR)
  mfbr   Maximum Bit Rate (MFBR)
[smf] smf(config-qos-abc)# qosflow qi5 1 flow-parameter gfbr ?
Possible completions:
  dl   GFBR Downlink threshold
  ul   GFBR Uplink threshold
[smf] smf(config-qos-abc)# qosflow qi5 1 flow-parameter gfbr dl ?
Description: GFBR Downlink threshold
Possible completions:
  <string>
[smf] smf(config-qos-abc)# qosflow qi5 1 flow-parameter mfbr ?  
Possible completions:
  dl   MFBR Downlink threshold
  ul   MFBR Uplink threshold
[smf] smf(config-qos-abc)# qosflow qi5 1 flow-parameter mfbr 

[smf] smf(config-qos-abc)# qosflow qi5 1 arp-priority-level 1 flow-parameter ?
Possible completions:
  gfbr   Guaranted Bit Rate (GFBR)
  mfbr   Maximum Bit Rate (MFBR)
[smf] smf(config-qos-abc)# qosflow qi5 1 arp-priority-level 1 flow-parameter

Default DNN Support in HR Roaming

In the HR roaming scenario, the vSMF supports the use of default DNN to avoid listing or configuring all the DNNs used by the roaming partners.

The DNN validation is disabled for the visitor-hr calls received by the vSMF. From the default DNN profile, the virtual DNN configuration is used toward vCHF, vUPF, and RMGR for vUPF selection.

To configure the default DNN profile, use the following CLI configuration:

config 
   policy dnn policy_name 
      profile profile_name 
   exit 
exit 

To configure the virtual DNN name, use the following CLI configuration:

config 
   profile dnn profile_name 
      dnn virtual_dnn_name network-function-list [ chf | rmgr | upf ]  
   exit 
exit 

IPv6 RS/RA Support in HR Roaming

In this release, the Home Routed roaming feature supports the mechanism for vSMF to receive the IPv6 interface ID from the hSMF using the N16 interface as per 3GPP TS 29.502, Release 16, CR 202206.

In the HR roaming scenario, the Router Solicitation (RA) and Router Advertisement (RA) is handled by the hUPF or hSMF, where the vUPF relays in both directions for RA to properly function. In CR 202206, the hSMF sends the IPv6 interface ID to the vSMF and then the vSMF relays the same to UE in the N1 payload.

For inter-operability, even if the vSMF does not receive the IPv6 interface ID from the hSMF on the N16 interface, it still relays based on the Virtual Mac configuration in the DNN profile to the UE.

SEPP Support

Feature Description

The Security Edge Protection Proxy (SEPP) is used to protect Control Plane traffic that is exchanged between different 5G PLMNs (Public Land Mobile Networks). The SEPP performs message filtering, policing and topology hiding for all API messages at the PLMN boundaries.

The SMF supports the Failure Handling template for SEPP to identify the source of failure through SEPP or Peer.

How it Works

The SEPP protects the communication pathways and performs topology hiding for every Control Plane message in an inter-PLMN signalling, acting both as a service relay between the actual service producer and the service consumer. For both the service producer and consumer, the result of the service relaying is equivalent to a direct service interaction.

For HR roaming, each SEPP communicates with the respective SMF in the VPLMN and HPLMN by using the N16 interface.


Note


The SEPP is only used on inter-PLMN boundaries, and is not used between nodes in the home domain, for example, between the hSMF and the hUDM.


SEPP Selection

The SEPP is selected through local configuration. The current set of NF nodes are extended to allow for SEPP selection. Both the vSMF and hSMF use the same configuration to select SEPP.

Failure Handling for SEPP and hSMF/vSMF

The SMF supports failure handling (FH) for hSMF or vSMF and SEPP. The client SMF detects the originator of the failure response based on the 3GPP header message received in the HTTP response. The originator can be either peer SMF or SEPP.

Depending on the NF instance value in the header message, it selects either the SEPP FH profile or the N16 FH profile.

The N16 FH profile works similar to the existing N32 SEPP FH profile. But the N16 FH profile uses an AdditionalHsmfUri attribute instead of the Endpoint (EP) configuration available for other NFs.


Important


AdditionalHsmfUri attribute is used only in the create session procedure.


When there is an error response from SMF, it includes the server header in the following format:

SMF-nf-instance-id

Example: 
SMF-54804518-4191-46b3-955c-ac631f953ed8
 SEPP-35644518-9291-46b3-934c-ac5678f953ed

If the header has the SEPP NF instance value, the client SMF that receives the failure applies the SEPP failure handling configuration.


Note


If the header has two SEPP server names, it deems the failure response as originated from the peer SMF.


Following is the sequence of failure handling steps taken during the PDU session creation procedure:

  1. The vSMF selects the first SEPP based on the locally configured SEPP EPs and appends the “3gg-target-api-root” header with the hSMF URI.

  2. If the first SEPP EP fails, vSMF selects the SEPP FHT and retries the procedure with another EP.

  3. In the absence of SEPP FHT or exhaustion of retry count, the SMF terminates the session.

  4. When the peer SMF fails, vSMF uses N16 FHT and selects the next EP from the AdditionalHsmfUri EPs.

  5. If all the URIs defined in the AdditionalHsmfUri IE fail or the retry count exhaust, the vSMF terminates the procedure..

SEPP and SMF Failure Actions

During the PDU session lifecycle, the SMF checks for the hSMF and SEPP with the NF instance value. Depending on the HTTP status code configured in the FH profile, the SMF takes one of the following actions.

Table 13. Supported Actions in SEPP and SMF FHT

N16 Procedure

SEPP FHT Actions

SMF FHT Actions

Create

terminate

retry-and-terminate

terminate

retry-and-terminate

Release

terminate

retry-and-terminate

terminate

HsmfPduSessionNotify

terminate

retry-and-terminate

terminate


Note


The SMF overwrites any other configured FH action with the default terminate action.


Call Flows

This section describes the call flow for selecting and using SEPP.

The following types of requests are sent from a client to a server:

  • Requests to API roots - These requests are sent to the API root as defined in the YAML. The following headers are added to the request:

    • 3gpp-Sbi-Target-apiRoot - The value of this header is the FQDN of the NF that services the request. For requests sent to the hSMF, this is the hSMF FQDN.

    • Authority - The value of this header is the server SEPP to which the request is sent to by the client. When the request is sent by the vSMF, the value is vSEPP, and when the request is sent by the hSMF, it's hSEPP.

  • Callback Requests - These requests are callbacks that are invoked across PLMN boundaries. The values of the header field in such requests are defined in 3GPP TS 29.500, Annex B.

Figure 17. Call Flow with SEPP
Table 14. Call Flow Description for Selecting a SEPP
Step Description
1 - 2 The vSMF initiates the procedure by sending an indication to hSMF about using a SEPP and the address of the SEPP. The call flow sequence for this forward messaging is as follows:
  • The vSEPP and hSEPP encrypts and decrypts the messages sent from the vSMF to hSMF respectively.

  • The AMF sends the hSMF FQDN to smf-service, which in turn sends it to rest-ep in all the messages.

  • The vSMF selects the vSEPP by reading the locally configured IP address and port number for the vSEPP and uses it to send messages to hSMF.

  • The rest-ep updates the 3gpp-Sbi-Target-apiRoot headers with the hSMF URI and Authority header with the IP address and port number of the vSEPP and then, sends the messages to vSEPP, which is further communicated to the hSEPP.

  • The hSEPP resolves the DNS (if required), decrypts the message and transmits it to the hSMF.

3 - 4 The hSMF responds with a callback header value. The call flow sequence for this return messaging is as follows:
  • The hSEPP and vSEPP encrypts and decrypts the messages sent from the hSMF to vSMF respectively.

  • The smf-service gets the FQDN for the vSMF from the notification URI that is received as apart of message from the vSMF and updates the 3gpp-Sbi-Target-apiRoot headers. The smf-service updates the 3gpp-sbi-callback enum value in all the messages.

  • The smf-service forwards the message to the rest-ep. The rest-ep updates the 3gpp-sbi-callback and 3gpp-Sbi-Target-apiRoot header values.

  • The rest-ep updates the Authority (pseudo header) with the locally configured IP address and port number of the hSEPP and forwards the message to the hSEPP, which is further communicated to the vSEPP.

  • The vSEPP resolves the DNS (if required), decrypts the message and transmits it to the vSMF.

Configuring the SEPP

This section describes how to configure SEPP.

The following conditions are applicable when you configure SEPP:

  • It's configured in the same way how you configure the other NFs, like, for example, UDM, CHF, or PCF.

  • As it's an Edge proxy and not a proper NF, it must have service lists, which are supported by a peer SMF.

  • It supports failure handling functionality using the existing nf-client failure templates, similar to the other NFs.

Configuring the SEPP nf-client

To configure a SEPP nf-client, use the sample CLI configuration only as a reference.

profile nf-client nf-type sepp
 sepp-profile SEPP1
  locality LOC1
   service name type nsmf-pdusession
    endpoint-profile EP1
     capacity   50
     priority   50
     uri-scheme http
     endpoint-name sepp-ep-1
      priority 50
      capacity 50
      primary ip-address ipv4 xx.xx.xx.xx
      primary ip-address port xxxx
     exit
    exit
   exit
  exit
 exit
exit
Configuring the Network Element Profiles for a SEPP

To configure the network element profiles linked to a SEPP nf-client, use the sample CLI configuration.

profile network-element sepp nrf-nf-sepp-1
 nf-client-profile SEPP1
exit
Configuring the DNN Profile for a SEPP

To configure the DNN profile for a SEPP, use the sample CLI configuration only as a reference.

network-element-profile sepp nrf-nf-sepp-1 is linked to dnn 

profile dnn intershatRoamer
 network-element-profiles sepp nrf-nf-sepp-1
exit
Configuring the Failure Handling for a SEPP

The SEPP supports the existing failure handling template for all the HTTP error response codes. To configure failure handling for a SEPP, use the sample configuration only as a reference.

profile nf-client-failure nf-type sepp
 profile failure-handling FH-SEPP
  service name type nsmf-pdusession
   message type VsmfPduSessionCreate
    status-code httpv2 504
     retry  2
     action retry-and-terminate
    exit
   exit
  exit
 exit
exit

Note


In the current release, only the retry-terminate option is supported for all the messages.


Configuring the Failure Handling Template for hSMF/vSMF and SEPP

The peer SMF and SEPP support the failure handling template for all the HTTP error response codes. To configure failure handling for a peer SMF message, use the sample configuration only as a reference.

The following is a sample configuration for hSMF:


profile nf-client-failure nf-type sepp
 profile failure-handling FHSEPP
  service name type nsmf-pdusession
   responsetimeout 4000
   message type VsmfPduSessionUpdate
    status-code httpv2 500-599
     retry  3
     action retry-and-terminate
    exit
   exit
   message type VsmfPduSessionNotify
    status-code httpv2 400-599
     retry  3
     action retry-and-terminate
    exit
   exit
  exit
 exit
exit

The following is a sample configuration for vSMF:

profile nf-client-failure nf-type sepp
 profile failure-handling sepp
  service name type nsmf-pdusession
   responsetimeout 4000
   message type HsmfPduSessionCreate
    status-code httpv2 400-599
     retry  3
     action retry-and-terminate
    exit
   exit
   message type HsmfPduSessionUpdate
    status-code httpv2 500-599
     retry  3
     action retry-and-terminate
    exit
   exit
   message type HsmfPduSessionRelease
    status-code httpv2 504
     retry  3
     action retry-and-terminate
    exit
   exit
  exit
 exit
exit

Note


The sample configurations use the nf-type SEPP. You can use the same for nf-type SMF.


Configuring the Failure Handling Template with Alternate hSMF

If there is failure from a primary hSMF, vSMF tries the alternate hSMF. SMF service sends the alternate hSMF details to Rest Endpoint (rest-ep) and SMF gets alternate HSM details from AMF. Based on the N26 failure handling configuration, an alternate hSMF is selected.

Alternate hSMF is selected only if retry is configured for.pduSessionCreate


Note


smf-service includes listalternate-hsmf in the discoveryParams to Rest Endpoint.

Based on the N26 failure handling configuration, an alternate hSMF is selected.

Rest-ep or NfLib sends the selected alternate hSMF back to service and vSMF sends this back to AMF. vSMF displays SelectedSmfId in smContextCreatedData.

Configuration Example:

The following is an example configuration:


[smf] smf(config)# profile nf-client-failure nf-type n16smf  
smf] smf(config-n16smf)# profile failure-handling fh 
[smf] smf(config-failure-handling-fh)# service name type nsmf-pdusession 
[smf] smf(config-type-nsmf-pdusession)# message type [ PduSessionCreate  ] status-code httpv2 <0-599>
[smf] smf(config-httpv2-400)# action [continue  retry-and-continue  retry-and-ignore  retry-and-terminate  terminate]
[smf] smf(config-httpv2-400)# retry <1-10>
Configuring the SMF NRF Registration

To configure the SMF NRF registration, use the sample configuration only as a reference.

profile smf smf1 instances 
            instances 1 fqdn 5gc.mnc456.mnc123.3gppnetwork.org
            instances 1 inter-plmn-fqdn 5gc.mnc456.mnc123.3gppnetwork.org
            instances 1 supported-features [ vsmf ]

Note


In the current release, for the SMF to register with an NRF, the inter-plmn-fqdn and vsmf-supported IEs are included for the SMF discovery. The configuration for vsmfSupportIndicator must be added on vSMF along with inter-plmn-fqdn. This configuration is required for vAMF to find a vSMF, which supports roaming.


To undo the configuration for vsmfSupportIndicator, use the following sample configuration:

smf] smf(config-smf-smf1)# no instances 1 supported-features 
[smf] smf(config-smf-smf1)# commit

OAM Support

Bulk Statistics Support

This feature introduces "failed_nf_type" label in the "smf_restep_http_msg_total" statistics to indicate the target NF from where the failure response code is sent.

Following are the example queries for peer SMF and SEPP create session procedure failure responses.

  • Create session procedure success:

    smf_restep_http_msg_total{api_name="smf_pdu_session_create",app_name="SMF",
    cluster="SMF",data_center="DC",dnn="",gr_instance_id="1",
    instance_id="0",message_direction="outbound",message_type="",
    nf_type="smf",nf_uri="",proc_name="",rat_type="",req_cause="",response_cause="",
    response_status="201",service_name="rest-ep",sess_type="", failed_nf_type=""} 1
  • Create session procedure failure response from SMF:

    smf_restep_http_msg_total{api_name="smf_pdu_session_create",app_name="SMF",
    cluster="SMF",data_center="DC",dnn="",gr_instance_id="1",
    instance_id="0",message_direction="outbound",message_type="",
    nf_type="smf",nf_uri="",proc_name="",rat_type="",req_cause="",response_cause="",
    response_status="400",service_name="rest-ep",sess_type="", failed_nf_type="smf"} 1
    
  • Create session procedure failure response from SEPP:

    
    smf_restep_http_msg_total{api_name="smf_pdu_session_create",app_name="SMF",
    cluster="SMF",data_center="DC",dnn="",gr_instance_id="1",
    instance_id="0",message_direction="outbound",message_type="",
    nf_type="smf",nf_uri="",proc_name="",rat_type="",req_cause="",response_cause="",
    response_status="400",service_name="rest-ep",sess_type="", failed_nf_type="sepp"} 1 

For more information on the bulk statistics, see the UCC 5G SMF Metrics Reference.

N3 and N9 User Plane Separation

Users prefer to keep the N3 and N9 network separately in a 5G network on SMF or UPF that handles both non-roaming subscribers and home routed subscribers.

If the UPF does not detect whether an UE is an outbound roamer or a homer, the SMF passes information to the UPF about the interface to use for the subscriber. To overcome this scenario, SMF allows N3 interface on one network and S5-U/S8-U and N9 interface on another network, to allow users to maintain a separate RAN network from core network especially on the data path.

The SMF populates source interface type IE (3GPP interface type) in PDI IE in N4 messages while creating PDR with an appropriate interface type. The format of IE is as below:

Bits

Octets

8

7

6

5

4

3

2

1

1 to 2

Type = 160 (decimal)

3 to 4

Length = n

5

Spare

Interface Type Value

6 to n+4

These octets are present only if explicitly specified

Following table describes the 3GPP Interface type and its values.

Interface Value

Values (Decimal)

S1-U

0

S5 /S8-U

Note

 
If there is separation of roaming and non-roaming traffic, this value should only used for the S5-U interface and "S8-U" (decimal 19) should be used for the S8-U interface.

1

S4-U

2

S11-U

3

S12

4

Gn/Gp-U

Note

 
If there is separation of roaming and non-roaming traffic, this value should only be used for the Gn-U interface and "Gp-U" (decimal 20) should be used for the Gp-U interface.

5

S2a-U

6

S2b-U

7

eNodeB GTP-U interface for DL data forwarding

8

eNodeB GTP-U interface for UL data forwarding

9

SGW/UPF GTP-U interface for DL data forwarding

10

N3 3GPP Access

11

N3 Trusted Non-3GPP Access

12

N3 Untrusted Non-3GPP Access

13

N3 for data forwarding

14

N9 (or N9 for non-roaming

Note

 
If there is separation of roaming and non-roaming traffic, this value should only be used for N9 non-roaming interfaces and (decimal value "21") should be used for N9 roaming interfaces.

15

SGi

16

N6

17

N19

18

S8-U

19

Gp-U

20

N9 for roaming

21

Iu-U

22

N9 for data forwarding

23

Sxa-U

24

Sxb-U

25

Sxc-U

26

N4-U

27

SGW/UPF GTP-U interface for UL data forwarding

28

N6mb/Nmb9

29

N3mb

30

N19mb

31

Spare

32–63

How it Works

Following functions can occur during N3 and N9 User Plane Separation:

  • SMF provides:

    • S5-U as source interface type in the Packet Detection Information (PDI) of uplinks PDRs for homers attaching via 4G RAT.

    • N3 3GPP Access as source interface type in the PDI of uplinks PDRs for homers attaching through 5G RAT.

    • S5-U as source interface type in the PDI of uplinks PDRs for homers attaching through Wi-Fi RAT. This is done as an optimization to avoid tunnel recreation during 4G < - > Wi-Fi handovers.

  • During Hand Over (HO) scenarios:

    • From 5G to 4G/Wi-Fi: A Tunnel is recreated and N4 modification goes with uplink PDRs PDI having source interface type set to S5-U.

    • Fron 4G/Wi-Fi to 5G: A Tunnel is recreated and N4 modification goes with uplink PDRs PDI having source interface type set to N3.

    • Similarly, the uplink PDRs for dedicated flow/bearers get created with either N3 or S5-U source interface type depending on the RAT.

  • UPF handles N4 messages without source interface type and allocates tunnel from interface, which is not associated to any interface for backward compatibility reasons.

Configuring Interface Types

To configure the UPF ingress interface type, use the following configuration:


configure 
   context context_name 
      user-plane-service service_name 
         [ no ] associate gtpu-service gtpu_service_name upf-ingress   
         end 

NOTES:

  • associate gtpu-service gtpu_service_name : Associates the GTP-U service with the user plane service.

  • upf-ingress : Configures the interface type as UPF ingress.

The following is an example:

associate gtpu-service n3-upf-in upf-ingress
associate gtpu-service n3-upf-in upf-ingress interface-type S5-U | S8-U | 3 3Gpp Access | n9-s5-s8
| N3 for data Forwarding | N9 | N6 | SGi 

Homer Calls with N3 and N9 Separation

Following call flow process change happens in the Home routed calls.

  • vSMF Create Session Procedure: During the 5G session creation procedure, SMF includes source interface type IE (3GPP interface type) in the PDI IE in N4 messages while creating a PDR with an appropriate interface type. For example, SMF includes source interface type= N3 3GPP Access in the Create uplink PDR in N4 messages and UPF allocates TEID from that interface based on the configuration. If no GTPU service is associated to N3 3GPP Access, then TEID is allocated from default (one without interface configuration).

  • 4G Access Registration: At the time of 4G access registration, SMF includes source interface type= S5-U in the Create uplink PDR in N4 messages and UPF allocates TEID from that interface based on the configuration. If no GTPU service is associated to S5-U, then TEID is allocated from default (one without interface configuration.

Dedicated Bearer Call Flow

Following call flow changes happen during:

  • Dedicated Bearer Flow Creation: While creating dedicated bearer in 4G, SMF sends N4 modify with source interface type as S5-U in uplink PDR create.

  • Additional 5G Call Flow Creation: While creating additional flows in 5G, SMF sends N4 modify with source interface type as “N3 3GPP Access” in the uplink PDR create.

Roamer Calls with N3 and N9 Separation

Following call flow process change happens during Roamer calls:

  • For roamers, vSMF sends source interface type as N9 while creating downlink (DL) PDRs for N9 traffic and as “N3 3GPP Access” while creating Uplink (UL) PDRs for N3 traffic in N4 messages.

  • The hSMF sends source interface type as N9 while creating UL PDRs for N9 traffic and as S5-U while creating UL PDRs (secondary PDR) for 4G traffic.

  • The UPF allocates two different tunnels for the NR and 4G default bearer/flow.


Note


To achieve further optimization, SMF can send N9 as source interface type while creating both 4G and 5G UL PDRs if required, without any changes on the UPF.

Allowed PLMN List Support

In networks, where non-roaming SMF and hSMF are in different nodes, AMF can select SMF based on the NRF discovery using query parameters such as NSSAI, PLMN-ID of SUPI, DNN, and so on. This selection might not provide correct results.

In such scenarios, SMF uses the NRF discovery service to register with NRF with the Allowed PLMN list. Either non-roaming SMF can register with list of home serving PLMNs or hSMF can register with partner serving PLMNs.

The SMF includes the configured allowed-plmn-list in allowedPlmns in a Network profile at the time of registering a network function to the NRF.

AMF discovers SMF using a requester-plmn-list in addition to the existing query parameters.

If allowed plmns is configured and SMF receives any SmContextCreate or SmContextUpdate with serving-plmn, which doesn’t match with the configured allowed-plmn, then calls get rejected.

For more information about NF Discovery, refer to the NF Discovery chapter in the UCC 5G SMF Configuration and Administration Guide

Configuring the Allowed PLMN List

To configure the Allowed PLMN list for SMF use the following sample configuration.

config 
   profile smf smf_profile_name 
      allowed-plmn-list  [ mcc-mnc ] 
      end 

NOTES:

  • allowed-plmn-list [ mcc-mnc ] : Configures the allowed plmn list.

Inter-plmn Roaming Mobility Support

The Inter-plmn roaming mobility is a feature that allows a UE to move from their home network (H-PLMN) to a partner network (V-PLMN) and vice versa while maintaining an ongoing seamless data transfer.

The SMF supports home-routed roaming Inter-plmn scenarios when the UE moves from the home network to the visitor network and vice versa.

SMF supports the following functionalities:

  • Handovers from H-PLMN to V-PMLN and vice versa.

  • Enabling and disabling of inter-plmn handover functionalities through a CLI.

  • Advertises Deployments Topologies with specific SMF Service Areas (DTSSA) in supported features on N11 and N16 interfaces.

  • Creates Secondary PDRs for secondary RATs for homer calls for efficient Inter-RAT handoffs.

During Inter-plmn mobility, vSMF:

  • Selects operator policy based on the configured subscriber policy.

  • Selects V-UPF and V-CHF based on the configuration.

  • Uses roaming status that is configured under the Operator policy to override the HRT roaming request to treat the UE as Local Breakout (LBO).

N4 Changes

The SMF supports re-creating of PDRs rather than changing the associations.

  • 5G roaming: For 5G roaming, when the 5G UE moves from a homer to a roamer, and vice versa, N3 PDRs is created and deleted. The S5 and N9 Secondary PDRs get recreated with an existing FTEID.

  • 4G roaming: For 4G roaming, when the 4G UE moves from a homer to roamer and vice versa, S5 and N9 PDRs get recreated with existing FTEIDs. The N3 PDRs get freshly created and deleted.

  • Inter-RAT roaming: The SMF deletes older RAT PDRs and creates new RAT PDRs for Inter-RAT scenarios. SMF also recreates the S5 and N9 PDRs with existing FTEIDs.

Limitations and Restrictions

During inter-plmn mobility, H-SMF or SMF has the following limitations:

  • Does not reselect operator policy and the UPF.

  • Northbound NF selection criteria do not change.

  • Changes roaming status from/to homer/roamer

During inter-plmn mobility, V-SMF has the following limitations:

  • Selects operator policy based on the subscriber policy configuration

  • V-UPF and V-CHF are selected based on configuration.

  • Roaming-status configured under the Operator policy is used to override the HRT roaming request to treat the UE as LBO.

Restrictions

SMF has the following restrictions:

  • Intra-PLMN mobility where UE moves from one V-SMF to another in V-PLMN, V-SMF change is not supported.

  • IDFT is not supported for Inter-plmn HO.

  • If the inter-plmn CLI is not configured, ModifyBearerRequest with visitor PLMN is rejected.

  • For inter-plmn scenarios, the Roaming QOS flow based charging profile configured in the H-SMF is given priority and the one received from the V-SMF is ignored.

Standards Compliance

The Inter-plmn Roaming Mobility features complies with the following standards:

  • 3GPP TS 23.502,Version 16.6

  • 3GPP TS 29.502, Version 16.6

  • 3GPP TS 29.571, Version 16.6

  • 3GPP TS 29.244, Version 16.6

  • 3GPP TS 32.255, Version 16.6

How it Works

This section describes call flows and procedures for Inter-plmn handover feature.

Call Flows

SMF supports the following call flows for various inter-plmn mobility functions:

  • 5g homer to 5g roamer

  • 5g roamer to 5g homer

  • 5g roamer to 4g homer/roamer

  • 4g roamer/homer to 5g roamer

  • Intra PLMN roaming

Inter PLMN 5G Handover with Homer to Roamer

This section provides call flow and details about the Inter-plmn N2 HO procedure with v-SMF Insertion.

Figure 18. Call Flow for Inter-plmn N2 HO with v-SMF Insertion

Procedure

  • UE moves from being a homer in H-PLMN to a roamer in V-PLMN.

  • V-SMF gets added.

  • SMF transitions to the H-SMF.

Inter PLMN Handover from 5G Roamer to 5G Homer with v-SMF Deletion

This section provides call flow and details about the Inter-plmn N2 HO procedure with v-SMF deletion.

Figure 19. Call Flow for Inter-plmn N2 HO with v-SMF Deletion

Call Flow Description for Inter-plmn N2 HO with v-SMF Deletion:

  • UE moves from being a roamer in V-PLMN to a homer in H-PLMN.

  • Deletes V-SMF.

  • H-SMF transitions to SMF.

Inter PLMN and Inter-RAT Scenarios
Inter PLMN N26 Handover from 4G Homer to 5G Roamer

This section provides Call flow and details about the Inter-plmn N2 HO from 4G Homer to 5G Roamer.

Figure 20. Call Flow for Inter-plmn N26 HO from 4G Homer to 5G Roamer

Call Flow Description for Inter-plmn N26 HO from 4G Homer to 5G Roamer: The UE moves from a 4G homer in H-PLMN or a roamer in V-PLMN to a 5G roamer in V-PLMN.

Inter PLMN Handover from 5G Roamer to 4G Homer or Roamer

This section provides call flow and details about the Inter-plmn HO from 5G Roamer to 4G Homer.

Figure 21. Call Flow for Inter-plmn HO from 5G Roamer to 4G Homer

Call Flow Description for Inter-plmn HO from 5G Roamer to 4G Homer:

The UE moves from being a 5G roamer in V-PLMN to a 4G homer in H-PLMN or a 4G roamer in V-PLMN.

Inter PLMN Handover from 4G Homer to 4G Roamer

This section provides call flow and details about the Inter-plmn Handover (HO) procedure from 4G Homer to 4G Roamer.

Figure 22. Call Flow for Inter-plmn HO from 4G Homer to 4G Roamer

Call Flow Description for 4G Homer to 4G Roamer

  • Receives the ModifyBearerRequest from a visitor S-GW.

  • Determines roaming status during ModifyBearerRequest processing.

  • Deletes N3 and creates N9 Secondary PDRs.

  • Recreates S5 PDRs with existing FTEIDs.

Inter PLMN Handover from 4G Roamer to 4G Homer

This section provides call flow and details about the Inter-plmn N2 HO procedure from 4G Roamer to 4G Homer.

Figure 23. Call Flow for Inter-plmn N2 HO from 4G Roamer to 4G Homer

Call Flow Description for Inter-plmn N2 HO procedure from 4G Roamer to 4G Homer

  • If the Subscriber is Roamer, SMF receives ModifyBearerRequest from the home S-GW.

  • Determines roaming Status in ModifyBearerRequest messages.

  • Deletes N9 and creates N3 Secondary PDRs

  • Recreates S5 PDRs with an existing FTEID.

Inter PLMN Handover from 4G Roamer to 5G Homer

This section provides call flow and details about the Inter-plmn HO from 4G Roamer to 5G Homer.

Figure 24. Call Flow for Inter-plmn HO from 4G Roamer to 5G Homer

Call Flow Description for Inter-plmn HO from 4G Roamer to 5G Homer

  • Deletes N9 secondary and creates N3 primary PDRs.

  • Recreates S5 PDRs with existing FTEIDs.

Configuring the Inter PLMN Handover

Use the following sample configuration to enable or disable inter-plmn handover for roaming. You can use this configuration to disallow inter-plmn roaming for specific DNNs.


config 
   profile dnn dnnprofile_name 
      [ no ] supported-features [ inter-plmn-ho ] 

NOTES:

  • supported-features [ inter-plmn-ho ] : Enables inter-plmn handover for roaming.


    Note


    If the inter-plmn CLI is not configured in PGW-C+SMF, MBR from a V-PLMN is rejected by PGW-C+SMF. To handle handovers from V-PLMN, configuring the inter-plmn-ho in the DNN profile is mandatory.
  • no : Disables inter-plmn handover for roaming for a specific DNN.

Configuration for Creating Separate Tunnel for Secondary PDRs

Use the sample configuration to check whether N3and N9 interface separation is enabled or not at UPF. If n3-n9 interface-separation is enabled, then a separate tunnel is created for the Secondary RAT PDR else, the same tunnel is reused for the Secondary RAT.


config 
   profile dnn dnnprofile_name 
      [ no ] supported-features [ n3-interface-separation ] 

NOTES:

  • supported-features [ n3-interface-separation ] : Creates Separate Tunnel for Secondary PDRs.

  • no : Creates same tunnel for Primary and Secondary PDRs.


    Note


    If this config is not present, then SMF/PGW-C considers that the N3-N9 interface separation is disabled at UPF.

Sending DTSSA and ACSCR

SMF supports sending the DTSSA and ACSCR in supported-features in the following SmContextCreated, SmContextUpdated, PduSessionCreated, and PduSessionUpdated IEs on N11 and N16 interfaces.

This allows AMF to select an appropriate V-SMF and H-SMF for inter-plmn roaming.

Configuring DTSSA

To configure the DTSSA or ACSCR, use the sample configuration as a reference.


config 
   profile smf profile_name instances instance-id supported-features  
       [ vsmf dtssa acscr] 

NOTES:

  • vsmf dtssa acscr : Sends DTSSA and ACSCR in supported-features.

OAM Support

This section describes operations, administration, and maintenance information regarding support for interfaces in SMF.

Bulk Statistics Support

The following labels are added for the Inter-plmn mobility feature:

  • interplmn_ho_not_configured

  • dtssa_acscr_not_supported

  • disc_vsmf_insert_dtssa_acscr_not_configured

  • disc_vsmf_insert_interplmn_ho_not_configured

  • disc_vsm_insert_hsmf_retrieve_failure

  • disc_ro2ho_n2ho_interplmn_ho_not_configured

  • disc_ro2ho_n4_modify_failed

  • disc_ho2ro_n4_modify_failed

  • disc_ho2ro_failure

  • disc_ro2ho_failure

  • ho2ro_invalid_state

  • ro2ho_invalid_state

  • disc_ro2ho_guard_timer_expiry

  • disc_ho2ro_guard_timer_expiry

  • disc_ro2ho_idft_timer_expiry

  • smf_idft_inter_plmn_ro2ho_n2ho

  • smf_dft_inter_plmn_ro2ho_n2ho

  • smf_idft_inter_plmn_ho2ro_n2ho

  • smf_dft_inter_plmn_ho2ro_n2ho

Roaming Status on N4 Interface

A sub IE option is added under the proprietary IE, in the subscriber-params N4 messages to allow the UPF know about the roaming status.


SUBSCRIBER PARAMS: 
Type: 226
    roaming-status: homer/roamer/visitor-hr/visitor-lbo 

The following sample output lists roaming statuses.


Homer– 1
Visitor-LBO – 2
Visitor-HR – 3
Roamer – 4

Troubleshooting Information

This section provides information on using the command line interface (CLI) commands, alerts, logs, and metrics for troubleshooting any roaming related issues that may arise during system operation.

Subscriber Details for Roaming-specific Information

The show subscriber supi supi_id nf-service smf full CLI command displays the roaming status of a UE.


Note


In 2021.02 and later releases, the namespace keyword is deprecated and replaced with the nf-service keyword.


[unknown-smf] smf# show subscriber supi imsi-123456789012345 nf-service smf full 
subscriber-details 
{
…
        "authStatus": "Unauthenticated",
        "roamingStatus": "Vistor LBO",    <<< In-Roamer UE Roaming Status
        "uePlmnId": {
          "mcc": "123",
          "mnc": "456"
        }

…
     "authStatus": "Unauthenticated",
        "roamingStatus": "Roamer",      <<< Out-Roamer UE Roaming Status
        "uePlmnId": {
          "mcc": "123",
          "mnc": "456"
        }
…
        "authStatus": "Unauthenticated",
        "roamingStatus": "Homer",
        "uePlmnId": {
          "mcc": "123",
          "mnc": "456"
        }

Subscriber Details for Roaming-specific Information for hSMF

The show subscriber supi supi_id nf-service smf psid psid_value full CLI command displays the detailed subscriber information for roaming-specific use case as hSMF.

[unknown] smf# show subscriber supi imsi-123456789012345 nf-service smf psid 5 full  
subscriber-details 
{
  "status": true,
  "genericInfo": {
    "supi": "imsi-310210789012346",
    "pei": "imei-123456786666660",
    "pduSessionId": 5,
    "pduSesstype": "Ipv4PduSession",
    "accessType": "3GPP_ACCESS",
    "dnn": "intershat",
    "plmnId": {
      "mcc": "310",
      "mnc": "560"
    },
    "sScMode": 1,
    "uetimeZone": "UTC+12:00",
    "allocatedIp": "209.165.200.229",
    "nrLocation": {
      "ncgi": {
        "mcc": "310",
        "mnc": "560",
        "nrCellId": "123456789"
      },
      "tai": {
        "mcc": "310",
        "mnc": "560",
        "tac": "1820"
      }
    },
    "alwaysOn": "None",
    "dcnr": "None",
    "wps": "Non-Wps Session",
    "ratType": "NR",
    "ueType": "NR Capable UE",
    "sessTimeStamp": "2021-06-18 18:49:28.266245111 +0000 UTC",
    "callDuration": "20.549700502s",
    "ipPool": "poolv4",
    "commonId": 2097158,
    "snssai": {
      "sd": "Abf123",
      "sst": 2
    },
    "authStatus": "Unauthenticated",
    "roamingStatus": "Roamer",
    "uePlmnId": {
      "mcc": "310",
      "mnc": "210"
    }
  },
  "accessSubData": {
    "amfID": "AFbe08",
    "amfPlmnId": {
      "mcc": "310",
      "mnc": "560"
    },
    "epsInterworkingIndication": "WITHOUT_N26"
  },
  "policySubData": {
    "TotalDynamicRules": 2,
    "TotalFlowCount": 2,
    "TotalNonGBRFlows": 1,
    "TotalGBRFlows": 1,
    "pccRuleList": [
      {
        "pccRuleId": "PccRule-1",
        "qfi": 2,
        "gbrDl": 2000000000,
        "gbrUl": 1000000000,
        "mbrDl": 4000000000,
        "mbrUl": 3000000000,
        "flowInformation": [
          {
            "flowLabel": "flow",
            "spi": "2",
            "flowDirection": 3,
            "flowDescription": "permit out ip from 209.165.200.225 to 209.165.200.254",
            "tosTrafficClass": "8"
          }
        ],
        "chargingInformation": {
          "chargingId": "ChargingData-1",
          "meteringMethod": "Duration and Volume",
          "Type": "Online",
          "ratingGroup": 10,
          "serviceId": "20"
        }
      },
      {
        "pccRuleId": "defaultrule",
        "qfi": 1,
        "mbrDl": 125000000,
        "mbrUl": 100000000,
        "flowInformation": [
          {
            "flowDirection": 3,
            "flowDescription": "permit out ip from any to any"
          }
        ]
      }
    ],
    "qosFlow": [
      {
        "qfi": 2,
        "GBRFlow": "True",
        "bindingParameters": {
          "x5Qi": 3,
          "arp": {
            "preemptCap": "NOT_PREEMPT",
            "preemptVuln": "PREEMPTABLE",
            "priorityLevel": 7
          }
        },
        "AggregatedULGFbr": 1000000000,
        "AggregatedDLGFbr": 2000000000,
        "AggregatedULMFbr": 3000000000,
        "AggregatedDLMFbr": 4000000000,
        "pccRuleList": "PccRule-1",
        "qosDescList": "QoS-1,"
      },
      {
        "qfi": 1,
        "GBRFlow": "False",
        "bindingParameters": {
          "x5Qi": 5,
          "arp": {
            "preemptCap": "NOT_PREEMPT",
            "preemptVuln": "NOT_PREEMPTABLE",
            "priorityLevel": 15
          },
          "priorityLevel": 1
        },
        "AggregatedULMFbr": 100000000,
        "AggregatedDLMFbr": 125000000,
        "pccRuleList": "defaultrule",
        "qosDescList": "default,"
      }
    ],
    "policyType": "Pcf",
    "pcfInteraction": "Pcf Interaction: ON",
    "ruleBase": "starent",
    "sessRuleList": [
      {
        "authDefaultQos": "&QosProfileKey{X5QI:5,Arp:{PreemptionCapability_NOT_PREEMPT PreemptionVulnerability_NOT_PREEMPTABLE 15 true},Priority:1,MaxDataBurstVol:0,Qnc:false,AveragingWindow:,}",
        "authSessAmbr": {
          "downlink": 125000000,
          "uplink": 100000000
        },
        "sessRuleId": "default"
      }
    ],
    "presenceReporting": "Disabled"
  },
  "chargingData": {
    "invcSeqNo": 1,
    "pduChId": 2097158,
    "ccId": "1",
    "chargingIdRtgGrpMapInfo": {
      "rgId": "10",
      "chargingId": [
        "ChargingData-1",
        "l10of",
        "l10on"
      ]
    },
    "chargParmMapInfo": [
      {
        "ratingGrp": 10,
        "chargingId": "ChargingData-1",
        "online": "true",
        "offline": "true",
        "serviceID": 20,
        "pccRuleIds": [
          "PccRule-1"
        ],
        "linkedChrgId": [
          "l10of",
          "l10on",
          "sesslevelurr"
        ],
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingLevelOnline": "ReportingLevel_RAT_GR_LEVEL",
        "reportingLevelOffline": "ReportingLevel_RAT_GR_LEVEL",
        "configured": "false",
        "tightInterworkingMode": "false",
        "parent": "true",
        "reportingParm": "false",
        "limitParm": "false",
        "limitsChrgParamOnline": "l10on",
        "limitsChrgParamOffline": "l10of",
        "qosIds": [
          "QoS-1"
        ],
        "qfi": 2,
        "offlineConverted": "false"
      },
      {
        "ratingGrp": 10,
        "chargingId": "l10of",
        "online": "false",
        "offline": "true",
        "pccRuleIds": [
          "PccRule-1"
        ],
        "linkedChrgId": [
          "sesslevelurr"
        ],
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingLevelOnline": "ReportingLevel_Dummy",
        "reportingLevelOffline": "ReportingLevel_RAT_GR_LEVEL",
        "configured": "false",
        "tightInterworkingMode": "false",
        "parent": "false",
        "reportingParm": "true",
        "limitParm": "true",
        "qosIds": [
          "QoS-1"
        ],
        "qfi": 2,
        "offlineConverted": "false"
      },
      {
        "ratingGrp": 10,
        "chargingId": "l10on",
        "online": "true",
        "offline": "false",
        "pccRuleIds": [
          "PccRule-1"
        ],
        "linkedChrgId": [
          "sesslevelurr"
        ],
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingLevelOnline": "ReportingLevel_RAT_GR_LEVEL",
        "reportingLevelOffline": "ReportingLevel_Dummy",
        "configured": "false",
        "tightInterworkingMode": "false",
        "parent": "false",
        "reportingParm": "true",
        "limitParm": "true",
        "qosIds": [
          "QoS-1"
        ],
        "qfi": 2,
        "offlineConverted": "false"
      },
      {
        "chargingId": "sesslevelurr",
        "online": "false",
        "offline": "true",
        "pccRuleIds": [
          "PccRule-1"
        ],
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingLevelOnline": "ReportingLevel_Dummy",
        "reportingLevelOffline": "ReportingLevel_Dummy",
        "configured": "false",
        "tightInterworkingMode": "false",
        "parent": "false",
        "reportingParm": "false",
        "limitParm": "true",
        "offlineConverted": "false"
      }
    ],
    "chTriggerInfo": {
      "sessionTriggerInfo": [
        {
          "triggerType": "VOLUME_LIMIT",
          "triggerCategory": "IMMEDIATE_REPORT",
          "triglevel": 2
        },
        {
          "triggerType": "TIME_LIMIT",
          "triggerCategory": "IMMEDIATE_REPORT",
          "triglevel": 2
        },
        {
          "triggerType": "AMBR_CHANGE",
          "triggerCategory": "IMMEDIATE_REPORT",
          "triglevel": 2
        },
        {
          "triggerType": "QOS_CHANGE",
          "triggerCategory": "DEFERRED_REPORT",
          "triglevel": 2
        }
      ],
      "rgTrgrList": [
        {
          "ratingGroup": 10,
          "rgTriggerInfo": [
            {
              "triggerType": "QUOTA_THRESHOLD",
              "triggerCategory": "IMMEDIATE_REPORT",
              "triglevel": 1
            },
            {
              "triggerType": "VOLUME_LIMIT",
              "triggerCategory": "IMMEDIATE_REPORT",
              "triglevel": 1
            },
            {
              "triggerType": "TIME_LIMIT",
              "triggerCategory": "IMMEDIATE_REPORT",
              "triglevel": 1
            },
            {
              "triggerType": "QUOTA_EXHAUSTED",
              "triggerCategory": "IMMEDIATE_REPORT",
              "triglevel": 1
            }
          ]
        }
      ]
    },
    "chThresholdInfo": {
      "sessthresholdInformation": {
        "volumeThreshold": 45000,
        "durationThreshold": 90
      },
      "rgthresholdInformation": [
        {
          "volumeThreshold": 7000,
          "durationThreshold": 800
        }
      ],
      "quotaInformation": [
        {
          "quotaHoldingTime": -1,
          "timeQuotaThreshold": 10,
          "volQuotaThreshold": 1000,
          "downlinkVolume": 20000,
          "time": 100,
          "totalVolume": 35000,
          "uplinkVolume": 15000,
          "ratingGrp": 10
        }
      ]
    },
    "startTime": "2021-06-18T18:49:28Z",
    "rulebase": "starent",
    "chargingDisabled": "false",
    "dropTraffic": "false",
    "gtppGrp": "group1",
    "profileName": "chgprf1",
    "accountingEnabled": "false",
    "n40ChargingEnabled": "true",
    "QbcProfileName": "qbc_general",
    "qbcChargingEnabled": "True",
    "roamingQbcInfo": {
      "qfiTh": {
        "volTh": 30000,
        "durTh": 80
      },
      "qfis": {
        "rgTriggerInfo": [
          {
            "triggerType": "QOS_CHANGE",
            "triggerCategory": "IMMEDIATE_REPORT",
            "triglevel": 2
          },
          {
            "triggerType": "TIME_LIMIT",
            "triggerCategory": "IMMEDIATE_REPORT",
            "triglevel": 2
          },
          {
            "triggerType": "VOLUME_LIMIT",
            "triggerCategory": "IMMEDIATE_REPORT",
            "triglevel": 2
          }
        ]
      },
      "partialRecordMethod": "PartialRecordMethod_DEFAULT"
    },
    "qbcChargParam": [
      {
        "chargingId": "qfi1",
        "qfi": 1,
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingParam": "True",
        "limitParam": "True",
        "parent": "True"
      },
      {
        "chargingId": "qfi2",
        "qfi": 2,
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingParam": "True",
        "limitParam": "True",
        "parent": "True"
      }
    ],
    "chfGroupId": "CHF-dnn=intershat;",
    "fbcChargingEnabled": "True"
  },
  "upfServData": {
    "numberOfTunnels": 1,
    "smfSeid": 9007228892966842,
    "qerInfo": [
      {
        "qosId": "Sess#Level",
        "qerId": 1,
        "refcnt": 1
      },
      {
        "qosId": "QoS-1@def#TC",
        "qerId": 2,
        "refcnt": 1
      },
      {
        "qosId": "default@def#TC",
        "qerId": 3,
        "refcnt": 1
      }
    ],
    "urrInfo": [
      {
        "chargingId": "ChargingData-1",
        "urrId": 16
      },
      {
        "chargingId": "l10of",
        "urrId": 33
      },
      {
        "chargingId": "l10on",
        "urrId": 55
      },
      {
        "chargingId": "sesslevelurr",
        "urrId": 76
      },
      {
        "chargingId": "qfi1",
        "urrId": 82
      },
      {
        "chargingId": "qfi2",
        "urrId": 98
      }
    ],
    "mapping": {
      "tunnelMapping": [
        {
          "TunnelID": 1,
          "tunnelName": "gnbTunnel",
          "RemoteTeid": {
            "teID": 1001,
            "ipAddr": "209.165.200.241"
          }
        }
      ]
    },
    "upfSeid": "17293822569102704642",
    "TotalNumberOfPdrs": "4 (Ul:2 Dl:2)",
    "TotalNumberOfFars": 4,
    "TotalNumberOfQers": 3,
    "TotalNumberOfUrrs": 6
  }
}

Subscriber Session Details for Roaming-specific Information for hSMF

The show subscriber supi supi_id nf-service smf psid psid_value summary CLI command displays the detailed information about subscriber sessions for roaming-specific use case as hSMF.

[unknown] smf# show subscriber supi imsi-123456789012345 nf-service smfpsid 5 summary  
subscriber-details 
{
  "status": true,
  "genericInfo": {
    "supi": "imsi-310210789012346",
    "pduSessionId": 5,
    "pduSesstype": "Ipv4PduSession",
    "accessType": "3GPP_ACCESS",
    "dnn": "intershat",
    "plmnId": {
      "mcc": "310",
      "mnc": "560"
    },
    "allocatedIp": "209.165.200.240",
    "ratType": "NR",
    "sessTimeStamp": "2021-06-18 18:49:28.266245111 +0000 UTC",
    "authStatus": "Unauthenticated",
    "roamingStatus": "Roamer",
    "uePlmnId": {
      "mcc": "310",
      "mnc": "210"
    }
  },
  "policySubData": {
    "TotalDynamicRules": 2,
    "TotalFlowCount": 2,
    "TotalNonGBRFlows": 1,
    "TotalGBRFlows": 1,
    "pcfInteraction": "Pcf Interaction: ON",
    "ruleBase": "starent"
  },
  "chargingData": {
    "chargParmMapInfo": [
      {
        "chargingId": "ChargingData-1",
        "offlineConverted": "false"
      },
      {
        "chargingId": "l10of",
        "offlineConverted": "false"
      },
      {
        "chargingId": "l10on",
        "offlineConverted": "false"
      },
      {
        "chargingId": "sesslevelurr",
        "offlineConverted": "false"
      }
    ],
    "chargingDisabled": "false",
    "dropTraffic": "false",
    "gtppGrp": "group1",
    "profileName": "chgprf1",
    "accountingEnabled": "false",
    "n40ChargingEnabled": "true",
    "QbcProfileName": "qbc_general",
    "qbcChargingEnabled": "True",
    "qbcChargParam": [
      {},
      {}
    ],
    "chfGroupId": "CHF-dnn=intershat;",
    "fbcChargingEnabled": "True"
  },
  "upfServData": {
    "smfSeid": 9007228892966842,
    "qerInfo": [
      {
        "qosId": "Sess#Level",
        "qerId": 1,
        "refcnt": 1
      },
      {
        "qosId": "QoS-1@def#TC",
        "qerId": 2,
        "refcnt": 1
      },
      {
        "qosId": "default@def#TC",
        "qerId": 3,
        "refcnt": 1
      }
    ],
    "urrInfo": [
      {
        "chargingId": "ChargingData-1",
        "urrId": 16
      },
      {
        "chargingId": "l10of",
        "urrId": 33
      },
      {
        "chargingId": "l10on",
        "urrId": 55
      },
      {
        "chargingId": "sesslevelurr",
        "urrId": 76
      },
      {
        "chargingId": "qfi1",
        "urrId": 82
      },
      {
        "chargingId": "qfi2",
        "urrId": 98
      }
    ],
    "mapping": {
      "tunnelMapping": [
        {
          "TunnelID": 1,
          "tunnelName": "gnbTunnel",
          "RemoteTeid": {
            "teID": 1001,
            "ipAddr": "209.165.200.231"
          }
        }
      ]
    },
    "upfSeid": "17293822569102704642",
    "TotalNumberOfPdrs": "4 (Ul:2 Dl:2)",
    "TotalNumberOfFars": 4,
    "TotalNumberOfQers": 3,
    "TotalNumberOfUrrs": 6
  }
}

Subscriber Details for Roaming-specific Information for vSMF

The show subscriber supi supi_id nf-service smf psid psid_value full CLI command displays the detailed subscriber information for roaming-specific use case as vSMF.

[unknown] smf# show subscriber supi imsi-123456789012345 nf-service smf psid 5 full  
subscriber-details 
{
  "status": true,
  "genericInfo": {
    "supi": "imsi-310480789012346",
    "pei": "imei-123456786666660",
    "pduSessionId": 5,
    "pduSesstype": "Ipv4PduSession",
    "accessType": "3GPP_ACCESS",
    "dnn": "intershat",
    "plmnId": {
      "mcc": "310",
      "mnc": "260"
    },
    "uetimeZone": "UTC+12:00",
    "allocatedIp": "209.165.202.131",
    "nrLocation": {
      "ncgi": {
        "mcc": "310",
        "mnc": "260",
        "nrCellId": "123456789"
      },
      "tai": {
        "mcc": "310",
        "mnc": "260",
        "tac": "1820"
      }
    },
    "alwaysOn": "None",
    "dcnr": "None",
    "wps": "Non-Wps Session",
    "ratType": "NR",
    "ueType": "NR Capable UE",
    "sessTimeStamp": "2021-06-18 18:55:11.252750658 +0000 UTC",
    "callDuration": "42.336122162s",
    "commonId": 2097159,
    "snssai": {
      "sd": "Abf123",
      "sst": 2
    },
    "authStatus": "Unauthenticated",
    "roamingStatus": "Vistor HR",
    "uePlmnId": {
      "mcc": "310",
      "mnc": "480"
    }
  },
  "accessSubData": {
    "amfID": "AFbe08",
    "amfPlmnId": {
      "mcc": "310",
      "mnc": "260"
    },
    "ueCmStatus": "UeCMConnected",
    "amfNrfID": "76517361-338e-4d77-bc76-713a79779574",
    "epsInterworkingIndication": "WITHOUT_N26"
  },
  "policySubData": {
    "TotalFlowCount": 2,
    "TotalNonGBRFlows": 1,
    "TotalGBRFlows": 1,
    "qosFlow": [
      {
        "qfi": 1,
        "GBRFlow": "False",
        "bindingParameters": {
          "x5Qi": 5,
          "arp": {
            "preemptCap": "NOT_PREEMPT",
            "preemptVuln": "NOT_PREEMPTABLE",
            "priorityLevel": 1
          },
          "priorityLevel": 10,
          "maximumDataBurstVolume": 1,
          "averagingWindow": "2003"
        }
      },
      {
        "qfi": 4,
        "GBRFlow": "True",
        "bindingParameters": {
          "x5Qi": 4,
          "arp": {
            "preemptCap": "NOT_PREEMPT",
            "preemptVuln": "NOT_PREEMPTABLE",
            "priorityLevel": 1
          },
          "priorityLevel": 1,
          "maximumDataBurstVolume": 1,
          "averagingWindow": "1"
        },
        "AggregatedULGFbr": 10000000,
        "AggregatedDLGFbr": 10000000,
        "AggregatedULMFbr": 1000000000,
        "AggregatedDLMFbr": 1000000000,
        "ebi": 8
      }
    ],
    "SessAmbrUl": 200000000,
    "SessAmbrDl": 125000000
  },
  "chargingData": {
    "invcSeqNo": 3,
    "pduChId": 2097159,
    "ccId": "0",
    "chargingIdRtgGrpMapInfo": {},
    "chTriggerInfo": {},
    "chThresholdInfo": {
      "sessthresholdInformation": {}
    },
    "startTime": "2021-06-18T18:55:11Z",
    "chargingDisabled": "false",
    "dropTraffic": "false",
    "profileName": "chgprf1",
    "accountingEnabled": "false",
    "n40ChargingEnabled": "true",
    "QbcProfileName": "qbc_maxlimit",
    "qbcChargingEnabled": "True",
    "roamingQbcInfo": {
      "qfiTh": {
        "volTh": 40000,
        "durTh": 90
      },
      "qfis": {
        "rgTriggerInfo": [
          {
            "triggerType": "QOS_CHANGE",
            "triggerCategory": "IMMEDIATE_REPORT",
            "triglevel": 2
          },
          {
            "triggerType": "TIME_LIMIT",
            "triggerCategory": "IMMEDIATE_REPORT",
            "triglevel": 2
          },
          {
            "triggerType": "VOLUME_LIMIT",
            "triggerCategory": "IMMEDIATE_REPORT",
            "triglevel": 2
          }
        ]
      },
      "partialRecordMethod": "PartialRecordMethod_DEFAULT"
    },
    "qbcChargParam": [
      {
        "chargingId": "qfi1",
        "qfi": 1,
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingParam": "True",
        "limitParam": "True",
        "parent": "True"
      },
      {
        "chargingId": "qfi4",
        "qfi": 4,
        "meteringMthd": "MeteringMethod_DURATION_VOLUME",
        "reportingParam": "True",
        "limitParam": "True",
        "parent": "True"
      }
    ],
    "chfGroupId": "CHF-dnn=intershat;",
    "fbcChargingEnabled": "False"
  },
  "upfServData": {
    "numberOfTunnels": 1,
    "smfSeid": 9007233406673128,
    "qerInfo": [
      {
        "qosId": "Sess#Level",
        "qerId": 1,
        "refcnt": 1
      },
      {
        "qosId": "BQF_1",
        "qerId": 2,
        "refcnt": 1
      },
      {
        "qosId": "BQF_4",
        "qerId": 4,
        "refcnt": 1
      }
    ],
    "urrInfo": [
      {
        "chargingId": "qfi1",
        "urrId": 18
      },
      {
        "chargingId": "qfi4",
        "urrId": 50
      }
    ],
    "mapping": {
      "tunnelMapping": [
        {
          "TunnelID": 1,
          "tunnelName": "gnbTunnel",
          "RemoteTeid": {
            "teID": 5555,
            "ipAddr": "209.165.200.242"
          }
        }
      ]
    },
    "upfSeid": "17293822569102704642",
    "TotalNumberOfPdrs": "4 (Ul:2 Dl:2)",
    "TotalNumberOfFars": 4,
    "TotalNumberOfQers": 3,
    "TotalNumberOfUrrs": 2
  }
}

Subscriber Session Details for Roaming-specific Information for vSMF

The show subscriber supi supi_id nf-service smf psid psid_value summary CLI command displays the detailed information about subscriber sessions for roaming-specific use case as vSMF.

[unknown] smf# show subscriber supi imsi-123456789012345 nf-service smf psid 5 summary 
subscriber-details 
{
  "status": true,
  "genericInfo": {
    "supi": "imsi-310480789012346",
    "pduSessionId": 5,
    "pduSesstype": "Ipv4PduSession",
    "accessType": "3GPP_ACCESS",
    "dnn": "intershat",
    "plmnId": {
      "mcc": "310",
      "mnc": "260"
    },
    "allocatedIp": "209.165.200.231",
    "ratType": "NR",
    "sessTimeStamp": "2021-06-18 18:55:11.252750658 +0000 UTC",
    "authStatus": "Unauthenticated",
    "roamingStatus": "Vistor HR",
    "uePlmnId": {
      "mcc": "310",
      "mnc": "480"
    }
  },
  "policySubData": {
    "TotalFlowCount": 2,
    "TotalNonGBRFlows": 1,
    "TotalGBRFlows": 1,
    "SessAmbrUl": 200000000,
    "SessAmbrDl": 125000000
  },
  "chargingData": {
    "chargingDisabled": "false",
    "dropTraffic": "false",
    "profileName": "chgprf1",
    "accountingEnabled": "false",
    "n40ChargingEnabled": "true",
    "QbcProfileName": "qbc_maxlimit",
    "qbcChargingEnabled": "True",
    "qbcChargParam": [
      {},
      {}
    ],
    "chfGroupId": "CHF-dnn=intershat;",
    "fbcChargingEnabled": "False"
  },
  "upfServData": {
    "smfSeid": 9007233406673128,
    "qerInfo": [
      {
        "qosId": "Sess#Level",
        "qerId": 1,
        "refcnt": 1
      },
      {
        "qosId": "BQF_1",
        "qerId": 2,
        "refcnt": 1
      },
      {
        "qosId": "BQF_4",
        "qerId": 4,
        "refcnt": 1
      }
    ],
    "urrInfo": [
      {
        "chargingId": "qfi1",
        "urrId": 18
      },
      {
        "chargingId": "qfi4",
        "urrId": 50
      }
    ],
    "mapping": {
      "tunnelMapping": [
        {
          "TunnelID": 1,
          "tunnelName": "gnbTunnel",
          "RemoteTeid": {
            "teID": 5555,
            "ipAddr": "209.165.200.242"
          }
        }
      ]
    },
    "upfSeid": "17293822569102704642",
    "TotalNumberOfPdrs": "4 (Ul:2 Dl:2)",
    "TotalNumberOfFars": 4,
    "TotalNumberOfQers": 3,
    "TotalNumberOfUrrs": 2
  }
}

Roamer UE Alerts

This section describes the alerts supported for roamer UEs. These alerts can be enhanced per RAT based or as per the intent of the end user.

In-roamer UE Failure Threshold Alert

Use the following example to configure alerts related to In-roamer UE Failure Threshold.

alerts rules group RoamerUEs
 rule In-Roamer_SR
  expression "sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", roaming_status=\"visitor-lbo\", rat_type!=\"\", status=\"Success\"}[5m])) / sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", roaming_status=\"visitor-lbo\", rat_type!=\"\", status=\"attempted\"}[5m])) < 0.10"
  severity major
  type "Communications Alarm"
  annotation summary
   value "This alert is fired when the percentage of successful InRoamer is lesser than threshold"
  exit
exit

Out-roamer UE Failure Threshold Alert

Use the following example to configure alerts related to Out-roamer UE Failure Threshold.

rule Radius_Acct_Release_SR
   rule Out-Roamer_SR
  expression "sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", roaming_status=\"roamer\", rat_type!=\"\", status=\"Success\"}[5m])) / sum by (namespace) (increase(smf_service_stats{app_name=\"smf\", roaming_status=\"roamer\", rat_type!=\"\", status=\"attempted\"}[5m])) < 0.10"
  severity major
  type "Communications Alarm"
  annotation summary 
   value "This alert is fired when the percentage of successful InRoamer is lesser than threshold"
  exit
exit

Roamer UE Bulk Statistics

Use the following SMF service bulk statistics to monitor the failures or issues associated with Roamer UEs.

Table 15. Roamer UE
Bulk Statistics Name

Query

Description

4G_In-Roamers_Attempted

bulk-stats query 4G_In-Roamers_Attempted expression "sum(smf_service_stats {roaming_status='visitor-lbo', status='attempted',rat_type='EUTRA'}) by (namespace)" exit

4G_In-Roamers_Success

bulk-stats query 4G_In-Roamers_Success expression "sum(smf_service_stats {roaming_status='visitor-lbo', status='success',rat_type='EUTRA'}) by (namespace)" exit

4G_Out-Roamers_Attempted

bulk-stats query 4G_Out-Roamers_Attempted expression "sum(smf_service_stats {roaming_status='roamer', status='attempted',rat_type='EUTRA'}) by (namespace)" exit

4G_Out-Roamers_Success

bulk-stats query 4G_Out-Roamers_Success expression "sum(smf_service_stats {roaming_status='roamer', status='success',rat_type='EUTRA'}) by (namespace)" exit

5G_In-Roamers_Attempted

bulk-stats query 5G_In-Roamers_Attempted expression "sum(smf_service_stats {roaming_status='visitor-lbo', status='attempted',rat_type='NR'}) by (namespace)" exit

5G_In-Roamers_Success

bulk-stats query 5G_In-Roamers_Success expression "sum(smf_service_stats {roaming_status='visitor-lbo', status='success',rat_type='NR'}) by (namespace)" exit

5G_Out-Roamers_Attempted

bulk-stats query 5G_Out-Roamers_Attempted expression "sum(smf_service_stats {roaming_status='roamer', status='attempted',rat_type='NR'}) by (namespace)" exit

5G_Out-Roamers_Success

bulk-stats query 5G_Out-Roamers_Success expression "sum(smf_service_stats {roaming_status='roamer', status='success',rat_type='NR'}) by (namespace)" exit

WiFi_In-Roamers_Attempted

bulk-stats query WiFi_In-Roamers_Attempted expression "sum(smf_service_stats {roaming_status='visitor-lbo', status='attempted',rat_type='WLAN'}) by (namespace)" exit

WiFi_In-Roamers_Success

bulk-stats query WiFi_In-Roamers_Success expression "sum(smf_service_stats {roaming_status='visitor-lbo', status='success',rat_type='WLAN'}) by (namespace)" exit

WiFi_Out-Roamers_Attempted

bulk-stats query WiFi_Out-Roamers_Attempted expression "sum(smf_service_stats {roaming_status='roamer', status='attempted',rat_type='WLAN'}) by (namespace)" exit

WiFi_Out-Roamers_Success

bulk-stats query WiFi_Out-Roamers_Success expression "sum(smf_service_stats {roaming_status='roamer', status='success',rat_type='WLAN'}) by (namespace)" exit

Roaming Error Logs

This section provides the basic error conditions and logs that are captured to debug the failures for the roaming feature.

PLMN Validation Failure

The following example displays the error log for PLMN validation failure resulting into setting the roaming status as "none".

2021/01/06 15:25:18.630 smf-service [DEBUG] [genericinfo.go:1597] [smf-service.smf-app.subscriber] Set roaming status to 0
2021/01/06 15:25:18.630 smf-service [DEBUG] [genericinfo.go:2317] [smf-service.smf-app.subscriber]  Subscriber is %!s(uint32=0)
2021/01/06 15:25:18.630 smf-service [ERROR] [genericinfo.go:1082] [smf-service.smf-app.subscriber] PLMN validation failed
2021/01/06 15:25:18.630 smf-service [DEBUG] [subscriber_policy_config.go:187] [misc-lib.config.subscriber-policy] LookupParameters - {imsi-123456789012345 msisdn-223310101010101 imei-123456786666660  0 123 456 intershat}

Homer UE Status (Homer)

The following is an example of the generic logs for UE Roaming Status.

2021/01/06 15:04:39.146 smf-service [DEBUG] [genericinfo.go:1597] [smf-service.smf-app.subscriber] Set roaming status to 1
2021/01/06 15:04:39.146 smf-service [DEBUG] [genericinfo.go:2317] [smf-service.smf-app.subscriber]  Subscriber is %!s(uint32=1)
2021/01/06 15:04:39.146 smf-service [DEBUG] [subscriber_policy_config.go:187] [misc-lib.config.subscriber-policy] LookupParameters - {imsi-123456789012345 msisdn-9999988888 imei-352099001761480 Abf123 2 310 310 intershat}

Out-roamer UE Status (Roamer)

The following is an example of the generic logs for out-roamer UE status.

2021/01/06 16:11:02.710 smf-service [DEBUG] [genericinfo.go:1597] [smf-service.smf-app.subscriber] Set roaming status to 4
2021/01/06 16:11:02.710 smf-service [DEBUG] [genericinfo.go:2317] [smf-service.smf-app.subscriber]  Subscriber is %!s(uint32=4)
2021/01/06 16:11:02.710 smf-service [DEBUG] [subscriber_policy_config.go:187] [misc-lib.config.subscriber-policy] LookupParameters - {imsi-123456789012345

In-roamer UE Status (Visitor LBO)

The following is an example of the generic logs for in-roamer UE status.

2021/01/06 15:54:32.323 smf-service [DEBUG] [genericinfo.go:1597] [smf-service.smf-app.subscriber] Set roaming status to 2
2021/01/06 15:54:32.323 smf-service [DEBUG] [genericinfo.go:2317] [smf-service.smf-app.subscriber]  Subscriber is %!s(uint32=2)
2021/01/06 15:54:32.323 smf-service [DEBUG] [subscriber_policy_config.go:187] [misc-lib.config.subscriber-policy] LookupParameters - {imsi-123456789012345 msisdn-223310101010101 imei-123456786666660  0 310 310 intershat}