7 EPC-level ProSe discovery

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

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

7.1 Overview

This clause describes the PC3 Control Protocol procedures between the UE and the ProSe Function for EPC-level ProSe discovery.

7.1.1 Transport protocol for PC3 Control Protocol messages for EPC-level ProSe discovery

The UE and the ProSe Function shall use HTTP 1.1 as specified in IETF RFC 7230 [18] and IETF RFC 7231 [19] as the transport protocol for EPC-level ProSe discovery messages over the PC3 interface. The ProSe messages described here shall be included in the body of either an HTTP request message or an HTTP response message.

7.1.2 Handling of UE-initiated procedures

The following rules apply for UE-initiated procedures:

– The UE initiates ProSe transactions with an HTTP request message containing the PC3 request(s); and

– The ProSe Function responds to the requests with an HTTP response message containing the PC3 response(s) for the PC3 request(s).

Optionally, the operator can configure the UE with configuration parameters for establishment of the PDN connection for reaching the HPLMN ProSe Function. If the UE is configured with the configuration parameter for establishment of the PDN connection for reaching the HPLMN ProSe Function (see 3GPP TS 24.333 [9]):

a) if a PDN connection for reaching the HPLMN ProSe Function is not established yet, the UE shall establish the PDN connection for reaching the HPLMN ProSe Function according to the UE configuration and shall send the HTTP request message via the PDN connection for reaching the HPLMN ProSe Function; and

b) if a PDN connection for reaching the HPLMN ProSe Function is already established (e.g. either due to other ProSe feature or due to other application), the UE shall send the HTTP request message via the PDN connection for reaching the HPLMN ProSe Function;

7.1.3 Handling of network-initiated procedures

The network-initiated messages for EPC-level ProSe discovery over the PC3 interface shall be contained in an HTTP response message. Either HTTP long polling, or OMA Push, can be used to trigger the HTTP request corresponding to this HTTP response message. The UE and the ProSe Function shall support OMA Push for network initiated procedures. Optionally the UE and ProSe Function should support long polling as well for network initiated procedures.

During the UE registration procedure, the UE and the ProSe Function decide which method to use. If the UE supports long polling method, the UE indicates that to the ProSe Function in the UE-registration request with a "Method for server-initiated transaction" IE. If the ProSe Function supports long polling method as well and if it prefers to use the long polling method for network initiated procedures, then it checks if UE can also support long polling method via the "Method for server-initiated transaction" IE included in the registration request message and indicates the use of long-polling in the registration response message. If the ProSe Function supports OMA Push only or if it chooses to use OMA Push then it ignores the "Method for server-initiated transaction"IE in UE registration request.

7.1.3.1 HTTP long polling

The HTTP long polling method involves the following steps:

a) the UE sends an empty HTTP request message as a polling request when it expects network initiated message(s) over the PC3 interface;

b) the ProSe Function defers its response to the UE’s request until;

i) one ore more network-initiated PC3 message(s) for the UE are available. The ProSe Function will enclose the message(s) in an HTTP response message and send it to the UE; or

ii) a particular timeout for HTTP polling has occurred. The ProSe Function then sends an empty HTTP response message as the polling response to the UE.

c) After receiving the response from the ProSe Function, the UE may keep polling after some waiting period if:

i) the UE receives an empty polling response; or

ii) the UE receives network-initiated message(s) from the ProSe Function but still expects additional network-initiated message(s).

NOTE: The implementation of the HTTP polling process can be coordinated with the SUPL (Secure User Plane Location) procedures to synchronize the SUPL location report procedures and the HTTP polling procedure so as to reduce unnecessary wait time of polling.

If the UE is trigged to send a PC3 message to the ProSe Function while it has a pending HTTP polling request, the UE shall open another HTTP connection to the ProSe Function to send this new request. Alternately the UE may always use a separate dedicated HTTP connection for polling.

7.1.3.2 OMA Push

The OMA Push method involves the following steps:

