UDM Integration

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

SMF

Applicable Product(s) or Functional Area

SMI

Feature Default Setting

Enabled – Always-on

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

Added the N10 fail open support.

2023.04.0

First introduced.

2020.02.2

Feature Description

The Unified Data Management (UDM) is responsible for primarily storing the subscriber data, which SMF accesses for managing the user sessions on the network. The SMF explicitly subscribes to receive the notifications about the events that occur in the subscriber data such session terminate.

The N10 interface is between Unified Data Management (UDM) and SMF (Session Management Function). The UDM provides the following services to SMF via the Nudm interface:

  • Nudm_SubscriberDataManagement Service

  • Nudm_UEContextManagement Service

How it Works

This section describes how this feature works.

When the SMF skips UDM subscription, then it stops sending the following messages:

  • Fetch-Subscription during session establishment

  • Subscribe-for-Notification during session establishment

  • Unsubscribe-to-Notification during session release and when the UDCM receives the UECM messages

The SMF allows any dynamic changes to the UDM subscription skip configuration. That is, new value is applicable for the new session being established. The existing sessions continue to use the old values.

Configuring UDM

This section provides all the configurations related to UDM:

Configuring Options for Controlling SDM Messages

This section describes how to configure controlling Subscription Data Management (SDM) messages over the N10 interface.

Configuring RAT Type

To configure the RAT type with the local authorization under the DNN profile, use the following sample configuration:

config 
   profile dnn dnn_profile 
      authorization local rat-type [ nr | eutra | wlan ] 
      end

NOTES:

  • authorization local : This command skips the SDM messages for EPS sessions only. Upon configuring this command under the selected DNN profile, the SMF skips the UDM interaction for fetch subscription. The SMF uses the values received in the Create Session Request message. The SMF skips the UDM interaction to receive ‘Subscribe-for-Notifications’ from the UDM.

  • rat-type [ nr | eutra | wlan ] : This keyword skips the following SDM messages based on the specified RAT type.

    • udm subscription-fetch

    • subscribe-to-notifications

    • unsubscribe-to-notifications

    Upon configuring the RAT type with authorization local command in the selected DNN profile, then for sessions on that RAT-type, the SMF skips the UDM interaction for the following messages:

    • udm subscription-fetch during session establishment

    • subscribe-for-notifications during session establishment

    • unsubscribe-for-notifications during session release

  • no authorization local rat-type [ nr | eutra | wlan ] : Disables the local authorization under the DNN profile.

Configuration Verification

To verify the configuration, use the show running-config profile dnn dnn_profile_name command.

The output of this show command displays all the configurations including the RAT type information that is configured within the specified DNN profile. 

[smf] smf# show running-config profile dnn intershat
profile dnn intershat
network-element-profiles chf chf1
network-element-profiles amf amf1
network-element-profiles pcf pcf1
network-element-profiles udm udm1
charging-profile chgprf1
virtual-mac b6:6d:47:47:47:47
ssc-mode 2 allowed [ 3 ]
session type IPV6 allowed [ IPV6 ]
authorization local rat-type nr 
upf apn intershat
dcnr true
exit

Configuring Session Type

The SMF uses both subscription type data from UDM response and the session type configuration in DNN profile to allow or reject the call. The SMF selects the session type based on the initial look up of UE-requested PDN type in the UDM subscription data. Then, the SMF provisions session type for the session based on the selected session type and the session type configured in the DNN profile.

To configure the PDU session type in DNN profile, use the following sample configuration.

config 
   profile dnn dnnprofile 
      session type { IPV4 | IPV4V6 | IPV6 } allowed [ IPV4 | IPV4V6 | IPV6 ] 
      end

NOTES:

  • session type { IPV4 | IPV4V6 | IPV6 } allowed [ IPV4 | IPV4V6 | IPV6 ] : Specify the IP type for the PDU session. The allowed keyword allows you to specify two IP types other than the default session type.

  • The SMF uses this session type configuration to process the call. For example, if the UE requested type is IPv4 and the UDM subscription type is IPv4v6, the SMF selects IPv4 in the first pass and subsequently checks against the session type configuration. If the configured session type is IPv6, then the SMF rejects the call with a cause "#51 - PDU session type IPv6 only= IPV4 allowed".

  • If the IPAM configuration includes the IP address pool that is different from the finally selected PDU session type, the SMF rejects the call with a cause "#31 - request rejected, unspecified". For example, this cause value will be generated under the following conditions:

    • UeReq-PdnType = V4

    • UdmSubscription-PdnType = V4V6

    • SessionType-Config = V4V6

    • IP-Pool = V6

