4 Architecture Model and Concepts

23.2733GPP5G System (5GS) Location Services (LCS)Release 18Stage 2TS

4.1 General Concepts

A general description of location services and service requirements are given in the specification TS 22.071 [2] and TS 22.261 [3]. Support of location services for GERAN, UTRAN and E-UTRAN access networks is described in TS 23.271 [4], TS 43.059 [5], TS 25.305 [17] and TS 36.305 [7].

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

4.1a Types of Location Request

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

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)

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

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.

4.1a.5.1 Types of event

The following types of event are defined for a deferred location request.

a) 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.

b) 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).

Editor’s note: Whether finer granularity area reporting is applicable to other deferred events, i.e. a), c), d), is FFS.

NOTE: To achieve more precise usage of area event in some scenario, e.g. for small target area, it may be useful if LCS Client/AF requests UE location estimate and compares the location estimate with the target area.

c) 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.

d) 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).

4.1b LCS Quality of Service

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 as defined below.

– Accuracy: i.e. Horizontal Accuracy (see clause 4.3.1 of TS 22.071 [2]) and Vertical Accuracy (see clause 4.3.2 of TS 22.071 [2].

– Response Time (e.g. no delay, low delay or delay tolerant as described in clause 4.3.3 of TS 22.071 [2]).

NOTE 1: One or two QoS values for Horizontal Accuracy, Vertical Accuracy can be provided in the location request in addition to a preferred accuracy when LCS QoS Class is set to Multiple QoS Class.

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.

NOTE 2: An AF may provide a location request with Multiple QoS Class via NEF. For an LCS client to provide a location request with Multiple QoS Class an Le interface implementation supporting Multiple QoS Class may be required.

NOTE 3: Multiple QoS Class can only be applied for Deferred 5GC-MT-LR Procedure in this release of the specification.

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

NOTE 4: How the LMF decides the positioning method is an implementation aspect not pre-determined by QoS criteria.

For LCS client, it may indicate accuracy defined in TS 29.572 [12], tables 6.1.6.3.2-1 and 6.1.6.3.5-1. For AF, it may either indicate the accuracy defined in TS 29.572 [12], table 6.1.6.3.2-1, or indicate a particular value e.g. PLMN ID defined in TS 29.122 [35], table 5.3.2.4.7-1.

4.1c Scheduled Location Time

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.

NOTE: Which method to be used is implementation specific.

4.2 Architectural Reference Model

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.

Figure 4.2.1-1: Non-roaming reference architecture for Location Services in reference point representation

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.

Figure 4.2.1-2: Non-roaming reference architecture for Location Services in SBI representation

4.2.2 Roaming reference architecture

Figure 4.2.2-1 shows an architectural reference model for 5GS LCS for a roaming UE in reference point representation.

Figure 4.2.2-1: Roaming reference architecture for Location Services in reference point representation

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.2-2 shows an architectural reference model for 5GS LCS for a roaming UE in SBI representation.

Figure 4.2.2-2: Roaming reference architecture for Location Services in SBI representation

4.2a Interconnection between 5GC and EPC

4.2a.1 General

For MT-LR Location Request, when a LCS service request is received at 5GC GMLC, the target UE may be served by either 5GC or EPC. An EPC/5GC common interface is used between the LCS Client and the 5GC GMLC to enable the location service request being handled based on whether the target UE is served by EPC or 5GC. The AF initiates the service request to the 5GC GMLC via NEF.

NOTE: The LCS Client doesn’t know if UE is currently served by EPC or 5GC.

For MT-LR Location Request, the 5GC interconnection with EPC happens:

– when an LCS service request is received by the 5GC GMLC and the target UE is served by EPC in non-roaming case;

– when an LCS request is received by the 5GC GMLC in the HPLMN of the target UE and the target UE is served by EPC in the VPLMN in roaming case.

4.2a.2 Non-roaming architecture

Figure 4.2a.2-1 represents the non-roaming architecture of Location Services for interconnection between 5GC and EPC.

Figure 4.2a.2-1: Non-roaming architecture of interconnection between 5GC and EPC

NOTE 1: EPC GMLC and 5GC GMLC can be collocated in implementation, in such case, Lr’ is not needed.

NOTE 2: For this release, Lr’ is not standardized.

4.2a.3 Roaming architecture

Figure 4.2a.3-1 and Figure 4.2a.3-2 represent the Roaming architecture of interconnection between 5GC and EPC.

Figure 4.2a.3-1: Roaming architecture of Location Services for interconnection between 5GC and EPC (5GC GMLC and EPC GMLC are separately deployed in VPLMN)

Figure 4.2a.3-2: Roaming architecture of Location Services for interconnection between 5GC and EPC (5GC GMLC and EPC GMLC are co-located in VPLMN)

4.2b Positioning methods

The LCS feature utilises one or more positioning methods in order to determine the location of user equipment (UE). Determining the position of a UE involves two main steps:

– Radio signal measurements or non-RAT measurements; and

– Position estimate computation based on the measurements.

The positioning methods for 3GPP access are described in clause 5.2.

The positioning methods for non-3GPP access are described in clause 5.3.1.

4.3 Functional description of LCS per network function

4.3.1 Access Network

The Access Network is involved in the handling of various positioning procedures including positioning of a target UE, provision of location related information not associated with a particular target UE and transfer of positioning messages between an AMF or LMF and a target UE. The Access Network shall support determination of location estimates in geographical and/or local co-ordinates as defined in TS 23.032 [8].

In this version of the specification, location services are supported for NG-RAN and non-3GPP access.

The LCS specific functionalities of the radio access network elements are specified in TS 38.305 [9] for NG-RAN.

4.3.2 LCS Clients, Application Functions and Network Functions

AFs and NFs may access LCS services from a GMLC in the same trust domain (e.g. in the same PLMN) using the Ngmlc interface or Event Exposure with location information from an AMF in the same trust domain using the Namf interface. The NWDAF collects UE location information by accessing GMLC directly.

LCS Clients may access LCS services from a GMLC (e.g. HGMLC) using the Le reference point.

External AFs may access LCS services from an NEF using Nnef interface or CAPIF API. The CAPIF and associated API provider domain functions are specified in TS 23.222 [24].

An LCS Client or AF may access LCS services from a UE over a user plane connection for reporting of location events by the UE for a periodic or triggered 5GC-MT-LR when the UE is able to determine location estimates.

4.3.3 Gateway Mobile Location Centre, GMLC

The Gateway Mobile Location Centre (GMLC) contains functionality required to support LCS. In one PLMN, there may be more than one GMLC.

A GMLC is the first node an external LCS client accesses in a PLMN (i.e. the Le reference point is supported by the GMLC). AFs and NFs may access GMLC directly or via NEF. The GMLC may request routing information and/or target UE privacy information from the UDM via the Nudm interface. After performing authorization of an external LCS Client or AF and verifying target UE privacy, a GMLC forwards a location request to either a serving AMF using Namf interface or to a GMLC in another PLMN using the Ngmlc interface in the case of a roaming UE.

The target UE’s privacy profile settings shall always be checked in the UE’s home PLMN prior to delivering a location estimate.

The "Visited GMLC" (VGMLC) is the GMLC, which is associated with the serving node of the target UE.

The "Home GMLC" (HGMLC) is the GMLC residing in the target UE’s home PLMN, which is responsible for the control of privacy checking of the target UE.

Additional functions which may be performed by a GMLC to support location services include the following.

– At an HGMLC, determine the serving AMF for a target UE when there is more than one serving AMF.

– At an HGMLC, determine whether to attempt a second location request for a target UE from a different AMF when location information returned by a first AMF does not meet QoS requirements and there is more than one serving AMF.

– At an HGMLC, support location requests from an external LCS client or NEF for a 5GC-MT-LR and deferred 5GC-MT-LR for periodic, triggered and UE available location events.

– At an HGMLC, support additional check of whether the UE is located within the requested target area for deferred 5GC-MT-LR for periodic, triggered and UE available location events.

– At an HGMLC, forward location requests for a roaming UE to a VGMLC or serving AMF in the VPLMN based on deployment configurations.

– At an HGMLC, receive event reports from a VGMLC or LMF for a deferred 5GC-MT-LR for periodic or triggered location and return to an external LCS Client or NEF.

– At an HGMLC, support cancelation of a periodic or triggered location.

– At an HGMLC, receive location information from an VGMLC for a 5GC-MO-LR and forwards to an LCS Client or an AF (via NEF) if requested by the UE.

– At a VGMLC, receive location requests from an HGMLC for a roaming UE and forward to a serving AMF.

– At a VGMLC, receive event reports from an LMF for a deferred 5GC-MT-LR for periodic or triggered location for a roaming UE and forward to an HGMLC.

– At a VGMLC, receive location information from an AMF for a 5GC-MO-LR and forwards to an HGMLC.

– At an HGMLC, reject the LCS request coming from a LCS client, e.g. when the number of Target UEs in the LCS request exceeds the Maximum Target UE Number of such client.

– At an HGMLC, allocate the reference number for each location request from an external LCS client for LDR.

– At an HGMLC, assign the pseudonym if pseudonym indicator is received in the service request and transfer it to external LCS client, e.g. when core network provides the UE’s location information to LCS client. Resolve the verinym from the pseudonym, if it is received from the LCS client.

– At an HGMLC, resolve group identifier to identifier of individual UEs and aggregate responses to LCS Client or NEF during bulk operation procedure.

– At an HGMLC, verify a request for user plane reporting by an LCS Client or AF for a periodic or triggered 5GC-MT-LR and verify or assign parameters to the request to enable the target UE to establish a secure user plane connection to the LCS Client or AF. Subsequently, support the transfer of cumulative event reports from the target UE via control plane back to the LCS Client or AF.

4.3.4 Location Retrieval Function, LRF

The Location Retrieval Function (LRF) may be collocated with a GMLC or separate and is responsible for retrieving or validating location information, providing routing and/or correlation information for a UE which has initiated an IMS emergency session. The information is provided by an LRF to an E-CSCF. For more details, refer to TS 23.167 [10].

4.3.5 UE

A target UE may support positioning according to four different modes:

– UE assisted mode (the UE obtains location measurements and sends the measurements to another entity (e.g. an LMF) to compute a location);

– UE based mode (the UE obtains location measurements and computes a location estimate making use of assistance data provided by serving PLMN);

– standalone mode (the UE obtains location measurements and computes a location estimate without making use of assistance data provided by serving PLMN);

– network based mode (a serving PLMN obtains location measurements of signals transmitted by a target UE and computes a location estimate).

NOTE: The transmission of UE signals for network based mode may or may not be transparent to the UE.

Positioning procedures used by a UE for NG-RAN access are described in TS 38.305 [9].

A limited set of UE positioning capabilities can be transferred to the 5GCN during registration of the UE as described in TS 24.501 [11]. Some of these positioning capabilities may be transferred subsequently to an LMF as described in TS 29.572 [12]. UE positioning capabilities may also be transferred directly to a location server (e.g. LMF).

Additional functions which may be supported by a UE to support location services include the following.

– Support location requests received from a network for 5GC-MT-LR, 5GC-NI-LR or a deferred 5GC-MT-LR for periodic or triggered location.

– Support location requests to a network for a 5GC-MO-LR.

– Support privacy notification and verification for a 5GC-MT-LR or deferred 5GC-MT-LR for periodic or triggered location.

– Send updated privacy requirements to a serving AMF (for transfer to a UDR via UDM).

– Support periodic or triggered location reporting to an LMF.

– Support change of a serving LMF for periodic or triggered location reporting.

– Support cancelation of periodic or triggered location reporting.

– Support multiple simultaneous location sessions.

– Support the reception of unciphered and/or ciphered assistance data broadcast by NG-RAN.

– Support the reception of ciphering keys for the assistance data from the AMF.

– Support handling of 5GC-MT-LR, 5GC-NI-LR, 5GC-MO-LR and deferred 5GC-MT-LR for periodic or triggered location over a user plane connection between UE and LMF.

– Support reporting of location events for a periodic or triggered 5GC-MT-LR over a user plane connection to an LCS Client or AF with periodic cumulative event reports being sent over control plane to the LMF, H-GMLC and LCS Client or AF.

4.3.6 UDM

The UDM contains LCS subscriber LCS privacy profile and routing information. The UDM is accessible from an AMF, GMLC or NEF via the Nudm interface.

4.3.7 Access and Mobility Management Function, AMF

The AMF contains functionality responsible for managing positioning for a target UE for all types of location request. The AMF is accessible to the GMLC and NEF via the Namf interface, to the RAN via the N2 reference point and to the UE via the N1 reference point.

Functions which may be performed by an AMF to support location services include the following.

– Initiate an NI-LR location request for a UE with an IMS emergency call or to know a UE geographical area with NR satellite access for PLMN selection verification.

– Receive and manage location requests from a GMLC for a 5GC-MT-LR and deferred 5GC-MT-LR for periodic, triggered and UE available location events.

– Receive and manage location requests from a UE for a 5GC-MO-LR.

– Receive and manage Event Exposure request for location information from an NEF.

– Select an LMF.

– Receive updated privacy requirements from a UE and transfer to a UDR via UDM.

– Support cancelation of periodic or triggered location reporting for a target UE.

– Support change of a serving LMF for periodic or triggered location reporting for a target UE.

– When assistance data is broadcast by 5GS in ciphered form, the AMF receives ciphering keys from the LMF and forwards to suitably subscribed UEs using mobility management procedures.

– Store UE Positioning Capability received from an LMF and send the UE Positioning Capability along with the received location request to an LMF.

NOTE: Details of UE Positioning Capability is defined in TS 37.355 [20].

4.3.8 Location Management Function, LMF

The LMF manages the overall co-ordination and scheduling of resources required for the location of a UE that is registered with or accessing 5GCN. It also calculates or verifies a final location and any velocity estimate and may estimate the achieved accuracy. The LMF receives location requests for a target UE from the serving AMF using the Nlmf interface. The LMF interacts with the UE in order to exchange location information applicable to UE assisted and UE based position methods and interacts with the NG-RAN, N3IWF or TNAN in order to obtain location information.

The LMF shall determine the result of the positioning in geographical co-ordinates as defined in TS 23.032 [8] and/or in local co-ordinates as defined in TS 23.032 [8]. If requested and if available, the positioning result may also include the velocity of the UE. The coordinate type(s) is determined by LMF when receiving a location request, based on LCS Client type and supported GAD shapes. If the location request indicates regulatory LCS Client type the LMF shall determine a geographical location and optionally a location in local coordinates. For location request indicates a value added LCS Client type, the LMF may determine the UE location in local coordinates or geographical co-ordinates or both. If the supported GAD shapes is not received or Local Co-ordinates is not included in the supported GAD shapes, the LMF shall determine a geographical location.

NOTE 1: Some RAT independent position methods (e.g. GNSS based position methods) can only determine a UE location in geographical co-ordinates. In such a case, the LMF may translate a UE location in geographical co-ordinates into a location in local co-ordinates when an origin for the local co-ordinates has known global coordinates. When an origin for the local co-ordinates does not have known global coordinates, position methods that can only determine a UE location in geographical co-ordinates cannot be used to determine a UE location in local co-ordinates.

Additional functions which may be performed by an LMF to support location services include the following.

– Support a request for a single location received from a serving AMF for a target UE.

– Support a request for periodic or triggered location received from a serving AMF for a target UE.

– Determine type and number of position methods and procedures based on UE and PLMN capabilities, QoS, UE connectivity state per access type, LCS Client type, co-ordinate type and optionally service type and indication of requiring reliable UE location information.

– Report UE location estimates directly to a GMLC for periodic or triggered location of a target UE.

– Support cancelation of periodic or triggered location for a target UE.

– Support the provision of broadcast assistance data to UEs via NG-RAN in ciphered or unciphered form and forward any ciphering keys to subscribed UEs via the AMF.

– Support change of a serving LMF for periodic or triggered location reporting for a target UE.

– Support of receiving stored UE Positioning Capability from AMF and support of providing updated UE Positioning Capability to AMF.

– Map the UE location to a geographical area where the PLMN is or is not allowed to operate based on the request from AMF.

– Support determination of a UE location at a scheduled location time.

– Determine whether to use user plane or control plane for positioning.

– Support handling of 5GC-MT-LR, 5GC-NI-LR, 5GC-MO-LR and deferred 5GC-MT-LR for periodic or triggered location over a user plane connection between UE and LMF.

Editor’s note: LMF functionality of user plan connection handling will be updated according to the protocol stack decision made by CT WG1 and SA WG3 groups.

– Support collection of GNSS assistance data from AFs.

NOTE 2: Country, area within a country, or an international area can be supported as different types of geographical area.

– Support a request for user plane reporting from a UE to an LCS Client or AF for a periodic or triggered 5GC-MT-LR. Subsequently, support the transfer of cumulative event reports from the target UE via control plane back to the H-GMLC and LCS Client or AF. Also support any request for assistance data received in a cumulative event report.

4.3.9 Network Exposure Function, NEF

An NEF provides a means of accessing location services by an external AF or internal AF. AFs access location services from an NEF using an API. Depending on QoS requirements, an NEF can forward a location request to a GMLC or request an event exposure for location information from serving AMF (optionally via a UDM). When event exposure via AMF is used, an NEF may request routing information and/or target UE privacy information from the UDM via the Nudm interface.

Additional functions which may be performed by an NEF to support location services include the following.

– Support location requests from an AF for immediate location and for deferred periodic and triggered location events.

– Support location information exposure to an AF based on the location request.

– Support determination of GMLC or AMF based on e.g. the QoS requirements from AF, type of the location request.

NOTE: If the GMLC or AMF are determined based on the QoS requirements and the QoS requirements include Multiple QoS class, the determination of GMLC or AMF is done based on the most stringent (i.e. primary) QoS requirements.

– Select the serving AMF for a target UE when there is more than one serving AMF.

– Determine whether to attempt a second location request for a target UE from a different AMF when location information returned by a first AMF does not meet QoS requirements and there is more than one serving AMF.

– Support UE LCS privacy profile provision from the AF.

– Support suspending and cancellation of a periodic or triggered location request.

– Support authorization of LCS request from the AF.

– Support rejecting the LCS request coming from an AF, e.g. when the number of Target UEs in the LCS request exceeds the Maximum Target UE Number of such client.

– Support allocating the reference number for each location request from an AF for LDR.

4.3.10 Unified Data Repository, UDR

The UDR contains privacy data information for target UEs and may be updated by a serving AMF via UDM with new privacy information received from a UE.

4.4 Reference Point to Support Location Services

4.4.1 Le Reference Point

The Le reference point supports location requests sent by an LCS Client to a GMLC or LRF.

The Le reference point may be supported using the Mobile Location Protocol (MLP) defined by OMA [13].

4.4.2 NL3 Reference Point

The NL3 reference point supports location requests forwarded by an HGMLC to a VGMLC.

4.4.3 N1 Reference Point

The N1 reference point supports transfer of supplementary services messages between a serving AMF and target UE to support privacy notification and verification and change of UE privacy preference. The N1 reference point also supports transfer of positioning protocol messages and location event reports between a target UE and an LMF via a serving AMF. The N1 reference point supports the transfer of ciphering keys from an AMF to a suitably subscribed UE to enable the UE to receive ciphered broadcast assistance data. All messages sent over the N1 reference point for support of location services are encapsulated in NAS Transport messages as defined in TS 24.501 [11].

4.4.4 N2 Reference Point

The N2 reference point supports transfer of positioning messages, via an AMF, between an LMF and a RAN node, or N3IWF in the case of untrusted non-3GPP access. The N2 reference point also supports transfer of messages, via an AMF, from an LMF to an NG-RAN node, which carry assistance data to be broadcast by the NG-RAN node. Positioning messages relevant to the N2 interface are defined in TS 38.455 [15].

4.4.5 Void

4.4.6 NL5 Reference Point

The NL5 reference point supports location requests sent by an NEF or other NF to a GMLC.

4.4.7 NL2 Reference Point

The NL2 reference point supports location requests sent by a GMLC to a serving AMF for a target UE.

Messages for the NL2 reference point are defined in TS 29.518 [16].

4.4.8 NL6 Reference Point

The NL6 reference point supports queries from an HGMLC to a UDM for privacy subscription information for a target UE and routing information for a target UE.

4.4.9 N51 Reference Point

The N51 reference point supports queries from an NEF to a serving AMF for the location of a target UE.

Messages for the N51 reference point are defined in TS 29.518 [16].

4.4.10 NL1 Reference Point

The NL1 reference point supports location requests for a target UE sent from a serving AMF for the target UE to an LMF. Location requests are supported for immediate location and for deferred location for periodic or triggered location events.

The NL1 reference point also supports the transfer from an LMF to an AMF of ciphering keys and associated data that enable deciphering by suitably subscribed UEs of ciphered broadcast assistance data.

Messages for the NLI reference point are defined in in TS 29.518 [16] and TS 29.572 [12].

4.4.11 N52 Reference Point

The N52 reference point supports queries from an NEF to a UDM for privacy subscription information for a target UE and routing information for a target UE. The N52 interface also supports a request from an NEF to a UDM to forward a location request from the NEF to a serving AMF for the target UE.

4.4.12 NL7 Reference Point

The NL7 reference point supports location context transfer between two LMFs.

4.5 Service Based Interfaces to Support Location Services

The 5GS LCS architecture contains the following service-based interfaces for Location Services:

Nlmf: Service-based interface exhibited by LMF.

Ngmlc: Service-based interface exhibited by GMLC.