a) if one or more network-initiated PC3 message(s) for the UE are available, the ProSe Function sends a push message containing a particular URL to the UE via the OMA-Push Architecture as defined in OMA-AD-Push-V2_2-20110809-A [22]. The URL is linked to the PC3 message(s) to be sent to the UE. The ProSe Function (performing OMA Push Proxy Gateway functionality) generates a Push Message as specified in OMA-WAP-TS-PushOTA-V2_1-20110405-A [21] with the PDU set according to WAP-168-ServiceLoad-20010731-a [20]. The URL information shall be included in the PDU payload;

b) After receiving the push message, the UE retrieves the URL from the payload of the message and sends an HTTP GET request to the ProSe Function with this URL; and

c) the ProSe Function sends an HTTP response message containing the PC3 message(s) to the UE.

7.2 Procedures

7.2.1 Types of EPC-level ProSe discovery procedures

The following PC3 Control Protocol procedures are defined:

– UE registration;

– application registration;

– proximity request;

– proximity request validation;

– proximity alert;

– UE deregistration; and

– proximity request cancellation.

EPC support for WLAN direct discovery and communication may be requested as part of the EPC-level ProSe discovery procedure.

7.2.2 UE registration procedure

7.2.2.1 General

The purpose of the UE registration procedure is for the UE to register with the ProSe Function to obtain EPC-level ProSe discovery services as defined in 3GPP TS 23.303 [2]. The UE registers with the ProSe Function residing in the HPLMN.

7.2.2.2 UE registration procedure initiation

Based on pre-configuration, if the UE is authorised to perform EPC-level ProSe discovery in the registered PLMN, it shall initiate the UE registration procedure when the UE is triggered by upper layers to obtain EPC-level ProSe discovery services and the UE has no corresponding EPC ProSe User ID.

The UE initiates the UE registration procedure by sending a UE_REGISTRATION_REQUEST message with the UE identity set to the UE’s IMSI. If the UE intends to use EPC support for WLAN direct discovery and communication and if the UE uses a permanent WLAN link layer identifier, then the UE also includes the WLAN link layer identifier in the UE_REGISTRATION_REQUEST message. If the UE supports long polling method for network initiated procedures then the UE also includes a "Method for server-initiated transaction" parameter indicating to the ProSe Function that it support long polling method.

Figure 7.2.2.2.1 illustrates the interaction of the UE and the ProSe Function in the UE registration procedure.

Figure 7.2.2.2.1: UE registration procedure

7.2.2.3 UE registration procedure accepted by the ProSe Function

Upon receiving a UE_REGISTRATION_REQUEST message, the ProSe Function interacts with the HSS as described in 3GPP TS 29.344 [3] in order to authenticate the user and check whether the user is authorised to use EPC-level ProSe discovery services corresponding to the IMSI contained in the UE_REGISTRATION_REQUEST message in the registered PLMN.

If the ProSe Function contains all the settings related to authentication and authorisation for the user corresponding to the IMSI contained in the UE_REGISTRATION_REQUEST message then the ProSe function need not interact with the HSS and the ProSe Function checks locally if the user is authorised to use EPC-level ProSe discovery services.

If the UE is authorised to use EPC-level ProSe discovery services, the ProSe Function generates an EPC ProSe User ID corresponding to the IMSI contained in the UE_REGISTRATION_REQUEST message and shall send a UE_REGISTRATION_RESPONSE message containing a <response-register> element to the UE with the EPC ProSe User ID. The EPC ProSe User ID is a number generated by the ProSe Function that is unique within the ProSe Function on a per UE basis. The <response-register> element shall also contain a server-initiated method configuration parameter indicating to the UE which method to use to handle server-initiated procedures.

7.2.2.4 UE registration procedure completion by the UE

Upon receipt of the UE_REGISTRATION_RESPONSE message containing a <response-register> element the UE stores the EPC ProSe User ID and may start the application registration procedure. The UE shall use the method configured in UE_REGISTRATION_RESPONSE message to handle server-initiated procedures.

