5.5 EPC-level ProSe Discovery procedures

23.3033GPPProximity-based services (ProSe)Release 17Stage 2TS

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

5.5.1 General

EPC-level ProSe Discovery can be used independently or in conjunction with EPC support for WLAN direct discovery and communication.

When EPC support for WLAN direct discovery and communication is requested as part of the EPC-level ProSe Discovery procedure, the additional parameters for support of WLAN direct discovery and communication are enclosed in brackets in the figures.

5.5.2 Overall call flow for EPC-level ProSe Discovery

The overall call flow for EPC-level ProSe Discovery and optional EPC support for WLAN direct discovery and communication is illustrated in Figure 5.5.2-1. Each procedural box is subsequently described in more detail as a separate call flow.

Figure 5.5.2-1: Overall call flow for EPC-level ProSe Discovery and optional EPC support for WLAN direct discovery and communication

1. UEs perform UE registration for ProSe with the ProSe Function residing in their respective Home PLMNs;

2. UEs perform application registration for ProSe with the ProSe Function residing in their respective Home PLMNs;

3. UE A makes a proximity request for UE B, i.e. requests that it be alerted for proximity with UE B (possibly indicating a window of time during which the request is valid). In response, ProSe Function A requests location updates for UE A and UE B. These location updates can be periodic, based on a trigger, or a combination of both. To request location updates for UE A, ProSe Function A contacts SUPL Location Platform (SLP) A. To request location updates for UE B, ProSe Function A contacts ProSe Function B, which requests location updates for UE B from SLP B;

4. The UEs’ locations are reported to their respective ProSe Functions intermittently. ProSe Function B forwards UE B’s location updates to ProSe Function A based on the conditions set by ProSe Function A. Whenever ProSe Function A receives location updates for UE A and/or UE B, it performs proximity analysis on UE A and UE B’s locations;

5. When ProSe Function A detects that the UEs are in proximity, it informs UE A that UE B is in proximity and (optionally) provides UE A with assistance information for WLAN direct discovery and communication with UE B. ProSe Function A also informs ProSe Function B, which in turn informs UE B of the detected proximity and (optionally) provides UE B with assistance information for WLAN direct discovery and communication with UE A.

5.5.3 UE registration for ProSe

To obtain ProSe service a ProSe-enabled UE needs to register with the ProSe Function.

Depicted in Figure 5.5.3-1 is the procedure for UE registration for ProSe.

Figure 5.5.3-1: UE registration for ProSe

1. To select ProSe Function A, UE A constructs an FQDN using the HPLMN ID and relies on DNS translation to obtain the IP address of ProSe Function A. UE A registers with ProSe Function A by sending a UE Registration Request (IMSI, [WLLID_A]) message.

If UE A intends to use EPC support for WLAN direct discovery and communication and if it uses a permanent WLAN Link Layer ID, the message also includes UE A’s permanent WLAN Link Layer ID (WLLID_A). Alternatively, the UE may obtain a temporary WLAN Link Layer ID from the ProSe Function as part of the Proximity Request procedure.

2. ProSe Function A may interact with the HSS in order to authenticate the user, obtain the user’s profile and check whether the user is authorised for ProSe. Alternatively, all user settings related to authentication and authorisation for ProSe may be configured locally in ProSe Function A, in which case the interaction with the HSS is not needed.

3. ProSe Function A generates an EPC ProSe User ID for the authorized UE A (EPUID_A), stores the EPUID_A together with user’s IMSI and responds to UE A by sending a UE Registration Response (EPUID_A) message.

5.5.4 Application registration for ProSe

When a user registers with a 3rd party application server, he/she is designated an Application Layer User ID (e.g. ALUID_A for user A). This procedure is out of 3GPP specification scope. Then to activate ProSe features such as EPC-level ProSe Discovery for a specific application, the UE registers the application with the ProSe Function, as illustrated in Figure 5.5.4-1.

Figure 5.5.4-1: Application registration for ProSe

1. UE A sends Application Registration Request (EPUID_A, Application ID, ALUID_A) message to ProSe Function A to register an application for ProSe. EPUID_A is the EPC ProSe User ID for UE A. The Application ID is used to identify the 3rd party App Server platform. ALUID_A is user A’s Application Layer User ID.

2. ProSe Function A uses EPUID_A to retrieve user’s profile, checks that the requested application is on the stored list of authorised Application IDs and sends a ProSe Registration Request (ALUID_A, EPUID_A, PFID_A) message to the App Server indicating that a user of this application (identified as ALUID_A) has requested to use ProSe for that application. PFID_A is the ProSe Function ID of ProSe Function A. If the App Server accepts the request, it stores the user’s Application Layer User ID (ALUID_A) and EPC ProSe User ID (EPUID_A) together with the PFID_A.

