5.3.2 Service Operations

29.5033GPP5G SystemRelease 18Stage 3TSUnified Data Management Services

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.3.2.1 Introduction

For the Nudm_UEContextManagement service the following service operations are defined:

– Registration

– DeregistrationNotification

– Deregistration

– Get

– Update

– P-CSCF-RestorationNotification

– P-CSCF-RestorationTrigger

– AMFDeregistration

– PEI-Update

– DataRestorationNotification

– SendRoutingInfoForSM

The Nudm_UEContextManagement Service is used by Consumer NFs (AMF, SMF, SMSF, NWDAF) to register at the UDM by means of the Registration service operation.

It is also used by the registered Consumer NFs (AMF) to get notified by means of the DeregistrationNotification service operation when UDM decides to deregister the registered consumer NF.

It is also used by the registered Consumer NFs (AMF, SMF, SMSF, NWDAF) to deregister from the UDM by means of the Deregistration service operation.

It is also used by consumer NFs (NEF, NWDAF, NSSAAF, DCCF, SMF) to retrieve registration information from the UDM by means of the Get service operation.

It is also used by the registered Consumer NFs (AMF, SMF, NWDAF) to update registration information stored at the UDM by means of the Update service operation.

It is also used by the registered Consumer NFs (AMF, SMF) to get notified by means of the P-CSCF-RestorationNotification service operation when UDM detects the need for P-CSCF restoration.

It is also used by the consumer NF (HSS) to trigger P-CSCF restoration by means of the P-CSCF-RestorationTrigger service operation.

It is also used by the consumer NF (HSS) to trigger deregistration of the registered AMF for 3GPP access by means of the AMFDeregistration service operation

It is also used by the consumer NF (HSS) to update the stored PEI in e.g. the UDR, by means of the PEI-Update service operation.

It is also used by consumer NFs to retrieve NWDAF registration information from the UDM by means of the Get service operation.

It is also used by consumer NFs to retrieve addressing information for MT SMS delivery, e.g. addressing of the IP-SM-GW, SMS Router or SMSF serving nodes in both 3GPP and non-3GPP accesses, by means of the SendRoutingInfoForSM service operation.

5.3.2.2 Registration

5.3.2.2.1 General

The Registration service operation is invoked by a NF that has been selected to provide service to the UE to store related UE Context Management information in UDM.

NF Consumers are AMF for access and mobility management service, SMF for session management services, SMSF providing SMS services and HSS for IP-SM-GW registration in SMSoIP scenarios.

As part of this registration procedure, the UDM authorizes or rejects the subscriber to use the service provided by the registered NF, based on subscription data (e.g. roaming restrictions).

The following procedures using the Registration service operation are supported:

– AMF registration for 3GPP access

– AMF registration for non-3GPP access

– SMF registration

– SMSF registration for 3GPP access

– SMSF registration for non-3GPP access

– IP-SM-GW registration

– NWDAF registration

5.3.2.2.2 AMF registration for 3GPP access

Figure 5.3.2.2.2-1 shows a scenario where the AMF sends a request to the UDM to update the AMF registration information for 3GPP access (see also 3GPP TS 23.502 [3] figure 4.2.2.2.2-1 step 14). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and the AMF Registration Information for 3GPP access.

Figure 5.3.2.2.2-1: AMF registering for 3GPP access

1. The AMF sends a PUT request to the resource representing the UE’s AMF registration for 3GPP access to update or create AMF registration information.

If EPS interworking with N26 is supported, and the AMF has per DNN selected the PGW-C+SMF for EPS interworking, the AMF shall include the info of selected PGW-C+SMF to the UDM.

The AMF shall include ueReachableInd IE if the UE is currently not reachable (e.g. in not allowed areas) or the UE reachability is unknown (e.g. service restriction area of the UE is not received at the AMF during initial registration).

The AMF shall include the "backupAmfInfo" IE containing all of the GUAMI served by the AMF and the related backup AMF name if the AMF supports the AMF management without UDSF as specified in clause 6.5.2 of 3GPP TS 29.500 [4]. The "backupAmfInfo" IE is only applicable to this UE in 3GPP access.

2a. On success, the UDM updates the Amf3GppAccessRegistration resource by replacing it with the received resource information, and responds with "200 OK" or "204 No Content".

UDM shall invoke the Deregistration Notification service operation towards the old AMF using the callback URI provided by the old AMF.

When AMF indicates there are no ongoing event subscriptions, but UDM has ongoing event exposure subscriptions stored (e.g. in UDR), UDM shall invoke one Namf_EventExposure Subscribe Service operations (see clause 5.3.2.2 of 3GPP TS 29.518 [36]) on behalf of NEF per subscription stored.

If ueReachableInd IE is received indicating that the UE is not reachable, the UDM shall not trigger Reachability Report for the UE upon this UECM registration. The AMF shall subsequently generate UE Reachability Report when it detects the UE is reachable. If the If ueReachableInd IE is received indicating that the UE reachability is unknown, the UDM may trigger Reachability Report for the UE when needed based on operator policy.

2b. If the resource does not exist (there is no previous AMF information stored in UDM for that user), UDM stores the received AMF registration data for 3GPP access and responds with HTTP Status Code "201 created". A response body may be included to convey additional information to the NF consumer (e.g., features supported by UDM).