7.2.2.5 UE registration procedure not accepted by the ProSe Function

If the UE_REGISTRATION_REQUEST message is not accepted by the ProSe Function, the ProSe Function shall send a UE_REGISTRATION _RESPONSE message containing a <response-reject> element to the UE including an appropriate PC3 EPC Control Protocol cause value.

If the UE is not authorised for EPC-level ProSe discovery, the ProSe Function shall send the UE_REGISTRATION_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #2 "UE authorisation failure".

7.2.3 Application registration procedure

7.2.3.1 General

The purpose of the application registration procedure is for the UE to activate EPC-level Prose discovery for a specific application as defined in 3GPP TS 23.303 [2]. The UE registers the specific application with the ProSe Function residing in the HPLMN.

7.2.3.2 Application registration procedure initiation

When the user uses applications on the UE, an Application ID is used to identify the corresponding application server platform. When the user registers an application with the application server, the user is designated an Application Layer User ID. If the application requires EPC-level ProSe discovery, the UE is configured with the data structure of the Application IDs and the Application Layer User ID. This step is performed using mechanisms outside of the scope of 3GPP. The user may have multiple Application Layer User IDs for an application, but may choose to register only one of these to activate EPC-level ProSe discovery. The UE shall initiate the application registration procedure after successfully completing the UE registration procedure.

If the UE is authorised to perform EPC-level ProSe discovery in the registered PLMN, it shall initiate the application registration procedure when the UE is triggered by upper layers to activate EPC-level Prose discovery for a specific application and the application is not registered.

The UE initiates the application registration procedure by sending an APPLICATION_REGISTRATION_REQUEST message by including a new transaction ID, the UE’s EPC ProSe User ID, the Application ID for the application that is to be registered and the user’s Application Layer User ID for the application that is to be registered.

NOTE: A UE can include one or multiple transactions in one APPLICATION_REGISTRATION_REQUEST message for different Application IDs, and receive corresponding <response-register> element or <response-reject> element in the APPLICATION_REGISTRATION_RESPONSE message for each respective transaction. In the following description of the application registration procedure, only one transaction is included.

Figure 7.2.3.2.1 illustrates the interaction of the UE and the ProSe Function in the application registration procedure.

Figure 7.2.3.2.1: Application registration procedure

7.2.3.3 Application registration procedure accepted by the ProSe Function

Upon receiving an APPLICATION_REGISTRATION_REQUEST message, the ProSe Function retrieves the user profile based on the UE’s EPC ProSe User ID included in the APPLICATION_REGISTRATION_REQUEST message. The ProSe Function then checks if the list of authorised applications in the user’s profile includes the requested application based on the Application ID in the APPLICATION_REGISTRATION_REQUEST message.

If the check is successful then the ProSe Function sends a request to the application server so that the user of this application identified by Application Layer User ID in the APPLICATION_REGISTRATION_REQUEST message can use EPC-level ProSe discovery for that application.

If the user is authorised to use EPC-level ProSe discovery for the specified application, the ProSe Function generates one or more allowed range classes corresponding to the Application ID contained in the APPLICATION_REGISTRATION_REQUEST message. The ProSe Function shall send an APPLICATION_REGISTRATION_RESPONSE message containing a <response-register> element to the UE with transaction ID set to the value of the transaction ID received in the APPLICATION_REGISTRATION_REQUEST message from the UE and the set of allowed range classes. The set of allowed range classes for each Application ID is stored in the ProSe Function.

7.2.3.4 Application registration procedure completion by the UE

Upon receipt of the UE_REGISTRATION_RESPONSE message, if the transaction ID contained in the <response-register> element matches the value sent by the UE in an APPLICATION_REGISTRATION_REQUEST message the UE stores the set of allowed range classes for this Application ID and may start the proximity request procedure.

7.2.3.5 Application registration procedure not accepted by the ProSe Function

