5 Services Offered by the LMF

29.5723GPP5G SystemLocation Management ServicesRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Introduction

The LMF offers to other NFs the following services:

– Nlmf_Location

– Nlmf_Broadcast

Table 5.1-1 summarizes the corresponding APIs defined for this specification.

Table 5.1-1: API Descriptions

Service Name	Clause	Description	OpenAPI Specification File	apiName	Annex
Nlmf_Location	6.1	LMF Location Service	TS29572_Nlmf_Location.yaml	nlmf-loc	A.2
Nlmf_Broadcast	6.2	LMF Broadcast Service	TS29572_Nlmf_Broadcast.yaml	nlmf-broadcast	A.3

5.2 Nlmf_Location Service

5.2.1 Service Description

The Nlmf_Location service enables an NF to request location determination (current geodetic and optionally local and/or civic location) for a target UE or to request periodic or triggered location for a target UE.

5.2.2 Service Operations

5.2.2.1 Introduction

The service operations defined for the Nlmf_Location service are as follows:

– DetermineLocation: It provides UE location information to the consumer NF.

– EventNotify: It notifies the consumer NF of an event for periodic or triggered location for a target UE.

– CancelLocation: It enables a consumer NF to cancel an ongoing periodic or triggered location for a target UE.

– LocationContextTransfer: It enables a consumer NF to transfer location context information for periodic or triggered location of a target UE to a new LMF.

5.2.2.2 DetermineLocation

5.2.2.2.1 General

The following procedures are defined, using the "DetermineLocation" service operation:

– Retrieve UE Location

– Retrieve UE Location for 5G-MO-LR

5.2.2.2.2 Retrieve UE Location

This procedure allows a consumer NF to request the location information (geodetic location and, optionally, local and/or civic location) for a target UE or to activate periodic or triggered deferred location for a target UE.

Figure 5.2.2.2.2-1: DetermineLocation Request

1. The NF Service Consumer shall send an HTTP POST request to the resource URI associated with the "determine-location" custom operation. The input parameters for the request (external client type, LCS correlation identifier, serving cell identifier, location QoS, supported GAD shapes, LDR Type, H-GMLC address, LDR Reference, UE connectivity state per access type, TNAP identifier, TWAP identifier, scheduled location time, ….) may be included in the HTTP POST request body;

If UE geographical area identified by the country, area within a country or international area needs to be determined, the NF Service Consumer shall include UE geographical area determination for PLMN selection verification indication in the request;

If UE LCS Capability is received in the request indicating LPP is not supported by the UE, the LMF shall not send LPP messages to the UE in subsequent positioning procedures.

2a. On success, "200 OK" shall be returned. The response body shall contain the parameters related to the determined position of the UE if any (geodetic position, local location, civic location, positioning methods…);

If the NF service consumer has requested to determine UE country, area within a country or international area, the LMF shall also include ueAreaInd.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.4.2.2-2 shall be returned. For a 4xx/5xx response, the message body should contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.4.2.2-2.

5.2.2.2.3 Retrieve UE Location for 5G-MO-LR

This procedure allows a consumer NF (i.e. an AMF) to request the location information or location assistance data for a target UE which initiates MO-LR procedure (see 3GPP TS 23.273 [19]).

Figure 5.2.2.2.3-1: DetermineLocation Request for 5G-MO-LR

The same requirements in clause 5.2.2.2.2 shall be applied with following modifications:

1. Same as step 1 of figure 5.2.2.2.2-1, the request body shall include the following additional information:

– The indication received from UE indicating whether a location estimate or location assistance data is required.

– The LPP messages if received in MO-LR Request from UE

– UE’s subscribed assistance data for 5GC-MO-LR if received from UDM.

2a. Same as step 2a of figure 5.2.2.2.2-1 if a consumer NF requests the location information for a target UE. If a NF consumer requests location assistance data for a target UE and LMF has successfully delivered location assistance data to the UE, 204 No Content shall be returned.

2b. Same as step 2b of figure 5.2.2.2.2-1.

5.2.2.3 EventNotify

5.2.2.3.1 General

The following procedures are defined, using the "EventNotify" service operation:

– Periodic or Triggered Event Notification

5.2.2.3.2 Periodic or Triggered Event Notification

This procedure notifies the NF Service Consumer (i.e. GMLC) about event information related to periodic or triggered location of a target UE. The notification is delivered to:

– the callback URI of an H-GMLC received (from an AMF) during an earlier DetermineLocation service operation if still available and if the LMF is configured for direct access to the H-GMLC;

– the callback URI of an H-GMLC received (from another LMF) during an earlier LocationContextTransfer service operation if still available and if the LMF is configured for direct access to the H-GMLC;

– the callback URI of an H-GMLC received (from the target UE) in a supplementary services event report if the LMF is configured for direct access to the H-GMLC;

otherwise (if not available),

– the callback URI of a V-GMLC registered in the NRF, if the V-GMLC registered to the NRF with notification endpoints for periodic or triggered event notifications; or

otherwise (if not available),

– the URI of a V-GMLC locally provisioned in the LMF.

Figure 5.2.2.3.2-1: EventNotify Request

1. The LMF shall send a POST request to the GMLC callback URI determined as described above. The request body shall include a notification correlation ID (LDR reference), the UE identification (SUPI and if available GPSI), the type of event and may include a geodetic location, local location, civic location, position methods used, and other available parameters related to the position if any (e.g. Velocity, Altitude etc.), H-GMLC callback URI (if the NF consumer is a V-GMLC) and serving LMF identification.

2a. On success, "204 No content" shall be returned by the NF Service Consumer.

