5 Local LMF in NG-RAN

38.8563GPPRelease 16Study on local NR positioning in NR Radio Access Network (RAN)TS

5.1 Architecture

5.1.1 Alternative 1

In architecture alternative 1, the LMC is an internal function of the NG-RAN node. In case of split gNB, the LMC is located in the gNB-CU-CP.

The interface between the LMC and the serving NG-RAN node is internal, and therefore minimizes the latency between the LMC and serving NG-RAN node. Functions of the NLs interface could be specified also for the NG-C interface.

Characteristics:

– No new interfaces.

– When UE positioning involves only TRPs within the NG-RAN node, positioning-related signalling is internal to the gNB.

– To support location continuity in case of handover, LMC relocation to the target NG-RAN node can be enabled via enhancements to the XnAP Handover Preparation procedure. Further study is needed.

Figure 5.1.1-1: Alternative 1 – LMC as internal gNB function

5.1.2 Alternative 2

In architecture alternative #2, the LMC is a logical node within the split gNB connected to the gNB-CU-CP via a new interface.

This alternative requires a dedicated interface between the LMC and the serving NG-RAN node. The impacts to the NG-C interface are the same as alternative 1.

Characteristics:

– New interface between the LMC and the gNB-CU-CP.

– Allows LMC and gNB-CU-CP to be provided by different vendors.

– Allows offloading of positioning support from a gNB-CU.

– To support location continuity in case of handover, further study is needed.

Figure 5.1.2-1: Alternative 2 – LMC as logical node within split gNB

5.1.3 Alternative 3

In architecture alternative #3, the LMC is a new logical node in the NG-RAN, connected to NG-RAN nodes (gNBs and/or ng-eNBs) via a new interface.

This alternative requires a dedicated interface between the LMC and the serving NG-RAN node. The impacts to the NG-C interface are the same as alternative 1 and could be supported also by the new interface.

Characteristics:

– New interface between the LMC and the NG-RAN node.

– Allows LMC and NG-RAN nodes to be provided by different vendors.

– Allows a single LMC to support multiple NG-RAN nodes (i.e. avoid introducing LMC in each individual NG-RAN node).

– Allows offloading of positioning support from a gNB-CU.

– To support location continuity in case of handover when both source and target NG-RAN nodes are served by the same LMC, LMC relocation is not needed. However, when source and target NG-RAN nodes are served by different LMCs, support for location continuity requires further study.

Figure 5.1.3-1: Alternative 3 – LMC as logical node in NG-RAN

5.1.4 Function supported by LMC

The LMC can support all the location request types defined for the LMF in clause 4.1a of TS 23.273 [3].

In order to manage the various location services for target UEs, the LMC can be expected to have capabilities similar to an LMF.

In addition, the LMC can be expected to:

– interact with other internal functions of the serving NG-RAN node (e.g. TMF) in order to e.g. obtain position measurements for the UE;

– interact with neighboring NG-RAN nodes in order to e.g. obtain position measurements for the UE.

The LMC support of possible new functions, not supported by the LMF, are described in Annex A.

5.2 Impact on existing protocols and interfaces

5.2.1 Location Service procedures involving LMC

5.2.1.1 5GC Mobile Terminated Location Request (5GC-MT-LR)

NOTE 1: Flows are intended to show common operation for all architectures with LMC. Specific architectures may require further details

Figure 5.2.1.1-1 illustrates the steps applicable to the UE and NG-RAN node in case of 5GC-MT-LR involving LMC. In this scenario, the UE is assumed to be in connected mode prior to step 1.

Figure 5.2.1.1-1: 5GC-MT-LR involving LMC

The steps of Figure 5.2.1.1-1 are as follows:

1. Some LCS entity in the 5GC (e.g. GMLC) requests some location service (e.g. positioning) for a target UE to the serving AMF (see step 4 of Figure 6.1.1-1 in TS 23.273 [3]).

2. The AMF selects the serving NG-RAN node (LMC) to perform the positioning, based on e.g. knowledge of the NG-RAN node’s location management capabilities, Requested Quality of Service information, etc.

Note 2: The details of whether to select LMC are SA2 scope, including whether it is part of the LMF Selection function or a new function of the AMF.

3. The AMF sends a location service request to the NG-RAN node (LMC) via NGAP, instructing it to perform the UE positioning.

4. Same as steps 4a/4b of the RI-LR procedure in Annex A.

5. The NG-RAN node (LMC) provides a location service response to the AMF via NGAP and includes any needed results – e.g. success or failure indication and, if requested and obtained, a location estimate for the UE.

6. The AMF returns a location service response to the 5GC entity of step 1 and includes any needed results – e.g. a location estimate for the UE (see step 10 of Figure 6.1.1-1 in TS.23.273 [3]).

5.2.2 Impacts on Signalling protocols and interfaces

5.2.2.1 Signalling between an AMF and gNB/LMC