If the APPLICATION_REGISTRATION_REQUEST message is not accepted by the ProSe Function, the ProSe Function shall send an APPLICATION_REGISTRATION_RESPONSE message containing a <response-reject> element to the UE including an appropriate PC3 EPC Control Protocol cause value.

If the application corresponding to the Application ID contained in the APPLICATION_REGISTRATION_REQUEST message is not authorised for EPC-level ProSe Discovery in the registered PLMN, the ProSe Function shall send the APPLICATION_REGISTRATION_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #1 "Invalid Application".

If the UE is not authorised for EPC-level ProSe Discovery, the ProSe Function shall send the APPLICATION_REGISTRATION_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #2 "UE authorisation failure".

If the Application Layer User ID contained in the APPLICATION_REGISTRATION_REQUEST message is unknown to the Application Server, the ProSe Function shall send the APPLICATION_REGISTRATION_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #10 "Invalid Application Layer User ID".

7.2.4 Proximity request procedure

7.2.4.1 General

The purpose of the proximity request procedure is to allow a UE (UE A) to request to be alerted when it enters in proximity with a targeted UE (UE B) as defined in 3GPP TS 23.303 [2]. UE A performs the proximity request procedure with the ProSe Function residing in the HPLMN.

7.2.4.2 Proximity request procedure initiation

Before initiating the proximity request procedure, UE A needs to register the user’s Application Layer User ID A with ProSe Function A as described in subclause 7.2.3. UE A shall initiate the proximity request procedure when triggered by upper layers to activate EPC-level Prose discovery for a specific application and for a specific targeted user identified via its Application Layer User ID B.

UE A initiates the proximity request procedure by sending a PROXIMITY_REQUEST message to ProSe Function A by including a new transaction ID, UE A’s EPC ProSe User ID, the Application ID for the application for which the request is made, UE A’s Application Layer User ID (Application Layer User ID A), the Application Layer User ID of UE B (Application Layer User ID B), a requested range class value selected from the set of allowed range classes for this application, UE A’s Current Location with the best known accuracy and a Time Window indicating the time interval during which the request is valid.

NOTE: A UE can include one or multiple transactions in one PROXIMITY_REQUEST message for different Application IDs, and receives corresponding <response-accept> element or <response-reject> element in the PROXIMITY_REQUEST_RESPONSE message for each respective transaction. In the following description of the Proximity Request procedure, only one transaction is included.

If UE A, subsequent to successful proximity detection with UE B, wishes to engage in WLAN direct discovery and communication, UE A also includes a WLAN Indication in the PROXIMITY_REQUEST message.

Figure 7.2.4.2.1 illustrates the interaction of the UE and the ProSe Function in the proximity request procedure.

Figure 7.2.4.2.1: Proximity request procedure

7.2.4.3 Proximity request procedure accepted by the ProSe Function

Upon receiving a PROXIMITY_REQUEST message from UE A, ProSe Function A retrieves the user profile based on the UE’s EPC ProSe User ID included in the PROXIMITY_REQUEST message. ProSe Function A then checks that UE A has previously registered the application identified with the Application ID in the PROXIMITY_REQUEST message and that the requested range class value belongs to the set of allowed range classes for this application.

If the check is successful then ProSe Function A interacts with the Application Server to obtain the identifier of ProSe Function B that owns the user profile of the targeted user, as well as its EPC ProSe User ID (EPC ProSe User ID B). ProSe Function A then propagates the proximity request to ProSe Function B on the targeted UE side (the B-side). The Current Location of UE A included in the PROXIMITY_REQUEST message may be used by ProSe Function B to determine whether the proximity request is accepted or not.

NOTE: The mechanism used by ProSe Function B to determine acceptance or non-acceptance of PROXIMITY_REQUEST messages is outside the scope of this specification.

