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 23.273  Word version:  19.0.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   4.2a…   4.3…   5…   5.5…   6…   6.1.2   6.1.3   6.1.4…   6.2   6.3…   6.3.2…   6.4   6.5…   6.7…   6.7.3   6.7.4   6.7.5   6.8   6.9…   6.10…   6.11…   6.12…   6.13…   6.14…   6.15…   6.16…   6.17…   6.18…   6.19…   6.19.2…   6.20…   6.20.4…   6.21…   7…   8…   A…   B…   C… 
4 Architecture Model and Concepts  4.1 General Concepts  4.1a Types of Location Request  4.1a.1 Network Induced Location Request (NI-LR)  4.1a.2 Mobile Terminated Location Request (MT-LR)  4.1a.3 Mobile Originated Location Request (MO-LR)  4.1a.4 Immediate Location Request  4.1a.5 Deferred Location Request  4.1a.5.1 Types of event  4.1b LCS Quality of Service  4.1c Scheduled Location Time 
...

 

4  Architecture Model and Concepts  p. 14

4.1  General Concepts  p. 14

A general description of location services and service requirements are given in the specification TS 22.071 and TS 22.261. Support of location services for GERAN, UTRAN and E-UTRAN access networks is described in TS 23.271, TS 43.059, TS 25.305 and TS 36.305.
The positioning of a UE can be supported by RAT dependent position methods, which rely on for example 3GPP RAT measurements obtained by a target UE and/or on measurements obtained by an Access Network of 3GPP RAT signals transmitted by a target UE. Positioning of a UE can also be supported by RAT independent position methods which may rely on non-RAT measurements obtained by a UE and/or on other information.
The Location Services defined in this specification are applicable to PLMN(s) and within a SNPN as described in clause 6, except for the following features, which are not supported in SNPNs:
  • interworking with EPC;
  • roaming; and
  • direct access to SNPN via non-3GPP access.
The Location Service in PNI-NPN with signalling optimisation is defined as clause 5.13.
The positioning of a UE can be performed by either 3GPP access network or non-3GPP access network. A proper access type shall be determined to assure that the positioning result can fulfil the requested QoS and operator policy.
Location information for one or multiple target UEs may be requested by and reported to an LCS client or an AF within or external to a PLMN or SNPN, or a control plane NF within a PLMN or SNPN. Location information contained in the location request and location information contained in the location response are defined in clause 5.5.
For location request from LCS client (neither in the UE nor in the NG-RAN) or AF external to a PLMN or SNPN, privacy verification of the target UE shall be enabled to check whether it is allowed to acquire the UE location information based on UE LCS privacy profile and whether the LCS client or the AF is authorised to use the location service as defined in clause 5.4. Additionally, UEs may optionally support privacy notification and verification on behalf of a user. Privacy override is also supported for regulatory LCS services according to local regulation.
The capabilities of a target UE to support LCS may be signalled by the UE to a serving PLMN or to an SNPN at the AS, NAS and application (positioning protocol) levels to enable use of position methods supported by the UE.
To provide Location Service in the EPC interworking scenario, an EPC and 5GC common interface shall be used for the location request from LCS client or AF.
Ranging based services and Sidelink Positioning for a UE can be supported, and details are described in clause 5.17.
Up

4.1a  Types of Location Request  p. 14

4.1a.1  Network Induced Location Request (NI-LR)  p. 14

With a Network Induced Location Request (NI-LR), a serving AMF for a UE initiates localization of the UE for a regulatory service (e.g. an emergency call from the UE) or for verification of a UE location (country or international area) for NR satellite access.

4.1a.2  Mobile Terminated Location Request (MT-LR)  p. 14

With a Mobile Terminated Location Request (MT-LR), an LCS client or AF external to or internal to a serving PLMN sends a location request to the PLMN (which may be the HPLMN or VPLMN) for the location of a target UE.

4.1a.3  Mobile Originated Location Request (MO-LR)  p. 15

With a Mobile Originated Location Request (MO-LR), a UE sends a request to a serving PLMN for location related information for the UE.

4.1a.4  Immediate Location Request  p. 15

With an immediate location request, an LCS client or AF sends or instigates a location request for a target UE (or group of target UEs) and expects to receive a response containing location information for the target UE (or group of target UEs) within a short time period which may be specified using QoS. In regulatory cases, one or more responses of the target UE's location information can be expected. An immediate location request may be used for an NI-LR, MT-LR or MO-LR.

4.1a.5  Deferred Location Request  p. 15

With a deferred location request, an LCS client or AF sends a location request to a PLMN for a target UE (or group of target UEs) and expects to receive a response containing the indication of event occurrence and location information if requested for the target UE (or group of target UEs) at some future time (or times), which may be associated with specific events associated with the target UE (or group of target UEs). In this version of the specification, only deferred location requests for an MT-LR are supported.
Up

4.1a.5.1  Types of event  p. 15

