Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.273  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   4.2a…   4.3…   5…   5.5…   6…   6.1.2   6.1.3   6.1.4…   6.2   6.3…   6.3.2…   6.4   6.5…   6.7…   6.7.3   6.7.4   6.7.5   6.8   6.9…   6.10…   6.11…   6.12…   6.13…   6.14…   6.15…   6.16…   6.17…   6.18…   6.19…   6.19.2…   6.20…   6.20.4…   6.21…   7…   8…   A…   B…   C…

 

5.5  Location service exposurep. 39

Location service can be exposed to the authorized control plane NF or the LCS client to obtain the UE location to enable their application and services using the MT-LR procedure. For the location service exposed to the AF which is not allowed to directly interact with the GMLC or AMF, CAPIF API may be used between NEF and the AF as described in clause 6.2.5.1 of TS 23.501.
For location service exposure, there are two types of location service requests as defined in clause 4.1a.4 and clause 4.1a.5:
  • Location Immediate Request (LIR); and
  • Location Deferred Request (LDR).
The following attributes may be included in the location service requests:
  • Target UE identity;
  • LCS Client identity or AF ID;
  • Service identity, if needed;
  • Codeword, if needed;
  • Type of Event definition, i.e. UE available, change of area, motion or periodic location, applicable to deferred location requests only;
  • Indication of requiring reliable UE location information;
  • Definitions for change of area type deferred location requests. Following parameters may be defined, if needed:
    1. Indication for event trigger, i.e. UE enters, leaves or is within requested target area;
    2. Indication of either a single event report or multiple event reports;
    3. Minimum time interval between area event reports, if multiple event reports are requested;
    4. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the change of area event report;
    5. Duration of event reporting;
    6. Maximum time interval between reports;
    7. Maximum sampling time for event detection;
    8. Indication to have an additional check whether UE is located within the requested target area, and when this additional check is requested, the location estimate is mandatory;
  • Definitions for motion type deferred location requests. Following parameters may be defined, if needed:
    1. Linear distance threshold;
    2. Indication of either a single event report or multiple event reports;
    3. Minimum time interval between motion event reports, if multiple event reports are requested;
    4. Indication of the requested location estimate; i.e. whether the location estimate of the target UE should be contained in the motion event report;
    5. Duration of event reporting;
    6. Maximum time interval between reports;
    7. Maximum sampling time for event detection;
  • Definitions for periodic location type deferred location requests. Following parameters may be defined, if needed:
    1. Time interval between successive location reports;
    2. Total number of reports;
  • Start time, stop time (i.e. specifying the validity time of LCS request), if needed for LCS Client e.g. using the OMA MLP protocol;
  • Interval, applicable to periodical requests only;
  • Requested LCS Quality of Service information, if needed, i.e. accuracy, response time and LCS QoS Class;
  • Requested type of location, i.e. "current location", "current or last known location" or "initial location" applicable to LIR only (current location is only available for LDR);
  • Supported GAD shapes, if needed;
  • Velocity of the UE, if needed;
  • Priority, if needed;
  • Service coverage (i.e. E.164 country codes for geographic areas, ITU-T Recommendation E.164 [23]), if needed;
  • Requested maximum age of location, if needed;
  • Local coordinate reference system, if needed for LCS Client e.g. using the OMA MLP protocol;
  • Target area, i.e. geographical area expressed as one of the following format, if needed:
    1. a shape defined in TS 23.032;
    2. local coordinate system for LCS Client e.g. using the OMA MLP protocol;
    3. E.164 country code for a geographic area [23] for LCS Client e.g. using the OMA MLP protocol;
    4. PLMN identity for LCS Client e.g. using the OMA MLP protocol;
    5. geopolitical name of the area (e.g. London) for LCS Client e.g. using the OMA MLP protocol;
  • Response Method, if needed for LCS Client e.g. using the OMA MLP protocol;
  • Scheduled Location Time.
  • Definitions for periodic or triggered location reporting from a UE to an LCS Client or AF over user plane. Following parameters may be defined, if needed:
    1. Request for user plane reporting;
    2. User plane address of the LCS Client or AF;
    3. Security information to enable a secure connection.