2b. On failure or redirection, one of the appropriate HTTP status code listed in Table 6.1.5.1.3.1-2 shall be returned. For a 4xx/5xx response, the message body should contain a ProblemDetails structure indicating appropriate additional error information.

5.2.2.4 CancelLocation

5.2.2.4.1 General

The following procedures are defined, using the "CancelLocation" service operation:

– Cancel Periodic or Triggered Location

5.2.2.4.2 Cancel Periodic or Triggered Location

This procedure allows a consumer NF to cancel periodic or triggered location for a target UE. The cancellation is delivered to a resource URI on the serving LMF identified by the serving LMF identification provided to the consumer NF (i.e. AMF) by a V-GMLC or H-GMLC (see 3GPP TS 23.273 [19]).

Figure 5.2.2.4.2-1: CancelLocation Request

1. The NF Service Consumer shall send an HTTP POST request to the resource URI of "cancel-location" custom operation on the serving LMF. The request body shall include a notification correlation ID (LDR reference) and an H-GMLC callback URI.

2a. On success, "204 No content" shall be returned by the LMF.

2b. On failure or redirection, one of the HTTP status code listed in Table 6.1.4.3.2-2 shall be returned. For a 4xx/5xx response, the message body should contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.1.4.3.2-2.

5.2.2.5 LocationContextTransfer

5.2.2.5.1 General

The following procedures are defined, using the "LocationContextTransfer" service operation:

– Transfer Location Context

5.2.2.5.2 Transfer Location Context

This procedure allows a NF service consumer (e.g. the old LMF) to transfer location context information for periodic or triggered location for a target UE (see clause 6.4 and clause 6.7.2 of 3GPP TS 23.273 [19]). The NF service consumer discovers the service URI of the new LMF by performing a discovery via NRF using:

– the identification of the LMF received (from an AMF) during an earlier Namf_Communication_N1MessageNotify service operation to the consumer NF;

otherwise (if not available),

– the identification of an LMF locally provisioned in the consumer NF.

Figure 5.2.2.5.2-1: LocationContextTransfer Request

1. The NF Service Consumer shall send an HTTP POST request to the Custom operation URI ("/location-context-transfer") on the Service URI discovered as described above. The request body shall include an AMF identity, Deferred location type, Deferred location parameters, Notification Target Address (H-GMLC callback URI), Notification Correlation ID (LDR reference), an embedded event report message and may include an event reporting status, UE location information and scheduled location time, and shall include an indication of Control Plane CIoT 5GS Optimisation if N1 message is received from the UE with Control Plane CIoT 5GS Optimisation.

2a. On success, "204 No content" shall be returned by the LMF.

2b. On failure or redirection, one of the HTTP status codes listed in Table 6.1.4.4.2-2 shall be returned. For a 4xx/5xx response, the message body should contain a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table 6.1.4.4.2-2.

5.3 Nlmf_Broadcast Service

5.3.1 Service Description

The Nlmf_Broadcast service enables an NF to obtain ciphering keys and associated parameters applicable to location assistance data that is broadcast to subscribed UEs in ciphered form.

5.3.2 Service Operations

5.3.2.1 Introduction

The service operations defined for the Nlmf_Broadcast service are as follows:

– CipheringKeyData: It provides the ciphering key information to the consumer NF.

5.3.2.2 CipheringKeyData

5.3.2.2.1 General

The following procedures are defined, using the "CipheringKeyData" service operation:

– Request Ciphering Key Information

– Provide Ciphering Key Information

NOTE: The Request Ciphering Key procedure is included in order to provide a valid context in OpenAPI version 3 for the Provide Ciphering Key Information procedure. The Request Ciphering Key procedure is not used for support of ciphering key transfer in 3GPP TS 23.273 [19] and hence need not be supported by an NF Service Consumer or by an LMF.

5.3.2.2.2 Request Ciphering Key Information

This procedure allows a consumer NF to request ciphering key information.

Figure 5.3.2.2.2-1: CipheringKeyData Request

1. The NF Service Consumer shall send an HTTP POST request to the resource URI associated with the "cipher-key-data" custom operation. The request body shall include a notification callback URI.

2a. On success, "200 OK" shall be returned. The response body shall indicate whether the LMF has ciphering key data. If the LMF has ciphering key data, the Provide Ciphering Key Information procedure is used to provide the ciphering key data to the NF Service Consumer.

2b. On failure or redirection, one of the HTTP status codes listed in Table 6.2.4.4.2-2 shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in Table 6.2.7.3-1.

5.3.2.2.3 Provide Ciphering Key Information

This procedure notifies the NF Service Consumer (i.e. AMF) about updated ciphering key information applicable to broadcast of location assistance data in ciphered form to subscribed UEs. The notification is delivered to:

– the callback URI of an AMF received during an earlier CipheringKeyData request service operation if still available; or

– a callback URI registered in the NRF, if the AMF registered to the NRF with notification endpoints for ciphering key data notifications;

Otherwise (if not available),

– an AMF callback URI locally provisioned in the LMF.

The procedure is invoked by issuing a POST request to the callback URI of the NF Service Consumer. See figure 5.3.2.2.3-1.

Figure 5.3.2.2.3-1: CipheringKeyData Notify

1. The LMF shall send an HTTP POST request to the callback URI for the NF service consumer determined as described above. The request body shall include one or more ciphering keys and for each ciphering key may include a ciphering key value, ciphering key identifier, validity period and set of applicable types of broadcast assistance data.

2a. On success or partial success, "200 OK" shall be returned. The response body shall indicate which ciphering key information was successfully stored by the NF service consumer.

2b. On failure or redirection to store any ciphering key information, one of the HTTP status codes listed in table 6.2.5.1.3.1-2 shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the "cause" attribute set to one of the application errors listed in table 6.2.5.1.3.1-2.