6.2.3 Announce request procedure for restricted 5G ProSe direct discovery model A

24.5543GPPProximity-services (ProSe) in 5G System (5GS) protocol aspectsRelease 17Stage 3TS

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

6.2.3.1 General

The purpose of the announce request procedure for restricted 5G ProSe direct discovery model A is for the UE:

a) to obtain a ProSe restricted code corresponding to the RPAUID to be announced over the PC5 interface, upon a request for announcing from upper layers (e.g., application client) as defined in 3GPP TS 23.304 [2]; or

b) to inform the 5G DDNMF that the UE wants to stop announcing a ProSe restricted code as defined in 3GPP TS 23.304 [2].

Before initiating the announce request procedure, the UE shall be authorized for restricted 5G ProSe direct discovery model A announcing in the registered PLMN or local PLMN based on the service authorization procedure as specified in clause 5.

The UE includes the ProSe restricted code obtained from a successful announce request procedure in a PROSE PC5 DISCOVERY message and passes the PROSE PC5 DISCOVERY message to the lower layers for transmission over the PC5 interface.

6.2.3.2 Announce request procedure initiation

Before initiating the announce request procedure, the user sets the permissions for the restricted discovery using application layer mechanisms. The application client in the UE retrieves the PDUID provisioned to the UE as part of the service authorization procedure as specified in clause 5 and obtains an RPAUID associated with the UE’s PDUID from the ProSe application server. The UE may provide metadata to be associated with the RPAUID and the ProSe application server stores the metadata. This step is performed using mechanisms that are out of scope of the present specification.

If the UE is authorized to perform restricted 5G ProSe direct discovery model A announcing in the PLMN operating the radio resources signalled from the serving PLMN, it shall initiate an announce request procedure:

a) when the UE is triggered by an upper layer application to announce an RPAUID and the UE has no valid corresponding ProSe restricted code for that RPAUID of the upper layer application;

b) when the validity timer T5062 assigned by the 5G DDNMF to a ProSe restricted code has expired and the request from upper layers to announce the RPAUID corresponding to that ProSe restricted code is still in place;

c) when the UE selects a new PLMN while announcing a ProSe restricted code and intends to announce in the new PLMN and the UE is authorized for restricted 5G ProSe direct discovery model A announcing in the new PLMN;

d) when, while announcing a RPAUID, the UE intends to switch the announcing PLMN to a different PLMN without performing PLMN selection and the UE does not have a valid allocated ProSe restricted code for this new PLMN yet; or

e) when the UE needs to update a previously sent restricted 5G ProSe direct discovery model A announcing request.

When the UE selects a new PLMN while announcing a ProSe restricted code and the UE is not yet authorized for restricted 5G ProSe direct discovery model A announcing in the new PLMN, the UE shall initiate an announce request procedure only after the UE is authorized for restricted 5G ProSe direct discovery model A announcing in the new PLMN.

NOTE 1: To ensure service continuity if the UE needs to keep announcing a ProSe restricted code corresponding to the same RPAUID, the UE can initiate the announce request procedure before the validity timer T5062 assigned by the 5G DDNMF for a ProSe restricted code expires.

The UE shall initiate the announce request procedure by sending a DISCOVERY_REQUEST message with:

a) a new transaction ID not used in any other direct discovery procedures in PC3a interface;

b) the RPAUID set to the RPAUID received from upper layers;

c) the command set to "announce";

d) the application identity set to the ProSe identifier of the upper layer application that requested the announcing as specified in clause 5.2.3;

e) the discovery type set to "Restricted discovery";

r) the ACE enabled indicator set to "application-controlled extension enabled" if application-controlled extension is required by the upper layers or "normal" if application-controlled extension is not used;

g) the announcing type set to "on demand" if on demand announcing is requested by upper layers and "normal" if on demand announcing is not requested by upper layers;

h) optionally the requested timer set to the length of validity timer associated with the ProSe restricted code that the UE expects to receive from the 5G DDNMF;

i) the discovery entry ID set to a 0 if the announcing request is a new request and set to the discovery entry ID received from the 5G DDNMF if the announcing request is to update a previously sent announcing request;

j) optionally the announcing PLMN ID set to the PLMN ID of the local PLMN operating the radio resources that the UE intends to use for announcing the RPAUID; and