2c. If the operation cannot be authorized due to e.g UE does not have required subcription data, the AMF does not support CAG feature and the UE is allowed to access 5GS via CAG cell(s) only, access barring, roaming restrictions, core network restriction, or if an UE performs registration in an SNPN using credentials from the Credentials Holder, but it is not authorized to access the SNPN, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in "ProblemDetails" element).

NOTE: Clause 5.4.2.2 in 3GPP TS 29.505 [10] explains how an UDM determines if the UE, which performs registration in an SNPN using credentials from a Credentials Holder is authorized to access the specific SNPN.

2d. On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PUT response body.

5.3.2.2.3 AMF registration for non 3GPP access

Figure 5.3.2.2.3-1 shows a scenario where the AMF sends a request to the UDM to update the AMF registration information for non 3GPP access (see also 3GPP TS 23.502 [3] figure 4.2.2.2.2-1 step 14). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and the AMF Registration Information for non 3GPP access.

Figure 5.3.2.2.3-1: AMF registering for non 3GPP access

1. The AMF sends a PUT request to the resource representing the UE’s AMF registration for non 3GPP access to update or create AMF registration information.

2a. On success, the UDM updates the AmfNon3GppAccessRegistration resource by replacing it with the received resource information, and responds with "200 OK" or "204 No Content".

UDM shall invoke the Deregistration Notification service operation towards the old AMF using the callback URI provided by the old AMF.

2b. If the resource does not exist (there is no previous AMF information stored in UDM for that user), UDM stores the received AMF registration data for non-3GPP access and responds with HTTP Status Code "201 created". A response body may be included to convey additional information to the NF consumer (e.g., features supported by UDM).

2c. If the operation cannot be authorized due to e.g UE does not have required subcription data, the AMF does not support CAG feature and the UE is allowed to access 5GS via CAG cell(s) only, access barring, roaming restrictions or core network restriction, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PUT response body.

5.3.2.2.4 SMF registration

Figure 5.3.2.2.4-1 shows a scenario where an SMF sends a request to the UDM to create a new registration (see also 3GPP TS 23.502 [3] clause 4.3.2.2.1 step 16c and clause 4.26.5.3 step 11). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and the SMF Registration Information.

Figure 5.3.2.2.4-1: SMF registration

1. The SMF sends a PUT request to the resource …/{ueId}/registrations/smf-registrations/{pduSessionId}, to create an SMF Registration as present in the message body.

During SM Context Transfer procedure (see clause 4.26.5.3 of 3GPP TS 23.502 [3]) the SMF shall include registrationReason IE set to the value "SMF_CONTEXT_TRANSFERRED" in the message body.

If the SMF belongs to an SMF Set, the NF Set ID of the SMF Set shall be included in the request message.

If EPS interworking is supported, the SMF+PGW-C shall include the PCF ID selected for the PDU session to the UDM when the SMF+PGW-C register in the UDM.

2a. The UDM responds with "201 Created" with the message body containing a representation of the created SMF registration.

2b. If the individual resource exists, on success, the UDM updates the resource by replacing it with the received resource information, and responds with "200 OK" with the message body containing a representation of the updated Individual SmfRegistration resource.

If the new SMF is not in a SMF set or is not in the same SMF Set as the old SMF, the UDM shall invoke the Deregistration Notification service operation towards the old SMF using the callback URI provided by the old SMF.

2c. If the operation cannot be authorized due to e.g UE does not have required subscription data, access barring or roaming restrictions, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in "ProblemDetails" element). Subscription information associated to a specific DNN (if any) shall take precedence over subscription information associated to the Wildcard DNN.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PUT response body.

5.3.2.2.5 SMSF Registration for 3GPP Access

Figure 5.3.2.2.5-1 shows a scenario where the SMSF sends a request to the UDM to create or update the SMSF registration information for 3GPP access (see also 3GPP TS 23.502 [3], clause 4.13.3.1). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and the SMSF Registration Information for SMS service.

When a UE requests SMS service from both 3GPP access and Non-3GPP access, the SMSF shall perform seperate individual SMSF registration for each access type.

Figure 5.3.2.2.5-1: SMSF registering for 3GPP Access

1. The SMSF sends a PUT request to the resource representing the UE’s SMSF registration for 3GPP Access to update or create SMSF registration information.

If the SMSF supports SBI-based MT SM transmit, the "SBI support indication" of the SMSF shall be included in the SMSF registration information.

If the SMSF belongs to an SMSF Set, the NF Set ID of the SMSF Set shall be included in the request message.

2a. If successful, the UDM responds with "200 OK", or "201 Created" with the message body containing the representation of the SmsfRegistration.

2b. If the operation cannot be authorized due to e.g UE does not have required subcription data, access barring or roaming restrictions, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PUT response body.

5.3.2.2.6 SMSF Registration for Non 3GPP Access

Figure 5.3.2.2.6-1 shows a scenario where the SMSF sends a request to the UDM to create or update the SMSF registration information for non 3GPP access (see also 3GPP TS 23.502 [3], clause 4.13.3.1). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and the SMSF Registration Information for SMS service.

When a UE requests SMS service from both 3GPP access and Non-3GPP access, the SMSF shall perform seperate individual SMSF registration for each access type.

Figure 5.3.2.2.6-1: SMSF registering for Non 3GPP Access

1. The SMSF sends a PUT request to the resource representing the UE’s SMSF registration for Non 3GPP Access to update or create SMSF registration information.

If the SMSF supports SBI-based MT SM transmit, the "SBI support indication" of the SMSF shall be included in the SMSF registration information.