If the proximity request is accepted by the B-side, ProSe Function A stores Application Layer User ID A, Application Layer User ID B, EPC ProSe User ID B, requested range class and Time Window in the UE A’s context identified with EPC ProSe User ID A. The WLAN Indication is also stored, if it was included in the PROXIMITY_REQUEST message. Then ProSe Function A shall initiate location reporting for UE A and send a PROXIMITY_REQUEST_RESPONSE message containing a <response-accept> element to UE A with transaction ID set to the value of the transaction ID received in the PROXIMITY_REQUEST message from UE A.

7.2.4.4 Proximity request procedure completion by the UE

Upon receipt of the PROXIMITY_REQUEST_RESPONSE message, if the transaction ID contained in the <response-accept> element matches the value sent by the UE in a PROXIMITY_REQUEST message, the proximity request procedure is successfully completed.

7.2.4.5 Proximity request procedure not accepted by the ProSe Function

If the PROXIMITY_REQUEST message is not accepted by the ProSe Function, the ProSe Function shall send a PROXIMITY_REQUEST_RESPONSE message containing a <response-reject> element to the UE including an appropriate PC3 EPC Control Protocol cause value.

If the application corresponding to the Application ID contained in the PROXIMITY_REQUEST message is not authorised for EPC-level ProSe discovery, the ProSe Function shall send the PROXIMITY_REQUEST_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #1 "Invalid Application".

If the application corresponding to the Application ID contained in the PROXIMITY_REQUEST message has not been registered for EPC-level ProSe discovery, the ProSe Function shall send the PROXIMITY_REQUEST_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #4 "Application not registered".

If the requested Range Class value is not allowed for this application, the ProSe Function shall send the PROXIMITY_REQUEST_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #5 "Range Class not allowed for this application".

If based on the Current Location the B-side determines that UE A and targeted UE B are unlikely to enter proximity within the requested Time Window, the ProSe Function shall send the PROXIMITY_REQUEST_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #6 "Proximity detection unlikely within requested time window".

If the ProSe Function determines that the targeted UE has not registered the application identified with Application ID, the ProSe Function shall send the PROXIMITY_REQUEST_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #7 "Targeted user not registered for this application".

If the B-side rejects to validate the proximity request, the ProSe Function shall send the PROXIMITY_REQUEST_RESPONSE message containing a <response-reject> element with PC3 EPC Control Protocol cause value #8 "Proximity validation rejected by B side".

7.2.5 Proximity alert procedure

7.2.5.1 General

The purpose of the proximity alert procedure is to inform the UE (UE A) that it has been determined to be in proximity with the targeted UE (UE B) as defined in 3GPP TS 23.303 [2]. If UE A has indicated in the proximity request procedure that it wishes to engage in WLAN direct discovery and communication with UE B, the proximity alert procedure is also used to provide Assistance Information that expedites the WLAN direct discovery and communication to both UE A and UE B. The proximity alert procedure is initiated by the ProSe Function residing in the HPLMN.

7.2.5.2 Proximity alert procedure initiation by the network

When ProSe Function A on the A-side determines that UE A and UE B are in proximity, it cancels the location reporting for UE A with the SUPL Location Platform and sends a PROXIMITY_ALERT message to UE A including the Application ID, Application Layer User ID A and Application Layer User ID B.

UE A may have registered multiple proximity requests for applications with different Application IDs. In this case the ProSe Function may combine the multiple alerts for each of the different Application IDs and send a combined PROXIMITY_ALERT message to the UE.

If UE A’s context contains a WLAN Indication, the ProSe Function generates Assistance Information for WLAN direct discovery and communication according to the underlying WLAN technology, includes the Assistance Information in the PROXIMITY ALERT message and forwards the alert towards the B-side.

If the context of UE A does not contain WLAN Indication then ProSe Function A sends a cancellation request towards ProSe Function B.

After transmitting the PROXIMITY_ALERT message to UE A and alerting (or sending a cancellation request to) the B-side, the ProSe Function deletes the information related to this specific Proximity Request in UE A’s context.

