This clause provides location reporting functionality for both UE location obtained as part of normal network access or user service usage and location actively triggered through location based services or other LALS reporting.
In addition, clause 7.3.4 describes Cell Supplemental Information (CSI) (e.g., civic address, geographical coordinates, or operator specific information) derived from CSP databases.
For all UE locations obtained, generated or reported to the MDF2, the POI shall report the time at which the location was established by the location source (e.g. AMF, MME or HSS/UDM) and provide this to the MDF along with the location information.
For all UE locations obtained, generated or reported to the ICF, the IEF shall report the time at which the location was established by the location source (e.g. AMF) and provide this to the ICF along with the location information.
This clause specifies requirements relating to location reporting that is obtained as part of target user usage of network services. Only location reporting that is available as part of the network service being used by the target user is specified in this clause.
This clause defines requirements for reporting of location when location is provided as part of other associated interception information sent from the POI to the MDF2.
Location shall be available at the start and end of a user communication. In addition, where available, a POI shall be able to provide location updates to the MDF2 (e.g. due to UE mobility at the AMF or MME).
The following information shall be transferred from the POI to the MDF2 as part of POI events for which location reporting is required:
Date/time of UE location(s) (if target location provided).
Source location information (if target location provided).
This clause defines a dedicated location reporting event when location cannot be reported (or is not available) at the same time as the POI output event for which the location was required is sent to the MDF2. The event shall also be used when an updated location becomes available and no other suitable POI output event message is triggered (e.g. mid- session location update).
Location reporting availability shall be the same as for embedded location reporting in clause 126.96.36.199.
The following information needs to be transferred from the POI to the MDF2 in order to enable a MDF2 to perform its functionality:
LALS provides lawful access to the target's location. LALS is based on the Location Services (LCS) capabilities defined in TS 23.271, TS 23.273 and inOMA MLP . The 5G Core Network support of LCS is described in clause 4.4.4 of TS 23.501 and clause 4.13.5 of TS 23.502.
LALS shall adhere to the requirements in clauses 6.6 (Security) and 6.3 (Detect and Capture) of TS 33.126. The LCS supporting LALS shall be able to provide priority to LALS requests. The subscriber location privacy settings shall be overridden for LALS by setting the privacy override indicator to "override" in the LI LCS client profile in the GMLC (see clause 5.4.4 of TS 23.273).
For inbound roaming targets, the VPLMN LCS functional entities fulfilling LALS requests, by default, shall not communicate with the target's HPLMN, as it may cause detectability issues, but rather the GMLC shall be able to determine the serving AMF/MME from which it can acquire the inbound roaming target's location. Detectability issues may also exist when LALS is invoked for outbound roaming targets. This means by default, the GMLC shall refrain from performing the positioning of an outbound roaming target.
Depending on national requirements and LCS capabilities of the CSP, the location information provided by LALS may vary in location information types (mobile network cell ID, location shape and geo-coordinates, civic address, or a combination of those), in the set of additional location parameters (map data, motion state, speed, etc.), as well as in the accuracy of provided location information.
The parameters controlling the LALS output are either delivered per warrant over the LI_X1 interface from the ADMF to the LI-LCS Client, or to the Location Triggering Function (LTF, see clause 188.8.131.52), or are pre-configured in the LI-LCS Client. The LI-LCS Client is a special type of IRI-POI in the CSP network fulfilling the role of the LCS client for LALS purposes. As such, the LI-LCS client shall support all the requirements and interfaces in accordance with TS 23.273 for an LCS client.
There are two types of the location interception defined in the present document: target positioning and triggered location.
Target positioning determines the target's location independently of the services used by the target.
Triggered location determines the LALS based location of the target when specific network or service events related to the target occur.
The warrant for target positioning and for triggered location of the same target may be independent of each other and may be overlapping in time or combined in a single intercept warrant by the LEA.
There may be multiple active LALS warrants from different LEAs at any given time.
As required by TS 33.126 R6.3 - 370, the location provision variants supported in the current document are immediate location and periodic location.
The LI-LCS client shall include an IRI-POI that has the LI capabilities to generate the target UE's location related xIRI.
Figure 7.3-1 shows the architecture for LALS where the LI-LCS client provides the target's location and associated information towards the MDF2 over the LI_X2 interface as per the ADMF request for target positioning delivered over LI_X1 interface.
The request for immediate location provision is delivered to the LI-LCS client over the LI_X1 interface. Upon receiving the request, the LI-LCS client initiates a Location Immediate Request (LIR, see TS 23.271) to the LCS Server/GMLC supporting LALS over the Le interface and reports the acquired location to the MDF2 over LI_X2.
While waiting for a response to an LIR from the LCS Server/GMLC, the LI-LCS client may receive and process additional LIRs from the ADMF over the LI_X1.
The resulting immediate location information shall be delivered by the LI-LCS client as xIRI over LI_X2 to the MDF2. The MDF2 generates and delivers the IRI messages based on received xIRI to the LEMF over LI_H2.
The request for periodic location provision is delivered to the LI-LCS client over the LI_X1 interface.
The request for periodic location from the ADMF to the LI-LCS client may include a set of parameters defining the duration of reporting, report periodicity, etc. The description of the service response parameters is provided in clause 184.108.40.206. The periodic location result shall be delivered by the LI-LCS client as xIRI over LI_X2 to the MDF2. The MDF2 generates and delivers the IRI messages based on received xIRI to the LEMF over LI_H2.
The periodicity of the LALS reports shall be controlled by the LI-LCS client. The LI-LCS client shall issue a series of Location Immediate Requests (LIR, see TS 23.271) at required time intervals.
The Triggered location is the capability of providing LALS based location information when specific network or service events related to the target occur. While IRI generated by the event that also triggers the LALS may have the location information included (in the form of cell ID), LALS may provide additional location parameters, such as the target geo-location, velocity, etc. (see TS 33.126 R6.3 - 270). The triggered location reporting utilizes the immediate location variant.
The LALS triggered location architecture in Figure 7.3-2 and Figure 7.3-3 depicts the Location Triggering Function (LTF). The LTF is an IRI-TF and resides in the same NF (e.g. AMF) that has the IRI-POI or in an MDF2. The LTF is responsible for triggering the IRI-POI in the LI-LCS Client when a specific event related to the target is observed at the co-located IRI-POI or received at the MDF2 in which the LTF is residing.
Figure 7.3-2 depicts the architecture of Triggered Location for IRI acquisition and delivery for the case when the LTF is residing in the same NF that has the IRI-POI reporting IRI events for the target.
In case of triggered location, the LTF (present in either an NF hosting an IRI-POI or in a MDF2) is provisioned by the ADMF over LI_X1 interface.
As part of this request, the ADMF provides the address for the LTF to reach the LI-LCS client for use on the LI_T2 interface. The IRI-POI (s) or the MDF2 then arm the LTF(s).
The LTF triggers the LI-LCS client over the LI_T2 interface.
The LALS result is delivered to MDF2 from the LI-LCS Client as xIRI over the LI_X2 interface asynchronously with the associated IRI events delivered by the IRI-POI. To enable correlation between the LALS reports and the associated IRI events, the LTF shall include the correlation information of the IRI event, if provided by the IRI-POI, into the LI_T2 trigger.
When a cell identity is provided for the target's location in an IRI message, the CSP may also provide CSI for the reported cell identity. The MDF2 may retrieve CSI by access to a CSP maintained database (referred to as CSP Cell Database) as shown in Figure 7.3.4-1. The CSP delivers the CSI either via the IRI message generated from the corresponding xIRI, or asynchronously in a stand-alone Cell Site Report (CSR) IRI message.
The following information shall be delivered when CSI is provided in IRI message or a MDF2 generated CSR:
Date/time(s) established by MDF2.
Cell supplemental information.
Cell supplemental information (CSI) shall include the physical location (e.g. geographical coordinates) information for the reported cell. If the reported cell is not fixed to a permanent location, the report should indicate the cell mobility type (e.g. nomadic cell, vehicle-mounted cell) as well as the time period of the location validity.
If CSI for a cell identity has been previously reported to the LEMF for the current interception, CSI may be omitted, if allowed by the warrant.
If the CSP does not support CSR or CSI, the database can be provided by non-real-time means.
This clause defines the location acquisition procedure, which provides lawful access to the target's network-provided location. The outcome of this procedure is the target's TAI, NCGI and optionally the timestamp when the target's location was acquired. It is emulating the AMF location services request and consumes the response as defined in clause 220.127.116.11 of TS 29.518. The AMF shall override any user consent, privacy and paging restrictions concerned with location acquisition that may apply to the target UE.
The LEA shall be able to indicate in the request to the LAF whether the AMF location services shall be invoked or whether the current stored value of the location as known by the AMF is returned.
Prior to issuing of location acquisition requests, the LEA shall provide an authorization for these requests. This is done by issuing a warrant over the LI_HI1 interface prior to issuing the location acquisition requests. Subsequently, the LIPF will provision the MDF2 if needed.
This clause describes the architecture for location acquisition. The architecture is based on the use of a LAF, which communicates with the LARF associated with an AMF over the LI_XLA interface.
To use the location acquisition procedure, the LAF needs to determine the serving AMF for the target UE.
The LAF is requested to perform location acquisition via the LI_HILA interface between LEA and LAF. Upon receiving the request, the LAF initiates location acquisition to the LARF via the LI_XLA interface.
The networks shall support the delivery of location information via the following methods:
Location information is delivered back as a response to the location acquisition request via the LAF over the LI_XLA and the LI_HILA interfaces.
Location information is delivered via the MDF2 over the LI_X2_LA and the LI_HI2 interfaces.
The two delivery options may be used simultaneously.
The LARF and the IRI-POI will exchange the necessary information to ensure that IRI-POI will not generate the xIRI for location requests initiated by the LARF.
The ADMF shall be able to audit the LARF over the LI_XLA interface.
Upon determining the location, the LARF will forward the location information to the LAF via the LI_XLA interface. The retrieved information is further provided in the response to the LEA over the interface LI_HILA. The LARF and the IRI-POI will exchange the necessary information to ensure that IRI-POI will not generate the xIRI for location requests initiated by the LARF.
Upon determining the location, the LARF shall forward the location information to the MDF2 over the LI_X2_LA interface using the information provided by the LAF in the LI_XLA request (e.g. internal intercept identifier). The retrieved information is further provided by the MDF2 to the LEMF via the LI_HI2 interface. The LARF and the IRI-POI will exchange the necessary information to ensure that IRI-POI will not generate the xIRI for location requests initiated by the LARF.