Configuration Verification

To verify the configuration, use the show running-config profile dnn dnn_profile_name command.

The output of this show command displays all the configurations including the session type information that is configured within the specified DNN profile. 

[smf] smf# show running-config profile dnn intershat
profile dnn intershat
network-element-profiles chf chf1
network-element-profiles amf amf1
network-element-profiles pcf pcf1
network-element-profiles udm udm1
charging-profile chgprf1
virtual-mac b6:6d:47:47:47:47
ssc-mode 2 allowed [ 3 ]
session type IPV6 allowed [ IPV6 ]
upf apn intershat
dcnr true
exit

Configuration to Disable Optional IEs

To disable optional IEs such as epdgInd and registrationTime attributes in the N10 Registration Request, use the following sample configuration: 


config 
   profile message-handling nf-type nf_ype 
      mh-profile mh_profile_name 
      service name type { nudm-ee | nudm-pp | nudm-sdm | nudm-ueau | nudm-uecm }  
      message type { UdmRegistrationReq | UdmSdmGetUESMSubscriptionData | UdmSdmSubscribeToNotification | UdmSdmUnsubscribeToNotification | UdmSubscriptionReq | UdmUecmRegisterSMF skip optional-ies [ epdgInd | registrationTime ] | UdmUecmUnregisterSMF } 
     exit 
  exit 
exit

NOTES:

  • mh-profile mh_profile_name : Specify the name of the message handling profile.

  • skip optional-ies [ epdgInd | registrationTime ] : Skips ePDG indication and registration time in the Registration Request.


    Note
    The skip optional-ies [ epdgInd | registrationTime ] command is available only with the UdmUecmRegisterSMF message.

N10 Fail Open on Converged Core

Table 3. Feature History
Feature Name

Release Information

Description

Minimizing SMF and UDM interactions on N10 interface through fail open support

 2023.04

With the fail open feature, the SMF supports the ignore and continue failure handling actions as well for the call during the N10 message failures. These failures include the UDM registration, Subscriber Fetch, and Subscribe to Notify for all RAT types.

Feature Description

This feature provides the following support:

  • Fail open—The SMF supports the ignore and continue failure handling actions as well for the call during the N10 message failures. These failures include the UDM registration, Subscriber Fetch, and Subscribe to Notify for all RAT types, which are LTE, NR and Wi-Fi.

    If the registration isn’t performed or failed during the session creation, then based on the configured failure handling action, the SMF performs the N10 registration during handover. The failure handling action can either be ignore or continue. If you haven’t configured the failure action to terminate the session, and the failure happens during handover, then SMF ignores the failure and continues with the handover procedure.

  • Interaction with SCP Model-D—If you have configured the SCP failure handling as continue or ignore, then the preceding failure handling is applicable. If you have configured the SCP failure handling as a fallback and a failure happens after the fallback, then the action that you configured under UDM failure handling is applicable.

Configuration-based Control of Subscription Messages

Feature Description

The Unified Data Management (UDM) is responsible for primarily storing the subscriber data, which SMF accesses for managing the user sessions on the network. The SMF explicitly subscribes to receive the notifications about the events that occur in the subscriber data such session terminate. When the SMF wants to stop receiving the notifications, it initiates the Unsubscribe-to-Notification messages to UDM. Upon receiving these messages, the UDM cancels the subscription by removing the notification subscription for the subscribed session.


Note

The SMF does not receive notification when the UDM-triggered subscription change is observed. However, for UDM-triggered session terminations, the SMF receives notifications from UDM.

How it Works

