Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.127  Word version:  16.4.0

Top   Top   Up   Prev   Next
0…   5…   5.4…   5.6…   6…   6.3…   7…   7.3…   7.4…   7.4.7…   7.5…   8…   A…   A.2…   A.3…   A.4…   B…

 

7.3  Location

7.3.1  General

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.
Up

7.3.2  Service usage location reporting

7.3.2.1  General

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.

7.3.2.2  Embedded location reporting

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:
  • Target location(s).
  • Date/time of UE location(s) (if target location provided).
  • Source location information (if target location provided).
Up

7.3.2.3  Separated location reporting

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 7.3.2.2.
The following information needs to be transferred from the POI to the MDF2 in order to enable a MDF2 to perform its functionality:
  • Target identity.
  • Event date/time.
  • Target location(s).
  • Date/time of UE location(s).
  • Nature and identity of the POI.
  • Location source(s).
Up

7.3.3  Lawful Access Location Services (LALS)Word‑p. 53

7.3.3.1  General

LALS provides lawful access to the target's location. LALS is based on the Location Services (LCS) capabilities defined in the TS 23.271 and in the OMA MLP specification [6]. 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 Clause 6.6 (Security) and Clause 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 (see Clause 9 of TS 23.271) shall be overridden for LALS.
For inbound roaming targets, the VPLMN LCS functional entities fulfilling LALS requests should not communicate with the target's HPLMN, as it may cause detectability issues. Detectability issues may also exist when LALS is invoked for outbound roaming targets.
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 7.3.3.3), or are pre-configured in the LI-LCS Client. The LI-LCS Client is an IRI-POI in the CSP network fulfilling the role of the LCS client for LALS purposes.
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.
Up

7.3.3.2  Target positioningWord‑p. 54
7.3.3.2.1  General
As required by the R6.3 - 370 of TS 33.126, the location provision variants supported in the current document are immediate location and periodic location. 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.
[not reproduced yet]
Figure 7.3-1: LALS model for target positioning
Up
7.3.3.2.2  Immediate location provision
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 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 is delivered over LI_X2 to the MDF2 and propagated to the LEMF over LI_HI2.
Up
7.3.3.2.3  Periodic location provision
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 7.3.3.4. The periodic location result is delivered over LI_X2 to the MDF2 and propagated to the LEMF over LI_HI2.
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 LI-LCS client provides the acquired location reports to the MDF2 over LI_X2.
Up

7.3.3.3  Triggered location

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), the LALS may provide additional location parameters, such as the target geo-location, velocity, etc. (see R6.3 - 270 of TS 33.126).
The LALS triggered location architecture in Figures 7.3-2 and 7.3-3 depicts the LTF. The LTF is an IRI-TF embedded into an IRI-POI (e.g. AMF, etc.), or into an MDF2. The LTF is responsible for triggering the LI-LCS Client when a specific event related to the target is observed at the IRI-POI or received at the MDF2. Figure 7.3-2 depicts the architecture of Triggered Location for IRI acquisition and delivery for the case when the LTF is embedded into an IRI-POI reporting IRI events for the target.
[not reproduced yet]
Figure 7.3-2: LALS model for triggered location (POI/LTF option)
Up
Figure 7.3-3 depicts the architecture of triggered location acquisition and delivery for the case when the LTF is embedded into an MDF2.
[not reproduced yet]
Figure 7.3-3: LALS Model for triggered location (MDF/LTF option)
Up
The request for triggered location is delivered from the ADMF to either an IRI-POI or to a MDF2 over LI_X1 interface along with other parameters of IRI intercept authorization/activation. 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 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.
Up

7.3.3.4  LI_X2 interface for target positioning and triggered locationWord‑p. 56
The following information needs to be delivered from the LI-LCS Client to MDF2 in order to enable the MDF2 to format and deliver LALS intercept product to LEMF:
  • Target identity.
  • Target reported location(s).
  • Date/time(s) location(s) established by reporting function.
  • Additional location parameters based on operator policy.
  • Correlation information.

7.3.4  Cell database information reporting

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:
  • LIID.
  • Cell identity.
  • Date/time(s) established by MDF2.
  • Cell supplemental information.
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.
[not reproduced yet]
Figure 7.3.4-1: CSP cell database
Up

Up   Top   ToC