The following attributes may be included in the location service response:
  • Location indication of UE in geographical coordinates and/or local coordinates expressed as a shape as defined in TS 23.032 or for LCS Client e.g. using the OMA MLP protocol, local coordinate reference system;
  • Velocity of the UE as defined in TS 23.032, if requested and if available;
  • The information about the positioning method used to obtain the location estimate of the UE, if it is available at the LCS server and if needed;
  • Time stamp of location estimate;
  • Indication when UE enters, is within or leaves the Geographical area, if needed;
  • Acknowledgement for a deferred location request, if needed.
  • Request id, if needed.
  • Indication that the requested QoS was not met, if needed, only applicable if the request was for best effort class
  • Indication of a periodic event.
  • Indication of a motion event.
  • Indication that a deferred location request has been activated in a UE.
  • Indication of expiration of the maximum reporting interval for the area event or motion event for LCS Client e.g. using the OMA MLP protocol.
  • Indication of a cumulative event for user plane location reporting from a UE to an LCS Client or AF.
In addition, the information attributes of the location service request may be used also in the location service response.
For a LCS client in the core network, the LCS service request is sent to GMLC using Le interface.
For an AF not allowed to directly interact with the GMLC or AMF, the LCS service request is sent to NEF using the service based interface.
For an internal control plane NF, the LCS service request is sent to AMF or GMLC using the service based interface.
To support location service exposure through NEF, when NEF receives a LCS service request, it determines based on the location accuracy of the QoS requirement, e.g. lower or higher than cell-ID level, on whether to invoke the GMLC service or the AMF service for the LCS service request.
Up

5.6  LCS Chargingp. 41

Charging Information for LCS service is collected at GMLC and AMF. For roaming case, the Charging Information shall be collected in both home PLMN and visited PLMN for inter-operator charging purpose.
Charging mechanism for LCS service and the Charging Information collected at GMLC and at AMF are defined in TS 32.271 and TS 32.298.

5.7  Support of Concurrent Location Requestsp. 41

5.7.1  Generalp. 41

Concurrent Location Requests occur when any entity (e.g. UE, AMF, LMF, GMLC, NEF):
  • Case A: receives/initiates multiple LCS requests (e.g. 5GC-MT LR, 5GC-MO LR, 5GC-NI LR) for the location estimate of the same target UE within a time period; or
  • Case B: receives/initiates one or more new LCS request(s) (e.g. 5GC-MT LR, 5GC-MO LR, 5GC-NI LR) for the location estimate of the same target UE during the location session to support the old LCS request(s).
In either case, if allowed by the QoS requirements and privacy settings, the entity may combine the concurrent location requests by fully executing one of the requests and using the ensuing location estimate result(s) to satisfy the other request(s) without fully executing the latter. When concurrent location requests are supported, each entity needs to ensure it correlates each location/position response with the associated request and different concurrent location requests shall be treated separately without any dependency on one another by any entity.
If the entity, either itself or in association with another entity, cannot support concurrent location requests or it can only support up to a certain number of concurrent location requests, it can reject or defer a new concurrent request or cancel one or more existing requests. For Case B, it can also allow the new location request to proceed concurrently with and separately from the previous requests.
LCS Client/AF priority and any other relevant priority information (e.g. UE subscription preferences) should be considered when rejecting or deferring a concurrent request or when cancelling one or more existing requests. In particular, location requests associated with emergency services or lawful interception clients should be given priority over other location requests.
Up

5.7.2  Combining location requests by an H-GMLC or NEFp. 42

An H-GMLC or NEF may combine concurrent location requests (e.g. 5GC-MT LR, 5GC-MO LR, 5GC-NI LR) for the same target UE by executing only one request and using the ensuing location estimate result(s) to satisfy the other request(s). The conditions for this are as follows:
  • the H-GMLC must be able to fully resolve privacy requirements for the other location request(s) without requiring notification or verification by the UE (though notification only as in steps 17-23 of clause 6.1.2 could still be used in the case of location dependent privacy); and
  • the QoS for the other request(s) should be less strict than the QoS for the executed location request.