The NL1 interface between AMF and LMF supports location requests for a target UE sent from a serving AMF for the target UE to an LMF as specified in TS 29.572 [5] (Nlmf_Location_DetermineLocation Request/Response). The Request operation can include the following parameter (at least one of these parameters should be present):

– externalClientType, correlationID, amfId, locationQoS, supportedGADShapes, supi, pei, gpsi, ecgi, ncgi, priority, velocityRequested;

and the Response operation may include (where the parameter locationEstimate should be present):

– locationEstimate, accuracyFulfilmentIndicator, ageOfLocationEstimate, velocityEstimate, civicAddress, positioningDataList, gnssPositioningDataList, ecgi, ncgi, altitude, barometricPressure.

An Nlmf_Location_DetermineLocation Request/Response message could be transported between the serving gNB and serving AMF for a target UE in an NGAP transport container, which could be defined as a new NGAP UL/DL transport message.

This has several advantages, including the following:

– An AMF can use the same message/operation towards an LMF and LMC.

– Better functional alignment between an LMC and LMF.

Figure 5.2.2.1-1 below shows an example procedure for a basic MT-LR. Steps 5 are the procedures which would be performed if the AMF at Step 4 selects an LMF; steps 6 would be performed if the AMF at step 4 selects a LMC. From an AMF point of view, the same message would be used in both cases; only the transport (container) would be different. Similarly, an LMC would see the same "input/output" data as an LMF.

NOTE 1: Whether to reuse AMF/LMF service operations in an NGAP message container or extend/introduce NGAP message with explicit IEs could be decided in a potential work item phase by RAN3.

Figure 5.2.2.1-1: Example of MT-LR Location Service Support using 5GC LMF (Steps 5) and using a NG-RAN LMC (steps 6).

NOTE 2: Triggered/periodic MT-LR with LMF/LMC in NG-RAN requires further study by SA2.

5.2.2.2 Signalling between a gNB/LMC and UE

The LPP protocol TS 36.355 [6] is used for the positioning procedures between an LMF and target UE, as specified in TS 38.305 [4]. For an LMF, LPP messages are carried as transparent PDUs across intermediate network interfaces using the appropriate protocols (e.g. NAS/NGAP over the NG-C interface, NAS/RRC over the Uu interface).

LPP can be reused for the positioning signalling between an LMC and target UE and transported in an RRC message container. The DL and UL Information Transfer messages (TS 38.331 [7]) may be extended to support a non-NAS message container, or a new UL/DL RRC Transfer container message can be defined. The reuse of LPP has the lowest overall impact, which also makes UE positioning procedures agnostic to where the LMF is located (i.e., 5GCN LMF or NG-RAN LMC) (similar to the reuse of NL1 messages (clause 5.2.2.1)). The Step 6b in Figure 5.2.2.1-1 can then be extended as shown in Figure 5.2.2.2-1.

NOTE 1: Whether to reuse LPP in an RRC message container or extend/introduce RRC message with explicit IEs should be decided in the work item phase by RAN2.

Figure 5.2.2.2-1: LPP signalling between LMC and UE.

For Location Services operation, the Supplementary Services (SS) Protocol (TS 24.080 [10]) is also used for 5GC Location Services, as specified in TS 23.273 [3]. The MT-LR and MO-LR Services messages are exchanged between an AMF and a UE and can also be used in the same way as currently defined for 5GC LMF location services (see subclause 5.2.1). The Supplementary Services messages for support of periodic and triggered location services are exchanged between a 5GC LMF and UE (TS 23.273 [3]. For an NG-RAN LMC these messages can be transported in the same RRC container message as for the LPP messages and is shown in Figure 5.2.2.2-2.

NOTE 2: Whether to reuse SS Protocol in an RRC message container or extend/introduce RRC message with explicit IEs should be decided in the work item phase by RAN2.

Figure 5.2.2.2-2: Supplementary Services (SS) signalling between LMC and UE.

5.2.2.3 Signalling between gNBs/LMCs

Location procedures between pairs of gNBs/LMCs are required to support one or more of the following functions:

a) Request UL measurements for a target UE by one gNB (e.g. a serving gNB with an LMC) from another gNB (TRP).

b) Provide assistance data for a target UE by one gNB (e.g. a serving gNB with an LMC) to another gNB to assist UL measurements of the target UE by the other gNB/TRP.

c) Request a change in DL PRS broadcast scheduling and configuration by one gNB to a neighbour gNB.

d) Request a change in scheduling and resources for broadcast of location information by one gNB to a neighbour gNB.

Items a) to d) are the same functionality as required between a 5GC LMF and an NG-RAN Node which can be supported using NRPPa.

5.2.2.4 Signalling between gNB-CU and LMC

This subclause is applicable only to architecture alternatives #2 and #3.

A new interface is needed between gNB-CU and LMC to support the following functions:

– Interface management function(s) to allow for initial setup of the interface, exchange/update of application level data, etc.

– Error handling function to allow the reporting of general error situations on application level.