k) the PC5 UE ciphering algorithm capability set to the UE supported ciphering algorithm(s) for ciphering the PROSE PC5 DISCOVERY message.

If restricted 5G ProSe direct discovery model A with application-controlled extension is requested by upper layers, the DISCOVERY_REQUEST message shall also include the application level container, which contains application-level data transparent to the 3GPP network, to be used by the ProSe application server e.g., to assign ProSe restricted code suffix(es).

When the UE initiates the announce request procedure to inform the 5G DDNMF that the UE wants to stop announcing a ProSe restricted code before the associated valid timer expires, the UE shall set the requested timer to 0.

NOTE 2: A UE can include one or multiple transactions in one DISCOVERY_REQUEST message for different RPAUIDs and receive corresponding <restricted-announce-response> element or <response-reject> element in a DISCOVERY_RESPONSE message for each respective transaction. In the following description of the announce request procedure, only one transaction is included.

Figure 6.2.3.2.1 illustrates the interaction of the UE and the 5G DDNMF in the announce request procedure.

Figure 6.2.3.2.1: Announce request procedure for restricted 5G ProSe direct discovery model A

6.2.3.3 Announce request procedure accepted by the 5G DDNMF

Upon receiving a DISCOVERY_REQUEST message with the command set to "announce" and the discovery type set to "Restricted discovery", if the requested timer is included in the DISCOVERY_REQUEST message and the requested timer is set to 0, the 5G DDNMF shall check whether there is an existing UE context containing the discovery entry identified by the discovery entry ID included in the DISCOVERY_REQUEST message. If the discovery entry exists in the UE context, the 5G DDNMF shall inform the 5G DDNMF in the announcing PLMN to remove the corresponding discovery entry as specified in 3GPP TS 29.555 [9] when the announcing PLMN is not the same as that of the PLMN to which the 5G DDNMF belongs and remove the discovery entry identified by the discovery entry ID from the UE’s context.

Upon receiving a DISCOVERY_REQUEST message with the command set to "announce" and the discovery type set to "Restricted discovery", if the requested timer is not included in the DISCOVERY_REQUEST message or the requested timer included in the DISCOVERY_REQUEST message is not set to 0, the 5G DDNMF shall perform the following procedure.

The 5G DDNMF shall check that the application corresponding to the ProSe identifier contained in the DISCOVERY_REQUEST message is authorized for restricted 5G ProSe direct discovery model A announcing. If the application is authorized for restricted 5G ProSe direct discovery model A announcing, the 5G DDNMF shall check whether there is an existing context for the UE.

If there is no associated UE context, the 5G DDNMF checks with the UDM whether the UE is authorized for restricted 5G ProSe direct discovery model A announcing as described in 3GPP TS 29.503 [10]. If the check indicates that the UE is authorized, the 5G DDNMF creates a UE context that contains the UE’s subscription parameters obtained from the UDM. The UDM also provides to the 5G DDNMF the PLMN ID of the PLMN in which the UE is currently registered. If the UE context exists, the 5G DDNMF shall then check whether the UE is authorized for restricted 5G ProSe direct discovery model A announcing in the currently registered PLMN or in the local PLMN identified by the Announcing PLMN ID included in the DISCOVERY_REQUEST message.

If the UE is authorized and the discovery entry ID included in the DISCOVERY_REQUEST message is set to 0 then:

a) the 5G DDNMF shall check whether the UE is authorized to announce the RPAUID contained in the DISCOVERY_REQUEST message. Optionally this can include checking with the ProSe application server as described in 3GPP TS 29.557 [19] to obtain the binding between the RPAUID and PDUID and then verifying that the PDUID belongs to the requesting UE;

b) if the UE is authorized to announce the RPAUID, the ACE enabled indicator is set to "application-controlled extension enabled", the application level container is included in the DISCOVERY_REQUEST message and the requested application uses application-controlled extension, the 5G DDNMF shall check whether the UE is authorized to use ACE. If the UE is authorized for ACE, the 5G DDNMF shall invoke the procedure described in 3GPP TS 29.557 [19] to check whether the UE is authorized to announce the requested RPAUID with application-defined suffix(es) and obtain suffix-related information from the ProSe application server. The 5G DDNMF shall then allocate a ProSe restricted code prefix and a value for validity timer T5062 to be used with the ProSe restricted code suffix(es) obtained from the ProSe application server for the given RPAUID as specified in 3GPP TS 29.557 [19]. The 5G DDNMF may take into account the requested timer if contained in the DISCOVERY_REQUEST message when allocating validity timer T5062;

