5.2 Nudsf_DataRepository Service

29.5983GPPRelease 18TSUnstructured data storage services

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

5.2.1 Service Description

The UDSF is acting as an NF Service Producer. It provides UDSF data repository service to the NF service consumer. Any NF may use the UDSF to store unstructured data.

NOTE 1: Structured data in this specification refers to data for which the structure is defined in 3GPP specifications. Unstructured data refers to data for which the structure is not defined in 3GPP specifications.

5.2.2 Service Operations

5.2.2.1 Introduction

For the Nudsf_DataRepository service, the following service operations are defined:

– Query

– Create

– Update

– Delete

– Notify

– Subscribe

– Unsubscribe

5.2.2.2 Query

5.2.2.2.1 General

The following procedures using the Query service operation are supported:

– Record Retrieval

– Meta Retrieval

– Blocks Retrieval

– Block Retrieval

– Search

– Subscriptions Retrieval

– Individual Subscription Retrieval

– Meta Schema Retrieval

5.2.2.2.2 Record Retrieval

Figure 5.2.2.2.2-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve a record that matches the provided recordId and optionally includes the query parameter supported-features.

Figure 5.2.2.2.2-1: Requesting a Record

1. The NF service consumer (any NF) sends a GET request to the resource indicated by recordId.

2a. On success, the UDSF responds with "200 OK" with the message body containing the record.

2b. If the record for the given recordId does not exist in the UDSF, the HTTP status code "404 Not Found" shall be returned optionally 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.2.2.2.3 Meta Retrieval

Figure 5.2.2.2.3-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve meta data associated with the provided recordId and optionally includes the query parameter supported-features.

Figure 5.2.2.2.3-1: Requesting Meta for a Record

1. The NF service consumer (any NF) sends a GET request to the meta resource associated with the record indicated by recordId.

2a. On success, the UDSF responds with "200 OK" with the message body containing the RecordMeta.

2b. If the record for the given recordId and thus the RecordMeta does not exist in the UDSF, the HTTP status code "404 Not Found" shall be returned optionally 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.2.2.2.4 Blocks Retrieval

Figure 5.2.2.2.4-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve (all) the blocks associated with the provided recordId and optionally includes the query parameter supported-features.

Figure 5.2.2.2.4-1: Requesting Blocks

1. The NF service consumer (any NF) sends a GET request to the resource indicated by recordId.

2a. On success, the UDSF responds with "200 OK" with the message body containing the Blocks associated with the record.

2b. If a Block for the given recordId does not exist in the UDSF, the HTTP status code "204 No Content" shall be returned.

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.2.2.2.5 Block Retrieval

Figure 5.2.2.2.5-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve a single block associated with the provided recordId and blockId and optionally includes the query parameter supported-features.

Figure 5.2.2.2.5-1: Requesting a Block

1. The NF service consumer (any NF) sends a GET request to the resource indicated by recordId and blockId.

2a. On success, the UDSF responds with "200 OK" with the message body containing the Block associated with the blockId.

2b. If the Block for the given recordId and blockId does not exist in the UDSF, the HTTP status code "404 Not Found" shall be returned optionally 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.2.2.2.6 Search

Figure 5.2.2.2.6-1 shows a scenario where the NF service consumer sends a request to the UDSF to search a record that matches the provided search criteria.

The request contains the query parameters filter and optionally supported-features, limit-range, and count-indicator, and if the CombinedSearchRetrieve feature is supported may contain the query parameters retrieve-records and max-payload-size. If the BulkOperations feature is supported, the query parameter filter may contain a list of record IDs identifying the records to be retrieved.

Figure 5.2.2.2.6-1: Searching for Records

1. The NF service consumer (any NF) sends a GET request to the Records resource with the filter query parameter indicating the search criteria.

2a. On success, the UDSF responds with "200 OK" with the message body containing the RecordSearchResult.

2b. If the UDSF is not able to return any record for the given search criteria, the HTTP status code "204 No Content" shall be returned.

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.2.2.2.7 Subscriptions Retrieval

Figure 5.2.2.2.7-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve all subscriptions associated with the provided storageId and optionally includes the query parameter supported-features and limit-range.

Figure 5.2.2.2.7-1: Requesting Subscriptions

1. The NF service consumer (any NF) sends a GET request to the resource indicated by the storageId.