This section provides a overview of how the SMF and UDM communicate over the Unsubscribe-to-Notifications message:

  1. The NF, such as SMF, sends an Unsubscribe-to-Notifications request to the resource identified by the URI to the UDM. The SMF transacts the request to the UDM over the N10 interface. The Unsubscribe-to-Notifications request allows the SMF unsubscribe from notifications for a specific subscriber session. The SMF receives the URI details during the subscription creation process.

    The Unsubscribe-to-Notifications request contains the ‘SUPI’ and ‘subscriptionId’ in the URI.

  2. The UDM processes the request, and based on the response; it sends a response code to the SMF. For example, if the unsubscription is successful, then UDM sends 204 code. If the request is not processed, then the appropriate HTTP status code indicating the error is returned in the response body along with the additional error information.

  3. The SMF handles the timeout and failure that occurs when sending the Unsubscribe-to-Notifications messages to the UDM. In case the Unsubscribe-to-Notifications request fails, the SMF continues to purge the corresponding sessions.

    The Unsubscribe-to-Notification message is required for sessions that are hosted on the EUTRA network. Being on this network may not be a requirement for sessions that are released on the NR and WLAN network. For these access types, the SMF sends the UDM registration and deregistration messages that include subscription to notifications through implicit-unsubscribe during the deregistration.

Standards Compliance

The Support for the Unsubscribe-To-Notifications Messages feature complies with the following standards:

  • 3GPP TS 29.503 - 5G System; Unified Data Management Services

Call Flows

This section describes the call flow for the Unsubscribe-To-Notifications message support.

Unsubscribe-to-Notifications Call Flow

This section describes the call flow on how the SMF sends a request to the UDM to unsubscribe from notifications of data changes.

Figure 1. Unsubscribe-to-Notifications Communication with UDM
Table 4. Unsubscribe-to-Notifications Communication Call Flow Description

Step

Description

1

The NF service consumer, such as SMF, sends a request to the UDM to unsubscribe from notifications. By unsubscribing, the UDM no longer sends notifications to SMF when the data modifications occur in the respective subscriber session.

The NF service consumer sends a DELETE request to the resource identified by the URI. The NF service consumer receives the URI when the subscription gets created.

2a

If the deletion of request is successful, the UDM responds with "204 No Content".

2b

If the subscription is invalid, which can be due to an unknown subscriptionId value, then the HTTP status code "404 Not Found" is returned along with the additional error information in the response body (as part of the "ProblemDetails" element).

If the request is not processed, then the appropriate HTTP status code indicating the error is returned in the DELETE response body along with the additional error information.

OAM Support for the Unsubscribe-To-Notifications Messages

This section describes operations, administration, and maintenance information for this feature.

Statistics Support

The SMF maintains the following labels on the smf-rest-ep pod for monitoring the number of unsubscribe-to-notifications messages that are initiated towards UDM:

  • nfType – “udm”

  • messageDirection – “outbound”

  • apiName – “sdm_unsubscription_req”

  • nfUri – “nf_uri”

  • respStatus – “response_status”

  • rspCause – “response_cause”

Configuration-based Control of UDM Registration Messages

Table 5. Feature History
Feature Name

Release Information

Description

Configuration-based Control of UDM Registration Messages

 2024.01.2

SMF allows the user to ignore the UDM registration messages during the PDU setup and Wi-Fi attach procedures.

With this controlled UDM registrations, the interactions between SMF and UDM over the N10 interface are minimized to handle the message overload and attach failures on the N10 interface.

This feature introduces the new CLI command skip-n10-registration rat-type [ NR | WIFI | ALL ] in the DNN profile.

Default Setting: Disabled – Configuration Required

Feature Description

When the UE attach failures are caused by message overload on N10 interface, SMF ignores the UE registration messages from reaching the UDM. This feature optimizes the N10 interactions in the 5G and Wi-Fi network. You can configure this feature through the skip-n10-registration rat-type [ NR | WIFI | ALL ] CLI command.

How it Works

When you configure the skip-n10-registration rat-type [ NR | WIFI | ALL ] CLI command, SMF ignores the UDM registration during session creation in the 5G and Wi-Fi network. The handover between 5G and Wi-Fi fails because ePDG doesn't find the target SMF that was handling the session. If the UE registration fails during 5G or Wi-Fi attach and if the UDM failure handling template (FHT) is configured as continue or ignore, then SMF reattempts the registration during Wi-Fi-to 5G and 5G to Wi-Fi handovers.

Configuring Control for UDM Registration Messages

To control the UDM registration messages, use the following sample configuration:

config 
   profile dnn dnn_profile 
      skip-n10-registration rat-type [ NR | WIFI | ALL ] 
      exit

NOTES:

  • skip-n10-registration rat-type [ NR | WIFI | ALL ] : Specify the RAT type for which you want to ignore the UDM registration.

Session Management based on UDM Data Change Notification

Session management based on UDM data change notification

