Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.128  Word version:  18.6.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.7…   6…   6.2.2.2A…   6.2.3…   6.2.3.2.7…   6.2.3.3…   6.2.4…   6.3…   6.3.2.2A…   6.3.3…   6.3.3.2…   6.3.3.2.4…   6.3.3.2A…   7…   7.3…   7.3.3…   7.3.3.2.21…   7.3.3.2.42…   7.3.3.2.63…   7.3.4…   7.4…   7.4.3.8…   7.5…   7.6…   7.7…   7.7.4…   7.8…   7.8.4…   7.9…   7.10…   7.10.4…   7.11…   7.12…   7.13…   7.13.3…   7.13.3.4…   7.14…   7.15…   8…   A…   D…   E…   M… 
7.3.4 Separated location reporting  7.3.5 Location acquisition  7.3.5.1 General description  7.3.5.2 Acquisition request over LI_HILA  7.3.5.3 Acquisition request over LI_XLA  7.3.5.4 Location acquisition procedure at the LARF  7.3.5.4.1 General description  7.3.5.4.2 Location acquisition procedure at the LARF in case of EPC  7.3.5.4.3 Location acquisition procedure at the LARF in case of 5GC  7.3.5.5 Location acquisition delivery via the LI_HILA  7.3.5.5.1 Location acquisition response over LI_XLA  7.3.5.5.2 Location acquisition response over LI_HILA  7.3.5.6 Location acquisition delivery via the LI_HI2  7.3.5.6.1 Provisioning of the MDF2  7.3.5.6.2 LI_X2_LA delivery  7.3.5.6.3 LI_HI2 delivery  7.3.6 Location Only Reporting  7.3.6.1 General Information  7.3.6.2 Provisioning Information  7.3.6.3 Generation of Location Only xIRI  7.3.6.3.1 General  7.3.6.3.2 Location Only xIRI in 5GS  7.3.6.3.3 Location Only xIRI in EPS  7.3.6.4 Generation of Location Only IRI 
...

 

7.3.4  Separated location reporting  p. 207

7.3.4.1  General description  p. 207

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.
Field name Type Cardi­nality Description M/C/O
sUPISUPI1SUPI associated with the registration (see clause 6.2.2.4). If the location being reported is being reported from EPS, the IMSI shall be used as the values for this field.M
sUCISUCI0..1SUCI used in the registration, if available.C
pEIPEI0..1PEI provided by the UE during the registration, if available.C
gPSIGPSI0..1GPSI obtained in the registration, if available as part of the subscription profile.C
gUTIFiveGUTI0..15G-GUTI provided as outcome of initial registration or used in other cases, see clause 5.5.1.2.2 of TS 24.501.C
locationLocation1Location information determined by the network at the time of message generation. M
non3GPPAccessEndpointUEEndpointAddress0..1For 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
rATTypeRATType0..1RAT Type associated with the data for which location information is provided, see clause 4.3.2 of TS 23.502. Values given as per clause 5.4.3.2 of TS 29.571.C
ePSIdentitiesEPSSubscriberIDs0..1Indicates the identifiers for which the location is being reported. All target identifiers known at the NF shall be included.C
Up

7.3.5  Location acquisition  p. 207

7.3.5.1  General description  p. 207

The architecture for location acquisition is specified in clause 7.3.5 of TS 33.127.

7.3.5.2  Acquisition request over LI_HILA  p. 208

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  p. 208

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  p. 208

