5 Services offered by the 5G DDNMF

29.5553GPP5G Direct Discovery Name Management Services5G SystemRelease 18Stage 3TS

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

5.1 Introduction

The table 5.1-1 shows the 5G DDNMF Services and 5G DDNMF Service Operations:

Table 5.1-1: List of 5G DDNMF Services

Service Name	Service Operations	Operation Semantics	Example Consumer(s)
N5g-ddnmf_Discovery	AnnounceAuthorize	Request/Response	5G DDNMF
	AnnounceUpdate	Request/Response	5G DDNMF
	MonitorAuthorize	Request/Response	5G DDNMF
	MonitorUpdate	Request/Response	5G DDNMF
	MonitorUpdateResult	Notify	5G DDNMF
	DiscoveryAuthorize	Request/Response	5G DDNMF
	MatchReport	Request/Response	5G DDNMF
	MatchInformation	Notify	5G DDNMF

Table 5.1-2 summarizes the corresponding APIs defined for this specification.

Table 5.1-2: API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
N5g-ddnmf_Discovery	6.1	N5g-ddnmf Discovery Service	TS29555_ N5g-ddnmf_Discovery.yaml	n5gddnmf-disc	A.2

5.2 N5g-ddnmf_Discovery Service

5.2.1 Service Description

The N5g-ddnmf_Discovery service enables an NF or SCP to manage inter-PLMN ProSe Direct Discovery operations for a target UE. The following are the key functionalities of this NF service.

– Allow the consumer NF to obtain the authorization from the 5G DDNMF for announcing in the PLMN.

– Allow the consumer NF to update or revoke the authorization from the 5G DDNMF for announcing in the PLMN.

– Allow the consumer NF to obtain the authorization from the 5G DDNMF for monitoring in the PLMN.

– Allow the consumer NF to update or revoke the authorization for the indicated UE to monitor in the PLMN.

– Allow the consumer NF to inform the 5G DDNMF of the monitoring revocation results.

– Allow the consumer NF to obtain the authorization from the 5G DDNMF for a discoverer UE in the PLMN to operate Model B restricted discovery.

– Allow the consumer NF to obtain the information about the indicated discovery code from the 5G DDNMF.

– Allow the consumer NF to receive from the 5G DDNMF of a matching result, and the information can be used for charging purpose.

5.2.2 Service Operations

5.2.2.1 Introduction

This clause introduces the service operations defined for the N5g-ddnmf_Discovery services as follows:

– AnnounceAuthorize

– AnnounceUpdate

– MonitorAuthorize

– MonitorUpdate

– MonitorUpdateResult

– DiscoveryAuthorize

– MatchReport

– MatchInformation

5.2.2.2 AnnounceAuthorize

5.2.2.2.1 General

The AnnounceAuthorize service operation shall be used by the NF Service consumer to obtain the authorization to announce for a UE from the 5G DDNMF in the PLMN. The following procedures are supported using the AnnounceAuthorize service operation:

– Discovery Request procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.4)

– Announcing Alert Procedures for restricted discovery (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.6)

– Direct Discovery Update Procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.7)

5.2.2.2.2 Obtain the authorization to announce for a UE

The AnnounceAuthorize service operation is invoked by a NF Service Consumer, e.g. HPLMN 5G DDNMF, towards the 5G DDNMF (e.g. VPLMN 5G DDNMF or Local PLMN 5G DDNMF) to request to obtain the authorization from the 5G DDNMF for announcing for a target UE. See Figure 5.2.2.2.2-1. The request contains the UE’s identity (/{ueId}) which shall be a SUPI or GPSI and the discovery Entry ID (/{discEntryId}) which is used to identify the discovery entry related to this request.

Figure 5.2.2.2.2-1: Obtain the authorization to announce for a UE

1. The NF Service Consumer shall send an HTTP PUT request to the resource representing the authorization to announce for a UE to obtain the authorization to announce for this UE. The request shall include the Discovery Type, if the Discovery Type is OPEN the Announce Authorisation Data for open discovery shall be included, and if the Discovery Type is RESTRICTED the Announce Authorisation Data for restricted discovery shall be included in the HTTP PUT request body.

2a. If the context indicated by the discEntryId doesn’t exist, the 5G DDNMF shall create the new resource, and upon success of creation of the resource, "201 created" shall be returned.

2b. If the context indicated by the discEntryId already exists, the 5G DDNMF shall replace the stored data using the received data, and upon success of the update of the resource, "204 No Content" shall be returned.

2c. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.2.3.1-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.1-3.

5.2.2.3 AnnounceUpdate

5.2.2.3.1 General

The AnnounceUpdate service operation shall be used by the NF Service consumer to update or revoke the authorization from the 5G DDNMF for announcing in the PLMN. The following procedures are supported using the AnnounceUpdate service operation:

– Direct Discovery Update Procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.7)

5.2.2.3.2 Update the authorization for announcing for a UE

