Content for &nbsp; TS 23.434 &nbsp; Word version:&nbsp; 19.5.0

The location management server identifies the registered location management client1 and location management server client 2 are associated and may share the same location with each other based on the received location service registration information (e.g. same associated ID as defined in clause 9.3.15). Then it further verifies if they are sharing the same location at present.

The location management server initiates the verify location sharing request to the location management server client 1 with the user ID of location management client 2 to verify if they are sharing the same location.

The location management client 1 checks if the location management client 2 is close enough and shares the same location via the following ways.

The location management client 1 may trigger the location reporting to the location management client 2 via some positioning capabilities (e.g., Prose) and receive off-network location report from the location management client 2 and determines that the VAL UE2 is within allowed proximity range of the VAL UE1 as specified in step 1 of clause 9.3.23.3.
The location management client 1 may ask the VAL user to check if VAL UE1 and VAL UE2 are in the same location. If the answer is yes, the VAL user may inform the location management client 1 that the VAL UE1 and VAL UE2 are in the same location area.

Figure 9.3.23.3-1: Location reuse procedure

The location management server client 1 sends the verify location sharing response to the location management server with the confirmation of sharing same location with location management client 2, and the validity timer is also included to indicate the valid duration for the confirmation.

Before the validity timer expired, if the location management client 1 discovers the location management client 2 is far away from itself and they are not able to share the same location, the location management client 1 will inform the location management server they are no long sharing the same location as specified in step 2(disable) of clause 9.3.23.3.

