6.2.13 Announcing alert procedure

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

6.2.13.1 General

The purpose of the announcing alert procedure is for the 5G DDNMF in HPLMN to send to the announcing UE the ProSe restricted code generated in the announce request procedure for restricted 5G ProSe direct discovery model A as specified in clause 6.2.3.

Before initiating the announcing alert procedure, the 5G DDNMF shall determine whether the announcing UE and the monitoring UE are close enough to trigger the announcing alert procedure.

The announcing UE includes the ProSe restricted code in a PROSE PC5 DISCOVERY message and passes the PROSE PC5 DISCOVERY message to the lower layers for transmission over the PC5 interface in the registered PLMN or local PLMN as a result of a successful announcing alert procedure.

6.2.13.2 Announcing alert procedure initiation

If the UE has initiated an announce request procedure for restricted 5G ProSe direct discovery model A before as specified in clause 6.2.3 and the on demand announcing enabled indicator associated with the RPAUID in the announcing UE context is set to 1, the 5G DDNMF shall initiate an announcing alert procedure:

a) when the 5G DDNMF receives a pair of target PDUID – target RPAUID from the ProSe application server as described in 3GPP TS 29.503 [10], the target RPAUID is the same as the RPAUID stored in the announcing UE context and 5G DDNMF determines the monitoring UE is in the vicinity of the announcing UE; or

b) when the 5G DDNMF receives a pair of target PDUID – target RPAUID from other 5G DDNMF as described in 3GPP TS 29.555 [9], the target RPAUID is the same as the RPAUID stored in the announcing UE context and the 5G DDNMF determines the monitoring UE is in the vicinity of the announcing UE.

NOTE: How the 5G DDNMF in the HPLMN determines whether the announcing UE and the monitoring UE are close enough to trigger the announcing alert procedure is left to the implementation of 5G DDNMF.

The 5G DDNMF shall initiate the announcing alert procedure by sending an ANNOUNCING_ALERT_REQUEST message with:

a) a new DDNMF transaction ID;

b) the RPAUID set to the Target RPAUID received from ProSe application server as specified in 3GPP TS 29.503 [10] or from other 5G DDNMF as specified in 3GPP TS 29.555 [9];

c) the ProSe restricted code set to the ProSe restricted code or the ProSe restricted code prefix. If restricted Direct Discovery with application-controlled extension was requested by the announcing UE , the ANNOUNCING_ALERT_REQUEST message also contains one or more ProSe restricted code suffix Ranges which contain the suffix(es) for the RPAUID retrieved from the announcing UE context; and

d) the discovery entry ID set to the identifier associated with the corresponding discovery entry in the UE’s context.

Figure 6.2.13.2.1 illustrates the interaction of the 5G DDNMF and the UE in the Announce Alert procedure.

Figure 6.2.13.2.1: Announcing alert procedure

6.2.13.3 Announcing alert procedure accepted by the UE

Upon receipt of the ANNOUNCING_ALERT_REQUEST message, the UE shall check whether there is an existing discovery entry identified by the discovery entry ID included in the ANNOUNCING_ALERT_REQUEST message. If the discovery entry exists in the UE, the UE shall send an ANNOUNING_ALERT_RESPONSE message to the 5G DDNMF with a DDNMF transaction ID set to the value of the DDNMF transaction ID received in the ANNOUNCING_ALERT_REQUEST message.

Then, the UE may perform restricted 5G ProSe direct discovery model A announcing as described below.

The UE requests the parameters from the lower layers for restricted 5G ProSe direct discovery model A announcing (see 3GPP TS 38.331 [13]). The UE shall perform restricted 5G ProSe direct discovery model A announcing only if the lower layers indicate that ProSe direct discovery is supported by the network. If the UE in 5GMM-IDLE mode has to request resources for ProSe direct discovery announcing as specified in 3GPP TS 38.331 [13], the UE shall perform a service request procedure or registration procedure as specified in 3GPP TS 24.501 [11]. The UE shall obtain the UTC time for the next discovery transmission opportunity for ProSe direct discovery from the lower layers.

