5.6 Nudm_ParameterProvision Service

29.5033GPP5G SystemRelease 18Stage 3TSUnified Data Management Services

5.6.1 Service Description

See 3GPP TS 23.501 [2] table 7.2.5-1.

5.6.2 Service Operations

5.6.2.1 Introduction

For the Nudm_ParameterProvision service the following service operations are defined:

– Update

– Create

– Delete

– Get

The Nudm_ParameterProvision service is used by consumer NFs (e.g. NEF) to update a UE’s or a group of UEs’ subscription data by means of the Update service operation.

For details see 3GPP TS 23.502 [3] clause 4.15.6.2.

The Nudm_ParameterProvision service can also be used by a NF Service Consumer (e.g. SOR-AF) to send updated Steering of Roaming Information for a UE to the UDM at any time, as specified in Annex C.3 of 3GPP°TS°23.122°[20].

5.6.2.2 Update

5.6.2.2.1 General

The following procedures using the Update service operation are supported:

– Subscription data update

– SoR Information update

– 5G VN Group modification

– Parameter Provisioning Data Entry per AF update

5.6.2.2.2 Subscription data update

Figure 5.6.2.2.2-1 shows a scenario where the NF service consumer (e.g. NEF, AMF) sends a request to the UDM to update a UE’s subscription data (see 3GPP TS 23.502 [3] figure 4.15.6.2-1 step 2 and also 3GPP TS 23.273 [38] Figure 6.12.1-1 step 2). The request contains the identifier of the UE’s parameter provision data ( …/{ueId}/pp-data) and the modification instructions. The values ueId shall take are specified in Table 6.5.3.2.2-1.

Figure 5.6.2.2.2-1: NF service consumer updates subscription data

1. The NF service consumer (e.g. NEF, AMF) sends a PATCH request to the resource that represents a UE’s modifiable subscription data.

If MTC Provider information and/or AF ID are received in the request, the UDM shall check whether the MTC Provider and/or the AF is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider and/or AF authorization check.

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

2b. If MTC Provider or AF are not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

NOTE: Upon reception of an update or removal of maximum latency, maximum response time or DL Buffering Suggested Packet Count, UDM may need to adjust the value of active time and/or periodic registration timer and/or DL Buffering Suggested Packet Count and the UDM shall notify AMF and/or SMF if the values are updated (see clause 4.15.6.3a of 3GPP TS 23.502 [3]).

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.6.2.2.3 5G VN Group modification

Figure 5.6.2.2.3-1 shows a scenario where the NF service consumer sends a request to the UDM to modify an external group id’s group data. The request contains the external group identifier of the group and the modification instructions.

Figure 5.6.2.2.3-1: NF service consumer modifies a 5G VN Group

1. The NF service consumer sends a PATCH request to the resource that represents a 5G VN Group.

If MTC Provider information and/or AF ID are received in the request, the UDM shall check whether the MTC Provider and/or the AF is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider and/or AF authorization check.

2a. On success, the UDM responds with "204 No Content".

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

2c. If MTC Provider or AF are not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" 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 PATCH response body.

5.6.2.2.4 SoR Information update

Figure 5.6.2.2.4-1 shows a scenario where the NF service consumer (e.g. SOR-AF) sends updated SoR Information for a UE to the UDM to trigger the sending of this updated SoR Information to the UE via the AMF (as per Annex C.3 of 3GPP TS 23.122 [20]). The request contains the identifier of the UE’s parameter provision data ( …/{ueId}/pp-data), the SUPI in this case, and the modification instructions.

Figure 5.6.2.2.4-1: NF service consumer updates SoR Information for a UE

1. The NF service consumer (e.g. SOR-AF) sends a PATCH request to the resource that represents a UE’s modifiable subscription data, containing updated Steering of Roaming Information (i.e. new list of preferred PLMN/access technology combinations, the SOR-CMCI, if any, and the "Store the SOR-CMCI in the ME" indicator, if any, or a secured packet for a UE) for a UE.

The UDM, after contacting the AUSF to perform integrity protection and getting the related information (sorMacIausf and coutersor), shall immediately convey this updated SoR Information to the concerned UE by triggering a notification to the registered AMF (that has subscribed to receive notifications on change of AccessAndMobilitySubscriptionData) for the UE, if any, as per annex C.3 of 3GPP TS 23.122 [20]. Once the subscribing AMF is notified (or when no AMF has subscribed), the UDM shall delete the updated SorInfo and shall not send it as part of AccessAndMobilitySubscriptionData to an NF (e.g. AMF) retrieving the AccessAndMobilitySubscriptionData.

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