The following types of event are defined for a deferred location request.
  1. UE availability: Any event in which the 5GCN has established a contact with the UE. This event is considered to be applicable when the UE is temporarily unavailable due to inaction by the user, or for temporarily loss of radio connectivity or IMSI detach and so on. The UE Available event only requires one response to an LCS client/AF and after this response, the UE Available event is concluded.
  2. Area: An event where the UE enters, leaves or remains within a pre-defined geographical area. At least one type of area event can be defined (i.e. entering, leaving or remaining within the area). The LCS client or AF may define the target area as a geographical area or as a geopolitical name of an area. The PLMN may translate and define the target area as the identities of one or more radio cells or tracking areas. The LCS client or AF may request an additional check about whether the UE is located within the provisioned target area. The area event may be reported one time only, or multiple times. The area event report shall contain an indication of the event occurrence. The location estimate may be included in the report. If an area event is detected by the UE but an event report cannot be sent (e.g. because the UE cannot access the network or due to a minimum reporting interval), a report shall be sent later when possible irrespective of whether the area event still applies for the current UE location. Area event reporting is controlled by a minimum and a maximum reporting time. The minimum reporting time defines the minimum allowed time between successive area events. The maximum reporting time defines the maximum time between successive reports. When a UE sends a report due to expiration of the maximum reporting time, the UE indicates expiration of the maximum reporting time as the trigger event. The maximum reporting time enables the AF, LCS client and HGMLC to remain aware of continuing support by the UE for the area event (e.g. to detect if area event reporting may have been aborted due to UE power off).
  3. Periodic Location: An event where a defined periodic timer expires in the UE and activates a location report. If a periodic event is detected by the UE but an event report cannot be sent (e.g. because the UE cannot access the network temporarily), a report shall be sent later when possible and the periodic timer for the next event shall then be started. The reporting duration for periodic location shall equal the requested number of reports multiplied by the periodic interval even when reports are delayed.
  4. Motion: An event where the UE moves by more than some predefined straight line distance from a previous location. The motion event may be reported one time only, or multiple times. The motion event report shall contain an indication of the event occurrence. A location estimate may be included in the report if requested by the LCS client or AF. For successive motion event reports, motion is determined relative to the UE location corresponding to the immediately preceding event report (including an event report triggered by expiration of the maximum reporting time). If a motion event is detected by the UE but an event report is deferred (e.g. because the UE cannot access the network temporarily), a report shall be sent later when possible irrespective of whether the motion event still applies to the current UE location. Motion reporting is controlled by a minimum and a maximum reporting time. The minimum reporting time defines the minimum allowed time between successive event reports. The maximum reporting time defines the maximum time between successive reports. When a UE sends a report due to expiration of the maximum reporting time, the UE indicates expiration of the maximum reporting time as the trigger event. The maximum reporting time enables the AF, LCS client and HGMLC to remain aware of continuing support by the UE for the motion event (e.g. to detect if motion event reporting may have been aborted due to UE power off).
Up

4.1b  LCS Quality of Service  p. 16

LCS Quality of Service is used to characterise the location request. It can either be determined by the operator or determined based on the negotiation with the LCS client or the AF. It is optional for LCS client or the AF to provide the LCS Quality of Service in the location request.
LCS Quality of Service information is characterised by 3 key attributes:
The LCS QoS Class defines the degree of adherence by the Location Service to another quality of service parameter (Accuracy), if requested. The 5G system shall attempt to satisfy the other quality of service parameter regardless of the use of QoS Class. There are 3 LCS QoS Classes:
  • Best Effort Class: This class defines the least stringent requirement on the QoS achieved for a location request. If a location estimate obtained does not fulfil the other QoS requirements, it should still be returned but with an appropriate indication that the requested QoS was not met. If no location estimate is obtained, an appropriate error cause is sent.
  • Multiple QoS Class: This class defines intermediate stringent requirements on the QoS achieved for a location request. If the obtained location estimate does not fulfil the most stringent (i.e. primary) other QoS requirements affected by the degree of adherence of the QoS class, then another location estimation may be triggered at LMF attempting less stringent other QoS requirements. The process may be iterated until the least stringent (i.e. minimum) other QoS requirements are attempted. If the least stringent other QoS requirements cannot be fulfilled by a location estimate, then the location estimate shall be discarded, and an appropriate error cause shall be sent.
  • Assured Class: This class defines the most stringent requirement on the accuracy achieved for a location request. If a location estimate obtained does not fulfil the other QoS requirements, then it shall be discarded, and an appropriate error cause shall be sent.
For LCS client, it may indicate accuracy defined in TS 29.171, Table 7.4.7-1. For AF, it may either indicate the accuracy defined in TS 29.171, Table 7.4.7-1, or indicate a particular value e.g. PLMN ID defined in TS 29.122, Table 5.3.2.4.7-1.
Up

4.1c  Scheduled Location Time |R17|  p. 17

A scheduled location time allows an external LCS Client, AF or the UE to specify a time in the future at which a current location of the UE is to be obtained. A scheduled location time can be used with a 5GC-MT-LR, 5GC-MO-LR or deferred 5GC-MT-LR for periodic or triggered location events. The location preparation phase starts when a location related request is sent by an LCS Client, AF or UE requesting a current location of the UE. The request includes the scheduled location time T. As part of the location preparation phase, the 5GC, and UE interact to determine suitable position methods and schedule location measurements of the UE. The LMF coordinates the interaction and is aware of the scheduled location time. The location preparation phase ends at or near to the time T and is followed by a location execution phase in which the UE location is obtained and returned to the external LCS Client, AF or the UE.
A scheduled location time only applies when an external LCS Client, AF or the UE is aware of a specific time in the future at which the location of the UE is needed. A location estimate returned to an LCS Client, AF or UE for a scheduled location time can be treated by the LCS Client, AF or UE as an estimate of the location of the UE at the scheduled location time.
To support the Scheduled Location Time in 5GC-MO-LR, the UE defers sending the request to AMF until the time remaining until the scheduled location time is within some implementation dependent threshold in order to avoid failure triggered by HTTP request timeout.
When support the Scheduled Location Time in 5GC-MT-LR (i.e. the LCS Client/AF obtains one time UE location at Scheduled Location Time), to avoid failure triggered by HTTP request timeout, one of the following methods is applied:
  • The LCS Client or AF defers sending the request until the time remaining until the scheduled location time is within some implementation dependent threshold; or
  • Re-using the deferred 5GC-MT-LR for periodic location events procedure to realize providing one time UE location at Scheduled Location Time by, e.g. set the value of total reporting number parameter in the location request to one.
Up

Up   Top   ToC