If a valid UTC time is obtained, the UE shall generate the UTC-based counter corresponding to this UTC time as specified in clause 11.2.5. If the resulting UTC-based counter is within Max Offset of the time shown by the clock used for ProSe by the UE, the UE shall use the UTC-based counter and the DUIK contained in the <restricted-announce-response> element of the DISCOVERY_RESPONSE message to compute the MIC field for the PROSE PC5 DISCOVERY message as described in 3GPP TS 33.503 [34].

The UE shall either use the ProSe restricted code received in the ANNOUNCING_ALERT_REQUEST message, or select one ProSe restricted code based on the ProSe restricted code prefix and ProSe restricted code suffix Range(s) received in the ANNOUNCING_ALERT_REQUEST message as announced ProSe restricted code, along with the MIC and the eight least significant bits of the UTC-based counter, in order to construct a PROSE PC5 DISCOVERY message, according to the format defined in clause 10.2.5.

NOTE: The UE can use different codes formed based on different ProSe restricted code suffixes to announce, without having to send a new DISCOVERY_REQUEST message to the 5G DDNMF, as long as the validity timer T5062 of the ProSe restricted code prefix has not expired.

The UE then passes the PROSE PC5 DISCOVERY message to the lower layers for transmission if:

a) the UE is currently authorized to perform restricted 5G ProSe direct discovery model A announcing in the registered PLMN or the local PLMN operating the radio resources that the UE intends to use;

b) the validity timer T5062 for the corresponding discovery entry allocated ProSe restricted code or ProSe restricted code prefix has not expired; and

c) a request from upper layers to announce the RPAUID associated with both the ProSe restricted code or ProSe restricted code prefix and the authorized ProSe identifier, is still in place.

The UE shall ensure that it keeps on passing PROSE PC5 DISCOVERY messages to the lower layers for transmission until the validity timer T5062 of the ProSe restricted code or ProSe restricted code prefix expires. How this is achieved is left up to UE implementation.

During the announcing operation, if one of the above conditions is no longer met, the UE may instruct the lower layers to stop announcing. When the UE stops announcing, if the lower layers indicate that the UE is required to send a discovery indication to the NG-RAN and the UE is in 5GMM-CONNECTED mode, the UE shall trigger the corresponding procedure in lower layers as specified in 3GPP TS 38.331 [13].

6.2.13.4 Announcing alert procedure completion by the 5G DDNMF

Upon receipt of the ANNOUNCING_ALERT_RESPONSE message with a DDNMF transaction ID set to the value of the DDNMF transaction ID included in the ANNOUNCING_ALERT_REQUEST message, the 5G DDNMF will set the associated on demand announcing enabled indicator to 0. Then the announcing alert procedure is successfully completed.

6.2.13.5 Announcing alert procedure not accepted by the UE

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

If the discovery entry ID contained in the ANNOUNCING_ALERT_REQUEST message is unknown, the UE shall send the ANNOUNCING_ALERT_RESPONSE message containing a <response-reject> element with PC3a control protocol cause value #10"Unknown or invalid discovery entry ID".

6.2.13.6 Abnormal cases

6.2.13.6.1 Abnormal cases in the 5G DDNMF

The following abnormal cases can be identified:

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

The 5G DDNMF shall close the existing secure connection to the UE.

b) No response from the UE after the ANNOUNCING_ALERT_REQUEST message has been successfully delivered (e.g., TCP ACK has been received for the ANNOUNCING_ALERT_REQUEST message)

The 5G DDNMF shall retransmit the ANNOUNCING_ALERT_REQUEST message.

NOTE: The timer to trigger retransmission and the maximum number of allowed retransmissions are 5G DDNMF implementation specific.

6.2.13.6.2 Abnormal cases in the UE

The following abnormal cases can be identified:

a) Indication from the lower layer of transmission failure of ANNOUNCING_ALERT_RESPONSE message.

After receiving an indication from lower layer that the ANNOUNCING_ALERT_RESPONSE message has not been successfully acknowledged (e.g., TCP ACK is not received), the UE shall abort the procedure.