6 API Definitions

29.5983GPPRelease 18TSUnstructured data storage services

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

6.1 Nudsf_DataRepository Service API

6.1.1 Introduction

The Nudsf_DataRepository service shall use the Nudsf_DataRepository API.

The API URI of the Nudsf_DataRepository API shall be:

{apiRoot}/<apiName>/<apiVersion>/

The request URI used in HTTP requests from the NF service consumer towards the NF service producer shall have the Resource URI structure defined in clause 4.4.1 of 3GPP TS 29.501 [5], i.e.:

{apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>

with the following components:

– The {apiRoot} shall be set as described in 3GPP TS 29.501 [5].

– The <apiName> shall be "nudsf-dr".

– The <apiVersion> shall be "v1".

– The <apiSpecificResourceUriPart> shall be set as described in clause 6.1.3.

6.1.2 Usage of HTTP

6.1.2.1 General

HTTP/2, IETF RFC 7540 [11], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].

HTTP/2 shall be transported as specified in clause 5.3 of 3GPP TS 29.500 [4].

The OpenAPI [6] specification of HTTP messages and content bodies for the Nudsf_DataRepository API is contained in Annex A.

6.1.2.2 HTTP standard headers

6.1.2.2.1 General

See clause 5.2.2 of 3GPP TS 29.500 [4] for the usage of HTTP standard headers.

6.1.2.2.2 Content type

The following content types shall be supported:

– JSON, IETF RFC 8259 [12], shall be used as content type of the HTTP bodies specified in the present specification as specified in clause 5.4 of 3GPP TS 29.500 [4]. The use of the JSON format shall be signalled by the content type "application/json".

– "Problem Details" JSON object shall be used to indicate additional details of the error in a HTTP response body and shall be signalled by the content type "application/problem+json", as defined in IETF RFC 7807 [13].

– JSON Patch (IETF RFC 6902 [14]). The use of the JSON Patch format in a HTTP request body shall be signalled by the content type "application/json-patch+json".

Multipart messages shall also be supported possibly indicating other content-types as described in clause 6.1.2.4.

6.1.2.2.3 Cache-Control

As described in IETF RFC 7234 [17] clause 5.2, a "Cache-Control" header should be included in HTTP responses carrying a representation of cacheable resources. If it is included, it shall contain a "max-age" value, indicating the amount of time in seconds after which the received response is considered stale.

The "max-age" value shall be configurable by operator policy.

6.1.2.2.4 ETag

As described in IETF RFC 7232 [16] clause 2.3, an "ETag" (entity-tag) header should be included in HTTP responses carrying a representation of cacheable or modifiable resources to allow an NF Service Consumer performing a conditional GET request with an "If-None-Match" header or a conditional PUT/PATCH/DELETE request with an "If-Match" header. If it is included, it shall contain a server-generated strong validator, that allows further matching of this value (included in subsequent client requests) with a given resource representation stored in the server or in a cache.

6.1.2.2.5 If-None-Match

As described in IETF RFC 7232 [16] clause 3.2, an NF Service Consumer may issue conditional GET or PUT requests towards UDSF by including an "If-None-Match" header in HTTP requests containing one or several entity tags received in previous responses for the same resource.

If the If-None-Match header is included with the PUT method, it shall be used with a value of "*" to prevent the inadvertent modification of an existing representation of the target resource when the client believes that the resource does not have a current representation.

6.1.2.2.6 If-Match

As described in IETF RFC 7232 [16] clause 3.1, an NF Service Consumer may issue conditional PUT/PATCH/DELETE request towards UDSF by including an "If-Match" header in HTTP requests containing an entity tag received in previous responses for the same resource.

6.1.2.2.7 Last-Modified

As described in IETF RFC 7232 [16] clause 2.2, a "Last-Modified" header should be included in HTTP responses carrying a representation of cacheable resources to allow an NF Service Consumer performing a conditional request with "If-Modified-Since" header.

6.1.2.2.8 If-Modified-Since

As described in IETF RFC 7232 [16] clause 3.3, an NF Service Consumer may issue conditional GET request towards UDSF, by including an "If-Modified-Since" header in HTTP requests.

6.1.2.2.9 When to Use Entity-Tags and Last-Modified Dates

Both "ETag" and "Last-Modified" headers should be sent in the same HTTP response as stated in IETF RFC 7232 [16] clause 2.4.

NOTE: "ETag" is a stronger validator than the "Last-Modified" and is preferred.

If the UDSF included an "ETag" header with the resource then a conditional GET request for this resource shall be performed with the "If-None-Match" header, and a PUT/PATCH/DELETE request for this resource shall be performed with the "If-Match" header.

6.1.2.2.10 Content-Location

As described in IETF RFC 7231 [15] clause 3.1.4.2, the UDSF shall include the Content-Location header set to the URI of the expired Record when sending a Notification to an NF Consumer.

6.1.2.3 HTTP custom headers

The mandatory HTTP custom header fields specified in clause 5.2.3.2 of 3GPP TS 29.500 [4] shall be applicable.

6.1.2.4 HTTP multipart messages

6.1.2.4.1 General

HTTP multipart messages shall be supported to transfer the opaque Record and Block Information in the following service operations (and HTTP messages):

– Record (PUT/GET/DELETE)

– BlockCollection (GET)

– RecordNotification (POST)

NOTE: In the clauses below, this specification deviates in the definition of the Content-Id header from IETF RFC 2045 [20] in that there is no need for the Content-Id to be "world unique", as in this specification the Content-Id is only required to be unique within the context of a Record, BlockCollection or RecordNotification.

6.1.2.4.2 Record

The Record is encoded as an HTTP multipart message with the multipart/mixed content-type as described in IETF RFC 2046 [21].

The boundary parameter is used to delimit each part (Start of parts to RecordMeta, RecordMeta to Block, Block to Block and Block to End of parts) and shall be set to a value as in accordance with IETF RFC 2046 [21].

The RecordMeta part shall be the first part, and shall always be present. It shall include a Content-Id header that may be set to an unquoted value of "meta" or any other suitable value, for example as described in IETF RFC 2045 [20], the Content-Type (see IETF RFC 2045 [20]) header set to "application/json" and include JSON content for the RecordMeta.

Zero or more Block parts may follow the RecordMeta Part. For each Block part in the HTTP multipart/mixed message, the Block part shall include a Content-Id header identifying the Block with the value of the blockId, a Content-Type (see IETF RFC 2045 [20]) header indicating the MIME type of the Block (any value), e.g. application/octet-stream, application/json or another applicable MIME type and the Content-Transfer-Encoding (see IETF RFC 2045 [20]) header with an appropriate value.

6.1.2.4.3 BlockCollection

The BlockCollection is encoded as an HTTP multipart message with the multipart/parallel content-type as described in IETF RFC 2046 [21].

The boundary parameter is used to delimit each part (Start of parts to Block, Block to Block and Block to End of parts) and shall be set to a value as in accordance with IETF RFC 2046 [21].

For the BlockCollection, zero or more Block parts may be included. For each Block part in the HTTP multipart/parallel message, the Block part shall include a Content-Id header identifying the Block with the value of the blockId, a Content-Type header indicating the MIME type of the Block (any value) e.g. application/octet-stream, application/json or another applicable MIME type and the Content-Transfer-Encoding (see IETF RFC 2045 [20]) header with an appropriate value.

6.1.2.4.4 RecordNotification

The RecordNotification is encoded as an HTTP multipart message with the multipart/mixed content-type as described in IETF RFC 2046 [21].

The boundary parameter is used to delimit each part (Start of parts to RecordNotification, RecordNotification to RecordMeta, RecordMeta to Block, Block to Block and Block to End of parts) and shall be set to a value in accordance with IETF RFC 2046 [21].

The RecordNotification shall be the first part, and shall always be present. It shall include a Content-Id header set to an unquoted value of "meta" or any other suitable value, for example as described in IETF RFC 2045 [20], the Content-Type (see IETF RFC 2045 [20]) header set to "application/json" and include JSON content for the NotificationDescription.

The RecordMeta part shall be the second part, and shall always be present. It shall include a Content-Id header set to an unquoted value of "meta" or any other suitable value, for example as described in IETF RFC 2045 [20], the Content-Type (see IETF RFC 2045 [20]) header set to "application/json" and include JSON content for the RecordMeta.

6.1.3 Resources

6.1.3.1 Overview

Figure 6.1.3.1-1: Resource URI structure of the nudsf-dr API

Table 6.1.3.1-1 provides an overview of the resources and applicable HTTP methods.

Table 6.1.3.1-1: Resources and methods overview

Resource name	Resource URI	HTTP method or custom operation	Description
RecordCollection (Collection)	/{realmId}/{storageId}/records	GET	Search for records
RecordCollection (Collection)	/{realmId}/{storageId}/records	DELETE	Delete records
Record (Document)	/{realmId}/{storageId}/records/{recordId}	GET	Retrieve a record
		PUT	Create or update a record
		DELETE	Delete a record
Meta (Document)	/{realmId}/{storageId}/records/{recordId}/meta	GET	Retrieve the meta of a record
Meta (Document)	/{realmId}/{storageId}/records/{recordId}/meta	PATCH	Modify the meta of a record
BlockCollection (Collection)	/{realmId}/{storageId}/records/{recordId}/blocks	GET	Retrieve all the blocks of a record
Block (Document)	/{realmId}/{storageId}/records/{recordId}/blocks/{blockId}	GET	Retrieve a block
		PUT	Create or update a block
		DELETE	Delete a block