Table 6. Feature History
Feature Name

Release Information

Description

Session management based on UDM data change notification

 2025.01.0

With this feature, SMF terminates or continues the session on receiving the data change notification with REPLACE operation from Unified Data Management (UDM). This feature enables the User Equipment (UE) to avail new subscription changes.

This feature introduces a new event subscription-change in the existing Event Management Policy configuration.

Command Enhanced:

policy eventmgmt policy_eventmgmt_name priority priority_number event subscription-change

Default Setting: Disabled–Configuration Required

When there is a change in the subscriber data such as upgrading the data speed from 2 Mbps to 8 Mbps, UDM sends this data change notification with the changed attributes to SMF. SMF continues or terminates the session. When SMF terminates the session the new subscription value gets updated in the UE. When SMF continues the session, no action takes place in UE.

How SMF manages the session using UDM data change notification

When SMF receives UDM data change notification, SMF takes action based on user-defined configuration in the event management policy or the system-defined configuration. When SMF finds the user-defined configuration for subscription change in the event management policy, then SMF manages the session based on that configuration. Otherwise, SMF manages the session based on the system-defined configuration.

UDM data change notification includes the ModificationNotification with a list of NotifyItems. The NotifyItems includes the ChangeItem field with the following changed attributes:

  • Ambr

  • 3gppChargingCharacteristics

  • sscModes

  • Snssai

  • SubscribedDefaultQos

  • staticIpAddress

  • pduSessionTypes

The ChangeItem field includes the following parameters:

  • op—Indicates the type of operation that happens to the resource.


    Note
    SMF takes action only if the op attribute is set to REPLACE operation.

  • path—Contains the JSON pointer value which indicates the target location within the resource where the change is applied.


    Note
    SMF supports the UDM change notify path as empty (“”).

  • origValue—Indicates the original value at the target location. This attribute is present if the op attribute is of value MOVE, REPLACE, or REMOVE.

  • newValue—Indicates a new value at the target location. This attribute is present if the op attribute is of value ADD or REPLACE.


Note

On hSMF (home SMF), SMF continues the call on receiving the UDM change notification and performs no other action.

Manage session with user-defined configuration

These stages describe how SMF manages the session with user-defined configuration:

  1. When SMF receives the data change notification with the op attribute value set to REPLACE. SMF terminates or continues the session based on the user-defined action of the subscription-change event in the policy eventmgmt CLI command.

  2. If the action terminate is configured for the subscription-change event, SMF terminates the session and sends N1 cause as Reactivation-Require message to UE. The new subscription value gets updated in the UE. If the action continue is configured for the subscription-change event, SMF continues the session and changes are not updated in the UE.

For more information, refer to the Enable subscribtion change event in the event management policy section.

Manage session with system-defined configuration

These stages describe how SMF manages the session based on the system-defined configuration:

  1. When SMF receives the UDM data change notification that has origValue and newValue with op set to REPLACE operation in the ChangeItem field of NotifyItem, then SMF terminates or continues the session.

  2. On receiving the NotifyItems in the notification, SMF compares the origValue of the NotifyItem with its subscribed data.

  3. If the origValue matches the subscribed data, the SMF selects the relevant NotifyItem. Within the selected NotifyItem, the SMF compares the origValue with the newValue of the attributes. This comparison identifies which attribute is changed. Based on the changed attributes identified in the origValue and newValue comparison, the SMF decides whether to terminate or continue the session. When SMF terminates the session, the new subscription value is updated in the UE. When SMF continues the session, no action is taken.


Note

When SMF receives the data change notification without the origValue in the ChangeItem field of NotifyItem, then SMF continues the session and sends an error response 503 to UDM.

The SMF manages the session as shown in the following table:

Attribute

Condition

Action

Ambr

SMF does not compare the newValue and origValue of Ambr.

Continues the session and takes no action.
3gppChargingCharacteristics

Condition 1: If the newValue of ChargingCharacteristics is different from the origValue of ChargingCharacteristics.

Terminates the session.

Condition 2: If the newValue of ChargingCharacteristics is the same as the origValue of ChargingCharacteristics.

Continues the session and takes no action.

Snssai

Condition 1: If the newValue of Snssai has no sst and sd match or no sst match (in case when Snssai includes only sst) with the origValue.

Terminate the session.