An H-GMLC may also combine concurrent location requests in the case of a bulk location request for a group of UEs as described in clause 6.8. In this case, location information for any UE in the group may be obtained from location information obtained from another concurrent location request for the same UE.
Up

5.7.3  Combining location requests by a V-GMLCp. 42

A V GMLC may combine concurrent 5GC-MT LR and 5GC-MO-LR related location requests for the same target UE provided it is clear and unambiguous for any 5GC-MT LR that will not be fully executed (e.g. from the contents of any location request received from the H GMLC) that no outstanding privacy related actions are required for the UE (e.g. no privacy notification and/or privacy verification interaction with the UE). QoS requirements must also be satisfied for the non-executed location requests.

5.7.4  Combining location requests by an AMFp. 42

An AMF may combine concurrent 5GC-MT LR, 5GC-MO LR and 5GC-NI LR location requests once any needed privacy related actions (e.g. UE notification and verification) have been performed for each 5GC-MT LR. (i.e. AMF may decide to not execute multiple positioning procedures for the concurrent location requests) QoS requirements must also be satisfied for the non-executed location requests.

5.7.5  Combining location requests by an LMFp. 42

An LMF may combine concurrent location requests for the same target UE provided QoS requirements can be satisfied for the non-executed location requests.

5.7.6  Combining location requests by a UEp. 42

A UE may combine concurrent location requests provided QoS requirements can be satisfied and provided any positioning procedures with an LMF remain supported according to the positioning protocol.

5.8  Interworking with the IMSp. 43

When the location service request is initiated by the LCS Client / AF for the location estimation of a target UE in an IMS session, a SIP-URI or a TEL-URL maybe included in the request to identify the target UE. In that case, the H-GMLC of the UE shall be able to convert the SIP-URI/TEL-URL into SUPI of the target UE.
Up

5.9  Location Service involving Mobile Base Station Relay |R18|p. 43

5.9.1  Generalp. 43

A MBSR (i.e. mobile IAB-node) may have location service capability as specified in TS 38.305 and participate in the location service of a UE. As the MBSR may be moving, the location service procedures need to be enhanced as following for an accurate estimation of the UE positioning:
  • The UE reports the cell IDs of all the cells the UE performed DL positioning measurements on.
  • The MBSR which performed the location service procedures for the UE includes it's cell ID in the reported UL positioning measurement.
  • The AMF serving the UE provides the cell ID of serving cell of the UE and indicates, if possible, that the cell-ID belongs to a MBSR to the LMF in the location request. The AMF serving the UE also provides LMF with the additional ULI Information received from NG-RAN, so that the LMF can initiate the positioning procedure to obtain the location information of the MBSR.
  • Additionally, the LMF uses the reported cell IDs to derive whether the cell ID(s) corresponds to a MBSR. There can be multiple MBSR cells in the measurement report.
  • The LMF may also decide whether the cell ID(s) corresponds to MBSR(s) based on information received in a TRP information exchange i.e. that the cell-ID belongs to a MBSR and the UE-ID (GPSI) associated with MBSR.
  • To aid the LMF to improve the accuracy of the UE location estimation, the MBSR velocity information and time of obtaining its location measurement data should be obtained by the LMF when available. The LMF uses the received location and velocity of the MBSR(s) when estimating the location of the Target UE.
Up

5.9.2  Obtaining location information for the MBSRp. 43

There are multiple options for an LMF to obtain the location information and velocity of the MBSR(s):
  • The LMF can derive the location and velocity of the MBSR by triggering the gNB serving the MBSR using NRPPa or by requesting the GMLC to derive the location of the MBSR (UE) using the UE-ID of the MBSR. The GMLC triggers MT-LR procedure as specified in clause 6.11.1 or 6.11.2.
  • As the timing of the location estimations for the Target UE and MBSR(s) is important for the quality of the location estimation of the Target UE, the LMF needs to reduce the timing offset of the positioning measurements, i.e. the positioning of the Target UE and MBSR can be scheduled with using the same scheduled location time and compensate for the potential time difference of the positioning measurements, e.g. taking velocity of MBSR into account.