3. The App Server sends a ProSe Registration Response message to ProSe Function A indicating that the registration was successful (or not).

4. ProSe Function A sends Application Registration Response (Allowed Range) message to UE A indicating that the registration was successful (or not). The Allowed Range parameter contains the set of range classes that are allowed for this application.

5.5.5 Proximity Request

In order to request that it be alerted when it enters proximity with user B, UE A triggers the Proximity Request procedure, as illustrated in Figure 5.5.5-1.

Figure 5.5.5-1: Proximity Request

1. UE A sends a Proximity Request (EPUID_A, Application ID, ALUID_A, ALUID_B, window, Range, A’s location, [WLAN indication]) message to ProSe Function A. The Application ID parameter identifies the 3rd party App Server platform. ALUID_A and ALUID_B are the Application Layer User IDs for users A and B, respectively. The window parameter indicates the time period during which the request is valid. Range is a requested range class for this application chosen from the set of allowed range classes. A’s location is the current location of UE A with the best accuracy known by UE A. UE A may optionally request EPC support for WLAN direct discovery and communication with UE B by adding the WLAN indication.

2. ProSe Function A sends a Map Request (ALUID_A, ALUID_B) message to the App Server, requesting that it provide the EPC ProSe User ID for the targeted user B. ProSe Function A stores the Application Layer User IDs (ALUID_A and ALUID_B) until the execution of the Proximity Alert procedure described in clause 5.5.7, the Proximity Request Cancellation procedure described in clause 5.5.9 or until the expiry of the time window during which the request is valid.

3. The App Server checks user B’s application-specific ProSe permissions, confirms that user A is allowed to discover user B, and sends a Map Response (EPUID_B PFID_B) message to ProSe Function A indicating user B’s EPC ProSe User ID (EPUID_B) as well as the ProSe Function ID of ProSe Function B (PFID_B), ProSe Function A stores the EPUID_B and PFID_B until the execution of the Proximity Alert procedure described in clause 5.5.7, the Proximity Request Cancellation procedure described in clause 5.5.9 or until the expiry of the time window during which the request is valid.

4. ProSe Function A propagates the Proximity Request (EPUID_B, EPUID_A, Application ID, window, A’s location, [WLLID_A], SUPL Config) message to ProSe Function B. A’s location is the current location of UE A provided in step 1 expressed in GAD shapes defined in TS 23.032 [3]. WLAN indication is included if UE A has requested EPC support for WLAN direct discovery and communication in step 1. SUPL Config is a set of parameters that enable ProSe Function B to configure SUPL reporting in UE B using the ‘"Inside" Trigger with Repeated Reporting’ as defined in OMA AD SUPL [2].

5. Based on EPUID_B received in the previous step, ProSe Function B retrieves subscriber B’s record. ProSe Function B may request UE B’s last known location via the HSS (step 5a). Based on the last known location of UE B obtained via the HSS and UE A’s location and time window provided by ProSe Function A in step 4, ProSe Function B may determine that the users are unlikely to enter proximity within the requested time window and rejects the request by sending a Proximity Request Reject message towards UE A with an appropriate cause value (steps 5b and 5c), in which case the remaining steps of the procedure are skipped.

6. Depending on UE B’s ProSe profile, UE B may be asked to confirm permission for the proximity request (e.g. user B may have temporarily disabled the ProSe function on UE B).

7. ProSe Function B requests location reporting on UE B from SLP B and acknowledges the proximity request to ProSe Function A and provides UE B’s current location (if known). The WLAN Link Layer ID of UE B (WLLID_B) is included if UE A has requested EPC support for WLAN direct discovery and communication in step 1 and if UE B uses a permanent WLAN Link Layer ID.

8. ProSe Function A requests location reporting on UE A from SLP A. If UE A’s current location is available and if UE B’s location was included in step 7, ProSe Function A may decide to cancel the Proximity Request procedure if it determines that the UEs are unlikely to enter proximity within the requested time window. Otherwise ProSe Function A acknowledges the proximity request to UE A.

5.5.6 UE Location Reporting

SLP A and SLP B configure UE A and UE B, respectively, to report their locations periodically, based on a trigger, or a combination of both depending on what ProSe Function A and ProSe Function B requested (see Figure 5.5.6-1).

Figure 5.5.6-1: UE location reporting

1-4. The locations of UE A and UE B are reported to their corresponding Prose Servers intermittently.

NOTE 1: If UE is engaged in multiple concurrent proximity request procedures, the location reports are grouped together by the SLP.

NOTE 2: The UE location reporting procedure is executed until the time window expires even if UE B "unfriends" UE A at application layer in the middle of an active proximity request.