Condition 2: If the newValue of Snssai has sst and sd match or sst match (in case when Snssai includes only sst) with the origValue.

Continues the session and takes no action.
SubscribedDefaultQos

SMF does not compare the newValue and origValue of SubscribedDefaultQos.

Continues the session and takes no action.
sscModes Only SSCmode1 is supported on SMF. If SSCmode1 is not preset on newValue, then the call is disconnected.

Terminates the session.

pduSessionTypes

Condition 1: If the newValue of pduSessionType is not the same or superset of origValue.

Terminate the session.

Condition 2: If the newValue of pduSessionType is the same of origValue.

Continues the session and takes no action.

staticIpAddress

Condition 1:If the newValue of staticIpAddress is not the same as of origValue.

Terminate the session.
Condition 2: If the newValue of staticIpAddress is the same as of origValue.

Continues the session and takes no action.

Enable subscription change event in the event management policy

Follow these steps to perform the user-defined configuration in the event management policy:

Procedure

Step 1

Configure the subscription change event

Step 2

Define rules and condition for subscription change event

Step 3

Configure action for subscription change event

Configure the subscription change event

Follow these steps to configure the subscription change event:

Procedure

Step 1

Enter the event management policy configuration mode.

policy eventmgmt policy_eventmgmt_name

Example:
[smf] smf# config 
[smf] smf(config)# policy eventmgmt em1

Step 2

Define the priority of the event management policy and then configure the subscription-change event, rule, and action name to be executed.

priority priority_number event event_name ruledef ruledef_name actiondef actiondef_name

Example:
[smf] smf(config-eventmgmt-em1 )# priority  16 event subscription change ruledef rd-udmDataChangeNotif  actiondef ad-udmDataChangeNotif

The valid priority range is from 1 to 65535. Both ruledef_name and actiondef_name are alphanumeric strings that can be between 1 and 63 characters long.

Step 3

Save and commit the configuration.

Example:
[smf] smf(config-eventmgmt-em1 ))# end

Step 4

[Optional] Use show running-config policy eventmgmt em1 command to verify if the subscription change is enabled.

Example:

smf] smf# show running-config policy eventmgmt em1 
Fri Dec  6  08:34:32.360 UTC+00:00
policy eventmgmt em1
priority 16 event subscription-change ruledef rd-udmDataChangeNotif actiondef ad-udmDataChangeNotif
exit

Define rules and condition for subscription change event

Follow these steps to define the rules and condition for the subscription change event.

Procedure

Step 1

Enter the policy rule management configuration mode.

policy rulemgmt policy_rulemgmt_name

Example:
[smf] smf# config 
[smf] smf(config)# policy rulemgmt rm1

Step 2

Specify the name of the ruledef to add to the policy.

ruledef ruledef_name

Example:
[smf] smf(config-rulemgmt-rm1 )# ruledef rd-udmDataChangeNotif

Step 3

Define the condition as any.

Example:
[smf] smf(config-ruledef-rd-udmDataChangeNotif )# condition any
The ruledef gets updated with this condition any.

Step 4

Save and commit the configuration.

Example:
[smf] smf(config-ruledef-rm1 ))# end

Step 5

[Optional] Use show running-config policy rulemgmt rm1 command to verify if the rules and conditions are defined.

Example:

smf] smf# show running-config policy rulemgmt rm1 
Fri Dec  6  08:34:32.360 UTC+00:00
policy rulemgmt rm1
 ruledef rd-udmDataChangeNotif
 condition any
 exit

Configure action for subscription change event

Follow these steps to configure the action.

Procedure

Step 1

Enter the action management policy configuration mode.

policy actionmgmt policy_actionmgmt_name

Example:
[smf] smf# config 
[smf] smf(config)# policy actionmgmt act1

Step 2

Specify the action definition policy and define the action attributes to be executed.

actiondef actiondef_name

Example:
[smf] smf(config-actionmgmt-act1 )# actiondef  ad-udmDataChangeNotif

Step 3

Specify the priority in which the actions are to be executed. Then, configure one of the following action:

  • terminate—Configure this action to terminate the session. Terminating the session enables to update the new subscription changes in the UE.

  • continue—Configure this action to continue the session.

priority priority_number action action_name

Example:
[smf] smf(config-actiondef-act1 )# priority  12 action terminate-session
The action is configured. Configuring this action enables SMF to decide either to terminate or continue the session.

Step 4