c) if the UE is authorized to announce the RPAUID, the ACE enabled indicator is set to "normal" in the DISCOVERY_REQUEST message and the requested application does not use application-controlled extension, the 5G DDNMF shall allocate the corresponding ProSe restricted code and a value for validity timer T5062. The 5G DDNMF may take into account the requested timer if contained in the DISCOVERY_REQUEST message when allocating validity timer T5062;

d) if the UE is authorized to announce the RPAUID, the ACE enabled indicator is set to "normal" in the DISCOVERY_REQUEST message, the application level container is included in the DISCOVERY_REQUEST and the requested application only uses application-controlled extension, the 5G DDNMF shall check whether the UE is authorized to use ACE. If the UE is authorized for ACE, the 5G DDNMF shall invoke the procedure described in 3GPP TS 29.557 [19] to check whether the UE is authorized to announce the requested RPAUID with application-defined suffix(es) and obtain suffix-related information from the ProSe application server. The 5G DDNMF shall then allocate a ProSe restricted code prefix and a value for validity timer T5062 to be used with the ProSe restricted code suffix(es) obtained from the ProSe application server for the given RPAUID as specified in 3GPP TS 29.557 [19] The 5G DDNMF may consider the requested timer if contained in the DISCOVERY_REQUEST message when allocating validity timer T5062;

e) if the UE is authorized to announce the RPAUID, the ACE enabled indicator is set to "application-controlled-extension enabled" and the application level container is included in the DISCOVERY_REQUEST message but the requested application does not use application-controlled extension, the 5G DDNMF shall allocate the corresponding ProSe restricted code and a value for validity timer T5062. The 5G DDNMF may consider the requested timer if contained in the DISCOVERY_REQUEST message when allocating validity timer T5062; and

f) the 5G DDNMF associates the allocated ProSe restricted code or ProSe restricted code prefix with a new discovery entry in the UE’s context and starts timer T5063. The UDM also provides to the 5G DDNMF the PLMN ID of the PLMN in which the UE is currently registered. For a given ProSe restricted code, timer T5063 shall be longer than timer T5062. By default, the value of timer T5063 is 4 minutes greater than the value of timer T5062.

If the discovery entry ID included in the DISCOVERY_REQUEST message is not set to 0 and if there is an existing discovery entry for this discovery entry ID value in the UE’s context, the 5G DDNMF shall either update the discovery entry with a new validity timer T5062, or allocate a new ProSe restricted code or ProSe restricted code prefix for the requested RPAUID with a new validity timer T5062, restart timer T5063 and clear any existing on demand announcing enabled indicator. The 5G DDNMF may consider the requested timer if contained in the DISCOVERY_REQUEST message when allocating validity timer T5062.

If the discovery entry ID contained in the DISCOVERY_REQUEST message is not found in the UE context or there is no UE context in the 5G DDNMF, the 5G DDNMF shall behave as if the discovery entry ID included in the DISCOVERY_REQUEST message was set to 0 and the 5G DDNMF shall allocate a new non-zero discovery entry ID for this entry.

If the announcing type is set to "on demand" in the DISCOVERY_REQUEST message, the 5G DDNMF shall check if "on demand" announcing is authorized and enabled based on the ProSe identifier and the operator’s policy. If "on demand" announcing is authorized and enabled and there is no ongoing monitoring request for this RPAUID, then the 5G DDNMF shall set the on demand announcing enabled indicator to 1 for the corresponding discovery entry in the UE’s context.

If a new UE context was created or an existing UE context was updated and the UE is currently roaming or the announcing PLMN ID is included in the DISCOVERY_REQUEST message and the on demand announcing enabled indicator is not set to 1 for this discovery entry in the UE’s context, the 5G DDNMF checks with the 5G DDNMF of the VPLMN or the local PLMN represented by the Announcing PLMN ID whether the UE is authorized for restricted 5G ProSe direct discovery model A announcing as described in 3GPP TS 29.555 [9].

The 5G DDNMF shall then send a DISCOVERY_RESPONSE message containing a <restricted-announce-response> element with:

a) the transaction ID set to the value of the transaction ID received in the DISCOVERY_REQUEST message from the UE;