Up

5.9.3  Privacy check for MBSRp. 43

If the positioning of the MBSR is performed for the location estimation of a Target UE (UE different from the MBSR), the privacy check in clause 5.4 is skipped for the MBSR. When the LMF requests the GMLC to derive the location of the MBSR (UE), the LMF includes a MBSR indication indicating the location of MBSR is requested to determine the location of a Target UE in the location request. The GMLC obtains the subscription information of the MBSR (UE) from the UDM. Based on the indication, and/or MBSR's subscription information, the GMLC skips the privacy check.
If the positioning of the MBSR is performed for the location estimation of the MBSR itself when it acts as a normal UE which is not authorized to operate as MBSR based on the subscription information, the UE privacy check procedure in clause 5.4 is performed.
Up

5.10  Support of Positioning over user plane connection between UE and LMF for non-regulatory service |R18|p. 44

LMF and UE may utilize a user plane connection to transfer supplementary services messages and LPP messages. User Plane protocol (LCS-UPP) to support supplementary services messages and LPP messages transport between the UE and the LMF is defined in TS 24.572.
If LMF decides to use user plane the LMF should indicate the UE to use user plane for positioning with the information to establish a secure connection, and via this secure connection, position messages can be transferred between UE and the LMF. The URSP defined in TS 23.503 is used by UE to determine how to route the position messages. The operator may provide LMF(s) address information and connection capability for LCS use in traffic descriptors and LCS user plane positioning dedicated PDU session parameters (e.g., DNN and S-NSSAI) in Route Selection Descriptors to the UE as part of the URSP rule. The position messages can be routed to an established PDU Session or can trigger the establishment of a new PDU Session. The LMF and UE may maintain the established user plane connection and the established user plane connection may be reused for subsequent user plane position messages transmission trigged by UE or LMF. If the LMF detects the user plane connection is not used for an implementation specific time, the LMF terminates the user plane connection. The supplementary services messages transferred over user plane only support event report messages, periodic triggered invoke messages and MS cancel deferred location messages.
Up

5.11  Collection of GNSS assistance data |R18|p. 44

LMF may collect GNSS assistance data by reusing Data Collection from AF as described in clause 5.20a of TS 23.501 and Naf_EventExposure service described in clause 5.2.19.2 of TS 23.502. The collection may be performed on a periodic basis.
LMF generates a mapping table of GNSS assistant data and applicable area (e.g. TA lists). LMF may generate multiple sets of GNSS assistance data for the same location area, and each of them corresponds to a certain location accuracy. The accuracy of GNSS assistance data may vary for different areas.
After the collection, LMF may send the collected GNSS assistance data to UEs via the procedures described in clause 6.14.1 (Broadcast of Assistance Data by an LMF) or clause 6.11.1 (UE Assisted and UE Based Positioning Procedure) during a positioning session.
In the case of using Broadcast of Assistance Data by an LMF, the LMF may provision one or more of GNSS assistance data to RAN. LMF may also provision one or more cyphered key(s) to UE from the AMF, and each cyphered key corresponds to a certain GNSS assistance data.
Up

5.12  UE Unaware Positioning |R18|p. 44

UE Unaware Positioning applies to the regulatory location service. When UE Unaware Positioning is required by LCS Client/AF, if the UE is in CM_IDLE or RRC_INACTIVE state, the UE cannot be paged during the positioning procedure. In this case, the 5GC provides the latest stored UE location information to the LCS Client/AF if the requested LCS QoS can be achieved. If the UE is in CM_CONNECTED state, the LMF selects Uplink Positioning method to obtain UE location.

5.13  Support of location service in PNI-NPN with signalling optimisation |R18|p. 45