NotificationSubscriptions (Collection)	/{realmId}/{storageId}/subs-to-notify	GET	Retrieve existing subscriptions
Individual NotificationSubscription (Document)	/{realmId}/{storageId}/subs-to-notify/{subscriptionId}	DELETE	Delete the subscription identified by {subscriptionId}, i.e. unsubscribe to notification for change of data
		PATCH	Update an individual Subscription to notification
		PUT	Create or update a subscription to notification,
		GET	Retrieve an individual Subscription to notification
Meta Schema (Document)	/{realmId}/{storageId}/meta-schemas/{schemaId}	GET	Retrieve a Meta Schema
		PUT	Create or update a Meta Schema
		DELETE	Delete a Meta Schema

6.1.3.2 Resource: RecordCollection (Collection)

6.1.3.2.1 Description

This resource represents the collection of records within a storage. It can be used to search for specific records matching specific filter criteria.

6.1.3.2.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/records

This resource shall support the resource URI variables defined in table 6.1.3.2.2-1.

Table 6.1.3.2.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id.
storageId	Represents the storage Id.

6.1.3.2.3 Resource Standard Methods

6.1.3.2.3.1 GET

This method shall support the URI query parameters specified in table 6.1.3.2.3.1-1.

Table 6.1.3.2.3.1-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
filter	SearchExpression	O	0..1	The filter criteria for searching the records of the storage.
limit-range	Uinteger	C	0..1	When set, the returned response shall contain at the most the number of record references specified by the parameter value. If the count-indicator parameter is set in the request, this parameter shall be ignored.
count-indicator	boolean	O	0..1	If this parameter is set, the number of records that matched the criteria shall be returned and no record references shall be returned.
retrieve-records	RetrieveRecords	O	0..1	If this parameter is set, the content of records that matched the criteria shall be returned. If count-indicator is set, this parameter shall not be set.	CombinedSearchRetrieve
max-payload-size	Uinteger	O	0..1	Maximum payload size (before compression, if any) of the response, expressed in kilo octets. When present, the UDSF shall limit the number of Records or Meta returned in the response so as not to exceed the maximum payload size indicated in the request.	CombinedSearchRetrieve

This method shall support the request data structures specified in table 6.1.3.2.3.1-2 and the response data structures and response codes specified in table 6.1.3.2.3.1-3.

Table 6.1.3.2.3.1-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.2.3.1-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
RecordSearchResult	M	1	200 OK	The search result containing the record references matching the filter.
n/a			204 No Content	The search did not result in any matching record references.
NOTE: The manadatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.2.3.2 DELETE

This method shall support the URI query parameters specified in table 6.1.3.2.3.2-1.

Table 6.1.3.2.3.2-1: URI query parameters supported by the DELETE method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
filter	SearchExpression	M	1	The filter criteria for identifying the records to be deleted.	BulkOperations

This method shall support the request data structures specified in table 6.1.3.2.3.2-2 and the response data structures and response codes specified in table 6.1.3.2.3.2-3.

Table 6.1.3.2.3.2-2: Data structures supported by the DELETE Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.2.3.2-3: Data structures supported by the DELETE Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 No Content	The bulk deletion request did not result in any matching records to be deleted.
RecordIdList	M	1	200 OK	Contains the list of record IDs identifying the deleted records.
NOTE: The mandatory HTTP error status code for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.3 Resource: Record (Document)

6.1.3.3.1 Description

This resource represents a record within a storage.

6.1.3.3.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/records/{recordId}

This resource shall support the resource URI variables defined in table 6.1.3.3.2-1.

Table 6.1.3.3.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id where the record is stored
storageId	Represents the storage Id where the record is stored
recordId	Represents the record Id of the record

6.1.3.3.3 Resource Standard Methods

6.1.3.3.3.1 GET

This method shall support the URI query parameters specified in table 6.1.3.3.3.1-1.

Table 6.1.3.3.3.1-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6.

This method shall support the request data structures specified in table 6.1.3.3.3.1-2 and the response data structures and response codes specified in table 6.1.3.3.3.1-3.

Table 6.1.3.3.3.1-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.3.3.1-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
RecordBody	M	1	200 OK	A response body containing the record.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -RECORD_NOT_FOUND
NOTE: The mandatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.3.3.2 PUT

This method shall support the URI query parameters specified in table 6.1.3.3.3.2-1.

Table 6.1.3.3.3.2-1: URI query parameters supported by the PUT method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
get-previous	boolean	O	0..1	Request to return the previous record content if a record already exists in the targeted storage for the same record identifier.

When creating or replacing the record, meta and zero or more blocks shall be included. The record meta information shall be the first part and is mandatory. The remaining parts of the body (if any) shall be the blocks to be updated or created. See clause 6.1.2.4 for details on the encoding.

If the operation updates an existing record, then the existing record and its blocks shall be discarded and replaced by the meta and blocks supplied with the request. This also applies to the case when no new blocks are included, i.e. the old blocks (if any) shall be deleted from the record.

This method shall support the request data structures specified in table 6.1.3.3.3.2-2 and the response data structures and response codes specified in table 6.1.3.3.3.2-3.

Table 6.1.3.3.3.2-2: Data structures supported by the PUT Request Body on this resource

Data type	P	Cardinality	Description
Record	M	1	The record that is to be created including meta and zero or more blocks.

Table 6.1.3.3.3.2-3: Data structures supported by the PUT Response Body on this resource

Data type	P	Cardinality	Response codes	Description
RecordBody	M	1	200 OK	Upon successful update of a record, a response body containing the previous record value (if get-previous was indicated in the request, and if one exists) will be returned
RecordBody	O	0..1	201 Created	Upon successful creation of a record, a response body of the created record shall be returned. If due to operator’s policy the value of the ttl (if any) in the request exceeded a maximum allowed ttl value with the ttl set to the value applied by the UDSF.
n/a			204 No Content	Upon successful update of a record, an empty response is returned or if no previous record value was requested.
ProblemDetails	O	0..1	403 FORBIDDEN	If the UDSF (based on operator policy), determines to apply a ttl value of the recordMeta different from the ttl value (if any) of the request, the get-previous query-parameter is present in the request and the request applies to a record that already exists in the UDSF, the "cause" attribute shall be set to one of the following application errors: -TTL_VALUE_NOT_ALLOWED
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND
RecordBody	O	0..1	412 Precondition Failed	If one or more conditions given in the request header fields evaluated to false and get-previous was indicated in the request, the UDSF shall include the RecordBody in the response.
NOTE: The mandatory HTTP error status code for the PUT method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.3.3.3 DELETE

This method shall support the URI query parameters specified in table 6.1.3.3.3.3-1.

Table 6.1.3.3.3.3-1: URI query parameters supported by the DELETE method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
get-previous	boolean	O	0..1	Request to return the record content if a record exists in the targeted storage for the same record identifier.

This method shall support the request data structures specified in table 6.1.3.3.3.3-2 and the response data structures and response codes specified in table 6.1.3.3.3.3-3.

Table 6.1.3.3.3.3-2: Data structures supported by the DELETE Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.3.3.3-3: Data structures supported by the DELETE Response Body on this resource

Data type	P	Cardinality	Response codes	Description
RecordBody	O	0..1	200 OK	Upon success, and a response body containing the record value with meta and associated blocks (if any), if get-previous was indicated in the request.
n/a			204 No Content	Upon success and no response body containing the record was requested.
RecordBody	O	0..1	412 Precondition Failed	If one or more conditions given in the request header fields evaluated to false and get-previous was indicated in the request, the UDSF shall include the RecordBody in the response.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -RECORD_NOT_FOUND
NOTE: The mandatory HTTP error status code for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.4 Resource: Meta (Document)

6.1.3.4.1 Description

This resource represents the meta associated with a record.

6.1.3.4.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/records/{recordId}/meta

This resource shall support the resource URI variables defined in table 6.1.3.4.2-1.

Table 6.1.3.4.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id where the record is stored
storageId	Represents the storage Id where the record is stored
recordId	Represents the record Id of the record

6.1.3.4.3 Resource Standard Methods

6.1.3.4.3.1 GET

This method shall support the URI query parameters specified in table 6.1.3.4.3.1-1.

Table 6.1.3.4.3.1-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.1.3.4.3.1-2 and the response data structures and response codes specified in table 6.1.3.4.3.1-3.

Table 6.1.3.4.3.1-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.4.3.1-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
RecordMeta	M	1	200 OK	A response body containing the record meta will be returned.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -RECORD_NOT_FOUND
NOTE: The mandatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.4.3.2 PATCH

This method shall support the URI query parameters specified in table 6.1.3.4.3.2-1.

Table 6.1.3.4.3.2-1: URI query parameters supported by the PATCH method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.1.3.4.3.2-2 and the response data structures and response codes specified in table 6.1.3.4.3.2-3.

Table 6.1.3.4.3.2-2: Data structures supported by the PATCH Request Body on this resource

Data type	P	Cardinality	Description
array(patchItem)	M	1..N	A collection of patch items to apply on the record meta.