2b. If the operation cannot be authorized due to e.g UE isn’t registered in the network, 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 PATCH response body.

5.6.2.2.5 Parameter Provisioning Data Entry per AF update

Figure 5.6.2.2.5-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to update the Parameter Provisioning Data entry for a certain AF, which will influence the UE’s subscription data (see 3GPP TS 23.502 [3] figure 4.15.6.2-1 step 2 and also 3GPP TS 23.273 [38] Figure 6.12.1-1 step 2). The NF consumer shall send a PUT request towards the resource URI of an existing Parameter Provisioning Data entry for the AF (…/{ueId}/pp-data-store/{afInstanceId}) with the new value in the request body. The URI variants ueId and afInstanceId shall take values as specified in Table 6.5.3.4.2-1.

Figure 5.6.2.2.5-1: NF service consumer updates a Parameter Provisioning Data Entry per AF

1. The NF service consumer (e.g. NEF) sends a PUT request to the resource that represents an existing Parameter Provisioning Data entry for the AF identified by the afInstnaceId. The request body shall contain a PpDataEntry object representing the new value of the resource.

The UDM shall check whether the AF is allowed to perform this operation for the UE. If MTC Provider information is received in the request, the UDM shall check whether the MTC Provider is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider authorization check.

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

2b. If MTC Provider or AF are not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

NOTE: Upon reception of an update or removal of maximum latency, maximum response time or DL Buffering Suggested Packet Count, UDM may need to adjust the value of active time and/or periodic registration timer and/or DL Buffering Suggested Packet Count and the UDM shall notify AMF and/or SMF if the values are updated (see clause 4.15.6.3a of 3GPP TS 23.502 [3]).

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 as specified in table 6.5.3.4.3.1-3.

5.6.2.3 Create

5.6.2.3.1 General

The following procedures using the Create service operation are supported:

– 5G-VN-Group creation

– Parameter Provisioning Data Entry per AF creation

5.6.2.3.2 5G-VN-Group creation

Figure 5.6.2.3.2-1 shows a scenario where the NF service consumer sends a request to the UDM to create a 5G VN Group. The request contains the group’s external identifier and the group configuration.

Figure 5.6.2.3.2-1: NF service consumer creates a 5G-VN-Group

1. The NF service consumer sends a PUT request to the resource …/5g-vn-groups/{extGroupId}, to create a 5G VN Group as present in the message body.

If MTC Provider information and/or AF ID are received in the request, the UDM shall check whether the MTC Provider and/or the AF is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider and/or AF authorization check.

2a. On success the UDM responds with "201 Created".

2b. If the creation can’t be accepted (e.g. MTC Provider or AF are not allowed to perform this operation for the UE), 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.6.2.3.3 Parameter Provisioning Data Entry per AF creation

Figure 5.6.2.2.3-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to create the Parameter Provisioning Data entry for a certain AF, which will influence the UE’s subscription data (see 3GPP TS 23.502 [3] figure 4.15.6.2-1 step 2 and also 3GPP TS 23.273 [38] Figure 6.12.1-1 step 2). The NF consumer shall send a PUT request towards the resource URI of new Parameter Provisioning Data entry for the AF (…/{ueId}/pp-data-store/{afInstanceId}) with the new value in the request body. The URI variants ueId and afInstanceId shall take values as specified in Table 6.5.3.4.2-1.

Figure 5.6.2.3.3-1: NF service consumer creates a Parameter Provisioning Data Entry per AF

1. The NF service consumer (e.g. NEF) sends a PUT request to the resource that represents the new Parameter Provisioning Data entry for the AF identified by the afInstnaceId. The request body shall contain a PpDataEntry object representing the value of the new resource.

The UDM shall check whether the AF is allowed to perform this operation for the UE. If MTC Provider information is received in the request, the UDM shall check whether the MTC Provider is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider authorization check.

The UDM allocates an internal group identifier to the 5G VN Group. The UDM stores the external group identifier and the group configuration received from the NF service consumer together with the allocated internal group identifier (e.g. in UDR).

2a. The UDM responds with "201 Created" and the response body shall contain a PpDataEntry object representing the new created resource.

2b. If MTC Provider or AF are not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

NOTE: Upon reception of creation of maximum latency, maximum response time or DL Buffering Suggested Packet Count, UDM may need to adjust the value of active time and/or periodic registration timer and/or DL Buffering Suggested Packet Count and the UDM shall notify AMF and/or SMF if the values are updated (see clause 4.15.6.3a of 3GPP TS 23.502 [3]).

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 as specified in table 6.5.3.4.3.1-3.