If the response is negative (e.g. the location management client 1 confirms the location management client 2 is not close with location management client 1 or the location management client 1 can't confirm whether both of UEs are closing enough), the location management server will not reuse the stored UE1's location for UE2.

9.3.23.3 Location reuse request p. 115

Figure 9.3.23.3-1 illustrates the procedure of client-triggered enable location reuse request.

Pre-condition:

All UEs in the association are registered to share the location.
UE has configured other UEs in the association to received offline location reports as specified in clause 9.5.3.
The VAL UE1 and VAL UE2 are associated and may belong to the same user or different users.
The LM Client 1(in VAL UE1) and LM Client 2(in VAL UE2) have reported the location capabilities (e.g. associated ID) for VAL UE1 and VAL UE2 to LM server respectively as defined in clause 9.3.15.

Reproduction of 3GPP TS 23.434, Fig. 9.3.23.3-1: Location reuse procedure

The SEAL LMC-1 (in UE-1) receives off-network location report from the SEAL LMC-2 (in UE-2). Based on location report, if UE-2 is within certain range of UE-1, the SEAL LMC-1 determines that the UE-2 is within allowed proximity range of the UE-1 (i.e. UE-1 and UE-2 are close enough) and so UE-1's location can be used by SEAL LMS instead of UE-2's location.

Based on location report, if UE-2 is out of certain range of UE-1, the SEAL LMC-1 determines that the UE-2 is outside allowed proximity range of the UE-1 (i.e. UE-1 and UE-2 are not close enough) and so UE-1's location can not be used by SEAL LMS instead of UE-2's location.

The SEAL LMC-1 (in UE-1) sends location reuse request message to the SEAL LMS to enable reuse of location of UE-1 for UE-2. If both UE1 and UE2 are close enough (i.e. within allowed proximity range), the request includes indication to enable reuse of location of UE-1 for UE-2. If both UE1 and UE2 are not close enough (i.e. outside allowed proximity range), the request includes indication to disable reuse of location of UE-1 for UE-2. The request message also includes VAL user's identity, identity of VAL UE-1, identity of UE-2 and latest location report of UE-1.

The SEAL LMS authenticates and authorizes the user. If authorized, the SEAL LMS identifies that if SEAL LMC-1 and SEAL LMC-2 are associated (e.g. same associated ID) or not based on the received registration information of SEAL LMC-1 and SEAL LMC-2, and if reusing of location is allowed of not.

Figure 9.3.24.1-1: Support for SL positioning procedure

If both UE-1 and UE-2 are assocaited and reusing of location is allowed (as determined in step-3), then the SEAL LMS stores the location of UE-1. If the request includes indication to enable reuse of location of UE-1, the SEAL LMS enables reuse of location of UE-1 for UE-2. If the request includes indication to disable reuse of location of UE-1, the SEAL LMS disables reuse of location of UE-1 for UE-2. The SEAL LMS sends response back to the SEAL LMC-1.

When location reuse is enabled, if location request for UE-2 is received from VAL server, the SEAL LMS reuses and provides the location of UE-1 (instead of location of UE-2) to the VAL server. When location reuse is disable, if location request for UE-2 is received from VAL server, the SEAL LMS provides the location of UE-2 only (instead of reusing location of UE-1) to the VAL server.

9.3.24 Support for sidelink positioning / ranging management |R19| p. 116

9.3.24.1 Procedure of SL positioning /ranging management service p. 116

The procedure provides a mechanism for configuring and provisioning information on the entities to be used and their responsibilities for a SL positioning / ranging service. In this procedure, an SL positioning enabler capability at LMS is authorized / delegated by SL positioning server to support the provisioning/delivery of ranging services in an area.

Figure 9.3.24.1-1 shows a high-level procedure with the details.

Reproduction of 3GPP TS 23.434, Fig. 9.3.24.1-1: Support for SL positioning procedure

The VAL server (SL Positioning / Ranging Server) sends an SL positioning management subscription request to SEAL LMS to provision and manage SL positioning / ranging operation and configurations.

The SEAL LMS authorizes the VAL subscription request.

The SEAL LMS sends an SL positioning management subscription response to the requestor VAL Server.

Figure 9.3.25-1: Short-Range based positioning information procedure

The SEAL LMS discovers all the SEAL LMCs in the target service area, and categorizes them by their capabilities as target UE, Reference UEs, or even Located UEs (if Reference UE location is known or for out of coverage scenarios). The identification of UEs in a target area happens via existing SEAL LMS procedures (as in clauses 9.3.10 and 9.3.12).

Step 5.

The SEAL LMS after getting all UE information at the target area, calculates the relative distances among them, and may request/receive HDMaps (e.g., from other VAL servers) for the target area.

Then, SEAL LMS evaluates the need of reference UE (based the information in step 4), and if reference UE is needed (e.g. in NLoS situation), the SEAL LMS selects the appropriate VAL UE to serve as reference and configures the VAL UEs (target, reference, client) with configuration information (thresholds, reporting configurations).

The LMS may also leverage analytics services (e.g. NWDAF) to obtain VAL UE location related predictions (e.g. UE location prediction, relative distance prediction) to discover reference UEs.

Step 6.

The SEAL LMS sends a SL positioning management notify message to the VAL server to indicate the roles of the VAL UEs and acknowledging that the SL positioning provisioning is performed.

Step 7.

The SEAL LMS configures the SEAL LMCs with the configuration information applicable to the corresponding VAL UEs based on step 5, and in particular the expected role (acting as reference UE, target UE) in relation ranging/SL positioning service. Based on this configuration, the LM clients interacts each other using off-network location management procedures as described in clause 9.5.

9.3.25 Short-Range based positioning information |R19| p. 118

Figure 9.3.25-1 describes a procedure to expose Short-Range based positioning information to third parties.

Pre-condition:

Target and reference UEs are configured and provisioned for SL positioning management service as described in clause 9.3.24.

Reproduction of 3GPP TS 23.434, Fig. 9.3.25-1: Short-Range based positioning information procedure

A VAL server sends a Short-Range based positioning information request to SEAL LMS to initiate ranging/SL positioning operation for target and reference UEs. The request includes the VAL service identifier, the reference UE list (client, target and reference UEs), the requested Short-Range based positioning information (e.g. range, direction, relative position, relative velocity, etc.), reporting events, QoS requirement, and expiration of the Short-Range based positioning information request.

The SEAL LMS sends a request to the Client UE to initiate the Short-Range based positioning information procedure between the target and reference UEs using the information provided in step 1.

The Client UE initiates the Ranging/SL positioning operation as described in TS 23.586 or in off network location reporting as specified in clause 9.5. Either UE-only operation or Network-based operation is performed when using procedure in TS 23.586.

Figure 9.3.26.2-1: Procedure of confirm location service subscription

The Client UE sends the Short-Range based positioning information results to the SEAL LMS, which uses the Short-Range based positioning information results to derive a field of view for the target UE. The SEAL LMS uses the range and direction between the target UE and reference UEs to determine UEs that are within a field of view of the target UE.

Step 5.

The SEAL LMS sends a response to the VAL server with the requested Short-Range based positioning information and exposes location information of UEs within a field of view of the target UE.

9.3.26 Verify UE location procedure |R19| p. 118

9.3.26.1 General p. 118

Verify UE location could be used by multiple applications that need confirmed location to provide their service. The UE application logic would first confirm customer location before accepting customer requests for service in a specific location.

This procedure provides the VAL server application with subscription for verification service and supports verification of UE provided location by the LMS. Only UEs using application with such subscription can use the confirm location verification from LMS. Sharing of UE location to the network is only possible with user consent. The network provided location is not directly shared but only verification is provided to the requesting LM client. The verified location is for internal UE usage.

9.3.26.2 Confirm location service subscription p. 119

The application is running on a VAL server. The application would like to use confirm location service and subscribes to LMS for it using the following procedure:

Reproduction of 3GPP TS 23.434, Fig. 9.3.26.2-1: Procedure of confirm location service subscription

The VAL server subscribes to LMS to receive notification every time UE using specific application is requesting confirmation of location.

The LMS shall check if the VAL server is authorized to subscribe for the confirm location service notifications for a specific application identifier.

If the VAL server and specific application are authorized to subscribe for confirm location service, the LMS creates subscription based on provided parameters in the request.

Figure 9.3.26.3-1: Procedure of confirm location verification

The LMS sends to VAL server confirm location service subscription response.

9.3.26.3 Confirm location verification p. 119

The location management client (LMC)/application in the UE gets from non-3GPP positioning (e.g. GNSS) in the UE its location. The application in the UE wants to check if this is really the correct location.

Pre-conditions:

The LMC is authorized to discover and to use Confirm Location API provided by the LMS;
LMS is authorized to use Nnef Event Exposure API, based on SLA with NEF/5GS of MNO;
It is assumed there is user consent given in the UE for exposing location information from UE to LMS.

Reproduction of 3GPP TS 23.434, Fig. 9.3.26.3-1: Procedure of confirm location verification

The UE sends Confirm Location request from the LMC towards LMS. It contains the location measured from the UE (non-3GPP location information, e.g. GNSS). It contains latitude and longitude, accuracy, timestamp, carrier name, cell id (known to the UE from the network signalling), application identifier.

The LMS shall check if there is subscription (based on VAL subscription in clause 6.12.2.1) for confirm location service with the specific application identifier received in step1. If subscription is present, step 3 is performed. If subscription is not present the LMS replies back to LMC with confirm location status unknown (step 4).

LMS requests UE location from 5GC/LMF via NEF (LMS send determine Location operation via NEF (N33 interface) and using Nlmf_Location API defined in TS 29.572 - parameters available from the location reporting are described in the TS). It also requests accuracy to be a parameter present in the response. LMS can also perform a location information request to GMLC directly or via NEF (as defined in clause 6.1 of TS 23.273), acting as AF. LMS can also perform a location information request to 3rd party location servers via LM-3P interface. LMS can also use the T8 interface to obtain UE location. Or the LMS can have already the UE location based on the methods described in TS 23.434. The received response contains the UE location from the network. LMS compares the location provided from the network with the location provided from the LMC. LMS can use event exposure using NEF according to Table 4.15.3.1-1 of TS 23.502 to obtain user location information from AMF.