Support of location service in PNI-NPN is based on the PNI-NPN description defined in clause 5.30.3 of TS 23.501. PNI-NPN architecture described in Annex C are supported.
Under the PNI-NPN architecture described in Annex C, the relevant Network Functions in local network are defined as follows:
  • Local AMF, an AMF type function deployed in the local network, it supports:
    • Functionalities related to AMF service operation "NonUeN2MessageTransfer" within Namf_Communication service, defined in TS 29.518.
    • Handling "UL and DL NON UE ASSOCIATED NRPPA TRANSPORT", defined in TS 38.413.
  • LMF, deployed in the local network, it supports:
    • Pre-configured with local AMF FQDN or communication address.
    • For DL UE associated NRPPa signalling, sends the signaling message to the serving AMF.
    • For DL NON UE associated NRPPa signalling, sends the signaling message to the local AMF.
  • NG-RAN, deployed in the local network, it supports:
    • Pre-configured with local AMF FQDN or communication address.
    • Establishes TNL association with local AMF.
    • For UL UE associated NRPPa signalling, sends the signalling message to the serving AMF
    • For UL NON UE associated NRPPa signalling, sends the signalling message to the local AMF
  • GMLC, deployed in the local network.
    • UDM, deployed in public network, it supports:
    • Pre-configured with UE's allowed local network list.
    • For GMLC request from a different network domain, verify GMLC request by checking whether the local network of GMLC is on the pre-configured UE's allowed local network list. For Nudm_SDM_Get request or Nudm_UECM_Get request from local network, sends the UE data (i.e. privacy setting of UE, current serving AMF address, SUPI) after successful verification.
When UE access the NG-RAN in the local network, during the registration procedure or service request procedure, NG-RAN selects the serving AMF in the public network. With appropriate configuration, local AMF cannot be selected as the serving AMF for the UE.
During the positioning procedure, if LMF determines network assisted positioning method, the positioning procedure defined in clause 6.11.2 is used and the AMF is the serving AMF. If the LMF determines to obtain Non-UE Associated Network Assistance Data, the positioning procedure defined in clause 6.11.3 is used and the AMF is the local AMF.
For MO-LR, immediate MT-LR and deferred MT-LR, the AMF provides the GMLC contact address and a reference number to LMF. When LMF determines UE location, LMF provides the UE location to GMLC directly, as defined in clause 6.3.1.
Up

5.14  Event Report Allowed Area |R18|p. 46

During the deferred 5GC-MT-LR procedure, when the UE detects the triggered or periodic event happens, if it is inside the event report allowed area, the UE is allowed to generate and send the event report to network to reduce UE power consumption.
The event report allowed area is a list of cell(s) or TA(s) determined by GMLC based on the event report expected area provided by UE which is a geographical area and is sent to the UE during the deferred 5GC-MT-LR procedure.
The event report allowed area applies to the Area, Periodic Location and Motion event types. When the UE decides to send an event report (i.e. the event is detected or the maximum reporting time is expired), if the UE is inside the event report allowed area, the UE sends the event report. If the event report is not received from the UE for an implementation dependent time period, the AF or LCS Client or GMLC cancels the deferred 5GC-MT-LR procedure for periodic, or triggered location events.
The event report allowed area can also be used differently if an area usage indication is provided together with the event report expected area by the UE. A reporting indication that is determined by GMLC based on the area usage indication means when the UE detects the triggered or periodic event happens, if it is outside the event report allowed area, the UE is allowed to generate and send the event report to network to reduce UE power consumption.
Up

5.15  Support of Low Power and High Accuracy Positioning |R18|p. 46

Service requirements for low power and high accuracy positioning (LPHAP) is defined in TS 22.261 and TS 22.104. Support of low power and high accuracy positioning is optional in this release of specification.
Low power and high accuracy positioning is supported via subscription and in the LCS related subscriber data in the UDM, an LPHAP indication may be included.
During the positioning procedure, AMF provides the LPHAP indication to the LMF. The LPHAP indication is either obtained from the GMLC, or stored in the UE LCS context received during UE registration procedure.
If LMF receives from AMF of the LPHAP indication in the location request, LMF determines appropriate positioning method, e.g. network-based positioning method, or may determine to trigger the low power periodic and triggered 5GC-MT-LR procedures in clause 6.7 by taking into account the LPHAP indication. In addition, LMF may also send LPHAP Assistance Information defined in TS 38.455 to RAN in the positioning procedure, as defined in clause 6.11.2.
Up