7.3.5.4.1  General description  p. 208
Upon the receipt of a location acquisition request over LI_XLA, the LARF shall first check that the UE is registered at the MME/AMF. If it is registered the LARF will check the UE context at the MME/AMF to see if the current location for the UE is known.
The LARF/MME/AMF shall override any user consent, privacy and paging restrictions concerned with location acquisition that may apply to the target UE. The LARF/MME/AMF shall ensure that overriding these restrictions does not result in additional detectability issues.
If delivery via the LI_HI2 is required, the LARF will send the acquisition response as either an AMFLocationUpdate (in case of the 5GC) or an MMELocationUpdate (in case of the EPC) xIRI record to the MDF2 via LI_X2_LA. Full details are given in clause 7.3.5.6.
If delivery via the LI_HILA is required, the LARF returns the acquisition response as part of the LI_XLA response, which the LAF then transforms into a LI_HILA response given as a LocationResponseDetails structure (see Table 5.11.2.3-1). Full details are given in clause 7.3.5.5 and clause 5.11.2.3.
Up
7.3.5.4.2  Location acquisition procedure at the LARF in case of EPC  p. 208
The procedure is as follows:
  • 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 the Insert Subscriber Data procedure, with the IDR-Flags with the "EPS Location Information Request" bit and the "Current Location Request" bit set (clause 5.2.2.1.2 of TS 29.272) using the information received in the location acquistion request message.
  • 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 MME 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.
Up
7.3.5.4.3  Location acquisition procedure at the LARF in case of 5GC  p. 208
The procedure is as follows:
  • 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 clause 5.5.2.4 of TS 29.518) 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 clause 5.5.2.4 of TS 29.518).
  • 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.
Up

7.3.5.5  Location acquisition delivery via the LI_HILA  p. 209

7.3.5.5.1  Location acquisition response over LI_XLA  p. 209
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  p. 209
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) as described in clause 5.11.2.3.
Up

7.3.5.6  Location acquisition delivery via the LI_HI2  p. 209

7.3.5.6.1  Provisioning of the MDF2  p. 209
The MDF2 listed as the delivery endpoint for xIRI generated by the LARF in the MME/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.1-2 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.
  • IMSI.
  • MSISDN.
ETSI TS 103 221-1 [7] field name Description M/C/O
XIDXID assigned by LIPF.M
TargetIdentifiersOne 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
ETSI TS 103 221-1 [7] field name Description M/C/O
LIIDLawful Intercept ID associated with the task.M
DeliveryType Set to "HI2Only". M
ListOfDIDsDetails 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
Up
7.3.5.6.2  LI_X2_LA delivery  p. 210
The LARF shall generate the MMELocationUpdate xIRI in case of the EPC or the AMFLocationUpdate xIRI in case of the 5GC only when it detects that MME/AMF returns the location for the corresponding LARF transaction.
In case of the 5GC, the acquisition response shall be given as a AMFLocationUpdate xIRI record. In case of the EPC, the acquisition response shall be given as an MMELocationUpdate xIRI record. The XID of the xIRI record shall be set to the XID specified in the original request (see clause 5.12.2).
Up
7.3.5.6.3  LI_HI2 delivery  p. 210
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  p. 210

7.3.6.1  General Information  p. 210

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

7.3.6.2  Provisioning Information  p. 210

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.
Field Name Description M/C/O
LocationOnlyIf included, the LI function shall generate the messages described in clause 7.3.6.3.C
Up

7.3.6.3  Generation of Location Only xIRI  p. 211

7.3.6.3.1  General  p. 211
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.
7.3.6.3.2  Location Only xIRI in 5GS  p. 211
For a 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.
Up
7.3.6.3.3  Location Only xIRI in EPS  p. 211
For a Location Only task at the IRI-POI in the MME, whenever any trigger specified for the IRI-POI in the MME is met for the generation of an xIRI (see clause 6.3.2.2.2), instead of generating that xIRI, the IRI-POI in MME shall generate an xIRI containing an MMELocationUpdate 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 MME, 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 HSS shall generate the following xIRIs when the appropriate triggers are met and and send them over LI_X2 for Location Only tasks:
  • HSSServingSystemMessage.
Up

7.3.6.4  Generation of Location Only IRI  p. 211

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.
  • HSSServingSystemMessage
  • MMELocationUpdate.
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.
Up

Up   Top   ToC