2. On success, the UDSF responds with "200 OK" with the message body containing the NotificationSubscriptions associated with the storageId (if any).

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.2.2.2.8 Individual Subscription Retrieval

Figure 5.2.2.2.8-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve a subscription associated with the provided storageId and subscriptionId.

Figure 5.2.2.2.8-1: Requesting an Individual Subscription

1. The NF service consumer (any NF) sends a GET request to the resource indicated by the storageId and the subscriptionId.

2a. On success, the UDSF responds with "200 OK" with the message body containing the NotificationSubscription.

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.2.2.2.9 Meta Schema Retrieval

Figure 5.2.2.2.9-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve a meta schema that matches the provided schemaId and optionally includes the query parameter supported-features.

Figure 5.2.2.2.9-1: Requesting a Meta Schema

1. The NF service consumer (any NF) sends a GET request to the resource indicated by schemaId.

2a. On success, the UDSF responds with "200 OK" with the message body containing the meta schema.

2b. If the meta schema for the given schemaId does not exist in the UDSF, the HTTP status code "404 Not Found" shall be returned optionally 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.2.2.3 Create

5.2.2.3.1 General

The following procedures using the Create service operation are supported:

– Record Create

– Block Create

– Meta Schema Create

5.2.2.3.2 Record Create

Figure 5.2.2.3.2-1 shows a scenario where the NF service consumer sends a request to the UDSF to create a record with the provided recordId.

The request contains the recordId and optionally the query parameters supported-features and get-previous.

Figure 5.2.2.3.2-1: Create a Record

1. The NF service consumer (any NF) sends a PUT request to create the resource indicated by recordId. The request body contains the meta, zero or more blocks. The record meta information is mandatory and shall be the first part and the remaining parts of the request body (if any) shall be child blocks. If the record meta information is received with record expiry details, UDSF shall create an implicit subscription locally and notify the NF service consumer on record expiry.

2a. On success, "201 Created" shall be returned, the payload body of the PUT response should contain the representation of the created resource, and the "Location" header shall be present and shall contain the URI of the created resource.

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.2.2.3.3 Block Create

Figure 5.2.2.3.3-1 shows a scenario where the NF service consumer sends a request to the UDSF to create a block with the provided blockId.

The request contains the blockid and optionally the query parameters supported-features and get-previous.

Figure 5.2.2.3.3-1: Create a Block

1. The NF service consumer (any NF) sends a PUT request to create the resource indicated by blockId.

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.2.2.3.4 Meta Schema Create

Figure 5.2.2.3.4-1 shows a scenario where the NF service consumer sends a request to the UDSF to create a meta schema with the provided schemaId.

The request contains the schemaId and optionally the query parameters supported-features and get-previous.

Figure 5.2.2.3.4-1: Create a Meta Schema

1. The NF service consumer (any NF) sends a PUT request to create the resource indicated by schemaId. The request body contains the meta schema.

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.2.2.4 Update

5.2.2.4.1 General

The following procedures using the Update service operation are supported:

– Record Update

– Block Update

– Meta Update

– Subscription Notification Update

– Meta Schema Update

5.2.2.4.2 Record Update

Figure 5.2.2.4.2-1 shows a scenario where the NF service consumer sends a request to the UDSF to update a record with the provided recordId.

The request contains the recordId and optionally the query parameters supported-features and get-previous.

The update shall include meta, zero or more blocks. The record meta information shall be the first part and is mandatory and the remaining parts of the body (if any) shall be interpreted as child blocks. Existing record, meta and blocks shall be discarded and the new record, meta and blocks (if any) shall be created.

NOTE: The order of the returned blocks in the response is not guaranteed and can be different from the order used to create them.

Figure 5.2.2.4.2-1: Update a record

1. The NF service consumer shall send a PUT request to the resource representing the record that is to be updated, and may include meta, zero or more blocks. The record meta information is mandatory and shall be the first part and the remaining parts of the request body (if any) shall be child blocks. An existing record, i.e., meta and blocks shall be discarded and the new record, meta and blocks (if any) shall be created.

2a. On success, the UDSF shall respond with "204 No Content" if no record is returned, i.e. the get-previous query parameter was not included in the request.