b) if the on demand announcing enabled indicator is not set to 1 in the UE’s context for this discovery entry, either the ProSe restricted code set to the ProSe restricted code or the ProSe restricted code prefix allocated by the 5G DDNMF. If restricted Direct Discovery with application-controlled extension was requested by the announcing UE , the DISCOVERY_RESPONSE message also contains one or more ProSe restricted code suffix Ranges which contain the suffix(es) for the RPAUID received in the DISCOVERY_REQUEST message;

c) a validity timer T5062 set to the T5062 timer value assigned by the 5G DDNMF to the ProSe restricted code;

d) the ACE enabled indicator set to "application-controlled extension enabled" if application-controlled extension is used, or "normal" if application-controlled extension is not used;

e) the code-sending security parameter containing the security-related information for the UE to protect the transmission of the ProSe restricted code;

f) the on demand announcing enabled indicator indicating whether the on demand announcing is enabled or not for this discovery entry if the announcing type is set to "on demand" in the DISCOVERY_REQUEST message;

g) the discovery entry ID set to the ID of the discovery entry associated with this announce request in the UE’s context;

h) the current time set to the current UTC-based time at the 5G DDNMF and the max offset;

i) optionally, the PC5 security policies that are associated with the ProSe restricted code and used for 5G ProSe direct link establishment procedure instead of any PC5 security policies configured in the UE as specified in clause 5; and

j) the selected PC5 ciphering algorithm set to the PC5 ciphering algorithm selected by the 5G DDNMF based on the received PC5 UE ciphering algorithm capability and the ProSe restricted code.

If timer T5063 expires, the 5G DDNMF shall remove the discovery entry associated with the corresponding RPAUID from the UE’s context.

The 5G DDNMF may associate the ProSe restricted code with the PC5 security policies.

The 5G DDNMF uses the information (e.g. application identity) received from the UE in the DISCOVERY_REQUEST message, UE identity in GBA or AKMA information related to TLS tunnel transporting the DISCOVERY_REQUEST message, and other information for charging purposes as specified in 3GPP TS 32.277 [45].

6.2.3.4 Announce request procedure completion by the UE

Upon receipt of the DISCOVERY_RESPONSE message, if only the transaction ID and the discovery entry ID are contained in the <restricted-announce-response> element and the transaction ID and the discovery entry ID match the corresponding values sent by the UE in a DISCOVERY_REQUEST message, the UE shall:

a) stop the validity timer T5062 for the discovery entry corresponding to the discovery entry ID received in the DISCOVERY_RESPONSE message;

b) remove the discovery entry identified by the discovery entry ID included; and

c) instruct the lower layers to stop announcing.

Upon receipt of the DISCOVERY_RESPONSE message, if the transaction ID contained in the <restricted-announce-response> element matches the value sent by the UE in a DISCOVERY_REQUEST message with the command set to "announce", the UE shall create a new discovery entry or update an existing discovery entry with the received ProSe restricted code or ProSe restricted code prefix and the PLMN ID of the intended announcing PLMN. For this discovery entry, the UE shall stop the validity timer T5062, if running, for the discovery entry corresponding to the discovery entry ID received in the DISCOVERY_RESPONSE message and start the validity timer T5062 for this discovery entry with the received value in the DISCOVERY_RESPONSE message. Otherwise, the UE shall discard the DISCOVERY_RESPONSE message and shall not perform the procedures below. The UE shall set a ProSe clock (see 3GPP TS 33.503 [34]) to the value of the received current time parameter and store the received max offset parameter.

If the DISCOVERY_RESPONSE message includes new ProSe restricted code or ProSe restricted code prefix to replace the existing ProSe restricted code being announced, the UE shall notify lower layer to stop announcing the old ProSe restricted code in PC5 interface.

The UE shall store the selected PC5 ciphering algorithm received in the DISCOVERY_RESPONSE message for the received ProSe restricted code and use it for protection of the restricted 5G ProSe direct discovery messages over the PC5 interface as specified in clause 6.1.3.2.3 of 3GPP TS 33.503 [34].

If the DISCOVERY_RESPONSE message contains an on demand announcing enabled indicator set to 1, the UE shall wait for an announcing alert Request message from the 5G DDNMF of the HPLMN before starting to perform restricted 5G ProSe direct discovery model A announcing. Otherwise, the UE may perform restricted 5G ProSe direct discovery model A announcing as described in clause 6.2.14.2.1.