5.6.2.4 Delete

5.6.2.4.1 General

The following procedures using the Delete service operation are supported:

– 5G-VN-Group deletion

– Parameter Provisioning Data Entry per AF deletion

5.6.2.4.2 5G-VN-Group deletion

Figure 5.6.2.4.2-1 shows a scenario where the NF service consumer sends a request to the UDM to delete a 5G VN Group. The request contains the group’s external identifier.

Figure 5.6.2.4.2-1: NF service consumer deletes a 5G-VN-Group

1. The NF service consumer sends a DELETE request to the resource …/5g-vn-groups/{extGroupId}, to delete the 5G VN Group identified by the external group id.

If MTC Provider information and/or AF ID are received in the request, the UDM shall check whether the MTC Provider and/or the AF is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider and/or AF authorization check.

2a. On success, the UDM responds with "204 No Content".

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

2c. If MTC Provider or AF are not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" 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 DELETE response body.

5.6.2.4.3 Parameter Provisioning Data Entry per AF deletion

Figure 5.6.2.4.3-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to delete a Parameter Provisioning Data Entry for a certain AF. The NF consumer shall send a DELETE request towards the resource URI of an existing Parameter Provisioning Data entry for the AF (…/{ueId}/pp-data-store/{afInstanceId}). The URI variants ueId and afInstanceId shall take values as specified in Table 6.5.3.4.2-1.

Figure 5.6.2.4.3-1: NF service consumer deletes a Parameter Provisioning Data Entry per AF

1. The NF service consumer sends a DELETE request to the resource … /{ueId}/pp-data-store/{afInstanceId}, to delete the Parameter Provisioning Data Entry for the AF identified by afInstanceId.

The UDM shall check whether the AF is allowed to perform this operation for the UE. If MTC Provider information is received in the request, the UDM shall check whether the MTC Provider is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider authorization check.

2a. On success, the UDM responds with "204 No Content".

2b. If the Parameter Provisioning Data Entry for the AF does not exist in the UDM, HTTP status code "404 Not Found" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

2c. If MTC Provider or AF are not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" 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 DELETE response body as specified in table 6.5.3.4.3.2-3.

5.6.2.5 Get

5.6.2.5.1 General

The following procedures using the Get service operation are supported:

– 5G-VN-Group get

– Parameter Provisioning Data Entry per AF get

5.6.2.5.2 5G-VN-Group get

Figure 5.6.2.5.2-1 shows a scenario where the NF service consumer sends a request to the UDM to get 5G VN Group. The request contains the group’s external identifier.

Figure 5.6.2.5.2-1: NF service consumer gets 5G-VN-Group

1. The NF service consumer sends a GET request to the resource …/5g-vn-groups/{extGroupId}, to get the 5G VN Group identified by the external group id.

2a. On success, the UDM responds with "200 Ok" with the VPN Group Information

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

2c. If the original AF is not allowed to get this information, HTTP status code "403 Forbidden" 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.6.2.5.3 Parameter Provisioning Data Entry per AF get

Figure 5.6.2.5.3-1 shows a scenario where the NF service consumer (e.g. NEF) sends a request to the UDM to get a Parameter Provisioning Data Entry for a certain AF. The NF consumer shall send a GET request towards the resource URI of an existing Parameter Provisioning Data entry for the AF (…/{ueId}/pp-data-store/{afInstanceId}). The URI variants ueId and afInstanceId shall take values as specified in Table 6.5.3.4.2-1.

Figure 5.6.2.5.3-1: NF service consumer gets a Parameter Provisioning Data Entry per AF

1. The NF service consumer sends a GET request to the resource …/{ueId}/pp-data-store/{afInstanceId}, to get the Parameter Provisioning Data Entry for the AF identified by afInstanceId.

The UDM shall check whether the AF is allowed to perform this operation for the UE. If MTC Provider information is received in the request, the UDM shall check whether the MTC Provider is allowed to perform this operation for the UE; otherwise, the UDM shall skip the MTC provider authorization check.

2a. On success, the UDM responds with "200 OK" with the Parameter Provisioning Data Entry for the AF.

2b. If the Parameter Provisioning Data Entry for the AF does not exist in the UDM, HTTP status code "404 Not Found" shall be returned including additional error information in the response body (in the "ProblemDetails" element).

2c. If MTC Provider or AF are not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" 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 as specified in table 6.5.3.4.3.3-3.