Table 6.1.3.4.3.2-3: Data structures supported by the PATCH Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 No Content	Upon successful modification, there is no body in the response message. (NOTE 2)
PatchResult	M	1	200 OK	If one or more modification instructions have been discarded, the execution report is returned. (NOTE 2)
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute maybe used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -RECORD_NOT_FOUND
NOTE 1: In addition common data structures as listed in table 6.1.7.3-1are supported. NOTE 2: If all the modification instructions in the PATCH request have been implemented, the UDSF shall respond with 204 No Content response; if some of the modification instructions in the PATCH request have been discarded, the UDSF shall respond with PatchResult.

6.1.3.5 Resource: BlockCollection (Collection)

6.1.3.5.1 Description

This resource represents the collection of blocks of associated with a record.

6.1.3.5.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/records/{recordId}/blocks

This resource shall support the resource URI variables defined in table 6.1.3.5.2-1.

Table 6.1.3.5.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id where the record is stored
storageId	Represents the storage Id where the record is stored
recordId	Represents the record Id of the record

6.1.3.5.3 Resource Standard Methods

6.1.3.5.3.1 GET

This method shall support the URI query parameters specified in table 6.1.3.5.3.1-1.

Table 6.1.3.5.3.1-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.1.3.5.3.1-2 and the response data structures and response codes specified in table 6.1.3.5.3.1-3.

Table 6.1.3.5.3.1-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.5.3.1-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
array(Block)	M	1..N	200 OK	A response body containing one or more blocks.
n/a			204 No Content	The BlockCollection did not contain any blocks.
NOTE: The mandatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.6 Resource: Block (Document)

6.1.3.6.1 Description

This resource represents a record within a storage.

6.1.3.6.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/records/{recordId}/blocks/{blockId}

This resource shall support the resource URI variables defined in table 6.1.3.6.2-1.

Table 6.1.3.6.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id where the record is stored
storageId	Represents the storage Id where the record is stored
recordId	Represents the record Id of the record
blockId	Represents the block Id of the block

6.1.3.6.3 Resource Standard Methods

6.1.3.6.3.1 GET

This method shall support the URI query parameters specified in table 6.1.3.6.3.1-1.

Table 6.1.3.6.3.1-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.1.3.6.3.1-2 and the response data structures and response codes specified in table 6.1.3.6.3.1-3.

Table 6.1.3.6.3.1-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.6.3.1-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
BlockBody	M	1	200 OK	Upon success, a response body containing the requested block is returned.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute maybe used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -RECORD_NOT_FOUND -BLOCK_NOT_FOUND
NOTE: The mandatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.6.3.2 PUT

This method shall support the URI query parameters specified in table 6.1.3.6.3.2-1.

Table 6.1.3.6.3.2-1: URI query parameters supported by the PUT method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
get-previous	boolean	O	0..1	Request to return the previous block content if a block already exists in the targeted storage for the same block identifier.

If the operation updates an existing block, then the existing block shall be discarded and replaced by the block supplied with the request.

This method shall support the request data structures specified in table 6.1.3.6.3.2-2 and the response data structures and response codes specified in table 6.1.3.6.3.2-3.

Table 6.1.3.6.3.2-2: Data structures supported by the PUT Request Body on this resource

Data type	P	Cardinality	Description
Block	M	1	The block definition that shall be created. A Content-Type http header can be set to specify the media type of the block’s opaque content. If the media-type is not included, the media-type shall be set to application/octet-stream.

Table 6.1.3.6.3.2-3: Data structures supported by the PUT Response Body on this resource