5.16  Location services assisted by NWDAF |R18|p. 46

LMF and AMF may utilize analytics from NWDAF to assist with location services as described in clause 6.21.
NWDAF may provide Location Accuracy analytics as specified in clause 6.17 of TS 23.288 to LMF. When LMF receives analytics for Location Accuracy from the NWDAF, it may use the analytics to determine indoor or outdoor for a location estimate, to select or adjust appropriate positioning methods for the requested location accuracy.
NWDAF may provide UE related mobility analytics as specified in clause 6.7 of TS 23.288 to AMF. The UE location information received in analytics can be used by AMF to perform the UE location verification for NR satellite access.
Up

5.16A  Network data analytics assisted by LCS |R18|p. 46

NWDAF may interact with the LCS system to request location information for a target UE or a group of UEs via Ngmlc services or NL9.
NWDAF may request an aggregated report for a single UE from GMLC to include multiple UE location estimates for a period of time. NWDAF may also provide a reporting time to indicate the latest time for reporting.
Up

5.16B  LCS Continuity During UE Mobility |R18|p. 47

LCS session continuity during UE mobility applies to:
  • deferred triggered/periodic MT-LR, immediate MT-LR and MO-LR procedures.
  • uplink, downlink or uplink and downlink positioning methods.

5.16B.1  Mobility Between 5GS and EPSp. 47

LCS continuity of UE in RRC-CONNECTED state enables transfer of a location session between 5GS and EPS. The LCS QoS may then be mapped from the source RAT to the target RAT.
The Lr' interface between the EPC-GMLC and 5GC-GMLC is implementation specific - or the EPC-GMLC and 5GC-GMLC may be co-located.

5.17  Support of Ranging and Sidelink Positioning |R18|p. 47

Ranging and Sidelink Positioning as defined in TS 23.586 is supported. The following procedures have been specified to support the Network Assisted Sidelink Positioning:
Up

5.18  Support for UE positioning based on a ML Model at the LMF |R19|p. 47

The LMF may calculate the UE location and estimate the achieved accuracy by using LMF-based AI/ML Positioning. When receiving the request for a UE location, the LMF selects an appropriate positioning method as described in clause 5.2 to determine the result of the positioning. The result of the positioning may be calculated by using LMF-based AI/ML Positioning ML model supported by LMF. The LMF collects input data from UE or NG-RAN for the LMF-based AI/ML Positioning to perform location calculation and provide the location to the consumer.
The ML model that is used for LMF-based AI/ML Positioning in LMF may be trained by LMF. The trigger for data collection and model training in LMF is up to implementation. LMF collects input data from UE for ML model training is described in clause 5.18.1.
LMF may also request a ML model for LMF-based AI/ML Positioning from NWDAF containing MTLF. LMF discovers a suitable NWDAF containing MTLF via NRF as described in clause 5.2 of TS 23.288. LMF requests ML model training for LMF-based AI/ML Positioning with ML Model Filter Information, which may indicate the area of interest. NWDAF containing MTLF collects input data to perform the ML model training and model provision to LMF as described in clause 6.2A of TS 23.288.
Either LMF or NWDAF containing MTLF may perform performance monitoring for LMF-based AI/ML Positioning. LMF may determine whether to use the LMF-based AI/ML Positioning to perform location calculation based on the model performance monitoring result. LMF may also trigger the ML model retraining in the training entity based on the result of model performance result.
Up

5.18.1  Data collection at LMF to train the AI/ML based positioning model to perform positioning based on UE measurementsp. 48