NOTE: If UE A has signalled a permanent WLAN Link Layer ID during UE Registration procedure as described in subclause 7.2.2, the WLAN Link Layer ID for UE A is retrieved from UE A’s context; otherwise a random WLAN Link Layer ID is generated for UE A by the ProSe Function. Similarly, if during the Proximity Request procedure the ProSe Function has received a permanent WLAN Link Layer ID for UE B, the WLAN Link Layer ID for UE B is retrieved from UE A’s context; otherwise a random WLAN Link Layer ID is generated for UE B by the ProSe Function.

When ProSe Function B is alerted that UE A and UE B are in proximity, it cancels the location reporting for UE B and shall send a PROXIMITY_ALERT message to UE B including the Application ID, Application Layer User ID A and Application Layer User ID B.

Figure 7.2.5.2.1 illustrates the interaction of the UE and the ProSe Function in the proximity alert procedure.

Figure 7.2.5.2.1: Proximity alert procedure

7.2.5.3 Proximity alert procedure completion by the UE

Upon receipt of the PROXIMITY_ALERT message the UE shall inform the application identified via the Application ID in the PROXIMITY_ALERT message including Application Layer User ID A and Application Layer User ID B. If the Assistance Information for WLAN direct discovery and communication is included in the PROXIMITY_ALERT message, the UE uses this information to engage in WLAN direct discovery and communication with the peer UE.

7.2.6 UE deregistration procedure

7.2.6.1 General

The UE deregistration procedure is used to deregister the UE for EPC-level ProSe discovery services. It can be initiated at any time by the UE or by the ProSe Function residing in the HPLMN.

7.2.6.2 UE-initiated UE deregistration procedure

7.2.6.2.1 UE-initiated UE deregistration procedure initiation

When the UE decides to deregister for EPC-level ProSe discovery services, it shall send the UE_DEREGISTRATION_REQUEST message to the ProSe Function residing in the HPLMN. The message includes the EPC ProSe User ID.

Figure 7.2.6.2.1.1 illustrates the interaction of the UE and the ProSe Function in the UE-initiated UE deregistration procedure.

Figure 7.2.6.2.1.1: UE-initiated UE deregistration procedure

7.2.6.2.2 UE-initiated UE deregistration procedure accepted by the ProSe Function

Upon receiving the UE_DEREGISTRATION_REQUEST message, the ProSe Function retrieves the user profile based on the UE’s EPC ProSe User ID included in the UE_DEREGISTRATION_REQUEST message, cancels any ongoing proximity alert procedures for this UE, clears the UE context and shall send a UE_DEREGISTRATION_RESPONSE message to the UE.

7.2.6.2.3 UE-initiated UE deregistration procedure completion by the UE

Upon receipt of the UE_DEREGISTRATION_RESPONSE message by the UE, the UE deregistration procedure is complete.

7.2.6.3 Network-initiated UE deregistration procedure

7.2.6.3.1 Network-initiated UE deregistration procedure initiation

When the ProSe Function residing in the HPLMN decides to deregister the UE for EPC-level ProSe discovery services, it shall send the UE_DEREGISTRATION_REQUEST to the UE.

Figure 7.2.6.3.1.1 illustrates the interaction of the UE and the ProSe Function in the network-initiated UE deregistration procedure.

Figure 7.2.6.3.1.1: Network-initiated UE deregistration procedure

7.2.6.3.2 Network-initiated UE deregistration procedure in the UE

Upon receiving a UE_DEREGISTRATION_REQUEST message, the UE deletes all context information related to EPC-level ProSe discovery and shall send a UE_DEREGISTRATION_RESPONSE message to the network.

7.2.6.3.3 Network-initiated UE deregistration procedure completion by the network

Upon receipt of the UE_DEREGISTRATION_RESPONSE message by the ProSe Function the UE deregistration procedure is complete.

7.2.7 Proximity request cancellation procedure

7.2.7.1 General