2b. On success, the UDSF shall respond with "200 OK" if a record is returned, i.e. the get-previous query parameter was included in the request, or due to operator’s policy, the ttl value in the request exceeded the maximum value allowed.

2c. On failure, the UDSF shall respond with "412 Precondition Failed" if one or more conditions given in the request header fields evaluated to false. The RecordBody shall include the stored Record if the get-previous query parameter was included in the request.

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.2.2.4.3 Block Update

Figure 5.2.2.4.3-1 shows a scenario where the NF service consumer sends a request to the UDSF to update a block with the provided blockId.

The request contains the recordId, blockId and the optional query parameters supported-features, get-previous and the data that is to be updated.

Figure 5.2.2.4.3-1: Update a block

1. The NF service consumer shall send a PUT request to the resource representing the block that is to be updated.

2a. On success, the UDSF shall respond with "204 No Content" if no record is returned, i.e. the get-previous query parameter was not included in the request.

2b. On success, the UDSF shall respond with "200 OK" if a record is returned, i.e. the get-previous query parameter was included in the request.

2c. On failure, the UDSF shall respond with "412 Precondition Failed" if one or more conditions given in the request header fields evaluated to false. The BlockBody shall be included with the stored Block if the get-previous query parameter was included in the request.

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.2.2.4.4 Meta Update

Figure 5.2.2.4.4-1 shows a scenario where the NF service consumer sends a request to the UDSF to update the meta data associated with the provided recordId and optionally the query parameter supported-features and the data that is to be updated.

Figure 5.2.2.4.4-1: Update meta

1. The NF service consumer shall send a PATCH request to the resource representing the meta of the record.

2a. On success, if all the modification instructions in the PATCH request have been implemented, the UDSF shall respond with "204 No Content".

2b. On partial success, i.e. if one or more modification instructions have been discarded, "200 OK" with the execution report, shall be returned.

2c. On failure, the UDSF shall respond with "404 Not Found" if the record indicated by the recordId and thus the meta does not exist and may shall include the ProblemDetails.

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.2.2.4.5 Subscription Notification Update

Figure 5.2.2.4.5-1 shows a scenario where the NF service consumer sends a request to the UDSF to update the Individual Subscription Notification identified with the storageId and subscriptionId and optionally the query parameter supported-features and the data that is to be updated.

Figure 5.2.2.4.5-1: Update Subscription Notification

1. The NF service consumer shall send a PATCH request to the resource representing the subscriptionId.

2a. On success, if all the modification instructions in the PATCH request have been implemented, the UDSF shall respond with "204 No Content".

2b. On partial success, i.e. if one or more modification instructions have been discarded, "200 OK" with the execution report, shall be returned.

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.2.2.4.6 Subscription Notification Update using PUT

Figure 5.2.2.4.6-1 shows a scenario where the NF service consumer sends a request to the UDSF to update a subscription to notifications of data change using PUT. The request contains the subscriptionId and the NotificationSubscription and optionally the query parameter supported-features.

Figure 5.2.2.4.6-1: NF service consumer updates subscription to notifications

1. The NF service consumer sends a PUT request to the resource indicated by the storageId and the subscriptionId. The parameter clientId shall be included. If the resource indicated in URI exists and was created by the Client identified by the clientId, the UDSF shall apply the update of the subscription.

2a. On success, the UDSF shall respond with "200 OK" and include the updated NotificationSubscription. The expiry attribute of the received NotificationSubscription may indicate a value or a value different from the request, if due to an operator policy, an expiry time is enforced or if the value in the request exceeded a maximum allowed expiry time.

2b. On failure, if one or more monitoredResourceUris from the request don’t exist in the UDSF, 409 Conflict shall be returned together with the non-existing monitoredResourceUris.

2c. On failure, if the service operation cannot be authorized due to e.g. the resource indicated in URI exists but the clientId in the PUT request does not match the clientId of the existing resource, the UDSF shall respond with "403 Forbidden" and optionally 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.2.2.4.7 Meta Schema Update

Figure 5.2.2.4.7-1 shows a scenario where the NF service consumer sends a request to the UDSF to update a meta schema with the provided schemaId.

The request contains the schemaId, the complete new meta schema and optionally the query parameters supported-features and get-previous.

Figure 5.2.2.4.7-1: Update a meta schema

1. The NF service consumer shall send a PUT request to the resource representing the record that is to be updated, the request body shall include the complete new meta schema.