Save and commit the configuration.

Example:
[smf] smf(config-actiondef-act1 )# end

Step 5

[Optional] Use show running-config policy actionmgmt act1 command to verify if the action is enabled.

Example:

[smf] smf# show running-config policy actionmgmt act1 
Fri Dec  6  08:34:32.360 UTC+00:00
policy actionmgmt act1
 actiondef ad-udmDataChangeNotif
  priority 1 action terminate-session
 exit

Sample configuration for subscription change event

This section provides the sample configuration to enable subscription change in the event management policy with appropriate rules and actions. 


policy eventmgmt em1-SynAndSemError
      priority 16 event subscription-change ruledef rd-udmDataChangeNotif actiondef ad-udmDataChangeNotif
exit
policy rulemgmt rm1
     ruledef rd-udmDataChangeNotif
     condition any
exit
policy actionmgmt act1
     actiondef ad-udmDataChangeNotif
     priority 1 action terminate-session
exit

Utilizing bulk statistics to manage session

Use these bulk statistics for managing session using the UDM data change notification.

  • UdmDataNotification: This label denotes the data change notification message.

  • disc_udm_subscription_change: This label is added under the Disconnect Stats category to denote the reason associated with the session disconnect based on UDM data change notification.

N10 UDM Registration Enhancement

Table 7. Feature History

Feature Name

Release Information

Feature Description

N10 UDM Registration Enhancement

2025.04.0

The N10 Registration Enhancement modifies the timing of N10 registration within the PDU setup / session creation call flow. This enhancement addresses changes introduced in later 3GPP releases, moving the N10 registration from an initial step to the final step in the call flow.

The N10 Registration Enhancement addresses a specific problem in 5G networks where the SMF needs to determine the correct slice for N10 registration.

The enhancement ensures that the SMF first obtains the subscribed slices from the UDM via an N10 subscription and then uses this information to perform N10 registration as the last step in the call flow. This is particularly relevant for UE's connecting via 5G/Wi-Fi Rat.

Command Introduced

profile dnn dnn-profile-name n10 delay-registration rat-type [ NR | WIFI | NR-REDCAP | all ]

Default Setting:

Disabled—Configuration required to enable the feature
What:

This feature modifies the N10 registration procedure, specifically changing its position in the PDU setup / session creation call flow from an early step to a later step

How:

Instead of sending N10 registration as the first message, the SMF (Session Management Function) first performs an N10 subscription to the UDM (Unified Data Management) to receive the subscribed slices. Once this information is obtained, the SMF proceeds with N10 registration, utilizing the correct subscribed slice. This behavior is controlled by a new configuration that can be enabled per Radio Access Technology (RAT) type.

Why:

The primary motivation for this enhancement is to resolve issues arising in scenarios where a 5G User Equipment (UE) attaches via WIFI RAT, and a PDU setup / create session request arrives without slice information. In earlier implementations, the SMF would have to populate a default slice value for N10 registration. This default might not match the UE's expectation, especially if a DNN (Data Network Name) is associated with multiple slices and different UEs require different slices. By delaying N10 registration, the SMF can first retrieve the actual subscribed slices from the UDM, ensuring the correct slice is used, thereby preventing potential service failures.

Information About N10 Registration Enhancement

The N10 Registration Enhancement addresses a specific problem in 5G networks where the SMF needs to determine the correct slice for N10 registration. In previous implementations, if a PDU setup / session create request (for example, GTP create) arrived without slice information, the SMF would use a default slice configuration. This could lead to mismatches if the UE expected a different slice. The enhancement ensures that the SMF first obtains the subscribed slices from the UDM via an N10 subscription, and then uses this information to perform N10 registration as the last step in the call flow. This is particularly relevant for 5G UEs connecting via WIFI RATs.

The N10 Registration Enhancement is configured within a DNN profile. It involves enabling a delay-registration option for specific RAT types or for all RAT types. 

profile dnn <dnn profile name>
    n10
        delay-registration rat-type [NR|WIFI|NR-REDCAP|all]
    exit
exit

Support for 'expires' IE in N10 Subscription Notification Response

SMF supports “expires” in subscription to notification response. SMF starts a timer for expires duration. SMF sends subscription to notification request on timer expiry.

Call Flows

Figure 2. 5G PDU setup / Session Creation
Figure 3. Wi-Fi Access Registration

