6.2.8 Announcing Alert procedure

24.3343GPPProximity-services (ProSe) User Equipment (UE) to ProSe function protocol aspectsRelease 17Stage 3TS

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

6.2.8.1 General

The purpose of the Announcing Alert procedure is for the ProSe Function in HPLMN to send to the announcing UE the ProSe Restricted Code generated in the announce request procedure for restricted ProSe direct discovery model A as specified in clause 6.2.2A.

Before initiating the Announcing Alert procedure, the ProSe Function 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 PC5_DISCOVERY message and passes the 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.8.2 Announcing Alert procedure initiation

If the UE has initiated an announce request procedure for restricted ProSe direct discovery model A before as specified in clause 6.2.2A and the On Demand Announcing Enabled Indicator associated with the RPAUID in the announcing UE context is set to 1, the ProSe Function shall initiate an Announcing Alert procedure:

a) when the ProSe Function receives a pair of Target PDUID -Target RPAUID from the ProSe Application Server as described in 3GPP TS 29.343[31], the Target RPAUID is the same as the RPAUID stored in the announcing UE context, and ProSe Function determines the monitoring UE is in the vicinity of the announcing UE; or

b) when the ProSe Function receives a pair of Target PDUID -Target RPAUID from other ProSe Functions as described in 3GPP TS 29.345[5], the Target RPAUID is the same as the RPAUID stored in the announcing UE context and the ProSe Function determines the monitoring UE is in the vicinity of the announcing UE.

NOTE: How the ProSe Function 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 ProSe Function.

The ProSe Function initiates the Announce Alert procedure by sending an ANNOUNCING_ALERT_REQUEST message with:

– a new ProSe Function transaction ID;

– the UE identity set to the UE’s IMSI;

– the RPAUID set to the Target RPAUID received from ProSe Application Server as specified in 3GPP TS 29.343[31] or from other ProSe Functions as specified in 3GPP TS 29.345[5];

– the ProSe Restricted Code set to the ProSe Restricted Code or the ProSe Restricted Code Prefix, and optionally one or more ProSe Restricted Code Suffix Ranges which contain the suffix(es) for the RPAUID retrieved from the announcing UE context; and

– the Discovery Entry ID set to the identifier associated with the corresponding discovery entry in the UE’s context.

Figure 6.2.8.2.1 illustrates the interaction of the ProSe Function and the UE in the Announce Alert procedure.

Figure 6.2.8.2.1: Announcing Alert procedure

6.2.8.3 Announcing Alert procedure accepted by the UE

Upon receipt of the ANNOUNCING_ALERT_REQUEST message, the UE shall check if the UE identity contained in the ANNOUNCING_ALERT_REQUEST message is the IMSI of the UE. If the UE identity is the IMSI of the UE, 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 ANNOUNCE_ALERT_RESPONSE message to the ProSe Function with a ProSe Function transaction ID set to the value of the ProSe Function transaction ID received in the ANNOUNCING_ALERT_REQUEST message.

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

The UE requests the parameters from the lower layers for restricted Prose direct discovery model A announcing (see 3GPP TS 36.331 [12]). The UE shall perform restricted 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 EMM-IDLE mode has to request resources for ProSe direct discovery announcing as specified in 3GPP TS 36.331 [12], the UE shall perform a service request procedure or tracking area update procedure as specified in 3GPP TS 24.301 [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 subclause 12.2.2.18. 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 to compute the MIC field for the PC5_DISCOVERY message as described in 3GPP TS 33.303 [6].

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 PC5_DISCOVERY message, according to the format defined in subclause 11.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 ProSe Function, as long as the validity timer T4007 of the ProSe Restricted Code Prefix has not expired.

The UE then passes the PC5_DISCOVERY message to the lower layers for transmission if:

– the UE is currently authorised to perform restricted ProSe direct discovery model A announcing in the registered PLMN or the local PLMN operating the radio resources that the UE intends to use;

– the validity timer T4007 for the corresponding discovery entry allocated ProSe Restricted Code or ProSe Restricted Code Prefix has not expired; and

– a request from upper layers to announce the RPAUID associated with both the ProSe Restricted Code or ProSe Restricted Code Prefix, and the authorised Application Identity, is still in place.

The UE shall ensure that it keeps on passing PC5_DISCOVERY messages to the lower layers for transmission until the validity timer T4007 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 eNodeB and the UE is in EMM-CONNECTED mode, the UE shall trigger the corresponding procedure in lower layers as specified in 3GPP TS 36.331 [12].

6.2.8.4 Announcing Alert procedure completion by the ProSe Function

Upon receipt of the ANNOUNCE_ALERT_RESPONSE message with a ProSe Function transaction ID set to the value of the ProSe Function Transaction ID included in the ANNOUNCING_ALERT_REQUEST message, the ProSe Function will set the associated On Demand Announcing Enabled Indicator to 0. Then the Announcing Alert procedure is successfully completed.

6.2.8.4A Announcing Alert procedure not accepted by the UE

If the ANNOUNCING_ALERT_REQUEST message cannot be accepted by the UE, the UE sends a ANNOUNCING_ALERT_RESPONSE message containing a <response-reject> element to the ProSe Function including an appropriate PC3 Control Protocol cause value.

If the UE identity contained in the ANNOUNCING_ALERT_REQUEST message is not the IMSI of the UE, the UE shall send a ANNOUNCING_ALERT_RESPONSE message containing a <response-reject> element with PC3 Control Protocol cause value #18 "Invalid UE Identity".

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 PC3 Control Protocol cause value #10"Unknown or Invalid Discovery Entry ID".

6.2.8.5 Abnormal cases

6.2.8.5.1 Abnormal cases in the ProSe Function

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 ProSe Function 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 ProSe Function shall retransmit the ANNOUNCING_ALERT_REQUEST message.

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

6.2.8.5.2 Abnormal cases in the UE

The following abnormal cases can be identified:

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

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