If the SMSF belongs to an SMSF Set, the NF Set ID of the SMSF Set shall be included in the request message.

2a. If successful, the UDM responds with "200 OK", or "201 Created" with the message body containing the representation of the SmsfRegistration.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PUT response body.

5.3.2.2.7 IP-SM-GW registration

Figure 5.3.2.2.7-1 shows a scenario where an HSS sends a request to the UDM to create a new registration of an IP-SM-GW (see also 3GPP TS 23.632 [32] figure 5.5.6.2.1-1 step 2). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and the IP-SM-GW registration information.

Figure 5.3.2.2.7-1: IP-SM-GW registration

1. The HSS sends a PUT request to the resource …/{ueId}/registrations/ip-sm-gw, to create an IP-SM-GW registration as present in the message body.

If the IP-SM-GW indicated support for SBI-based SMS when registering in HSS, "SBI Support Indication" shall be included in the IP-SM-GW registration information.

2a. If there was not a prior registration, the UDM responds with "201 Created" with the message body containing a representation of the created IP-SM-GW registration.

2b. If there was a prior registration, the UDM responds with "200 OK" with the message body containing a representation of the updated IP-SM-GW registration.

2c. If the operation cannot be authorized due to e.g UE does not have required subcription data, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PUT response body.

5.3.2.2.8 NWDAF registration

Figure 5.3.2.2.8-1 shows a scenario where an NWDAF sends a request to the UDM to create a new registration. The request contains the UE’s identity (/{ueId}) which shall be a SUPI, the NWDAF’s registration identity (/{nwdafRegistrationId}), and the NWDAF Registration Information.

Figure 5.3.2.2.8-1: NWDAF registration

1. The NWDAF sends a PUT request to the resource …/{ueId}/registrations/nwdaf-registrations/{nwdafRegistrationId}, to create an NWDAF Registration as present in the message body.

NOTE 1: nwdafRegistrationId could be the NfInstanceId, the combination of NfSetId and NfInstance ID or other identifier forms of the NWDAF. NWDAF implementation shall secure the global uniqueness of this resource ID.

2a. The UDM responds with "200 OK" or "201 Created" with the message body containing a representation of the created NWDAF registration.

2b. If the operation cannot be authorized due to e.g UE does not have required subcription data, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PUT response body.

5.3.2.3 DeregistrationNotification

5.3.2.3.1 General

The following procedure using the DeregistrationNotification service operation is supported:

– UDM initiated NF Deregistration

5.3.2.3.2 UDM initiated NF Deregistration

Figure 5.3.2.3.2-1 shows a scenario where the UDM notifies the registered NF about its deregistration (see also 3GPP TS 23.502 [3] figure 4.2.2.2.2-1 step 14, 3GPP TS 23.502 [3] figure 4.2.2.3.3-1 step 1 and 3GPP TS 23.502 [3] figure 4.26.4.1.1-1 step 14). The request contains the deregCallbackUri URI for deregistration notification as received by the UDM during registration, and Deregistration Data.

The UDM initiates the deregistration procedure when the UE is registered to the AMF which does not support CAG feature and the CAG subscription of the UE changes and it is allowed to access the 5GS via CAG cell(s) only.

The UDM also initiates deregistration notification when UE moves to different AMF within same AMF-Set.

The UDM may also initiate deregistration notification for the disaster inbound roaming UE when a disaster condition is no longer being applicable.

Deregistration notification shall not be sent if the nfInstanceId of the AMF initiating registration is same as the old AMF already registered in UDM (e.g. when multiple PLMNs are hosted on same AMF and UE moves across PLMNs).

The UDM also initiates the deregistration procedures towards the SMF of the old PDU session when a new PDU session has been established with the same PDU session ID from a different SMF, during SM Context Transfer procedure (see clause 4.26.5.3 of 3GPP TS 23.502 [3]) or when duplicated PDU sessions existing in the network (e.g. the AMF failed to release the old PDU session before creation of the new PDU session with the same PDU session ID).

Figure 5.3.2.3.2-1: UDM initiated NF Deregistration

1. The UDM sends a POST request to the deregCallbackUri as provided by the NF service consumer during the registration.

If the SMF deregistration is triggered by SM Context Transfer procedure, i.e. the UDM has received a registration request with registrationReason IE set to the value "SMF_CONTEXT_TRANSFERRED" from another SMF, the UDM shall set the deregReason IE to the value "SMF_CONTEXT_TRANSFERRED". If the SMF deregistration is due to duplicated PDU sessions in the network, i.e. the UDM has received a registration request from another SMF without registrationReason IE set to the value "SMF_CONTEXT_TRANSFERRED", the UDM shall set the deregReason IE to the value "DUPLICATE_PDU_SESSION".

If the SMF deregistration is due to an UDM-triggered PDU session release with re-activation, the UDM shall set the deregReason attribute in DeregistrationData to the value "PDU_SESSION_REACTIVATION_REQUIRED"; in this case, the SMF shall trigger a network-initiated PDU session release procedure (see clause 4.3.4 of 3GPP TS 23.502 [3]) with 5GSM cause "Reactivation requested" (see clause 8.3.14 of 3GPP TS 24.501 [27])

2a. On success, the NF service consumer responds with "204 No Content".

An SMF received the deregistration notification shall release the PDU session but shall not send a SM Context Status Notification to the AMF. For a PDU session with I-SMF or V-SMF, the anchor SMF shall send a Status Notification to the I-SMF or V-SMF indicating that the PDU session is released due to duplicated PDU sessions.