Data type	P	Cardinality	Response codes	Description
BlockBody	M	1	200 OK	Upon successful update of a block, a response body containing the previous record value ((if get-previous was indicated in the request and if one exists) will be returned
n/a			201 Created	Upon successful creation of a record, an empty response shall be returned.
n/a			204 No Content	Upon successful update of a record, an empty response is returned if no previous record value was requested.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -RECORD_NOT_FOUND
BlockBody	O	0..1	412 Precondition Failed	If one or more conditions given in the request header fields evaluated to false and get-previous was indicated in the request, the UDSF shall include the BlockBody in the response.
NOTE: The mandatory HTTP error status code for the PUT method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.6.3.3 DELETE

This method shall support the URI query parameters specified in table 6.1.3.6.3.3-1.

Table 6.1.3.6.3.3-1: URI query parameters supported by the DELETE method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
get-previous	boolean	O	0..1	Request to return the previous block content (if any).

This method shall support the request data structures specified in table 6.1.3.6.3.3-2 and the response data structures and response codes specified in table 6.1.3.6.3.3-3.

Table 6.1.3.6.3.3-2: Data structures supported by the DELETE Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.6.3.3-3: Data structures supported by the DELETE Response Body on this resource

Data type	P	Cardinality	Response codes	Description
BlockBody	O	0..1	200 OK	Upon success, and a response body containing the block was requested.
n/a			204 No Content	Upon success, and no response body containing the block was requested.
BlockBody	O	0..1	412 Precondition Failed	If one or more conditions given in the request header fields evaluated to false and get-previous was indicated in the request, the UDSF shall include the BlockBody in the response.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -RECORD_NOT_FOUND -BLOCK_NOT_FOUND
NOTE: The mandatory HTTP error status code for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.7 Resource: NotificationSubscriptions

6.1.3.7.1 Description

This resource is used to represent notification subscriptions.

6.1.3.7.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/subs-to-notify

This resource shall support the resource URI variables defined in table 6.1.3.7.2-1.

Table 6.1.3.7.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id.
storageId	Represents the storage Id.

6.1.3.7.3 Standard Methods

6.1.3.7.3.2 GET

This method shall support the URI query parameters specified in table 6.1.3.7.3.2-1.

Table 6.1.3.7.3.2-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
limit-range	Uinteger	C	0..1	When set, the returned response shall contain at the most the number of Notification Subscriptions specified by the parameter value.

This method shall support the request data structures specified in table 6.1.3.7.3.2-2 and the response data structures and response codes specified in table 6.1.3.7.3.2-3.

Table 6.1.3.7.3.2-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.7.3.2-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
array(NotificationSubscription)	M	0..N	200 OK	Upon success, a response body containing the individual subscriptions shall be returned.
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND
NOTE: The manadatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.8 Resource: IndividualNotificationSubscription

6.1.3.8.1 Description

This resource is used to represent an individual subscriber data subscriptions to notifications.

6.1.3.8.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/subs-to-notify/{subscriptionId}

This resource shall support the resource URI variables defined in table 6.1.3.8.2-1.

Table 6.1.3.8.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id.
storageId	Represents the storage Id.
subscriptionId	The subscriptionId identifies an individual NotficiationSubscription.

6.1.3.8.3 Resource Standard Methods

6.1.3.8.3.1 DELETE

This method shall support the URI query parameters specified in table 6.1.3.8.3.1-1.

Table 6.1.3.8.3.1-1: URI query parameters supported by the DELETE method on this resource

Name	Data type	P	Cardinality	Description
client-id	ClientId	M	1	The client-id is used by the UDSF to guard against deletion of notification subscriptions that do not belong to the same NF or NFSet.
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
get-previous	boolean	O	0..1	Request to return the associated NotificationSubscription if it exist.

This method shall support the request data structures specified in table 6.1.3.8.3.1-2 and the response data structures and response codes specified in table 6.1.3.8.3.1-3.

Table 6.1.3.8.3.1-2: Data structures supported by the DELETE Request Body on this resource

Data type	P	Cardinality	Description
n/a			The request body shall be empty.

Table 6.1.3.8.1-3: Data structures supported by the DELETE Response Body on this resource

Data type	P	Cardinality	Response codes	Description
NotificationSubscription	O	0..1	200 OK	Upon successful delete of a NotificationSubscription, a response body containing the NotificationSubscription value before the delete shall be returned if get-previous was indicated in the request.
n/a			204 NO CONTENTt	Upon success, an empty response body shall be returned.
ProblemDetails	O	0..1	403 FORBIDDEN	If the client-id query parameter does not match the clientId of the existing resource, 403 FORBIDDEN shall be returned and the "cause" attribute may be used to indicate one of the following application errors: – SUBSCRIPTION_EXISTS
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -SUBSCRIPTION_NOT_FOUND
NotificationSubscription	O	0..1	412 PRECONDITION FAILED	412 PRECONDITION FAILED is returned if one or more conditions given in the request header fields evaluated to false. If get-previous was indicated in the request, the UDSF shall include the NotificationSubscription in the response.
NOTE: The mandatory HTTP error status code for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.8.3.2 PATCH

This method shall support the URI query parameters specified in table 6.1.3.8.3.2-1.

Table 6.1.3.8.3.2-1: URI query parameters supported by the PATCH method on this resource

Name	Data type	P	Cardinality	Description
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.1.3.8.3.2-2 and the response data structures and response codes specified in table 6.1.3.8.3.2-3.

Table 6.1.3.8.3.2-2: Data structures supported by the PATCH Request Body on this resource

Data type	P	Cardinality	Description
array(PatchItem)	M	1..N	Contains the delta data of the Notification Subscription to be updated.

Table 6.1.3.8.3.2-3: Data structures supported by the PATCH Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 NO CONTENT	Upon successful modification, there is no body in the response message. (NOTE 2)
PatchResult	M	1	200 OK	Upon success, the execution report is returned. (NOTE 2)
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -SUBSCRIPTION_NOT_FOUND
NOTE 1: In addition common data structures as listed in table 6.1.7.3-1are supported. NOTE 2: If all the modification instructions in the PATCH request have been implemented, the UDSF shall respond with 204 No Content response; if some of the modification instructions in the PATCH request have been discarded, the UDSF shall respond with 200 OK and include the PatchResult.

6.1.3.8.3.3 GET

This method shall support the URI query parameters specified in table 6.1.3.8.3.3-1.

Table 6.1.3.8.3.3-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6.

This method shall support the request data structures specified in table 6.1.3.8.3.3-2 and the response data structures and response codes specified in table 6.1.3.8.3.3-3.

Table 6.1.3.8.3.3-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a			The request body shall be empty.

Table 6.1.3.8.3.3-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
NotificationSubscription	M	1	200 OK	Upon success, a response body containing the individual subscriptions shall be returned.
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -SUBSCRIPTION_NOT_FOUND
NOTE: The mandatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.8.3.4 PUT

This method shall support the URI query parameters specified in table 6.1.3.8.3.4-1.

Table 6.1.3.8.3.4-1: URI query parameters supported by the PUT method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.1.3.8.3.4-2 and the response data structures and response codes specified in table 6.1.3.8.3.4-3.

Table 6.1.3.8.3.4-2: Data structures supported by the PUT Request Body on this resource

Data type	P	Cardinality	Description
NotificationSubscription	M	1	The Notification Subscription.

Table 6.1.3.8.3.4-3: Data structures supported by the PUT Response Body on this resource

Data type	P	Cardinality	Response codes	Description
NotificationSubscription	M	1	201 CREATED	Upon success, the created NotificationSubscription is returned. The HTTP response shall include a "Location" HTTP header that contains the resource URI of the created resource.
NotificationSubscription	M	1	200 OK	Upon success, the updated NotificationSubscription is returned.
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND
ProblemDetails	O	0..1	403 FORBIDDEN	If the clientId of the PUT request does not match the clientId of the existing resource, 403 FORBIDDEN shall be returned and the "cause" attribute may be used to indicate one of the following application errors: – SUBSCRIPTION_EXISTS
array(Uri)	O	1..N	409 CONFLICT	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.
NOTE: The mandatory HTTP error status codes for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.9 Resource: Meta Schema (Document)

6.1.3.9.1 Description

This resource represents a meta schema within a storage.

6.1.3.9.2 Resource Definition

Resource URI: {apiRoot}/nudsf-dr/v1/{realmId}/{storageId}/meta-schemas/{schemaId}

This resource shall support the resource URI variables defined in table 6.1.3.9.2-1.

Table 6.1.3.9.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id where the schema is stored
storageId	Represents the storage Id where the schema is stored
schemaId	Represents the schema Id of the schema

6.1.3.9.3 Resource Standard Methods

6.1.3.9.3.1 GET

This method shall support the URI query parameters specified in table 6.1.3.9.3.1-1.

Table 6.1.3.9.3.1-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6.	Meta Schema

This method shall support the request data structures specified in table 6.1.3.9.3.1-2 and the response data structures and response codes specified in table 6.1.3.9.3.1-3.

Table 6.1.3.9.3.1-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.9.3.1-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
MetaSchema	M	1	200 OK	A response body containing the meta schema.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -SCHEMA_NOT_FOUND
NOTE: The mandatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.3.9.3.2 PUT

This method shall support the URI query parameters specified in table 6.1.3.9.3.2-1.

Table 6.1.3.9.3.2-1: URI query parameters supported by the PUT method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6	Meta Schema
get-previous	boolean	O	0..1	Request to return the previous meta schema content if the meta schema already exists in the targeted storage for the same schema identifier.	Meta Schema

This method shall support the request data structures specified in table 6.1.3.9.3.2-2 and the response data structures and response codes specified in table 6.1.3.9.3.2-3.

Table 6.1.3.9.3.2-2: Data structures supported by the PUT Request Body on this resource

Data type	P	Cardinality	Description
MetaSchema	M	1	The schema that is to be created/updated.

Table 6.1.3.9.3.2-3: Data structures supported by the PUT Response Body on this resource

Data type	P	Cardinality	Response codes	Description
MetaSchema	M	1	200 OK	Upon successful update of a schema, a response body containing the previous schema value (if get-previous was indicated in the request, and if one exists) will be returned
MetaSchema	M	1	201 Created	Upon successful creation of a schema, a response body of the created schema schall be returned. The HTTP response shall include a "Location" HTTP header that contains the resource URI of the created resource.
n/a			204 No Content	Upon successful update of a schema, an empty response is returned if no previous schema value was requested.
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND
NOTE: The mandatory HTTP error status code for the PUT method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

Table 6.1.3.9.3.2-4: Headers supported by the 201 Response Code on this resource

Name	Data type	P	Cardinality	Description
Location	string	M	1	Contains the URI of the newly created resource, according to the structure: {apiRoot}/nudsf-dr/<apiVersion>/{realmId}/{storageId}/meta-schemas/{schemaId}

6.1.3.9.3.3 DELETE

This method shall support the URI query parameters specified in table 6.1.3.9.3.3-1.

Table 6.1.3.9.3.3-1: URI query parameters supported by the DELETE method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6	Meta Schema
get-previous	boolean	O	0..1	Request to return the schema content if a schema exists in the targeted storage for the same schema identifier.	Meta Schema

This method shall support the request data structures specified in table 6.1.3.9.3.3-2 and the response data structures and response codes specified in table 6.1.3.9.3.3-3.

Table 6.1.3.9.3.3-2: Data structures supported by the DELETE Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.1.3.9.3.3-3: Data structures supported by the DELETE Response Body on this resource

Data type	P	Cardinality	Response codes	Description
MetaSchema	O	0..1	200 OK	Upon success, a response body containing the schema value, if get-previous was indicated in the request.
n/a			204 No Content	Upon success, if get-previous was not indicated in the request..
ProblemDetails	O	0..1	404 Not Found	The "cause" attribute may be used to indicate one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -SCHEMA_NOT_FOUND
NOTE: The mandatory HTTP error status code for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.4 Custom Operations without associated resources

None.

6.1.5 Notifications

6.1.5.1 General

Notifications shall comply to clause 6.2 of 3GPP TS 29.500 [4] and clause 4.6.2.3 of 3GPP TS 29.501 [5].

6.1.5.2 Timer Expiry Notification

6.1.5.2.1 Description

The Timer Expiry Notification is used by the NF service producer to report to an NF Consumer that the Record has expired as indicated by the ttl attribute (if set) of RecordMeta and if a callbackReference was set in the RecordMeta.

6.1.5.2.2 Target URI

The Callback URI "{callbackReference}" shall be used with the callback URI variables defined in table 6.1.5.2.2-1.

Table 6.1.5.2.2-1: Target URI variables for this resource

Name	Definition
callbackReference	string formatted as URI with the Callback Uri

6.1.5.2.3 Standard Methods

6.1.5.2.3.1 POST

This method shall support the request data structures specified in table 6.1.5.2.3.1-1 and the response data structures and response codes specified in table 6.1.5.2.3.1-1.

Table 6.1.5.2.3.1-2: Data structures supported by the POST Request Body on this resource

Data type	P	Cardinality	Description
RecordBody	M	1	The RecordBody of the record that was deleted.

Table 6.1.5.2.3.1-3: Data structures supported by the POST Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 No Content	Upon success, an empty response body shall be returned.
NOTE: The mandatory HTTP error status codes for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.5.3 Notification due to Data Change

6.1.5.3.1 Description

The Notification due to Data Change is used by the UDSF to report to an NF Consumer that a Record that is part of a NotificationSubscription has been updated or deleted.

6.1.5.3.2 Target URI

The Callback URI "{callbackReference}" shall be used with the callback URI variables defined in table 6.1.5.3.2-1.

Table 6.1.5.3.2-1: Callback URI variables for this resource

Name	Definition
callbackReference	String formatted as URI with the Callback Uri

6.1.5.3.3 Standard Methods

6.1.5.3.3.1 POST

This method shall support the request data structures specified in table 6.1.5.3.3.1-1 and the response data structures and response codes specified in table 6.1.5.3.3.1-1.

Table 6.1.5.3.3.1-2: Data structures supported by the POST Request Body on this resource

Data type	P	Cardinality	Description
RecordNotification	M	1	The notification with the record information.

Table 6.1.5.3.3.1-3: Data structures supported by the POST Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 NO CONTENT	Upon success, an empty response body shall be returned.
NOTE: The mandatory HTTP error status codes for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.5.4 Subscription Expiry Notification

6.1.5.4.1 Description

The Subscription Expiry Notification is used by the UDSF to report to an NF Consumer that a Subscription to Notification due to Data Change has expired or is about to expire.

6.1.5.4.2 Target URI

The Callback URI "{expiryCallbackReference}" shall be used with the callback URI variables defined in table 6.1.5.4.2-1.

Table 6.1.5.4.2-1: Callback URI variables for this resource

Name	Definition
expiryCallbackReference	String formatted as URI with the Callback URI

6.1.5.4.3 Standard Methods

6.1.5.4.3.1 POST

This method shall support the request data structures specified in table 6.1.5.4.3.1-1 and the response data structures and response codes specified in table 6.1.5.4.3.1-1.

Table 6.1.5.4.3.1-2: Data structures supported by the POST Request Body on this resource

Data type	P	Cardinality	Description
NotificationInfo	M	1	The notification info with expired subscriptions.

Table 6.1.5.4.3.1-3: Data structures supported by the POST Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 No Content	Upon success, an empty response body shall be returned.
NOTE: The mandatory HTTP error status codes for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.1.6 Data Model

6.1.6.1 General

This clause specifies the application data model supported by the API.

Table 6.1.6.1-1 specifies the data types defined for the N_udsf service based interface protocol. For simple data types defined for the Nudsf_DataRepository service API see table 6.1.6.3.2-1.

Table 6.1.6.1-1: N_udsf specific Data Types

Data type	Clause defined	Description	Applicability
RecordSearchResult	6.1.6.2.2	Record Search Result
RecordMeta	6.1.6.2.3	Record Meta
RecordBody	6.1.6.2.4	Record Body
Record	6.1.6.2.5	Record
BlockBody	6.1.6.2.6	Block Body
Block	6.1.6.2.7	Block
SearchCondition	6.1.6.2.8	Search Condition
SearchComparison	6.1.6.2.9	Search Comparison
ComparisonOperator	6.1.6.3.3	Comparison Operator
ConditionOperator	6.1.6.3.4	Condition Operator
SearchExpression	6.1.6.4.1	Search Expression
NotificationSubscription	6.1.6.2.10	Notification Subscription
RecordNotification	6.1.6.2.11	Record Notification
NotificationDescription	6.1.6.2.12	Notification Description
SubscriptionFilter	6.1.6.2.13	Subscription Filter
ClientId	6.1.6.2.14	Client Identity
MetaSchema	6.1.6.2.15	Meta Schema	Meta Schema
TagType	6.1.6.2.16	Tag Type	Meta Schema
RecordIdList	6.1.6.2.17	List of Record IDs	BulkOperations
NotificationInfo	6.1.6.2.18	Notification Info
RecordOperation	6.1.6.3.5	Record Operation
SchemaId	6.1.6.3.2	Identifier of a Meta Schema	Meta Schema
KeyType	6.1.6.3.6	Key Type	Meta Schema
RetrieveRecords	6.1.6.3.7	Request to return matching records	CombinedSearchRetrieve

Table 6.1.6.1-2 specifies data types re-used by the N_udsf service based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the N_udsf service based interface.

Table 6.1.6.1-2: N_udsf re-used Data Types

Data type	Reference	Comments	Applicability
SupportedFeatures	3GPP TS 29.571 [19]	see 3GPP TS 29.500 [4] clause 6.6.
PatchItem	3GPP TS 29.571 [19]	Data structure used for JSON patch.
PatchResult	3GPP TS 29.571 [19]
Uri	3GPP TS 29.571 [19]
DateTime	3GPP TS 29.571 [19]
NfInstanceId	3GPP TS 29.571 [19]
NfSetId	3GPP TS 29.571 [19]

6.1.6.2 Structured data types

6.1.6.2.1 Introduction

This clause defines the structures to be used in resource representations.

6.1.6.2.2 Type: RecordSearchResult

Table 6.1.6.2.2-1: Definition of type RecordSearchResult

Attribute name	Data type	P	Cardinality	Description	Applicability
count	Uinteger	M	1	The number of records found by the search.
references	array(Uri)	O	1..N	The Record references found by the search.
supportedFeatures	SupportedFeatures	O	0..1	See clause 6.1.8
matchingRecords	map(Record)	C	1..N	This attribute contains the records that match the search filters provided in the request. The key of the map is the recordId. It shall be present if the search request included an instruction to include record content in the response. The map may contain a subset of the matching records in the case where inclusion of more records would result in the payload size exceeding the max-payload-size received in the request (if any).	CombinedSearchRetrieve

6.1.6.2.3 Type: RecordMeta

Table 6.1.6.2.3-1: Definition of type RecordMeta

Attribute name	Data type	P	Cardinality	Description	Applicability
tags	map(array(string))	O	1..N(1..M)	A map of tag name/values pairs, where the tag name is a unique string name that is the primary key of the map and is paired with an array of string values.
ttl	DateTime	O	0..1	ttl refers to the lifetime of the record. After the expiry, the record shall be deleted.
callbackReference	Uri	O	0..1	The Uri where the NF Service Consumer shall receive notification on the expiry of the Record as indicated by the ttl attribute if desired.
schemaId	SchemaId	O	0..1	Id of the MetaSchema to which the tags comply to	Meta Schema

6.1.6.2.4 Type: RecordBody

Table 6.1.6.2.4-1: Definition of type RecordBody

Attribute name	Data type	P	Cardinality	Description	Applicability
record	Record	M	1	The record.

6.1.6.2.5 Type: Record

Table 6.1.6.2.5-1: Definition of type Record

Attribute name	Data type	P	Cardinality	Description	Applicability
meta	RecordMeta	M	1	The meta of a record.
blocks	array(Block)	O	1..N	The block(s) (if any) making up the record.

6.1.6.2.6 Type: BlockBody

Table 6.1.6.2.6-1: Definition of type BlockBody

Attribute name	Data type	P	Cardinality	Description	Applicability
n/a	Block	M	1	The block.

6.1.6.2.7 Type: Block

Table 6.1.6.2.7-1: Definition of type Block

Attribute name	Data type	P	Cardinality	Description	Applicability
value	Any Type	M	1	The block value of any data type.

6.1.6.2.8 Type: SearchCondition

Table 6.1.6.2.8-1: Definition of type SearchCondition

Attribute name	Data type	P	Cardinality	Description	Applicability
cond	ConditionOperator	M	1	Logical operator ("AND", "OR" or "NOT")
units	array(SearchExpression)	M	1..N	For the logical "NOT" operator indicated in the cond attribute, only one member shall be present in the array. For the logical "AND" or "OR" operators indicated in the cond attribute, at least two members shall be present in the array and all the members in the array shall be interpreted as logically concatenated with the logical operator.
schemaId	SchemaId	O	0..1	When included, the search is limited to records which have the given schemaId value stored in their RecordMeta	Meta Schema

6.1.6.2.9 SearchComparison

Table 6.1.6.2.9-1: Definition of type SearchComparison

Attribute name	Data type	P	Cardinality	Description	Applicability
op	ComparisonOperator	M	1	Comparison operator
tag	string	M	1	This attribute contains the tag name of an array of strings.
value	string	M	1	The array of strings indicated in the tag attribute compares to the value of this attribute.

6.1.6.2.10 Type: NotificationSubscription

Table 6.1.6.2.10-1: Definition of type NotificationSubscription

Attribute name	Data type	P	Cardinality	Description	Applicability
clientId	ClientId	M	1	Identity of the NF or NFSet for which the subscription applies.
callbackReference	Uri	M	1	Identifies the NF or NF pool where the notification shall be sent.
expiryCallbackReference	Uri	C	0..1	Identifies the NF or NF pool where the expiry notification shall be sent. Shall be present if the expiryNotification is present.
expiry	DateTime	C	0..1	This IE shall be included in a subscription response, if, based on operator policy and taking into account the expiry time included in the request, the UDSF needs to include an expiry time. The expiry time, based on operator policy, may indicate a value that is sooner than the NF consumer requested. The absence of this attribute in the subscription response indicates that the subscription does not have an expiry time.
expiryNotification	Uinteger	O	0..1	This attribute when present in the request, indicates to the UDSF that the UDSF shall Notify the NF Consumer about the expiry of the subscription if this capability is supported by the UDSF. -A value of 0 in the subscription request indicates that the UDSF shall notify the NF Consumer upon subscription expiry. -A value greater than 0 in the subscription request, indicates the number of seconds before the expiry of the subscription that the UDSF shall notify the NF Consumer about the expiry. -A value that results in the notification to occur in the past shall be treated the same as a value of 0 was received. A UDSF that supports this capability shall include the attribute in the subscription response and in the Notification, set to the value received in the request (or set to 0 if the notification would occur in the past as described above). For example, if the expiry time in the subscription request indicates a time 100 seconds from now and the expiryNotification indicates 110 seconds, the UDSF shall return a value of 0 in the subscription response, meaning the NF Consumer will be notified upon subscription expiry.
subFilter	SubscriptionFilter	O	0..1	If not included, the subscription applies to all Create, Delete and Update events of the storage.
supportedFeatures	SupportedFeatures	O	0..1	Used to negotiate the applicability of optional features

6.1.6.2.11 Type: RecordNotification

Table 6.1.6.2.11-1: Definition of type RecordNotification

Attribute name	Data type	P	Cardinality	Description	Applicability
descriptor	NotificationDescription	M	1	The block value of any data type.
meta	RecordMeta	M	1	The meta of a record.
blocks	array(Block)	O	1..n	The block(s) (if any) making up the record.

6.1.6.2.12 Type: NotificationDescription

Table 6.1.6.2.12-1: Definition of type NotificationDescription

Attribute name	Data type	P	Cardinality	Description	Applicability
recordRef	Uri	M	1	The reference of the record triggering the Notification.
operationType	RecordOperation	M	1	The operation type.
subscriptionId	string	O	0..1	This IE shall contain the subscriptionId that uniquely identifies the subscription to notification within a storage when present.

6.1.6.2.13 Type: SubscriptionFilter

Table 6.1.6.2.13-1: Definition of type SubscriptionFilter

Attribute name	Data type	P	Cardinality	Description	Applicability
monitoredResourceUris	array(Uri)	O	1..N	A set of URIs that identify the records for which a modification of the representation triggers a notification. The URI shall take the form of either an absolute URI or an absolute-path reference as defined in IETF RFC 3986 [22], also see NOTE 1. The monitored resource shall indicate an existing record. If not present, the subscription is applied to all records within the storage and a modification of the representation of any record within the storage triggers a notification.
operations	array(RecordOperation)	O	0..3	The operations that shall generate a notification. If the monitoredResourceUris is present, only "UPDATED" and "DELETED" are allowed values, any other value shall be ignored. If the attribute is not present, all applicable operations shall apply to the subscription.
NOTE 1: The UDSF should handle only the relative-path part (apiSpecificResourceUriPart, see 3GPP TS 29.501 [5] clause 4.4.1) and ignore possible inconsistencies (caused by e.g. an SCP) in the base URI part.

6.1.6.2.14 Type: ClientId

Table 6.1.6.2.14-1: Definition of type ClientId

Attribute name

Data type

Cardinality

Description

Applicability

nfId

NfInstanceId

0..1

The NF Instance Id uniquely identifying the NF Consumer.

Shall be present if the nfSetId is absent.

nfSetId

NfSetId

0..1

The NF Set Id of the NF Consumer.

Shall be present if the nfId is absent.

6.1.6.2.15 Type: MetaSchema

Table 6.1.6.2.15-1: Definition of type MetaSchema

Attribute name	Data type	P	Cardinality	Description	Applicability
schemaId	SchemaId	M	1	Id of the schema. Used as reference.	Meta Schema
metaTags	array(TagType)	M	1..N	Array of tag types that describe the schema	Meta Schema

6.1.6.2.16 Type: TagType

Table 6.1.6.2.16-1: Definition of type TagType

Attribute name	Data type	P	Cardinality	Description	Applicability
tagName	string	M	1	Name of the tag. Used as reference. Refers to the unique tag string name that is the primary key of the map and is paired with an array of string values in the RecordMeta tags IE	Meta Schema
keyType	KeyType	M	1	Type of key	Meta Schema
sort	boolean	C	0..1	Shall be present if keyType is "SEARCH_KEY" or "SEARCH_AND_COUNT_KEY" true: indicates that searches based on "GT", "GTE", "LT" and / or "LTE" are expected. false: indicates otherwise	Meta Schema
presence	boolean	O	0..1	true: indicates that presence of the tag is mandatory in the RecordMeta false (default): indicates that presence of the tag is optional in the RecordMeta	Meta Schema

6.1.6.2.17 Type: RecordIdList

Table 6.1.6.2.17-1: Definition of type RecordIdList

Attribute name	Data type	P	Cardinality	Description	Applicability
recordIdList	array(string)	M	1..N	List of Record IDs to be retrieved	BulkOperations

6.1.6.2.18 Type: NotificationInfo

Table 6.1.6.2.18-1: Definition of type NotificationInfo

Attribute name	Data type	P	Cardinality	Description	Applicability
expiredSubscriptions	array(NotificationSubscription)	M	1	An array of one or more expired subscriptions.

6.1.6.3 Simple data types and enumerations

6.1.6.3.1 Introduction

This clause defines simple data types and enumerations that can be referenced from data structures defined in the previous clauses.

6.1.6.3.2 Simple data types

The simple data types defined in table 6.1.6.3.2-1 shall be supported.

Table 6.1.6.3.2-1: Simple data types

Type Name	Type Definition	Description	Applicability
SchemaId	string	Id of the schema. Used as reference.	Meta Schema

6.1.6.3.3 Enumeration: ComparisonOperator

The enumeration ComparisonOperator represents the comparison of an array of strings to a string value. The comparison shall be based on lexicographical order. It shall comply with the provisions defined in table 6.1.6.3.3-1.

Table 6.1.6.3.3-1: Enumeration ComparisonOperator

Enumeration value	Description	Applicability
"EQ"	The array contains the string value.
"NEQ"	The array does not contain the string value.	AdvancedQuery
"GT"	The array contains a string that is greater than the string value.	AdvancedQuery
"GTE"	The array contains a string that is greater than or equal to the string value.	AdvancedQuery
"LT"	The array contains a string that is less than the string value.	AdvancedQuery
"LTE"	The array contains a string that is less than or equal to the string value.	AdvancedQuery

NOTE: It’s recommended to use GT/GTE/LT/LTE on single value tags. If not, the logical operator "NOT" applied over the comparison operator "GT" evaluates to "true" if there are no members in the array that are greater than the value.

6.1.6.3.4 Enumeration: ConditionOperator

Table 6.1.6.3.4-1: Enumeration ConditionOperator

Enumeration value	Description	Applicability
"AND"	Logical "AND"
"OR"	Logical "OR"
"NOT"	Logical "NOT"

6.1.6.3.5 Enumeration: RecordOperation

Table 6.1.6.3.5-1: Enumeration RecordOperation

Enumeration value	Description	Applicability
"CREATED"	Indicates a Create record operation
"UPDATED"	Indicates an Update record operation
"DELETED"	Indicates a Delete record operation

6.1.6.3.6 Enumeration: KeyType

Table 6.1.6.3.6-1: Enumeration KeyType

Enumeration value	Description	Applicability
"UNIQUE_KEY"	Tags with this key type may be used for search and will result in no or one matching records.	Meta Schema
"SEARCH_KEY"	Tags with this key type may be used for search and will result in no, one or more matching records.	Meta Schema
"COUNT_KEY"	Tags with this key type may be used for count.	Meta Schema
"SEARCH_AND_COUNT_KEY"	Tags with this key type may be used for seach and count.	Meta Schema
"OTHER_TAG"	Tags with this key type may not be used for search or count.	Meta Schema

6.1.6.3.7 Enumeration: RetrieveRecords

Table 6.1.6.3.7-1: Enumeration RetrieveRecords

Enumeration value	Description	Applicability
"ONLY_META"	Only the META of matching records are requested to be included in the RecordSearchResult.	CombinedSearchRetrieve
"META_AND_BLOCKS"	META and BLOCKS of matching records are requested to be included in the RecordSearchResult.	CombinedSearchRetrieve

6.1.6.4 Data types describing alternative data types or combinations of data types

6.1.6.4.1 Type: SearchExpression

Table 6.1.6.4.1-1: Definition of type SearchExpression as a list of mutually exclusive alternatives

Data type	Cardinality	Description	Applicability
SearchCondition	1	A search expression with logic operators	AdvancedQuery
SearchComparison	1	A minimum unit of the search expression
RecordIdList	1	List of Record IDs identifying records to be retrieved	BulkOperations

6.1.7 Error Handling

6.1.7.1 General

For the Nudsf_DataRepository API, HTTP error responses shall be supported as specified in clause 4.8 of 3GPP TS 29.501 [5]. Protocol errors and application errors specified in table 5.2.7.2-1 of 3GPP TS 29.500 [4] shall be supported for an HTTP method if the corresponding HTTP status codes are specified as mandatory for that HTTP method in table 5.2.7.1-1 of 3GPP TS 29.500 [4].

In addition, the requirements in the following clauses are applicable for the Nudsf_DataRepository API.

6.1.7.2 Protocol Errors

Protocol errors handling shall be supported as specified in clause 5.2.7 of 3GPP TS 29.500 [4].

6.1.7.3 Application Errors

The application errors defined for the Nudsf_DataRepository service are listed in Table 6.1.7.3-1.

Table 6.1.7.3-1: Application errors

Application Error	HTTP status code	Description
TTL_VALUE_NOT_ALLOWED	403 Forbidden	The ttl value indicated in the request exceeds the maximum value allowed in the UDSF.
SUBSCRIPTION_EXISTS	403 Forbidden	The subscription indicated in the HTTP/2 request is not authorized to be operated.
SCHEMA_IN_USE	403 Forbidden	The schema cannot be deleted as it is still referenced by existing records.
REALM_NOT_FOUND	404 Not Found	The realm indicated in the HTTP/2 request is unavailable in the UDSF.
STORAGE_NOT_FOUND	404 Not Found	The storage indicated in the HTTP/2 request is unavailable in the UDSF.
RECORD_NOT_FOUND	404 Not Found	The record indicated in the HTTP/2 request is unavailable in the UDSF.
BLOCK_NOT_FOUND	404 Not Found	The block indicated in the HTTP/2 request is unavailable in the UDSF.
SUBSCRIPTION_NOT_FOUND	404 Not Found	The subscription indicated in the HTTP/2 request is unavailable in the UDSF.
SCHEMA_NOT_FOUND	404 Not Found	The schema indicated in the HTTP/2 request is unavailable in the UDSF.

6.1.8 Feature negotiation

The optional features in table 6.1.8-1 are defined for the Nudsf_DataRepository API. They shall be negotiated using the extensibility mechanism defined in clause 6.6 of 3GPP TS 29.500 [4].

Table 6.1.8-1: Supported Features

Feature number	Feature Name	Description
1	AdvancedQuery	If an NF consumer detects that the UDSF supports the AdvancedQuery feature, it may use values of the ComparisonOperator besides "EQ" and may also use the cond attribute of the SearchCondition. If an NF consumer detects that the UDSF does not support the AdvancedQuery feature, it shall only use a value of "EQ" of the ComparisonOperator and shall not use the cond attribute of the SearchCondition.
2	Meta Schema	This feature supports optimization of UDSF data storage and allows the UDSF to know in advance how data search access by the NF consumer is expected. If the NF consumer detects that the UDSF does not support the Meta Schema feature, it shall not make use of the procedures for storing, updating and deleting Meta Schemas.
3	CombinedSearchRetrieve	This feature supports optimization of search and retrieval of records stored in the UDSF. When searching records (see clause 5.2.2.2.6), consumers supporting this feature can instruct the supporting UDSF to return matching records in addition to the matching records’ URIs. If the NF consumer detects that the UDSF does not support the CombinedSearchRetrieve feature, it shall not include the query parameters retrieve-records and max-payload-size in record search requests.
4	BulkOperations	This feature supports optimization for retrieval/deletion of huge number of records identified by a list of record IDs. When the CombinedSearchRetrieve feature has been used to request retrieval of matching records but only a subset of matching records have been received due to maximum payload size limitations, the consumers supporting this feature can instruct the supporting UDSF to return remaining records identified by a recordIdList. If the NF consumer detects that the UDSF does not support the BulkOperations feature, it shall not include the RecordIdList in the filter query parameter in record search requests.

6.1.9 Security

As indicated in 3GPP TS 33.501 [8] and 3GPP TS 29.500 [4], the access to the Nudsf_DataRepository API may be authorized by means of the OAuth2 protocol (see IETF RFC 6749 [9]), based on local configuration, using the "Client Credentials" authorization grant, where the NRF (see 3GPP TS 29.510 [10]) plays the role of the authorization server.

If OAuth2 is used, an NF Service Consumer, prior to consuming services offered by the <API Name> API, shall obtain a "token" from the authorization server, by invoking the Access Token Request service, as described in 3GPP TS 29.510 [10], clause 5.4.2.2.

NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF that the NF Service Consumer used for discovering the Nudsf_DataRepository service.

The Nudsf_DataRepository API defines a single scope "nudsf-dr" for the entire service, and it does not define any additional scopes at resource or operation level.

6.2 Nudsf_Timer Service API

6.2.1 Introduction

The Nudsf_Timer service shall use the Nudsf_Timer API.

The API URI of the Nudsf_Timer API shall be:

{apiRoot}/<apiName>/<apiVersion>/

The request URI used in HTTP requests from the NF service consumer towards the NF service producer shall have the Resource URI structure defined in clause 4.4.1 of 3GPP TS 29.501 [5], i.e.:

{apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>

with the following components:

– The {apiRoot} shall be set as described in 3GPP TS 29.501 [5].

– The <apiName> shall be "nudsf-timer".

– The <apiVersion> shall be "v1".

– The <apiSpecificResourceUriPart> shall be set as described in clause 6.2.3.

6.2.2 Usage of HTTP

6.2.2.1 General

HTTP/2, IETF RFC 7540 [11], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].

HTTP/2 shall be transported as specified in clause 5.3 of 3GPP TS 29.500 [4].

The OpenAPI [6] specification of HTTP messages and content bodies for the Nudsf_Timer API is contained in Annex A.

6.2.2.2 HTTP standard headers

6.2.2.2.1 General

See clause 5.2.2 of 3GPP TS 29.500 [4] for the usage of HTTP standard headers.

6.2.2.2.2 Content type

The following content types shall be supported:

– JSON Patch (IETF RFC 6902 [14]). The use of the JSON Patch format in a HTTP request body shall be signalled by the content type "application/json-patch+json".

6.2.2.3 HTTP custom headers

The mandatory HTTP custom header fields specified in clause 5.2.3.2 of 3GPP TS 29.500 [4] shall be applicable.

6.2.3 Resources

6.2.3.1 Overview

Figure 6.2.3.1-1: Resource URI structure of the nudsf-timer API

Table 6.2.3.1-1 provides an overview of the resources and applicable HTTP methods.

Table 6.2.3.1-1: Resources and methods overview

Resource name	Resource URI	HTTP method or custom operation	Description
Timers (Store)	/{realmId}/{storageId}/timers	GET	Search and retrieve timers matching a filter
Timers (Store)	/{realmId}/{storageId}/timers	DELETE	Stop (delete) timers matching a filter
Individual Timer (Document)	/{realmId}/{storageId}/timers/{timerId}	PUT	Start (create) or update (replace) a timer
		PATCH	Modify a timer
		DELETE	Stop (delete) a timer
		GET	Retrieve a timer

6.2.3.2 Resource: Timers (Store)

6.2.3.2.1 Description

This resource represents the collection of timers within a storage. It can be used to search for specific timers matching specific filter criteria, and to delete specific timers matching specific filter criteria.

6.2.3.2.2 Resource Definition

Resource URI: {apiRoot}/nudsf-timer/<apiVersion>/{realmId}/{storageId}/timers

This resource shall support the resource URI variables defined in table 6.2.3.2.2-1.

Table 6.2.3.2.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id.
storageId	Represents the storage Id.

6.2.3.2.3 Resource Standard Methods

6.2.3.2.3.1 GET

This method shall support the URI query parameters specified in table 6.2.3.2.3.1-1.

Table 6.2.3.2.3.1-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
filter	SearchExpression	C	0..1	The filter criteria for searching the timers of the storage. Shall be present if expired-filter is absent; otherwise may be present.
expired-filter	NullValue	C	0..1	A timer matches the expired-filter if the timer’s expiry time is earlier than the current time. Shall be present if filter is absent; otherwise may be present.
NOTE: If the query parameters filter and expired-filter are both present in the request, the result shall contain all timers that match both query parameters.

This method shall support the request data structures specified in table 6.2.3.2.3.1-2 and the response data structures and response codes specified in table 6.2.3.2.3.1-3.

Table 6.2.3.2.3.1-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.2.3.2.3.1-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality		Response codes		Description
TimerIdList	M	1		200 OK		The search result containing the IDs of timers matching the filter.
n/a				204 No Content		The search did not result in any matching timers.
ProblemDetails	O	0..1	404 NOT FOUND		The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND
NOTE: The manadatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.2.3.2.3.2 DELETE

This method shall support the URI query parameters specified in table 6.2.3.2.3.2-1.

Table 6.2.3.2.3.2-1: URI query parameters supported by the DELETE method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6
filter	SearchExpression	C	0..1	The filter criteria for identifying the timers of the storage that are to be deleted. Shall be present if expired-filter is absent; otherwise may be present.
expired-filter	NullValue	C	0..1	Presence of this query parameter indicates that only expired timers are to be deleted. Shall be present if filter is absent; otherwise may be present.
NOTE: If the query parameters filter and expired-filter are both present in the request, all timers that match both query parameters shall be deleted.

This method shall support the request data structures specified in table 6.2.3.2.3.2-2 and the response data structures and response codes specified in table 6.2.3.2.3.2-3.

Table 6.2.3.2.3.2-2: Data structures supported by the DELETE Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.2.3.2.3.2-3: Data structures supported by the DELETE Response Body on this resource

Data type	P	Cardinality		Response codes		Description
TimerIdList	M	1		200 OK		Contains the list of timer IDs identifying the deleted timers.
n/a				204 No Content		The search did not result in any matching timers.
ProblemDetails	O	0..1	404 NOT FOUND		The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND
NOTE: The manadatory HTTP error status code for the GET method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.2.3.3 Resource: Individual Timer (Document)

6.2.3.3.1 Description

This resource represents an individual timer within a storage.

6.2.3.3.2 Resource Definition

Resource URI: {apiRoot}/nudsf-timer/<apiVersion>/{realmId}/{storageId}/timers/{timerId}

This resource shall support the resource URI variables defined in table 6.2.3.3.2-1.

Table 6.2.3.3.2-1: Resource URI variables for this resource

Name	Definition
apiRoot	See clause 6.1.1
realmId	Represents the realm Id.
storageId	Represents the storage Id.
timerId	Represents the timer Id.

6.2.3.3.3 Resource Standard Methods

6.2.3.3.3.1 PUT

This method shall support the URI query parameters specified in table 6.2.3.3.3.1-1.

Table 6.2.3.3.3.1-1: URI query parameters supported by the PUT method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.2.3.3.3.1-2 and the response data structures and response codes specified in table 6.2.3.3.3.1-3.

Table 6.2.3.3.3.1-2: Data structures supported by the PUT Request Body on this resource

Data type	P	Cardinality	Description
Timer	M	1	The timer to be created or replaced.

Table 6.2.3.3.3.1-3: Data structures supported by the PUT Response Body on this resource

Data type	P	Cardinality		Response codes	Description
n/a				201 Created	Upon successful creation of a timer, an empty response shall be returned.
n/a				204 No Content	Upon successful replacement of a timer, an empty response shall be returned.
ProblemDetails		O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND
NOTE: The manadatory HTTP error status code for the PUT method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.2.3.3.3.2 PATCH

This method shall support the URI query parameters specified in table 6.2.3.3.3.2-1.

Table 6.2.3.3.3.2-1: URI query parameters supported by the PATCH method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.2.3.3.3.2-2 and the response data structures and response codes specified in table 6.2.3.3.3.2-3.

Table 6.2.3.3.3.2-2: Data structures supported by the PATCH Request Body on this resource

Data type	P	Cardinality	Description
array(PatchItem)	M	1..N	Contains the delta data of the Timer to be updated.

Table 6.2.3.3.3.2-3: Data structures supported by the PATCH Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 No Content	Upon successful modification of a timer, an empty response shall be returned.
PatchResult	M	1	200 OK	Upon success, the execution report is returned. (NOTE 2)
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -TIMER_NOT_FOUND
NOTE 1: In addition common data structures as listed in table 6.1.7.3-1 are supported. NOTE 2: If all the modification instructions in the PATCH request have been implemented, the UDSF shall respond with 204 No Content response; if some of the modification instructions in the PATCH request have been discarded, the UDSF shall respond with 200 OK and include the PatchResult.

6.2.3.3.3.3 DELETE

This method shall support the URI query parameters specified in table 6.2.3.3.3.3-1.

Table 6.2.3.3.3.3-1: URI query parameters supported by the DELETE method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.2.3.3.3.3-2 and the response data structures and response codes specified in table 6.2.3.3.3.3-3.

Table 6.2.3.3.3.3-2: Data structures supported by the DELETE Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.2.3.3.3.3-3: Data structures supported by the DELETE Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 No Content	Upon successful deletion of a timer, an empty response shall be returned.
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -TIMER_NOT_FOUND
NOTE: The mandatory HTTP error status code for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.2.3.3.3.4 GET

This method shall support the URI query parameters specified in table 6.2.3.3.3.4-1.

Table 6.2.3.3.3.4-1: URI query parameters supported by the GET method on this resource

Name	Data type	P	Cardinality	Description	Applicability
supported-features	SupportedFeatures	O	0..1	see 3GPP TS 29.500 [4] clause 6.6

This method shall support the request data structures specified in table 6.2.3.3.3.4-2 and the response data structures and response codes specified in table 6.2.3.3.3.4-3.

Table 6.2.3.3.3.4-2: Data structures supported by the GET Request Body on this resource

Data type	P	Cardinality	Description
n/a

Table 6.2.3.3.3.4-3: Data structures supported by the GET Response Body on this resource

Data type	P	Cardinality	Response codes	Description
Timer	M	1	200 OK	Upon success the timer shall be returned.
ProblemDetails	O	0..1	404 NOT FOUND	The "cause" attribute shall be set to one of the following application errors: -REALM_NOT_FOUND -STORAGE_NOT_FOUND -TIMER_NOT_FOUND
NOTE: The mandatory HTTP error status code for the DELETE method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.2.4 Custom Operations without associated resources

None.

6.2.5 Notifications

6.2.5.1 General

Notifications shall comply to clause 6.2 of 3GPP TS 29.500 [4] and clause 4.6.2.3 of 3GPP TS 29.501 [5].

6.2.5.2 Timer Expiry Notification

6.2.5.2.1 Description

The Timer Expiry Notification is used by the NF service producer to report to an NF Consumer that the Timer has expired as indicated by the expires attribute of Timer and if a callbackReference was set in the Timer.

6.2.5.2.2 Target URI

The Callback URI "{callbackReference}" shall be used with the callback URI variables defined in table 6.2.5.2.2-1.

Table 6.2.5.2.2-1: Target URI variables for this resource

Name	Definition
callbackReference	string formatted as URI with the Callback Uri

6.2.5.2.3 Standard Methods

6.2.5.2.3.1 POST

This method shall support the request data structures specified in table 6.2.5.2.3.1-1 and the response data structures and response codes specified in table 6.2.5.2.3.1-1.

Table 6.2.5.2.3.1-2: Data structures supported by the POST Request Body on this resource

Data type	P	Cardinality	Description
Timer	M	1	The timer that expired

Table 6.2.5.2.3.1-3: Data structures supported by the POST Response Body on this resource

Data type	P	Cardinality	Response codes	Description
n/a			204 No Content	Upon success, an empty response body shall be returned.
NOTE: The mandatory HTTP error status codes for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

6.2.6 Data Model

6.2.6.1 General

This clause specifies the application data model supported by the API.

Table 6.2.6.1-1 specifies the data types defined for the Nudsf_Timer service API. For simple data types defined for the Nudsf_Timer service API see table 6.2.6.3.2-1.

Table 6.2.6.1-1: Nudsf_Timer specific Data Types

Data type	Clause defined	Description	Applicability
Timer	6.2.6.2.2	Timer

Table 6.2.6.1-2 specifies data types re-used by the Nudsf_Timer service API from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Nudsf_Timer service API.

Table 6.2.6.1-2: Nudsf_Timer re-used Data Types

Data type	Reference	Comments	Applicability
SupportedFeatures	3GPP TS 29.571 [19]	see 3GPP TS 29.500 [4] clause 6.6.
PatchItem	3GPP TS 29.571 [19]	Data structure used for JSON patch.
PatchResult	3GPP TS 29.571 [19]
Uri	3GPP TS 29.571 [19]
DateTime	3GPP TS 29.571 [19]
NullValue	3GPP TS 29.571 [19]
SearchExpression	6.1.6.4.1

6.2.6.2 Structured data types

6.2.6.2.1 Introduction

This clause defines the structures to be used in resource representations.

6.2.6.2.2 Type: Timer

Table 6.2.6.2.2-1: Definition of type Timer

Attribute name	Data type	P	Cardinality	Description	Applicability
timerId	TimerId	C	0..1	Identifier of the timer; shall be present in Notification request messages; otherwise shall be absent.
expires	DateTime	M	1	Point in time of expiry
metaTags	map(array(string))	O	1..N	A map (list of key-value pairs where tagName serves as key) of tagValue lists.
callbackReference	Uri	O	0..1	The URI where the NF Service Consumer shall receive notification on the expiry of the Timer. Shall be absent from Notification request messages.
deleteAfter	Uinteger	O	0..1	If specified, the timer resource will be deleted following a period after the expires time of the number of seconds defined by the deleteAfter value. If not specified, the timer shall be deleted immediately after the expires time.

6.2.6.2.3 Type: TimerIdList

Table 6.2.6.2.3-1: Definition of type TimerIdList

Attribute name	Data type	P	Cardinality	Description	Applicability
timerIds	array(TimerId)	M	1..N	List of Timer IDs

6.2.6.3 Simple data types and enumerations

6.2.6.3.1 Introduction

This clause defines simple data types and enumerations that can be referenced from data structures defined in the previous clauses.

6.2.6.3.2 Simple data types

The simple data types defined in table 6.2.6.3.2-1 shall be supported.

Table 6.2.6.3.2-1: Simple data types

Type Name	Type Definition	Description	Applicability
TimerId	string	Id of a timer. Used as reference.

6.2.7 Error Handling

6.2.7.1 General

For the Nudsf_Timer API, HTTP error responses shall be supported as specified in clause 4.8 of 3GPP TS 29.501 [5]. Protocol errors and application errors specified in table 5.2.7.2-1 of 3GPP TS 29.500 [4] shall be supported for an HTTP method if the corresponding HTTP status codes are specified as mandatory for that HTTP method in table 5.2.7.1-1 of 3GPP TS 29.500 [4].

In addition, the requirements in the following clauses are applicable for the Nudsf_Timer API.

6.2.7.2 Protocol Errors

Protocol errors handling shall be supported as specified in clause 5.2.7 of 3GPP TS 29.500 [4].

6.2.7.3 Application Errors

The application errors defined for the Nudsf_Timer service are listed in Table 6.2.7.3-1.

Table 6.2.7.3-1: Application errors

Application Error	HTTP status code	Description
REALM_NOT_FOUND	404 Not Found	The realm indicated in the HTTP/2 request is unavailable in the UDSF.
STORAGE_NOT_FOUND	404 Not Found	The storage indicated in the HTTP/2 request is unavailable in the UDSF.
TIMER_NOT_FOUND	404 Not Found	The Timer indicated in the HTTP/2 request is unavailable in the UDSF.
EXPIRES_VALUE_NOT_ALLOWED	403 Forbidden	The timer could not be started as the expires time is in the past.

6.2.8 Feature negotiation

The optional features in table 6.1.8-1 are defined for the Nudsf_Timer API. They shall be negotiated using the extensibility mechanism defined in clause 6.6 of 3GPP TS 29.500 [4].

Table 6.2.8-1: Supported Features

Feature number	Feature Name	Description
n/a

6.2.9 Security

As indicated in 3GPP TS 33.501 [8] and 3GPP TS 29.500 [4], the access to the Nudsf_Timer API may be authorized by means of the OAuth2 protocol (see IETF RFC 6749 [9]), based on local configuration, using the "Client Credentials" authorization grant, where the NRF (see 3GPP TS 29.510 [10]) plays the role of the authorization server.

If OAuth2 is used, an NF Service Consumer, prior to consuming services offered by the Nudsf_Timer API, shall obtain a "token" from the authorization server, by invoking the Access Token Request service, as described in 3GPP TS 29.510 [10], clause 5.4.2.2.

NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF that the NF Service Consumer used for discovering the Nudsf_Timer service.

The Nudsf_Timer API defines a single scope "nudsf-timer" for the entire service, and it does not define any additional scopes at resource or operation level.

Annex A (normative):
OpenAPI specification