The LMF needs to obtain input data for AI/ML based positioning model training and may also request the UE to provide the UE location. The AI/ML based positioning model is trained to perform UE positioning for UEs located in an area of interest that may expand over multiple TA or cover multiple NG-RAN nodes.
Reproduction of 3GPP TS 23.273, Fig. 5.18.1-1: Data collection by LMF to train the AI/ML based positioning model using UE measurements
Up
Step 1.
The LMF starts data collection for the purpose to train a AI/ML Model for UE Positioning. The LMF subscribes to AMF to retrieve the list of SUPIs located in an area of interest using Namf_EventExposure_Subscriber_Request (Target of Event Reporting = "any UE", Event ID = "UEs in/out area of interest".
Step 2.
The AMF send Namf_EventExposure_Subscriber_Response ("list of SUPIs in the area of interest").
Step 3.
The LMF checks the user consent for data collection for model training.
Step 4.
For each UE that provides consent to data collection for model training and can support data collection the LMF initiates a request for input data.
At the time the LMF decides that the input data for a UE are not needed, e.g. the user consent for data collection for model training is revoked, the LMF stops to collect the input data from the UE to train the AI/ML based positioning model.
Up

5.19  Location Service involving Mobile Wireless Access Backhaul |R19|p. 49

5.19.1  Generalp. 49

A MWAB may have location service capability as specified in TS 38.305 and participate in the location service of a UE. As the MWAB may be moving, the location service procedures need to be enhanced as following for an accurate estimation of the UE position:
  • The UE reports the cell IDs of all the cells the UE performed DL positioning measurements on.
  • The MWAB which performed the location service procedures for the UE includes its cell ID in the reported UL positioning measurement.
  • The AMF serving the UE provides the cell ID of serving cell of the UE and indicates, if possible, that the cell-ID belongs to a MWAB to the LMF in the location request. The AMF serving the UE may also provide LMF with the additional ULI Information received from MWAB.
  • Additionally, the LMF uses the reported cell IDs to derive whether the cell ID(s) corresponds to a MWAB. There can be multiple MWAB cells in the measurement report.
  • The LMF may also decide whether the cell ID(s) corresponds to MWAB(s) based on information received in a TRP information exchange i.e., that the cell-ID belongs to a MWAB and the UE-ID (GPSI) associated with MWAB.
  • To aid the LMF to improve the accuracy of the UE location estimation, the MWAB velocity information and time of obtaining its location measurement data should be obtained by the LMF when available. The LMF uses the received location and velocity of the MWAB(s) when estimating the location of the Target UE.
The reference architectures for MWAB involved location services in different scenarios are specified in Annex S of TS 23.501.
Up

5.19.2  Obtaining location information for the MWABp. 49

There are multiple options for an LMF to obtain the location information and velocity of the MWAB(s):
  • The LMF can derive the location and velocity of the MWAB by using NRPPa or by requesting the (H)GMLC to derive the location of the MWAB-UE using the UE-ID of the MWAB-UE. The GMLC triggers MT-LR procedure as specified in clause 6.11.1 or 6.11.2.
  • As the timing of the location estimations for the Target UE and MWAB(s) is important for the quality of the location estimation of the Target UE, the LMF needs to reduce the timing offset of the positioning measurements, i.e. the positioning of the Target UE and MWAB can be scheduled with using the same scheduled location time and compensate for the potential time difference of the positioning measurements, e.g. taking velocity of MWAB into account.
Up

5.19.3  Privacy check for MWABp. 49

If the positioning of the MBSR is performed for the location estimation of a Target UE (UE different from the MWAB), the privacy check in clause 5.4 is skipped for the MWAB. When the LMF requests the GMLC to derive the location of the MWAB (UE), the LMF includes a MWAB indication indicating the location of MWAB is requested to determine the location of a Target UE in the location request. The GMLC obtains the subscription information of the MWAB (UE) from the UDM. Based on the indication, and/or MWAB's subscription information, the GMLC skips the privacy check.
If the positioning of the MWAB is performed for the location estimation of the MWAB itself when it acts as a normal UE which is not authorized to operate as MWAB based on the subscription information, the UE privacy check procedure in clause 5.4 is performed.
Up

Up   Top   ToC