The AnnounceUpdate service operation is invoked by a NF Service Consumer, e.g. HPLMN 5G DDNMF, towards the 5G DDNMF (e.g. VPLMN 5G DDNMF or Local PLMN 5G DDNMF) to request to update the authorization for announcing in the PLMN from the 5G DDNMF for a target UE. See Figure 5.2.2.3.2-1. The request contains the UE’s identity (/{ueId}) which shall be a SUPI or GPSI and the discovery Entry ID (/{discEntryId}) which is used to identify the discovery entry related to this request.

Figure 5.2.2.3.2-1: Update the authorization for announcing for a UE

1. The NF Service Consumer shall send an HTTP PATCH request to the resource representing the authorization to announce for a UE to update or revoke the authorization from the 5G DDNMF for announcing in the PLMN. The request shall include Discovery Type, the Validity Timer, and the ProSe Application Code if the ProSe Application Code is changed in the HTTP PATCH request body. If the Validity Timer sets to a full zero, it indicates to revoke the authorization for the announcing in the PLMN.

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.2.3.2-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.2.3.2-3.

5.2.2.4 MonitorAuthorize

5.2.2.4.1 General

The MonitorAuthorize service operation shall be used by the NF Service consumer to obtain the authorization from the 5G DDNMF for monitoring for an UE in the PLMN. The following procedures are supported using the MonitorAuthorize service operation:

– Discovery Request procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.4).

5.2.2.4.2 Obtain the authorization to monitor for a UE

The MonitorAuthorize service operation is invoked by a NF Service Consumer, e.g. HPLMN 5G DDNMF, towards the 5G DDNMF (e.g. VPLMN 5G DDNMF or Local PLMN 5G DDNMF) to request to obtain the authorization from the 5G DDNMF for monitoring for a target UE. See Figure 5.2.2.4.2-1. The request contains the UE’s identity (/{ueId}) which shall be a SUPI or GPSI and the discovery Entry ID (/{discEntryId}) which is used to identify the discovery entry related to this request.

Figure 5.2.2.4.2-1: Obtain the authorization to monitor for a UE

1. The NF Service Consumer shall send an HTTP PUT request to the resource representing the authorization to monitor for a UE to obtain the authorization to monitor for this UE. The request shall include the Discovery Type, if the Discovery Type is OPEN the Monitor Authorisation Data for open discovery shall be included, and if the Discovery Type is RESTRICTED the Monitor Authorisation Data for restricted discovery shall be included in the HTTP PUT request body.

2a. If the context indicated by the discEntryId doesn’t exist, the 5G DDNMF shall create the new resource, and upon success of creation of the resource, "201 created" shall be returned. The response body shall contain the parameters related to the determined authorization data to monitor for the UE.

2c. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.1-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.3.1-3.

5.2.2.5 MonitorUpdate

5.2.2.5.1 General

The MonitorUpdate service operation shall be used by the NF Service consumer to update or revoke the authorization for the indicated UE to monitor in the PLMN. The following procedures are supported using the MonitorUpdate service operation:

– Direct Discovery Update Procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.7).

5.2.2.5.2 Update the authorization for monitoring for a UE

The MonitorUpdate service operation is invoked by a NF Service Consumer, e.g. HPLMN 5G DDNMF, towards the 5G DDNMF (e.g. VPLMN 5G DDNMF or Local PLMN 5G DDNMF) to request to update the authorization for monitoring in the PLMN from the 5G DDNMF for a target UE. See Figure 5.2.2.5.2-1. The request contains the UE’s identity (/{ueId}) which shall be a SUPI or GPSI and the discovery Entry ID (/{discEntryId}) which is used to identify the discovery entry related to this request.

Figure 5.2.2.5.2-1: Update the authorization for monitoring for a UE

1. The NF Service Consumer shall send an HTTP PATCH request to the resource representing the authorization to monitor for a UE to update or revoke the authorization for the indicated UE to monitor in the PLMN. The request shall include Discovery Type, if the Discovery Type indicates "RESTRICTED", the ProSe Application ID Name, and the TTL shall be included in the HTTP PATCH request body. And if the value of TTL in the request sets to zero, it indicates to revoke the previously authorized monitoring to the given Discovery Entry ID, if the Discovery Type indicates "OPEN", ProSe Restricted Code, Application ID, Banned RPAUID, and Banned PDUID shall be included in the HTTP PATCH request body, and monitorUpdateResultCallbackRef may be included in the request body if the NF Service Consumer expects to receive the monitoring revocation results

2a. On success, "204 No Content" shall be returned.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.3.3.2-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.3.3.2-3.

5.2.2.6 MonitorUpdateResult

5.2.2.6.1 General

The MonitorUpdateResult service operation shall be used by the 5G DDNMF to notify the NF Service consumer of the 5G DDNMF of the monitoring revocation results. The following procedures are supported using the MonitorUpdateResult service operation:

– Direct Discovery Update Procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.7).

