Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.273  Word version:   16.3.0

Top   Up   Prev   Next
1…   4…   4.2a…   4.3…   5…   6…   6.1.2   6.2   6.3…   6.3.2…   6.4   6.5…   6.7…   6.8   6.9…   6.10…   6.11…   6.12…   6.13…   6.14…   7…   8…   A…   B…

 

4  Architecture Model and Concepts
4.1  General Concepts
A general description of location services and service requirements are given in the specification TS 22.071. 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 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 a control plane NF within a PLMN. 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, 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 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.
Up
4.1a  Types of Location RequestWord-p. 10
4.1a.1  Network Induced Location Request (NI-LR)
With a Network Induced Location Request (NI-LR), a serving AMF for a UE initiates location of the UE for some regulatory service (e.g. an emergency call from the UE).
4.1a.2  Mobile Terminated Location Request (MT-LR)
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)
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
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. An immediate location request may be used for an NI-LR. MT-LR or MO-LR.
4.1a.5  Deferred Location Request
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
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 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 ServiceWord-p. 11
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:
  • LCS QoS Class.
  • Accuracy.
  • Response Time.
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 2 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.
  • 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.2  Architectural Reference ModelWord-p. 12
4.2.1  Non-roaming reference architecture
Figure 4.2.1-1 shows an architectural reference model for 5GS LCS for a non-roaming UE in reference point representation.
Up
NOTE 1:
(R)AN represents NG-RAN, trusted non-3GPP access or untrusted non-3GPP access.
NOTE 2:
Reference point interface related to charging functionality is not shown in this specification.
Figure 4.2.1-2 shows an architectural reference model for 5GS LCS for a non-roaming UE in SBI representation.
Up
4.2.2  Roaming reference architectureWord-p. 13
Figure 4.2.2-1 shows an architectural reference model for 5GS LCS for a roaming UE in reference point representation.
Up
NOTE 1:
(R)AN represents NG-RAN, trusted non-3GPP access or untrusted non-3GPP access.
NOTE 2:
Reference point interface related to charging functionality is not shown in this specification.
NOTE 3:
If I-NEF is deployed in the VPLMN it is used to support interworking between AMF in the VPLMN and the NEF in the HPLMN. The roaming architecture for network exposure function and related interfaces are defined in TS 23.501.
Figure 4.2.2-2 shows an architectural reference model for 5GS LCS for a roaming UE in SBI representation.
Up
NOTE 4:
If I-NEF is deployed in the VPLMN it is used to support interworking between AMF in the VPLMN and the NEF in the HPLMN. The roaming architecture for network exposure function in SBI representation and related interfaces are defined in TS 23.501.

Up   Top   ToC