2a. On success, the UDSF shall respond with "204 No Content" if no meta schema is returned, i.e. the get-previous query parameter was not included in the request.

2b. On success, the UDSF shall respond with "200 OK" if a meta schema is returned, i.e. the get-previous query parameter was included in the request.

2c. On failure, the UDSF shall respond with "404 Not Found" if realm or storage does not exist.

2d On failure, the UDSF shall respond with "501 Not Implemented" if meta schema update is not implemented by the UDSF.

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.2.2.5 Delete

5.2.2.5.1 General

The following procedures using the Delete service operation are supported:

– Record Delete

– Block Delete

– Meta Schema Delete

– Bulk Records Delete

5.2.2.5.2 Record Delete

Figure 5.2.2.5.2-1 shows a scenario where the NF service consumer sends a request to the UDSF to Delete a record with the provided recordId.

The request contains the record id and optionally the query parameters supported-features and get-previous.

Figure 5.2.2.5.2-1: Delete a record

1. The NF service consumer shall send a DELETE request to the resource representing the record. The UDSF shall delete any resource associated with the resource (meta and block(s)).

2a. On success, the UDSF shall respond with "204 No Content" if no record is returned, i.e. the get-previous query parameter was not included in the request.

2b. On success, the UDSF shall respond with "200 OK" if a record is returned, i.e. the get-previous query parameter was included in the request.

2c. On failure, the UDSF shall respond with "404 Not Found" if the record does not exist and may include the ProblemDetails.

2d. On failure, the UDSF shall respond with "412 Precondition Failed" if one or more conditions given in the request header fields evaluated to false and the get-previous query parameter was included in the request. The RecordBody shall be included if the get-previous query parameter was included in the request.

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.2.2.5.3 Block Delete

Figure 5.2.2.5.3-1 shows a scenario where the NF service consumer sends a request to the UDSF to Delete a block with the provided blockId.

The request contains the recordId, blockId and optionally the query parameters supported-features and get-previous.

Figure 5.2.2.5.3-1: Delete a block

1. The NF service consumer shall send a DELETE request to the resource representing the block.

2a. On success, the UDSF shall respond with "204 No Content" if no block is returned, i.e. the get-previous query parameter was not included in the request.

2b. On success, the UDSF shall respond with "200 OK" if a block is returned, i.e. the get-previous query parameter was included in the request.

2c. On failure, the UDSF shall respond with "404 Not Found" if the block does not exist and may include the ProblemDetails.

2d. On failure, the UDSF shall respond with "412 Precondition Failed" if one or more conditions given in the request header fields evaluated to false. The BlockBody shall be included if the get-previous query parameter was included in the request.

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.2.2.5.4 Meta Schema Delete

Figure 5.2.2.5.4-1 shows a scenario where the NF service consumer sends a request to the UDSF to Delete a meta schema with the provided schemaId.

The request contains the schemaId and optionally the query parameters supported-features and get-previous.

Figure 5.2.2.5.4-1: Delete a meta schema

1. The NF service consumer shall send a DELETE request to the resource representing the meta schema.

2a. On success, the UDSF shall respond with "204 No Content" if no meta schema is returned, i.e. the get-previous query parameter was not included in the request.

2b. On success, the UDSF shall respond with "200 OK" if a meta schema is returned, i.e. the get-previous query parameter was included in the request.

2c. On failure, the UDSF shall respond with "404 Not Found" if the meta schema does not exist or "403 Forbidden" if the meta schema is still referenced by existing records, and may include the ProblemDetails.

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.2.2.5.5 Bulk Records Delete

Figure 5.2.2.5.5-1 shows a scenario where the NF service consumer sends a request to the UDSF to Delete records identified by a filter.

The request contains the query parameter filter and optionally the query parameter supported-features.

Figure 5.2.2.5.5-1: Delete records matching a filter

1. The NF service consumer shall send a DELETE request to the resource representing the records. The request shall contain a filter query parameter identifying the records to be deleted. The UDSF shall delete any resource associated with the matching records (meta and block(s)).

2a. On success, the UDSF shall respond with "200 OK" with the message body containing the RecordIdList identifying the deleted records.

2b. The UDSF shall respond with "204 No Content" if no records matching the filter could be found.

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.2.2.6 Notify