5.2.2.6.2 Monitor Update Result Notification

The MonitorUpdateResult service operation notifies the NF service consumer (e.g. HPLMN 5G DDNMF) serving the user about the monitoring revocation results for the user. The request contains the monitorUpdateResultCallbackRef URI. See Figure 5.2.2.6.2-1.

Figure 5.2.2.6.2-1: Monitor Update Result Notification

1. The 5G DDNMF sends a POST request to the monitorUpdateResultCallbackRef to notify the NF service consumer about the monitoring revocation results for the user. The request shall the Discovery Type, the ProSe Restricted Code, the Application ID, the Banned RPAUID, the Banned PDUID, and the monitoring revocation results.

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

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.5.2.3.1-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.5.2.3.1-3.

5.2.2.7 DiscoveryAuthorize

5.2.2.7.1 General

The DiscoveryAuthorize service operation shall be used by the NF Service consumer to obtain the authorization from the 5G DDNMF for a discoverer UE in the PLMN to operate Model B restricted discovery. The following procedures are supported using the DiscoveryAuthorize service operation:

– Discovery Request procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.4).

5.2.2.7.2 Obtain the authorization for a discoverer UE to operate Model B restricted discovery

The DiscoveryAuthorize service operation is invoked by a NF Service Consumer, e.g. HPLMN 5G DDNMF, towards the 5G DDNMF (e.g. VPLMN 5G DDNMF or Local PLMN 5G DDNMF) to request to obtain the authorization from the 5G DDNMF for a discoverer UE in the PLMN to operate Model B restricted discovery. See Figure 5.2.2.7.2-1. The request contains the UE’s identity (/{ueId}) which shall be a SUPI or GPSI and the discovery Entry ID (/{discEntryId}) which is used to identify the discovery entry related to this request.

Figure 5.2.2.7.2-1: Obtain the authorization for a discoverer UE to operate Model B restricted discovery

1. The NF Service Consumer shall send an HTTP PUT request to the resource representing the authorization for a discoverer UE to obtain the authorization for a discoverer UE to operate Model B restricted discovery. The request shall include the Discovery Type, authorisation data for restricted discovery in the HTTP PUT request body.

2c. On failure or redirection, one of the HTTP status code listed in Table 6.1.3.4.3.1-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.4.3.1-3.

5.2.2.8 MatchReport

5.2.2.8.1 General

The MatchReport service operation shall be used by the NF Service consumer to obtain the information about the indicated discovery code from the 5G DDNMF. The following procedures are supported using the MatchReport service operation:

– Discovery Reporting procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.5).

5.2.2.8.2 Obtain the information about the indicated discovery code

The MatchReport service operation is invoked by a NF Service Consumer, e.g. HPLMN 5G DDNMF, towards the 5G DDNMF (e.g. VPLMN 5G DDNMF or Local PLMN 5G DDNMF) to request to obtain the information about the indicated discovery code from the 5G DDNMF. See Figure 5.2.2.8.2-1. The request contains the UE’s identity (/{ueId}) which shall be a SUPI or GPSI, the type of request (/match-report).

Figure 5.2.2.8.2-1: Obtain the information about the indicated discovery code

1. The NF Service Consumer shall send an HTTP POST request to the resource representing the information about the indicated discovery code to obtain the information about the indicated discovery code. The request shall include the Discovery Type, the ProSe Application Codes if the discovery type is OPEN in the HTTP POST request body, and optionally includes Monitored PLMN ID in the HTTP POST request body.

2a. On success, "200 OK" shall be returned. The response body shall contain the parameters related to the information about the indicated discovery code.

2b On failure or redirection, one of the HTTP status code listed in Table 6.1.3.5.3.1-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.3.5.3.1-3.

5.2.2.9 MatchInformation

5.2.2.9.1 General

The MatchInformation service operation shall be used by the 5G DDNMF to notify the NF Service consumer of a matching result, and the information that can be used for charging purpose. The following procedures are supported using the MatchInformation service operation:

– Discovery Reporting procedures (see 3GPP 3GPP TS 23.304 [4], clause 6.3.1.5)

5.2.2.9.2 Match Information Notification

The MatchInformation service operation notifies the NF service consumer (e.g. VPLMN 5G DDNMF or Local PLMN 5G DDNMF) about match information including a matching result, and the information can be used for charging purpose. The request contains the matchInfoCallbackRef URI. See Figure 5.2.2.9.2-1.

Figure 5.2.2.9.2-1: Match Information Notification

1. The 5G DDNMF sends a POST request to the matchInfoCallbackRef URI to notify the NF service consumer about match information including a matching result, and the information can be used for charging purpose. The request shall include the Discovery Type, match report information for open discovery type if match report information for open discovery type is OPEN, and match report information for restricted discovery type if match report information for open discovery type is RESTRICTED

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

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.5.3.3.1-3 may be returned. For a 4xx/5xx response, the message body may contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.5.3.3.1-3.