2b. On failure or redirection, one of the appropriate HTTP status code listed in Table 6.2.5.2-3 shall be returned. For a 4xx/5xx response, the message body may contain appropriate additional error information.

5.3.2.4 Deregistration

5.3.2.4.1 General

The following procedures using the Deregistration service operation are supported:

– AMF deregistration for 3GPP access

– AMF deregistration for non-3GPP access

– SMF deregistration

– SMSF deregistration for 3GPP access

– SMSF deregistration for non-3GPP access

– IP-SM-GW deregistration

– NWDAF deregistration

5.3.2.4.2 AMF deregistration for 3GPP access

Figure 5.3.2.4.2-1 shows a scenario where the AMF sends a request to the UDM to deregister (purge) from the UDM for 3GPP access (see also 3GPP TS 23.502 [3] figure 4.5.3.1-1 step 3). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and an instruction to set the purgeFlag within the Amf3GppAccessRegistration resource.

Figure 5.3.2.4.2-1: AMF deregistering for 3GPP access

1. The AMF sends a PATCH request to the resource representing the UE’s AMF registration for 3GPP access.

2a. The UDM shall check whether the received GUAMI matches the stored GUAMI. If so, the UDM shall set the PurgeFlag. The UDM responds with "204 No Content".

2b. Otherwise the UDM responds with "403 Forbidden".

NOTE: Based on operator policy, when AMF receives 403 Forbidden, the AMF can avoid freezing the 5G-TMSI that the UE used, under consideration that the UE has been assigned another 5G-TMSI by another AMF.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PATCH response body.

5.3.2.4.3 AMF deregistration for non-3GPP access

Figure 5.3.2.4.3-1 shows a scenario where the AMF sends a request to the UDM to deregister (purge) from the UDM for non-3GPP access (see also 3GPP TS 23.502 [3] figure 4.5.3.1-1 step 3). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and an instruction to set the purgeFlag within the AmfNon3GppAccessRegistration resource.

Figure 5.3.2.4.3-1: AMF deregistering for non-3GPP access

1. The AMF sends a PATCH request to the resource representing the UE’s AMF registration for non-3GPP access.

2a. The UDM shall check whether the received GUAMI matches the stored GUAMI. If so, the UDM shall set the PurgeFlag. The UDM responds with "204 No Content".

2b. Otherwise the UDM responds with "403 Forbidden".

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PATCH response body.

5.3.2.4.4 SMF deregistration