5. Assuming that ProSe Function A is in charge of determining proximity, ProSe Function B forwards UE B’s location to ProSe Function A at the cadence prescribed by ProSe Function A in the Proximity Request message. The UE location information exchanged between ProSe Functions are expressed in GAD shapes defined in TS 23.032 [3]. ProSe Function A may decide to cancel the Proximity Request procedure if it determines that the UEs are unlikely to enter proximity within the requested time window.

NOTE 3: Based on the last reported UE A’s or UE B’s location, ProSe Function A may decide to send a new Proximity Request message over PC6 in order to provide updated SUPL Config to ProSe Function B.

5.5.7 Proximity Alert

When the UEs enter into proximity, the network triggers the Proximity Alert procedure, as illustrated in Figure 5.5.7-1.

Figure 5.5.7-1: Proximity Alert

1-3.The location of UE B is reported to ProSe Function B, which forwards it to ProSe Function A.

4. ProSe Function A detects that the two UEs are in proximity based on the requested discovery range class and alerts UE A by sending a Proximity Alert (Application ID, ALUID_B, Assistance Information) message. ALUID_B is the Application Layer User ID of user B. The message optionally includes Assistance Information for WLAN direct discovery and communications with UE B.

5. If UE A has requested as part of the Proximity Request procedure as described in step 1 of clause 5.5.5 to be assisted for WLAN direct discovery and communication, ProSe Function A requests ProSe Function B to send a Proximity Alert (Application ID, ALUID_A, Assistance Information) message to UE B. ALUID_A is the Application Layer User ID of user A. The message includes Assistance Information for WLAN direct discovery and communication with UE A. ProSe Function A cancels location reporting on UE A from SLP A. ProSe Function B also cancels location reporting on UE B from SLP B.

6. If UE A has not requested as part of the Proximity Request procedure as described in step 1 of clause 5.5.5 to be assisted for WLAN direct discovery and communication, ProSe Function A initiates Proximity Request Cancellation by sending a Cancel Proximity Request (EPUID_B, EPUID_A) message to ProSe Function B as described in step 2 of clause 5.5.9.

NOTE 1: The WLAN interface in the UE need not be turned on before step 7 in Figure 5.5.7-1.

NOTE 2: The assistance information is designed to expedite WLAN direct discovery and communication. The content of the assistance information depends on the technology used on the WLAN direct link. All the content in the assistance information is dynamically generated by ProSe Function A, with the exception of WLLID_B in case UE B supports only permanent WLLID.

5.5.8 UE deregistration for ProSe

5.5.8.1 General

At any time the UE or the ProSe Function may initiate UE deregistration for ProSe.

5.5.8.2 Network-initiated deregistration

Depicted in Figure 5.5.8.2-1 is the procedure for network-initiated deregistration for ProSe.

Figure 5.5.8.2-1: Network-initiated deregistration for ProSe

1. At any time the ProSe Function may decide to deregister the UE by sending a UE Deregistration Request (cause) message.

2. UE acknowledges the deregistration request by sending a UE Deregistration Response message.

5.5.8.3 UE-initiated deregistration

The UE may decide to deregister for ProSe (e.g. when there are no ProSe-enabled applications activated on the UE). Depicted in Figure 5.5.8.3-1 is the procedure for UE-initiated deregistration for ProSe.

Figure 5.5.8.3-1: UE initiated deregistration

1. At any time the UE may decide to deregister for ProSe by sending a UE Deregistration Request (EPUID, cause) message.

2. The ProSe Function acknowledges the deregistration request by sending a UE Deregistration Response message and removes the stored ProSe context for the UE.

5.5.9 Proximity Request Cancellation

The Proximity Request Cancellation may be initiated by the UE or the ProSe Function.

UE A may decide to cancel Proximity Request it sent earlier (e.g. due to change in its location, termination of corresponding application or due to completion of certain event). The ProSe Function A may cancel Proximity Request sent by UE A earlier (e.g. when time window is exceeded). In order to cancel Proximity Request, UE A triggers procedure as illustrated in Figure 5.5.9-1.

Figure 5.5.9-1 Proximity Request Cancellation

1. UE A sends Cancel Proximity Request (EPUID_A, Application ID, ALUID_B) to Prose Function A. This optional step is performed only when the Proximity Request Cancellation procedure is initiated by the UE.

2. Prose Function A sends the Cancel Proximity Request (EPUID_B, EPUID_A) message to ProSe Function B based on the stored PFID B information.

3. If there are no other pending proximity requests for UE A, ProSe Function A cancels location reporting on UE A from SLP A.

4-5. ProSe Function B cancels location reporting on UE B from SLP B and acknowledges the proximity request cancellation to ProSe Function A.

6. ProSe Function A sends Proximity Request Cancellation (Application ID, ALUID_B) to UE A. The Application ID and ALUID_B parameters are included only when the procedure is initiated by ProSe Function A.