Content for  TS 23.273  Word version:  19.0.0

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

• SL-MO-LR involving LMF as defined in clause 6.20.1;
• SL-MT-LR involving LMF as defined in clause 6.20.3;
• 5GC-MO-LR Procedure using SL positioning as defined in clause 6.20.2;
• 5GC-MT-LR Procedure using SL positioning as defined in clause 6.20.5;
• SL-MT-LR for periodic, triggered Location Events as defined in clause 6.20.4.

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.