Figure 5.3.2.4.4-1 shows a scenario where the SMF sends a request to the UDM to deregister an individual SMF registration (see also 3GPP TS 23.502 [3] figure 4.3.2.2-1 step 20). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and the PDU Session ID (/{pduSessionId}.

Figure 5.3.2.4.4-1: SMF deregistration

1. The SMF sends a DELETE request to the resource representing the individual SMF registration that is to be deregistered.

2. The UDM responds with "204 No Content". If the SMF had requested the SDM Subscription to be created with the "implicitUnsubscribe" flag set, then UDM will terminate the SDM Subscription when the last PDU Session for that SUPI and SMF is deregistered.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the DELETE response body.

5.3.2.4.5 SMSF Deregistration for 3GPP Access

Figure 5.3.2.4.5-1 shows a scenario where the SMSF sends a request to the UDM to delete the SMSF registration information for 3GPP access (see also 3GPP TS 23.502 [3], clause 4.13.3.2). The request contains the UE’s identity (/{ueId}) which shall be a SUPI.

For a UE previously requests SMS service from both 3GPP access and Non-3GPP access, if SMS service is disabled from one access type, the SMSF shall only delete the corresponding SMSF registration for that access type. If SMS service is disabled from both 3GPP access and Non-3GPP access, the SMSF shall delete the SMSF registration for both access types.

Figure 5.3.2.4.5-1: SMSF Deregistering for 3GPP Access

1. The SMSF sends a DELETE request to the resource representing the UE’s SMSF registration for 3GPP access.

2. If successful, the UDM responds with "204 No Content".

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the DELETE response body.

5.3.2.4.6 SMSF Deregistration for Non 3GPP Access

Figure 5.3.2.4.6-1 shows a scenario where the SMSF sends a request to the UDM to delete the SMSF registration information for non 3GPP access (see also 3GPP TS 23.502 [3], clause 4.13.3.2). The request contains the UE’s identity (/{ueId}) which shall be a SUPI.

Figure 5.3.2.4.6-1: SMSF Deregistering for Non 3GPP Access

1. The SMSF sends a DELETE request to the resource representing the UE’s SMSF registration for non 3GPP access.

2. If successful, the UDM responds with "204 No Content".

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the DELETE response body.

5.3.2.4.7 IP-SM-GW deregistration

Figure 5.3.2.4.7-1 shows a scenario where the HSS sends a request to the UDM to deregister the IP-SM-GW from the UDM (see also 3GPP TS 23.632 [32] figure 5.5.X.2-2 step 2). The request contains the UE’s identity (/{ueId}) which shall be a SUPI.

Figure 5.3.2.4.7-1: IP-SM-GW deregistration

1. The HSS sends a DELETE request to the resource representing the UE’s IP-SM-GW registration.

2. The UDM responds with "204 No Content".

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the DELETE response body.

5.3.2.4.8 NWDAF deregistration

Figure 5.3.2.4.8-1 shows a scenario where the NWDAF sends a request to the UDM to deregister the NWDAF from the UDM. The request contains the UE’s identity (/{ueId}) which shall be a SUPI ,and the NWDAF’s registration identity (/{nwdafRegistrationId}).

Figure 5.3.2.4.8-1: NWDAF deregistration

1. The NWDAF sends a DELETE request to the resource representing the UE’s NWDAF registration.

2. The UDM responds with "204 No Content".

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the DELETE response body.

5.3.2.5 Get

5.3.2.5.1 General

The following procedures using the Get service operation are supported:

– Amf3GppAccessRegistration Information Retrieval

– AmfNon3GppAccessRegistration Information Retrieval

– SmfRegistrations Information Retrieval

– SmsfRegistration Information Retrieval for 3GPP Access

– SmsfRegistration Information Retrieval for Non-3GPP Access

– Location Information Retrieval

– Retrieval Of Multiple UE Registration Data Sets

– IP-SM-GW Registration Information Retrieval

– NwdafRegistration Information Retrieval

5.3.2.5.2 Amf3GppAccessRegistration Information Retrieval

Figure 5.3.2.5.2-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to retrieve the UE’s Amf3GppAccessRegistration Information. The request contains the UE’s identity (/{ueId}) which shall be a GPSI or SUPI, the type of the requested information (/registrations/amf-3gpp-access) and query parameters (supported-features).

Figure 5.3.2.5.2-1: Requesting a UE’s AMF Registration Information for 3GPP Access

1. The NF service consumer (e.g. NEF) sends a GET request to the resource representing the UE’s AMF registration information for 3GPP access, with query parameters indicating the supported-features.

2. The UDM responds with "200 OK" with the message body containing the UE’s Amf3GppAccessRegistration.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.3 AmfNon3GppAccessRegistration Information Retrieval

Figure 5.3.2.5.3-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to retrieve the UE’s AmfNon3GppAccessRegistration Information. The request contains the UE’s identity (/{ueId}) which shall be a GPSI or SUPI, the type of the requested information (/registrations/amf-non-3gpp-access) and query parameters (supported-features).

Figure 5.3.2.5.3-1: Requesting a UE’s AMF Registration Information for non-3GPP Access

1. The NF service consumer (e.g. NEF) sends a GET request to the resource representing the UE’s AMF registration information for non-3GPP access, with query parameters indicating the supported-features.

2. The UDM responds with "200 OK" with the message body containing the UE’s AmfNon3GppAccessRegistration.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.4 Void

5.3.2.5.5 SmsfRegistration Information Retrieval for 3GPP Access

Figure 5.3.2.5.5-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to retrieve the UE’s SmsfRegistration Information. The request contains the UE’s identity (/{ueId}) which shall be a GPSI, the type of the requested information (/registrations/smsf-3gpp-access) and query parameters (supported-features).

Figure 5.3.2.5.5-1: Requesting a UE’s SMSF Registration Information for 3GPP Access

1. The NF service consumer (e.g. NEF) sends a GET request to the resource representing the UE’s SMSF registration information for 3GPP access, with query parameters indicating the supported-features.

2a. The UDM responds with "200 OK" with the message body containing the UE’s SmsfRegistration for 3GPP access.

2b. If the UE does not have required subscription data for SMS service or SMS service is barred, HTTP status code "403 Forbidden" should be returned including additional error information in the response body (in "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.6 SmsfRegistration Information Retrieval for Non-3GPP Access

Figure 5.3.2.5.6-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to retrieve the UE’s SmsfRegistration Information for non-3GPPP access. The request contains the UE’s identity (/{ueId}) which shall be a GPSI, the type of the requested information (/registrations/smsf-non-3gpp-access) and query parameters (supported-features).

Figure 5.3.2.5.6-1: Requesting a UE’s SMSF Registration Information for Non-3GPP Access

1. The NF service consumer (e.g. NEF) sends a GET request to the resource representing the UE’s SMSF registration information for non-3GPP access, with query parameters indicating the supported-features.

2a. The UDM responds with "200 OK" with the message body containing the UE’s SmsfRegistration for non-3GPP access.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.7 SmfRegistration Information Retrieval

Figure 5.3.2.5.7-1 shows a scenario where the NF service consumer (e.g. NWDAF, SMF) sends a request to the UDM to retrieve the UE’s SmfRegistration Information. NF Service Consumer (e.g. SMF) may send request to UDM to retrieve SMF registration information to ensure the uniqueness of PDU Session ID if handover between EPS and EPC/ePDG. The request contains the UE’s identity (/{ueId}) which shall be a GPSI or SUPI, the type of the requested information (/registration/smf-registrations) and query parameters (single-nssai, dnn, supported-features).

Figure 5.3.2.5.7-1: Requesting a UE’s SMF Registration Information

1. The NF service consumer (e.g. NWDAF) sends a GET request to the resource representing the UE’s SMF registration information, with query parameters indicating the single-nssai, dnn, supported-features.

2a. The UDM responds with "200 OK" with the message body containing the UE’s SmfRegistrationInfo.

2b. If there is no valid SMF Registration data for the UE, HTTP status code "404 Not Found" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.8 Individual SmfRegistration Information Retrieval

NF Service Consumer (e.g. AMF) may send request to UDM to retrieve individual SMF registration information identified by PDU Session ID.

Figure 5.3.2.5.8-1: Requesting individual SMF Registration Information

1. The NF service consumer (e.g. AMF) sends a GET request to the resource representing the individual SMF registration information.

2a. The UDM responds with "200 OK" with the message body containing the SmfRegistration corresponding to the indicated PDU session.

2b. If there is no valid SMF Registration data for the indicated PDU session, HTTP status code "404 Not Found" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.9 Location Information Retrieval

Figure 5.3.2.5.9-1 shows a scenario where the NF service consumer (e.g. (H)GMLC) sends a request to the UDM to retrieve the UE’s Location Information. The request contains the UE’s identity (/{ueId}), which shall be a GPSI or SUPI, and query parameters (supported-features).

Figure 5.3.2.5.9-1: Requesting a UE’s Location Information

1. The NF service consumer (e.g. (H)GMLC) sends a GET request to the resource representing the UE’s Location information, with query parameters indicating the supported-features.

2a. The UDM responds with "200 OK" with the message body containing the UE’s LocationInfo.

The returned LocationInfo shall include the NF instance ID of the serving AMF ID, and may include the GUAMI of the serving AMF, the VGMLC address info.

2b. If there is no valid location information data for the UE, a response with HTTP status code "404 Not Found" shall be returned to the NF service including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.10 Retrieval Of Multiple UE Registration Data Sets

Figure 5.3.2.5.10-1 shows a scenario where the NF service consumer (e.g. HSS, NWDAF, NSSAAF) sends a request to the UDM to receive multiple UE registration data sets. In this example scenario the UE’s AMF registration data sets are retrieved with a single request; see clause 6.2.6.3.6 for other data sets that can be retrieved with a single request. The request contains the resource of UE’s registrations({ueId}/registrations) and query parameters identifying the requested registration data sets (in this example: ?registration-dataset-names=AMF_3GPP, AMF_NON_3GPP).

Figure 5.3.2.5.10-1: Retrieval of Multiple UE Registration Data Sets

1. The NF Service Consumer (e.g. HSS, NWDAF) sends a GET request to the resource representing the UE registrations. Query parameters indicate the requested UE registration data sets.

2. The UDM responds with "200 OK" with the message body containing the requested UE registration data sets. When not all requested data sets are available at the UDM, only the requested and available data sets are returned in a "200 OK" response.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.11 IP-SM-GW Registration Information Retrieval

Figure 5.3.2.5.11-1 shows a scenario where the NF service consumer sends a request to the UDM to retrieve the UE’s IP-SM-GW Registration Information. The request contains the UE’s identity (/{ueId}) which shall be a SUPI.

Figure 5.3.2.5.11-1: Requesting a UE’s IP-SM-GW Registration Information

1. The NF service consumer sends a GET request to the resource representing the UE’s IP-SM-GW registration information for 3GPP access.

2. The UDM responds with "200 OK" with the message body containing the UE’s IP-SM-GW Registration.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.5.12 NwdafRegistration Information Retrieval

Figure 5.3.2.5.12-1 shows a scenario where the NF service consumer (e.g. NWDAF) sends a request to the UDM to retrieve the UE’s NwdafRegistration Information. The request contains the UE’s identity (/{ueId}), which shall be a SUPI, the type of the requested information (/registrations/nwdaf-registrations) and query parameters (analyticsIds, supported-features).

Figure 5.3.2.5.12-1: Requesting a UE’s NwdafRegistration Information

1. The NF service consumer (e.g. NWDAF) sends a GET request to the resource representing the UE’s NwdafRegistration information, with query parameters indicating the analyticsIds, supported-features.

2a. The UDM responds with "200 OK" with the message body containing the UE’s NwdafRegistration(s).

NOTE: if there are multiple NwdafRegsitration for the same UE, all matched NwdafRegistration(s) will be returned.

2b. If there is no valid NwdafRegistration information data for the UE, a response with HTTP status code "404 Not Found" shall be returned to the NF service including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the GET response body.

5.3.2.6 Update

5.3.2.6.1 General

The following procedures using the Update service operation are supported:

– Update a parameter (e.g. PEI, EPS Interworking Info, etc) in the AMF registration for 3GPP access

– Update a parameter (e.g. PEI) in the AMF registration for non-3GPP access

– Update a parameter (e.g. analyticsId(s)) in the NWDAF registration

– Update a parameter (e.g. PGW FQDN) in the SMF registration

5.3.2.6.2 Update A Parameter (e.g. PEI) in the AMF Registration For 3GPP Access

Figure 5.3.2.6.2-1 shows a scenario where the AMF sends a request to the UDM to update a parameter within the Amf3GppAccessRegistration resource. The request contains the UE’s identity (/{ueId}) which shall be a SUPI and an instruction to modify a parameter (e.g. PEI).

Figure 5.3.2.6.2-1: AMF registration parameter update for 3GPP access

1. The AMF sends a PATCH request to the resource representing the UE’s AMF registration for 3GPP access.

If the AMF needs to modify the backupAmfInfo, the AMF shall include the IE in the PATCH request. The modified backupAmfInfo is only applicable to this UE in 3GPP access.

2a. If all the modification instructions in the PATCH request have been implemented, the UDM shall respond with "204 No Content" response.

2b. If some of the modification instructions in the PATCH request have been discarded, and the NF service consumer has included in the supported-feature query parameter the "PatchReport" feature number, the UDM shall respond with "200 OK" with the response body containing PatchResult.

2c. If the resource does not exist e.g. the UE is not registered yet, HTTP status code "404 Not Found" should be returned including additional error information in the response body (in the "ProblemDetails" element).

2d. If the resource exists, but the requesting AMF is not the one currently registered for the UE, HTTP status code "422 Unprocessable Entity" should be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PATCH response body.

5.3.2.6.3 Update A Parameter (e.g. PEI) in the AMF Registration For Non 3GPP Access

Figure 5.3.2.6.3-1 shows a scenario where the AMF sends a request to the UDM to update a parameter within the AmfNon3GppAccessRegistration resource. The request contains the UE’s identity (/{ueId}) which shall be a SUPI and an instruction to modify a parameter (e.g. PEI).

Figure 5.3.2.6.3-1: AMF registration parameter update for non-3GPP access

1. The AMF sends a PATCH request to the resource representing the UE’s AMF registration for non-3GPP access.

If the AMF needs to modify the backupAmfInfo, the AMF shall include the IE in the PATCH request. The modified backupAmfInfo is only applicable to this UE in non-3GPP access.

2a. If all the modification instructions in the PATCH request have been implemented, the UDM shall respond with "204 No Content" response.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PATCH response body.

5.3.2.6.4 Update A Parameter (e.g. analyticsId(s)) in the NWDAF Registration

Figure 5.3.2.6.4-1 shows a scenario where the NWDAF sends a request to the UDM to update a parameter within the NwdafRegistration resource. The request contains the UE’s identity (/{ueId}) which shall be a SUPI, the NWDAF’s registration identity (/{nwdafRegistrationId}) and an instruction to modify a parameter (e.g. analyticsId(s)).

Figure 5.3.2.6.4-1: NWDAF registration parameter update

1. The NWDAF sends a PATCH request to the resource representing the UE’s NWDAF registration.

2a. If all the modification instructions in the PATCH request have been implemented, the UDM shall respond with "204 No Content" response.

2b. If some of the modification instructions in the PATCH request have been discarded:

– the UDM shall respond with "200 OK" with the response body containing PatchResult, if the NF service consumer has included in the supported-feature query parameter the "PatchReport" feature number; or

– the UDM shall respond with "200 OK" with the response body containing NwdafRegistration, if the NF service consumer does not support the "PatchReport" feature.

2d. If the resource exists, but the requesting NWDAF is not the one currently registered for the UE, HTTP status code "422 Unprocessable Entity" should be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PATCH response body.

5.3.2.6.5 Update A Parameter (e.g. PGW FQDN) in the SMF Registration

Figure 5.3.2.6.5-1 shows a scenario where the SMF sends a request to the UDM to update a parameter within the SmfRegistration resource (see also clause 4.11.5.2 of 3GPP TS 23.502 [3]). The request contains the UE’s identity (/{ueId}) which shall be a SUPI and an instruction to modify a parameter (e.g. PGW FQDN).

Figure 5.3.2.6.5-1: SMF registration parameter update

1. The SMF sends a PATCH request to the resource representing the UE’s SMF registration …/{ueId}/registrations/smf-registrations/{pduSessionId}.

2a. On success, the UDM responds with "204 No Content" or "200 OK" shall be returned; in the latter case, the payload body of the PATCH response shall contain the PatchResult indicating that some of the modification instructions in the PATCH request have been discarded.

2b. If the resource does not exist, HTTP status code "404 Not Found" should be returned including additional error information in the response body (in the "ProblemDetails" element).

2c. If the resource exists, but the requesting SMF is not the one currently registered for the UE, HTTP status code "422 Unprocessable Entity" should be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the PATCH response body.

5.3.2.7 P-CSCF-RestorationNotification

5.3.2.7.1 General

The following procedure using the P-CSCF-RestorationNotification service operation is supported:

– UDM initiated P-CSCF-Restoration

5.3.2.7.2 UDM initiated P-CSCF-Restoration

Figure 5.3.2.7.2-1 shows a scenario where the UDM notifies the registered AMF or SMF about the need for P-CSCF restoration. The request contains the pcscfRestorationCallbackUri URI for P-CSCF restoration as received by the UDM during registration, and P-CSCF Restoration Indication.

Figure 5.3.2.7.2-1: UDM initiated P-CSCF Restoration

1. The UDM sends a POST request to the pcscfRestorationCallbackUri as provided by the NF service consumer during the registration.

2a. On success, the AMF or SMF responds with "204 No Content".

2b. On failure or redirection, one of the appropriate HTTP status code listed in Table 6.2.5.3-3 shall be returned. For a 4xx/5xx response, the message body may contain appropriate additional error information.

5.3.2.8 P-CSCF-RestorationTrigger

5.3.2.8.1 General

The following procedure using the P-CSCF-RestorationTrigger service operation is supported:

– P-CSCF-RestorationTrigger

5.3.2.8.2 P-CSCF-RestorationTrigger

Figure 5.3.2.8.2-1 shows a scenario where the HSS sends a request to the UDM to initiate P-CSCF restoration. The request contains the UE’s identity which shall be a SUPI.

Figure 5.3.2.8.2-1: P-CSCF-RestorationTrigger

1. The HSS sends a POST request (custom method: restore-pcscf) to the UDM.

2. The UDM responds with "204 No Content".

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body.

5.3.2.9 AMFDeregistration

5.3.2.9.1 General

The following procedure using the AMFDeregistration service operation is supported:

– AMF-Deregistration

5.3.2.9.2 AMF-Deregistration

Figure 5.3.2.9.2-1 shows a scenario where the HSS sends a request to the UDM to deregister the registered AMF. The request contains the UE’s identity which shall be an IMSI.

Figure 5.3.2.9.2-1: AMF-Deregistration

1. The HSS sends a POST request (custom method: dereg-amf) to the resource representing the UE’s registration for 3GPP access. This shall result in sending of Nudm_UECM_DeregistrationNotification to the AMF (see 3GPP TS 23.632 [32]) and setting the purgeFlag in the Amf3GppAccessRegistration stored in the UDR.

2a. The UDM responds with "204 No Content".

2b. If the user does not exist, HTTP status code "404 Not Found" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body.

5.3.2.10 PEI-Update

5.3.2.10.1 General

The following procedure using the PEI-Update service operation is supported:

– PEI Update

5.3.2.10.2 PEI Update

Figure 5.3.2.10.2-1 shows a scenario where the HSS sends a request to the UDM to update the PEI attribute in the 3GPP Access Registration context. The request contains the UE’s identity which shall be an IMSI.

Figure 5.3.2.10.2-1: PEI Update

1. The HSS sends a POST request (custom method: pei-update) to the resource representing the UE’s registration for 3GPP access. This shall result in the UDM updating the stored pei attribute in e.g. the UDR.

2a. The UDM responds with "204 No Content".

2b. If the user does not exist, HTTP status code "404 Not Found" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body.

5.3.2.11 Roaming Information Update

5.3.2.11.1 General

The following procedure using the Roaming-Info-Update service operation is supported:

– Roaming Information Update

5.3.2.11.2 Roaming Information Update

Figure 5.3.2.11.2-1 shows a scenario where the HSS sends a request to the UDM to update the Roaming Information Update in the 3GPP Access Registration context. The request contains the UE’s identity which shall be an IMSI.

Figure 5.3.2.11.2-1: Roaming Information Update

1. The HSS sends a POST request to the resource representing the UE’s Roaming information to update or create the Roaming Information.

2a. On success, the UDM updates the RoamingInfoUpdate resource by replacing it with the received resource information, and responds with "204 No Content".

2b. If the resource does not exist (there is no previous Roaming Information Update stored in UDM for the user, UDM stores the received Roaming Information Update and responds with HTTP Status Code "201 created" with the created Roaming Information Update.

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body.

5.3.2.12 DataRestorationNotification

5.3.2.12.1 General

The following procedure using the DataRestorationNotification service operation is supported:

– UDR-initiated Data Restoration

5.3.2.12.2 UDR-initiated Data Restoration

Figure 5.3.2.12.2-1 shows a scenario where the UDM notifies the NF Service Consumer (e.g., a registered AMF, SMF, SMSF) about the need to restore subscription-data due to a potential data-loss event occurred at the UDR. The request contains identities representing those UEs potentially affected by such event.

Figure 5.3.2.12.2-1: UDR-initiated Data Restoration

1. The UDM (after receiving a notification from UDR about a potential data-loss event) sends a POST request to the dataRestorationCallbackUri; such callback URI may be provided by the NF service consumer during the registration, or dynamically discovered by UDM by querying the NRF for the NF Profile of the NF Service Consumer.

2a. On success, the NF Service Consumer responds with "204 No Content".

2b. On failure or redirection, one of the appropriate HTTP status codes listed in Table 6.2.5.3-3 shall be returned. For a 4xx/5xx response, the message body may contain appropriate additional error information.

5.3.2.13 SendRoutingInfoForSM

5.3.2.13.1 General

The following procedure using the SendRoutingInfoForSM service operation is supported:

– Successful Mobile Terminated short message transfer as defined in 3GPP TS 23.540 [66] clause 5.1.2, clause 5.1.3 and clause 5.1.4.

– Unsuccessful Mobile Terminated short message transfer as defined in 3GPP TS 23.540 [66] clause 5.1.5, clause 5.1.6 and clause 5.1.9.

– GPSI-to-Subscription-Network resolution as defined in 3GPP TS 23.540 [66] clause 5.1.7.

5.3.2.13.2 Send Routing Information For SM

Figure 5.3.2.13.2-1 shows a scenario where the NF consumer (e.g. SMS-GMSC, HSS…) sends a request to the UDM to retrieve the addressing information for SMS delivery, e.g. addressing of the available SMSF nodes registered in the UDM.

Figure 5.3.2.13.2-1: Send Routing Info For SM

1. The NF Service Consumer sends a POST request (custom method: send-routing-info-sm) to the UDM. The request URI contains the UE’s identity ({ueId}). The request body may contain a list of features of the Nudm_UECM API supported by the NF Service Consumer, if any; otherwise, the request body may contain an empty JSON object.

2a. The UDM responds with "200 OK" with the message body containing a RoutingInfoSm data structure, including the addressing info of the nodes that are currently available to be used for sending SMS to the recipient UE, if any.

2b. If there is no node at UDM currently available to be used for sending SMS to the recipient UE, then the UDM responds with "404 Not Found" with the message body containing a ProblemDetails object, with a cause code indicating "ABSENT_SUBSCRIBER_SM".

2c. If the UE does not have required subscription data for SMS service or SMS service is barred, the UDM responds with HTTP status code "403 Forbidden", with the reponse body including a ProblemDetails object containing an application error indicating "SERVICE_NOT_PROVISIONED" or "SERVICE_NOT_ALLOWED".

On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body.