5.2.2.6.1 General

The following procedures using the Notify service operation are supported:

– Record Expiry Notify

– Notification due to Data Change

– Subscription Expiry Notification

5.2.2.6.2 Record Expiry Notify

Figure5.2.2.6.2-1 shows a scenario where the UDSF notifies the NF service consumer of the expired record.

The Notify is sent by the UDSF to the NF Service Consumer when the record expires as indicated by the time to live (ttl) attribute of RecordMeta.

Figure 5.2.2.6.2-1: Record Expiry Notify

1. The UDSF shall send a POST request to the callback URI. The request shall contain the record details.

2a. On success, "204 No content" shall be returned by the NF Service Consumer to UDSF.

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.2.2.6.3 Notification due to Data Change

Figure 5.2.2.6.3-1 shows a scenario where the UDSF notifies the NF service consumer of a change to data associated with a block or a record triggered by one or more a Subscription to Notification.

Figure 5.2.2.6.3-1: Notification due to Data Change

1. The UDSF shall send a POST request to the callback URI. The request shall contain the RecordNotification details.

2. On success, "204 No content" shall be returned by the NF Service Consumer to UDSF.

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.2.2.6.4 Subscription Expiry Notification

Figure 5.2.2.6.4-1 shows a scenario where the UDSF notifies the NF service consumer of an expired subscription to data change.

Figure 5.2.2.6.4-1: Subscription Expiry Notification

1. The UDSF shall send a POST request to the expiryCallbackReference URI. The request shall contain the NotificationInfo.

2. On success, "204 No content" shall be returned by the NF Service Consumer to UDSF.

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.2.2.7 Subscribe

5.2.2.7.1 General

The following procedures using the Subscribe service operation are supported:

– Subscription to notification of data change

5.2.2.7.2 Subscription to notifications of data change

Figure 5.2.2.7.2-1 shows a scenario where the NF service consumer sends a request to the UDSF to subscribe to notifications of data change. The request contains the subscriptionId, the NotificationSubscription and optionally the query parameter supported-features.

Figure 5.2.2.7.2-1: NF service consumer subscribes to notifications

1. The NF service consumer sends a PUT request to the resource indicated by the storageId and the subscriptionId. The parameter clientId shall be included. If the resource indicated in URI doesn’t exist, the UDSF shall trigger the creation of the subscription.

2a. On success, the UDSF responds with "201 Created"with the message body containing the NotificationSubscription. The expiry attribute of the received NotificationSubscription may indicate a value or a value different from the request, if due to an operator policy, an expiry time is enforced or if the value in the request exceeded a maximum allowed expiry time.

2b. On failure, if one or more monitoredResourceUris from the request don’t exist in the UDSF, 409 Conflict shall be returned together with the non-existing monitoredResourceUris.

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.2.2.8 Unsubscribe

5.2.2.8.1 General

The following procedures using the Unsubscribe service operation are supported:

– Unsubscription to notification of data change

5.2.2.8.2 Unsubscription to notifications of data change

Figure 5.2.2.8.2-1 shows a scenario where the NF service consumer sends a request to the UDSF to Unsubscribe to notifications of data change. The request contains the subscriptionId, and query parameter client-id, optionally query parameters supported-features and get-previous.

Figure 5.2.2.8.2-1: NF service consumer unsubscribes to notifications

1. The NF service consumer sends a DELETE request to the resource representing the subscription to notification of data change which is indicated by the subscriptionId.

2a. On success, the UDSF shall respond with "204 No Content" if an empty response body is returned, i.e. the get-previous query parameter was not included in the request.

2b. On success, the UDSF shall respond with "200 OK" with NotificationSubscription containing the NotificationSubscription value before the delete if get-previous was indicated in the request.

2c. If the service operation cannot be authorized due to e.g. the client-id query parameter does not match the clientId of the existing resource, the UDSF shall respond with "403 Forbidden" with including additional error information in the response body (in "ProblemDetails" element).

2d. If there is no valid subscription to notification of data change which is indicated by the request, the UDSF shall respond with "404 Not Found" with including additional error information in the response body (in "ProblemDetails" element).

2e. If one or more conditions given in the request header fields evaluated to false, the UDSF shall respond with "412 Precondition Failed". NotificationSubscription shall be included in the response if get-previous was indicated in the request.

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.