– Message transfer function(s) to allow transfer of location-related messages.

– Other functions, if needed, to be decided by RAN3 in the work item phase.

The location procedures between a gNB-CU and LMC comprise all location related procedures on NG, Xn, and NR-Uu interfaces:

– location procedures between AMF and gNB/LMC (using Nlmf_Location_DetermineLocation), as described in subclause 5.2.2.1;

– location procedures between gNB/LMC and UE (using LPP and SS), as described in subclause 5.2.2.2;

– location procedures between gNBs/LMCs (using NRPPa), as described in subclause 5.2.2.3.

Essentially, a gNB-CU would forward any location related messages received on NG, Xn and Uu interfaces to the LMC.

5.3 Coordination and coexistence with LMF in the 5GC

In the Rel-15 LCS architecture, the AMF initiates (in case of NI-LR) or receives (in case of MO-LR and MT-LR) a location request, and then selects an LMF to perform the location estimation of the target UE. For LMF selection, the AMF may consider various factors as described in TS 23.273 including Requested Quality of Service information (e.g. LCS accuracy, latency), LMF capabilities, LMF load, LMF location and AMF local configuration. For a given target UE, only one LMF is "in use" to manage the overall coordination and scheduling of resources required for the location of the UE. The AMF also supports LMF re-selection e.g. when the LMF currently "in use" cannot be used for a newly initiated/received location request.

In order to integrate the LMC into the LCS architecture, the AMF should be aware that the NG-RAN node supports LMC and may also need to be aware of some of its capabilities.

NOTE: Whether this is explicitly signaled by the NG-RAN node to the AMF or configured to the AMF via OAM should be decided in the work item phase.

TS 22.261 [8] defines positioning service levels with corresponding performance requirements. The two positioning service levels requiring the most stringent QoS from a latency perspective are levels 4 and 6 which are only applicable to a 5G enhanced positioning service area, i.e. positioning service levels available in only a subset of the area where 5G is present. TS 22.104 [9] provides typical scenarios which require positioning service levels 4 and 6. It is a working assumption that the AMF should be able to select the LMC for only certain location requests (e.g. those requiring stringent QoS such as low latency and/or high accuracy corresponding to positioning service levels 4 and 6) while selecting an LMF for all other location requests (e.g. those requiring normal QoS).

In case there are concurrent location requests for the same target UE where at least one requires stringent QoS, there are two possible solutions:

Solution 1: The concurrent location requests are all handled by a single entity, i.e. the LMC.

Description: This solution is consistent with the Rel-16 LMF selection functionality as described in clause 5.1 of TS 23.273 where concurrent location requests are preferably handled by the same location management entity, i.e. in Rel-16 a new LCS Request is transferred to the LMF handling an ongoing location session if an LMF ID is available in the UE location context stored in the AMF. In the case of LMC, the UE location context indicates that there is an LMC handling an ongoing location session, and therefore concurrent location requests are transferred by the AMF to the LMC.

Potential benefit(s): Alignment with Rel-16 LMF selection principles, enabling the LMC to handle concurrent location requests in a coordinated and efficient way.

Potential drawback(s): The LMC may end up handling non-latency-sensitive location requests. In some deployments, it may be desirable to use the LMC only for location requests that require stringent QoS (e.g. low latency and/or high accuracy), while less demanding location requests continue to be served by LMF in the core network. This could be due to the more limited resources (e.g. processing power) at the NG-RAN node. Also, if there is an ongoing location session being handled by an LMF when a concurrent location request (requiring stringent QoS) is triggered for the same target UE, one of the location requests should fail unless a complex mechanism is introduced to move the ongoing location session from LMF to LMC.

Solution 2: The concurrent location request(s) requiring stringent QoS is handled by the LMC, while the other location request(s) is handled in parallel by an LMF.

Description: This solution allows different location requests for the same target UE to be handled concurrently by up to two location management entities: the LMC and an LMF. The AMF provides information about the location request(s) being handled by the LMC to the LMF which is "enhanced" (compared to legacy LMF functionality) to take the information into account when handling concurrent location requests for the same target UE. For example:

a) The LMF may "fetch" the latest available UE location information from the LMC, if the ongoing location session has appropriate attributes in terms of e.g. accuracy, expected age, etc.; or

b) The LMF may handle the concurrent location request in an independent way that does not conflict with the LMC. This may make sense if the concurrent location request does not require high accuracy, and thus the LMF is able to handle the request using E-CID that does not conflict with radio configurations being used by the LMC.

Potential benefit(s): Enables a deployment to use the LMC only for location requests that require stringent QoS, while less demanding location requests continue to be served by LMFs in the core network.

Potential drawbacks(s): Requires some new functionality in the LMF.

Comparing the two solutions, Solution 1 has little to no specification impact and could be acceptable in certain deployment scenarios (e.g. certain private networks and/or certain device types). However, Solution 2 seems to provide more flexibility for diversity of deployments and device types.