Benefits of N10 Registration Enhancement

  • Improved Slice Selection Accuracy:

    Ensures that the SMF uses the correct subscribed slice during N10 registration, preventing issues caused by default slice assignments.

  • Enhanced Compatibility:

    Aligns the N10 registration process with later 3GPP release specifications.

  • Flexible Configuration:

    Allows operators to configure UE subscriptions with different slices, and the SMF will pick the appropriate one.

  • Scenario-Specific Control:

    The feature can be enabled per RAT type, providing granular control over its application.

Supported Scenarios

  • 5G UE attaching via WIFI RAT:

    This feature is specifically designed to address scenarios where a 5G UE connects through a WIFI Radio Access Technology and the PDU setup / create session request does not include slice information.

  • Flexible RAT Type Application:

    The configuration allows enabling the feature for specific RAT types such as NR, WIFI, NR-REDCAP, or for all RAT types.

Prerequisites for N10 Registration Enhancement

  • Single Slice Configuration for UE Subscription:

    For use cases where the SMF needs to pick a specific slice, it is required to have only a single slice configured in the UE subscription to avoid the SMF randomly picking one if multiple slices are present.

  • Runtime Enablement:

    The configuration for this feature can be enabled at runtime and will take effect for new PDU setup / session creation procedures.

  • Subscription Fetch Enabled (for optimal behavior):

    If N10 registration is delayed and subscription fetch is disabled, the SMF will revert to using its existing mechanism to select the slice.

Restrictions for N10 Registration Enhancement

  • UDM 'expires' IE Capping:

    For refreshing subscription-change-notification, if the UDM sends an 'expires' Information Element (IE) with a value greater than 7 days (168 hours), the SMF will cap this value to 7 days.

  • Non-Applicable Scenarios:

    N10 registration is not explicitly done in the following scenarios, and the existing call flow remains unchanged:

    • UE coming via 4G RAT

    • Unauthenticated IMSI

    • IMEI based call

    • When "Skip N10 registration" configuration is enabled.

Configure N10 Registration Enhancement

o configure the N10 Registration Enhancement, you will access the DNN profile configuration and enable the delay-registration option for the desired RAT types.

  1. Access the DNN Profile:

    Enter the configuration mode for your specific DNN profile.

    profile dnn <dnn profile name>

    Replace <dnn profile name> with the actual name of the Data Network Name profile that you wish to configure.

  2. Enter N10 Configuration:

    Navigate to the N10-specific configuration within the DNN profile.

    n10
  3. Enable Delayed Registration:

    Configure the delay-registration option and specify the RAT type(s) for which this behavior should apply.

    Copy Code
            delay-registration rat-type [NR|WIFI|NR-REDCAP|all]

    • Choose NR for New Radio.

    • Choose WIFI for Wi-Fi access.

    • Choose NR-REDCAP for NR-Reduced Capability.

    • Choose all to apply the delayed registration behavior to all supported RAT types.

  4. Exit Configuration Modes:

    Exit the N10 and DNN profile configuration modes.

    exit

To enable delayed N10 registration for WIFI RAT type in a DNN profile named internet_dnn: 

profile dnn internet_dnn
    n10
        delay-registration rat-type WIFI
    exit
exit

Monitor N10 Registration Enhancement

After configuring the N10 Registration Enhancement, you can monitor its activity through specific statistics related to UDM message processing.

  • N10 Subscription Request Statistics:

    Monitor the number of N10 subscription requests sent due to timer expiry. This indicates the SMF's proactive subscription behavior. Look for new procedure statistics related to N10 subscription requests.

  • UDM Message Processing Status:

    The udm_msg_processing_status statistics for UdmSubscribeToNotify messages includes a new label:sent_due_to_expires=true/false

  • Delayed N10 Registrations:

    UDM message processing metrics are enhanced to track the number of delayed N10 registrations. The udm_msg_processing_status statistics for UdmRegistration messages include a new label: delayed.

Metrics

The following is an example of metrics when this feature is enabled. 


udm_msg_processing_status{app_name="SMF",cluster="SMF",data_center="DC",delayed="true",
gr_instance_id="1",immediate_report="false",instance_id="0",msg_status="accepted",
rat_type="nr",sent_due_to_expires="false",service_name="smf-service",snssai="",
udm_end_point="",udm_msg="UdmRegistration"} 1

The delayed="true" field is added in this release.