7.3 Location
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
7.3.1 Lawful Access Location Services (LALS)
7.3.1.1 General description
The LALS architecture and functionality is specified in TS 33.127 [5] clause 7.3.3.
7.3.1.2 Provisioning over LI_X1
7.3.1.2.1 Target positioning service
For the LALS target positioning service (TS 33.127 [5] clause 7.3.3.2) the IRI-POI provided by the LI-LCS Client is directly provisioned over LI_X1 by the LIPF using the LI_X1 protocol as described in clause 5.2.2 with the TaskDetailsExtensions field of the ActivateTask message specifying the type of the target positioning request, immediate vs. periodic, and, in the latter case, the periodicity of the positioning requests.
Based on national regulatory requirements and CSP policy, the TaskDetailsExtensions may also include the QoS parameters (specified in OMA-TS-MLP-V3_5-20181211-C [20]) for the use on the Le interface towards the LCS Server/GMLC. Alternatively, the QoS parameters may be statically configured in the LI-LCS Client.
Table 7.3.1.2-1 shows the details of the LI_X1 ActivateTask message used for the LI-LCS Client provisioning for the target positioning service.
The LI_X1 DeactivateTask shall be issued by the LIPF to terminate the target positioning service and withdraw the associated provisioning data, except for the Immediate target positioning service in which case the LI_X1 DeactivateTask is not used.
Table 7.3.1.2-1: ActivateTask message for LI-LCS Client target positioning provisioning
|
ETSI TS 103 221-1 field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
One of the following (see ETSI TS 103 221-1 [7]): – SUPIIMSI. – SUPINAI. – GPSIMSISDN. – GPSINAI. – IMSI. – MSISDN (E164Number target ID format, per ETSI TS 103 221-1 [7]). – IMPU. |
M |
|
DeliveryType |
Set to “X2Only”. |
M |
|
ListOfDIDs |
Delivery endpoints of LI_X2 interface. These delivery endpoints are configured in LI-LCS Client using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
TaskDetailsExtensions/ PositioningServiceType |
“Immediate” or “Periodic”. |
M |
|
TaskDetailsExtensions/ PositioningPeriodicity |
Time interval between the positioning requests in case of Periodic positioning, in seconds. |
C |
|
TaskDetailsExtensions/ PositioningParameters |
Set of optional parameters for MLP SLIR message, per OMA-TS-MLP-V3_5-20181211-C [20]: – requested location type (clause 5.3.60). – requested response type (clause 5.3.112.1). – max location age (clause 5.3.65). – response timing required (clause 5.3.106). – response timer (clause 5.3.107). – horizontal accuracy with QoS class (clause 5.3.44). – altitude accuracy with QoS class (clause 5.3.6). – motion state request (clause 5.3.70). |
O |
7.3.1.2.2 Triggered location service
For the LALS triggered location service (TS 33.127 [5] clause 7.3.3.3) the LTF, as an IRI-TF, is provisioned by the LIPF using the LI_X1 protocol as described in clause 5.2.2. The “TaskDetailsExtensions” parameter of the ActivateTask message in this case will carry the address of LI-LCS Client to be used for the service and, optionally, the positioning parameters for use on the Le interface, similar to the target positioning provisioning.
Prior to issuing one or more "ActivateTask" requests towards an LTF, the LIPF shall provision the LTF with the LI_X2 destinations by using the "CreateDestination" operation(s), as per clause 5.2.2.
Table 7.3.1.2-2 defines the details of the LI_X1 ActivateTask message used for the LTF provisioning for the Triggered Location service.
Table 7.3.1.2-2: ActivateTask message for LTF triggered location service provisioning
|
ETSI TS 103 221-1 field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
One or more of the following (see ETSI TS 103 221-1 [7]): – SUPIIMSI. – SUPINAI. – GPSIMSISDN. – GPSINAI. – IMSI. – MSISDN (E164Number target ID format, per ETSI TS 103 221-1 [7]). – IMPU. NOTE: An ActivateTask for an LTF may be issued by the LIPF if and only if at least one of the identifiers in the above list was specified in the warrant. |
M |
|
DeliveryType |
Set to “X2Only”. |
M |
|
ListOfDIDs |
Delivery endpoints for LI-LCS Client LI_X2. These delivery endpoints are configured in LTF using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
|
TaskDetailsExtensions/ LILCSClientAddress |
The IP address of the LI-LCS Client for triggering. |
M |
|
TaskDetailsExtensions/ PositioningParameters |
Set of optional parameters for MLP SLIR message, per OMA-TS-MLP-V3_5-20181211-C [20]: – requested location type (clause 5.3.60). – requested response type (clause 5.3.112.1). – max location age (clause 5.3.65). – response timing required (clause 5.3.106). – response timer (clause 5.3.107). – horizontal accuracy with QoS class (clause 5.3.44). – altitude accuracy with QoS class (clause 5.3.6). – motion state request (clause 5.3.70). |
O |
7.3.1.3 Triggering over LI_T2
An LTF, as an IRI-TF, provisioned as described in clause 7.3.1.2.2, triggers the LI-LCS Client (which plays the role of a triggered IRI-POI) using the LI_T2 protocol as described in clause 5.2.4. The "TaskDetailsExtensions" in the LI_T2 "ActivateTask" message carries the positioing parameters mapped from information the LTF receives from the ADMF over the LI_X1. The LI_T2 "ActivateTask" message header may include a correlation ID from the triggering xIRI, if available.
Prior to issuing one or more "ActivateTask" requests towards an LI-LCS Client, the LTF shall provision the LI-LCS Client with the LI_X2 destinations by using the "CreateDestination" operation(s), as per clause 5.2.2. The LI-LCS Client shall deactivate the task on its own upon issuing the final xIRI for the trigger. There is no DeactivateTask operation on the LI_T2 for the LI-LCS Client.
Table 7.3.1.3-1 shows the details of the LI_T2 ActivateTask message used by the LTF to trigger LI-LCS Client for the triggered location service.
Table 7.3.1.3-1: ActivateTask message from LTF to LI-LCS Client for the triggered location service triggering
|
ETSI TS 103 221-1 field name |
Description |
M/C/O |
|
XID |
The same value as in the LTF provisioning (clause 7.3.3.2.2). |
M |
|
TargetIdentifiers |
One of the following (see ETSI TS 103 221-1 [7]): – SUPIIMSI. – SUPINAI. – GPSIMSISDN. – GPSINAI. – IMSI. – MSISDN (E164Number target ID format, per ETSI TS 103 221-1 [7]). – IMPU. NOTE: The target identifier used shall correspond to one of the target identifiers in the xIRI observed by the LTF, and shall be one of the identifiers provided in the ActivateTask for the LTF (clause 7.3.1.2.2). |
M |
|
DeliveryType |
Set to “X2Only”. |
M |
|
ListOfDIDs |
Delivery endpoints for LI-LCS Client LI_X2. These delivery endpoints are configured in LI-LCS Client by the LTF using the CreateDestination message as described in ETSI TS 103 221-1 [7], clause 6.3.1 prior to the task activation. |
M |
|
CorrelationID |
Correlates the requested location to the triggering xIRI, if available. |
C |
|
TaskDetailsExtensions/ PositioningParameters |
Set of optional parameters for MLP SLIR message, per OMA-TS-MLP-V3_5-20181211-C [20]: – requested location type (clause 5.3.60). – requested response type (clause 5.3.112.1). – max location age (clause 5.3.65). – response timing required (clause 5.3.106). – response timer (clause 5.3.107). – horizontal accuracy with QoS class (clause 5.3.44). – altitude accuracy with QoS class (clause 5.3.6). – motion state request (clause 5.3.70). |
O |
7.3.1.4 Generation of xIRI over LI_X2
The IRI-POI provided by the LI-LCS client shall deliver the target location reports to respective MDF(s) as xIRI over the LI_X2 interface.
Table 7.3.1.4-1: LALSReport record
|
Field name |
Description |
M/C/O |
|
sUPI |
SUPI of the target, if used for the service (see NOTE). |
C |
|
gPSI |
GPSI of the target, if used for the service (see NOTE). |
C |
|
iMSI |
IMSI of the target, if used for the service (see NOTE). |
C |
|
mSISDN |
MSISDN of the target, if used for the service (see NOTE). |
C |
|
iMPU |
IMPU of the target, if used for the service (see NOTE). |
C |
|
location |
Location of the target, if obtained successfully. Encoded as a positioningInfo parameter (location>positioningInfo). Both the positionInfo (location>positioningInfo>positionInfo) and the mLPPositionData (location>positioningInfo>rawMLPResponse>mLPPositionData) are present in the case of successful positioning. In the case of positioning failure only the mLPErrorCode (location>positioningInfo>rawMLPResponse>mLPErrorCode) is present. See Annex A. |
C |
|
NOTE: One and only one of SUPI, GPSI, IMSI, MSISDN, IMPU shall be present and it shall correspond to the target identifier included in the respective ActivateTask message for the LI-LCS Client. |
||
The LI-LCS Client generating an xIRI containing an LALSReport record shall set the Payload Direction field in the PDU header to not applicable (Direction Value 5, see ETSI TS 103 221-2 [8] clause 5.2.6).
The LI_X2 header (as per clause 5.3.2) of the LALSReport record presented in table 7.3.1.4-1 shall contain the correlation ID (if provided) from a respective LI_T2 ActivationTask message.
7.3.1.5 Generation of IRI over LI_HI2
The LALSReport payload, defined in clause 7.3.1.4, shall be used as the payload of the respective LALSReport record, no payload mediation is required.
A LALSReport message shall be assigned the same CIN (see ETSI TS 102 232-1 [9] clause 5.2.4) as the IRI message that triggered the LALS reporting, if that triggering IRI message is assigned a CIN. Otherwise, i.e. when the LALSReport is a result of the LALS Target Positioning, or the triggering IRI message has no CIN assigned, the CIN in the LALSReport shall be omitted.
NOTE: In some specific scenarios the amount of LALS reports data may overload the LI_HI2 and/or LI_X2 interfaces. To prevent the overload, a flow control for LALS triggered location reports may be implemented in MDF and/or LI-LCS client, e.g. by limiting the frequency of the reports for individual targets.
7.3.2 Cell database information reporting
7.3.2.1 General description
When the location information present within an xIRI includes the cell identity, the MDF2 that receives the xIRI may retrieve the cell site information for that cell from a CSP database and deliver the same to the LEMF either within the IRI message generated from the received xIRI or in a separate IRI message containing the MDFCellSiteReport record.
For each intercept, if the MDF2 reports the cell site information, then it shall provide such information at least on the initial appearance of the cell identity in the related xIRI.
NOTE: The CSP needs to ensure that the most recent cell site information is reported to the LEA.
7.3.2.2 Delivery of cell site information over LI_HI2
The cell site information is encoded as the cellSiteInformation ASN.1 parameter and delivered either within the location field of an IRI message carrying the respective cell identity, or in a stand-alone IRI message containing the MDFCellSiteReport record.
The MDF2 shall use the IRI message containing the MDFCellSiteReport record to convey cell site information retrieved asynchronously with the sending of the IRI message that caused the retrieval. The MDFCellSiteReport record shall be delivered as an IRI REPORT (see ETSI TS 102 232-1 [9] clause 5.2.10) and allocated the same CIN, if any, as the IRI message that caused the retrieval.
When the cell site information is readily available at MDF2 or is retrieved synchronously (i.e. blocking the sending of the IRI message until the retrieval is complete), the cell site information shall be conveyed within the location field of the IRI message that caused the retrieval.
The cell site information for multiple cell identities can be delivered to the LEMF within an IRI message that carries the respective cell identities or within the IRI message containing the MDFCellSiteReport record (see Annex A).
The MDF2 generating the IRI message MDFCellSiteReport shall set the Payload Direction field in the PDU header to not applicable (Direction Value 5, see ETSI TS 103 221-2 [8] clause 5.2.6).
7.3.3 Use of the Location structure
7.3.3.1 General description
The Location structure is used to convey geolocation information.
When the reference datum used for a latitude and longitude given in the GeographicalCoordinates structure is known by the operator, the reference datum shall be identified in the mapDatumInformation field. The reference datum identity shall be specified as an Open Geospatial Consortium URN, as defined in OGC 05-010 [35].
7.3.4 Separated location reporting
7.3.4.1 General description
When location information cannot be reported via an existing message generation at the IRI-POI, a separate xIRI may be generated from any provisioned IRI-POI that has access to location information and included in the SeparatedLocationReporting record.
The following information needs to be transferred from the IRI-POI to the MDF2 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).
Details of how the IRI-POI in the SMF generates this record can be found in clause 6.2.3.2.1.
Details of how the IRI-POI in the NEF generates this record can be found in clause 7.7.2.1.1.
Details for Location Only reporting using this record can be found in clause 7.3.6.
Table 7.3.4.1-1: Payload for SeparatedLocationReporting record
|
Field name |
Description |
M/C/O |
|
sUPI |
SUPI associated with the registration (see clause 6.2.2.4). |
M |
|
sUCI |
SUCI used in the registration, if available. |
C |
|
pEI |
PEI provided by the UE during the registration, if available. |
C |
|
gPSI |
GPSI obtained in the registration, if available as part of the subscription profile. |
C |
|
gUTI |
5G-GUTI provided as outcome of initial registration or used in other cases, see TS 24.501 [13] clause 5.5.1.2.2. |
C |
|
location |
Location information determined by the network at the time of message generation. |
M |
|
non3GPPAccessEndpoint |
For Non-3GPP access, UE’s local IP address used to reach the N3IWF, TNGF or TWIF. IP addresses are given as 4 octets (for IPv4) or 16 octets (for IPv6) with the most significant octet first (network byte order). |
C |
|
rATType |
RAT Type associated with the data for which location information is provided, see TS 23.502 [4] clause 4.3.2. Values given as per TS 29.571 [17] clause 5.4.3.2. |
C |
7.3.5 Location acquisition
7.3.5.1 General description
The architecture for location acquisition is specified in TS 33.127 [5], clause 7.3.5.
7.3.5.2 Acquisition request over LI_HILA
The LAF is responsible for receiving acquisition requests from the LEA over the LI_HILA interface. Further details of LI_HILA messages are defined in clause 5.11.
7.3.5.3 Acquisition request over LI_XLA
LI_HILA requests are used to generate a LI_XLA request to the LARF over the LI_XLA interface. Further details of LI_XLA messages are defined in clause 5.12.
7.3.5.4 Location acquisition procedure at the LARF
Upon the receipt of a location acquisition request over LI_XLA, the LARF shall first check that the UE is registered at the AMF. If it is registered the LARF will check the UE context at the AMF to see if the current location for the UE is known.
If the current location for the UE is known:
– If the ReqCurrentLoc parameter (see table 5.12.2.1-1) is set to true in the location acquisition request message received over LI_XLA, the LARF shall invoke a ProvideLocationInfo service operation in the AMF (see TS 29.518 [22] clause 5.5.2.4) using the information received in the location acquistion request message to generate the RequestLocInfo parameters. The LARF shall set the reqCurrentLoc parameter of the RequestLocInfo IE to true (see TS 29.518 [22] clause 5.5.2.4).
– If the ReqCurrentLoc parameter (see table 5.12.2.1-1) is set to false in the location acquisition request message received over LI_XLA, the LARF shall use the location information in the UE context at the AMF to generate and deliver a location acquisition response based on the provisioned delivery method as described in clauses 7.3.5.5 and 7.3.5.6.
If the current location for the UE is not known at the AMF, the LARF shall invoke a ProvideLocationInfo service operation in the AMF (see TS 29.518 [22] clause 5.5.2.4) using the information received in the location acquistion request message to generate the RequestLocInfo parameters.
The LARF/AMF shall override any user consent, privacy and paging restrictions concerned with location acquisition that may apply to the target UE. The LARF/AMF shall ensure that overriding these restrictions does not result in additional detectability issues.
7.3.5.5 Location acquisition delivery via the LI_HILA
7.3.5.5.1 Location acquisition response over LI_XLA
The LARF shall populate the LocationResponseDetails field in the LocationAcquisitionResponse message as specified in clause 5.11.2.3.
7.3.5.5.2 Location acquisition response over LI_HILA
On receiving a LocationAcquisitionResponse message containing a LocationResponseDetails field, the LAF shall return the results to the LEA over the LI_HILA interface. The LI_HILA response is represented as XML following the LocationResponseDetails type definition (see Annex I). Responses are delivered within a DELIVER Request (see ETSI TS 103 120 [6] clause 6.4.10) containing a DeliveryObject (see ETSI TS 103 120 [6] clause 10).
The DeliveryObject Reference field (see ETSI TS 103 120 [6] clause 10.2.1) shall be set to the Reference of the LDTaskObject used in the request to provide a correlation between request and response. The DeliveryID, SequenceNumber, and LastSequence fields shall be set according to ETSI TS 103 120 [6] clause 10.2.1.
The content manifest (see ETSI TS 103 120 [6] clause 10.2.2) shall be set to indicate that the response is returned as an HILAResponse using the following Specification Dictionary extension.
Table 7.3.5.5.2-1: Specification Dictionary
|
Dictionary Owner |
Dictionary Name |
|
3GPP |
ManifestSpecification |
|
Defined DictionaryEntries |
|
|
Value |
Meaning |
|
HILAResponse |
The delivery contains a LocationResponseDetails (see Annex I) |
7.3.5.6 Location acquisition delivery via the LI_HI2
7.3.5.6.1 Provisioning of the MDF2
The MDF2 listed as the delivery endpoint for xIRI generated by the LARF in the AMF shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2 prior to issuing of LI_XLA requests for the given target. Table 7.3.5.6.2-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.
The MDF2 shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– SUPIIMSI.
– SUPINAI.
– GPSIMSISDN.
– GPSINAI.
Table 7.3.5.6.1-1: ActivateTask message for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
One or more of the target identifiers listed in the paragraph above. |
M |
|
DeliveryType |
Set to “X2Only”. (Ignored by the MDF2). |
M |
|
ListOfDIDs |
Delivery endpoints of LI_HI2. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ListOfMediationDetails |
Sequence of Mediation Details, see table 7.3.5.6.1-2. |
M |
Table 7.3.5.6.1-2: Mediation Details for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
LIID |
Lawful Intercept ID associated with the task. |
M |
|
DeliveryType |
Set to “HI2Only”. |
M |
|
ListOfDIDs |
Details of where to send the IRI for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
7.3.5.6.2 LI_X2_LA delivery
The LARF shall generate the AMFLocationUpdate xIRI only when it detects that AMF returns the location for the corresponding LARF transaction.
The acquisition response shall be given as a AMFLocationUpdate xIRI record. The XID of the xIRI record shall be set to the XID specified in the original request (see clause 5.12.2).
7.3.5.6.3 LI_HI2 delivery
The MDF2 shall generate the IRI message based on the AMFLocationUpdate xIRI record from the LARF and deliver it to the LEMF over LI_HI2.
7.3.6 Location Only Reporting
7.3.6.1 General Information
In some cases, it may be required to deliver only location information associated to a target.
For a warrant authorizing only location reporting, all other IRI information not associated with Location shall not be delivered. For example, when a target places a voice call, the new location information available as part of the call handling, shall be reported, but nothing else. LocationOnly reporting may be provisioned using one of the following methods:
– Using a specific Location Only task provisioned at the IRI-POI.
– Using the Mediation Details at the MDF2.
7.3.6.2 Provisioning Information
The LocationOnlyProvisioning parameter may be included:
– As a TaskDetailsExtension of an ActivateTask message sent to an IRI-POI.
– As a MediationDetailsExtension of an ActivateTask message sent to an MDF2.
Table 7.3.6-1 shows the details of the LocationOnlyProvisioning parameter for TaskDetailsExtension and MediationDetailsExtension.
Table 7.3.6-1: LocationOnlyProvisioning parameters
|
Field name |
Description |
M/C/O |
|
LocationOnly |
If included, the LI function shall generate the messages described in clause 7.3.6.3. |
C |
7.3.6.3 Generation of Location Only xIRI
If the LocationOnly flag is set in the TaskDetailsExtension of an ActivateTask message sent to an IRI-POI that task is considered a Location Only task.
For Location Only task at the IRI-POI in the AMF, whenever any trigger specified for the IRI-POI in the AMF is met for the generation of an xIRI (see clause 6.2.2.2), instead of generating that xIRI, the IRI-POI in AMF shall generate an xIRI containing an AMFLocationUpdate record if there is any location information in the triggering event and send it to the MDF2 over LI_X2. If there is no location information in the triggering event, no xIRI shall be generated.
For a Location Only task at an IRI-POI not in the AMF, whenever any trigger specified for that IRI-POI is met, instead of generating that xIRI, the IRI-POI shall genereate an xIRI containing a SeparatedLocationReport record if there is any location information in the triggering event and send it over to the MDF2 over LI_X2 the xIRI is listed in below in this clause.
The IRI-POI in the UDM shall generate the following xIRIs when the appropriate triggers are met and and send them over LI_X2 for Location Only tasks:
- UDMServingSystemMessage.
7.3.6.4 Generation of Location Only IRI
If the LocationOnly flag is set in the MediationDetailsExtension of an ActivateTask message sent to an MDF2 that task is considered a Location Only task only in the context of this specific MediationDetails set. The MDF2 shall generate IRIs for the following xIRIs for Location Only tasks and send them over LI_HI2:
- UDMServingSystemMessage.
- AMFLocationUpdate.
- LALSReport.
- SeparatedLocationReport.
In addition, whenever any xIRI for a Location Only task is received over LI_X2 from any IRI-POI, if the xIRI is not included in the list below and has location information, the MDF2 shall generate an IRI message containing a SeparatedLocationReport record and send it over LI_HI2 to the provisioned destinations without delay instead of the IRI message containing a copy of the relevant record received over LI_X2. The record may be enriched by other information available at the MDF (e.g. additional location information).
The MDF2 shall ignore the LocationOnlyProvisioning parameter if it is present in the TaskDetailsExtension of the ActivateTask message.