The proximity request cancellation procedure is used by the UE or ProSe Function to cancel an ongoing proximity request that was sent earlier as defined in 3GPP TS 23.303 [2]. The UE initiates the proximity request cancellation procedure due to occurrence of certain event (e.g.termination of the corresponding application). The ProSe Function initiates the proximity request cancellation procedure (e.g. due to excess of time window).

7.2.7.2 UE initiated proximity request cancellation procedure

7.2.7.2.1 Initiation of UE initiated proximity request cancellation procedure

The UE initiates the proximity request cancellation procedure by sending a CANCEL_PROXIMITY_REQUEST message to the ProSe Function including a new transaction ID, the UE’s EPC ProSe User ID, the Application ID for the application for which the cancellation is being made and the targeted user’s Application Layer User ID B.

NOTE: A UE can include one or multiple transactions in one CANCEL_PROXIMITY_REQUEST message for different Application IDs, and receive corresponding CANCEL_PROXIMITY_RESPONSE message for each respective transaction. In the following description of the proximity request cancellation procedure, only one transaction is included.

Figure 7.2.7.2.1.1 illustrates the interaction of the UE and the ProSe Function in the UE initiated proximity request cancellation procedure.

Figure 7.2.7.2.1.1: UE initiated proximity request cancellation procedure

7.2.7.2.2 UE initiated proximity request cancellation procedure handling by the ProSe Function

Upon receiving a CANCEL_PROXIMITY_REQUEST message from UE A, ProSe Function A retrieves the user profile of UE A based on UE A’s EPC ProSe User ID included in the CANCEL_PROXIMITY_REQUEST message. ProSe Function A then uses the Application ID and Application Layer User ID B to identify the ProSe Function identifier of ProSe Function B which owns the context of the targeted user and forwards the cancellation request towards ProSe Function B as defined in 3GPP TS 29.345 [5].

The ProSe Function A shall send a CANCEL_PROXIMITY_RESPONSE message to UE A with transaction ID set to the value of the transaction ID received in the CANCEL_PROXIMITY_REQUEST message from UE A. If UE A has no other ongoing proximity requests then ProSe Function A cancels the location reporting for UE A.

7.2.7.2.3 UE initiated proximity request cancellation procedure completion by the UE

Upon receipt of the CANCEL_PROXIMITY_RESPONSE message with transaction ID set to the value of the transaction ID received in the CANCEL_PROXIMITY_REQUEST message, the UE A shall abort the proximity request procedure and the UE initiated proximity request cancellation procedure is complete.

7.2.7.3 ProSe Function initiated proximity request cancellation procedure

7.2.7.3.1 Initiation of ProSe Function initiated proximity request cancellation procedure

The ProSe Function initiates the proximity request cancellation procedure by retrieving the user profile of UE A based on UE A’s EPC ProSe User ID included in the PROXIMITY_REQUEST message sent by UE A earlier.

The ProSe Function A shall send a CANCEL_PROXIMITY_REQUEST message to UE A with transaction ID set to the value of the transaction ID received in the PROXIMITY_REQUEST message from UE A, the UE A’s EPC ProSe User ID, the Application ID for the application for which the cancellation is being made and the targeted user’s Application Layer User ID B. If UE A has no other ongoing proximity requests then ProSe Function A cancels the location reporting for UE A.

NOTE: A ProSe Function can include one or multiple transactions in one CANCEL_PROXIMITY_REQUEST message for each respective transaction. In the following description of the proximity request cancellation procedure, only one transaction is included.

Figure 7.2.7.3.1.1 illustrates the ProSe Function initiated proximity request cancellation procedure.

Figure 7.2.7.3.1.1: ProSe Function initiated proximity request cancellation procedure

7.2.7.3.2 ProSe initiated proximity request cancellation procedure handling by the UE

Upon receiving a CANCEL_PROXIMITY_REQUEST message from ProSe Function A, the UE A shall abort the proximity request procedure and send a CANCEL_PROXIMITY_RESPONSE message to ProSe Function A with transaction ID set to the value of the transaction ID received in the CANCEL_PROXIMITY_REQUEST message from ProSe Function A.