6.2.3.5 Announce request procedure not accepted by the 5G DDNMF

If the DISCOVERY_REQUEST message cannot be accepted by the 5G DDNMF, the 5G DDNMF sends a DISCOVERY_RESPONSE message containing a <response-reject> element to the UE including an appropriate PC3a control protocol cause value.

If the application corresponding to the ProSe identifier contained in the DISCOVERY_REQUEST message is not authorized for ProSe direct discovery announcing, the 5G DDNMF shall send the DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #1 "Invalid application".

If the RPAUID contained in the DISCOVERY_REQUEST message is unknown to the 5G DDNMF or ProSe application server, the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #9 "Unknown RPAUID".

If the RPAUID contained in the DISCOVERY_REQUEST message does not match the stored RPAUID for the requested discovery entry ID, the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #10 "Unknown or invalid discovery entry ID".

If the UE is not authorized for restricted 5G ProSe direct discovery model A announcing, the 5G DDNMF shall send the DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #3 "UE authorization failure".

If the UE is not authorized for restricted "on demand" restricted 5G ProSe direct discovery model A announcing, the 5G DDNMF shall send the DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #13 "UE unauthorized for on-demand announcing".

If the RPAUID contained in the DISCOVERY_REQUEST message is not associated with the PDUID belonging to the requesting UE, the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #3 "UE authorization Failure".

If the UE is not authorized to use ACE, but the DISCOVERY_REQUEST message contains the ACE enabled indicator set to "application-controlled extension enabled", the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #12 "UE unauthorized for discovery with application-controlled extension".

If the DISCOVERY_REQUEST message contains the ACE enabled indicator set to "application-controlled extension enabled", but does not contain the application level container parameter, the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #14 "Missing application level container".

If the ProSe application server indicates to the 5G DDNMF that the application level container in the DISCOVERY_REQUEST message contains invalid information, the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #15 "Invalid data in application level container".

If the discovery entry ID contained in the DISCOVERY_REQUEST message is unknown to the 5G DDNMF and the requested timer is set to zero, the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value # 10 "Unknown or invalid discovery entry ID".

If the PC5 UE ciphering algorithm capability contained in the DISCOVERY_REQUEST message is not compatible with the selected PC5 ciphering algorithm for the target ProSe restricted code, the 5G DDNMF shall send a DISCOVERY_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #19 "Not compatible PC5 UE ciphering algorithm capability".

6.2.3.6 Abnormal cases

6.2.3.6.1 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Indication from the transport layer of transmission failure of DISCOVERY_REQUEST message (e.g., after TCP retransmission timeout)

The UE shall close the existing secure connection to the 5G DDNMF, establish a new secure connection and then restart the announce request procedure.

NOTE 1: The UE can abort this procedure when detecting loss of NG-RAN coverage in its serving PLMN.

b) No response from the 5G DDNMF after the DISCOVERY_REQUEST message has been successfully delivered (e.g., TCP ACK has been received for the DISCOVERY_REQUEST message)

The UE shall retransmit the DISCOVERY_REQUEST message.

NOTE 2: The UE can abort this procedure when detecting loss of NG-RAN coverage in its serving PLMN.

NOTE 3: The timer to trigger retransmission and the maximum number of allowed retransmissions are UE implementation specific.

c) Indication from upper layers that the request to announce the RPAUID is no longer in place after sending the DISCOVERY_REQUEST message, but before the announce request procedure is completed

The UE shall acknowledge the DISCOVERY_RESPONSE message received from the 5G DDNMF but discard its contents and then abort the procedure.

d) Change of PLMN

If a PLMN change occurs before the announce request procedure is completed, the procedure shall be aborted. If the UE is authorized to announce in the new PLMN, the procedure shall be restarted once the UE is registered on the new PLMN.

6.2.3.6.2 Abnormal cases in the 5G DDNMF

The following abnormal cases can be identified:

a) Indication from the lower layer of transmission failure of DISCOVERY_RESPONSE message

After receiving an indication from lower layer that the DISCOVERY_RESPONSE message has not been successfully acknowledged (e.g. TCP ACK is not received), the 5G DDNMF shall abort the procedure and stop any associated timer(s) T5063, if running.