7.2.7.3.3 ProSe Function initiated proximity request cancellation procedure completion by the ProSe Function

Upon receipt of the CANCEL_PROXIMITY_RESPONSE message by ProSe Function A, the ProSe Function initiated proximity request cancellation procedure is complete.

7.2.8 Proximity request Validation procedure

7.2.8.1 General

If the targeted UE’s profile indicates that the proximity requests for the UE need to be explicitly validated then the network uses the proximity request validation procedure to request the targeted UE (UE B) to confirm permission for the proximity requests (e.g. user B may have temporarily disabled the ProSe functionality on UE B). It is initiated by the ProSe Function residing in the HPLMN as part of the overall proximity request procedure defined in 3GPP TS 23.303 [2].

7.2.8.2 Initiation of the proximity request validation procedure

Upon reception of a proximity request from UE A, the ProSe Function on the targeted UE side (B-side) retrieves the stored profile of UE B. If UE B’s profile indicates that the proximity requests for UE B need to be explicitly validated, ProSe Function B shall send the PROXIMITY_REQUEST_VALIDATION message to UE B including the Application ID of the application for which the proximity request is being validated.

Figure 7.2.8.2.1 illustrates the interaction of the targeted UE and the ProSe Function in the proximity request validation procedure.

Figure 7.2.8.2.1: Proximity request validation procedure

7.2.8.3 Proximity request validation procedure in the UE

Upon receiving a PROXIMITY_REQUEST_VALIDATION message, UE B checks whether the application corresponding to the Application ID included in the message is ready for accepting a proximity request from other users.

If the application corresponding to the Application ID contained in the PROXIMITY_REQUEST_VALIDATION message is ready for accepting proximity requests from other users, the targeted UE shall send the PROXIMITY_REQUEST_VALIDATION_RESPONSE message to the ProSe Function.

If the application corresponding to the Application ID contained in the PROXIMITY_REQUEST_VALIDATION message is not ready for accepting proximity requests from other users, the targeted UE shall send the PROXIMITY_REQUEST_VALIDATION_RESPONSE message with PC3 EPC Control Protocol cause value #9 "Application disabled temporarily".

7.2.8.4 Proximity request validation procedure completion by the network

Upon receipt of the PROXIMITY_REQUEST_VALIDATION_RESPONSE message containing a <response-accept> element, ProSe Function B initiates location reporting for UE B and acknowledges the proximity request towards ProSe Function A.

Upon receipt of the PROXIMITY_REQUEST_VALIDATION_RESPONSE message containing a <response-reject> element, ProSe Function B forwards an indication towards ProSe Function A that the proximity request is rejected.

7.2.9 Abnormal cases

7.2.9.1 Abnormal cases in the UE

In case of the messages listed below:

– UE_REGISTRATION_REQUEST;

– APPLICATION_REGISTRATION_REQUEST;

– PROXIMITY_REQUEST;

– UE_DEREGISTRATION_REQUEST;

– CANCEL_PROXIMITY_REQUEST; and

– PROXIMITY_REQUEST_VALIDATION.

the following abnormal cases can be identified.

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

The UE shall close the existing connection to the ProSe Function, establish a new connection and then restart the appropriate procedure.

b) No response from the ProSe Function after a message has been successfully delivered (e.g. TCP ACK has not been received)

The UE shall retransmit the message.

7.2.9.2 Abnormal cases in the ProSe Function

In case of the messages listed below:

– UE_REGISTRATION_RESPONSE;

– APPLICATION_REGISTRATION_RESPONSE;

– PROXIMITY_REQUEST_RESPONSE;

– PROXIMITY_ALERT;

– UE_DEREGISTRATION_RESPONSE;

– CANCEL_PROXIMITY_RESPONSE; and

– PROXIMITY_REQUEST_VALIDATION_RESPONSE.

the following abnormal cases can be identified.

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

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