Troubleshoot MT-LR Call Flow in AMF and Common Integration Issues with 3RD Party LMF, GMLC

Introduction

This document describes the AMF Mobile-Terminated Location Request (MT-LR) functionality, integration, and troubleshooting for network engineers.

Prerequisites

Requirements

Cisco recommends that you have knowledge of the functionality of Access and Mobility Management Function (AMF)

Components Used

The information in this document is in relation with Cisco AMF which is the AMF in 5G Core Network.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Background Information

Location services are fundamental in modern mobile networks, not just for user experience but also for critical regulatory requirements like emergency calls and lawful intercepts. In the 5G core, the AMF plays a pivotal role in handling these location requests.

What is Mobile-Terminated Location Request (MT-LR)?

The AMF supports various types of location requests, including Network Induced Location Request (NI-LR) and MT-LR.

MT-LR is initiated when an external entity, typically the Gateway Mobile Location Center (GMLC), requests the location of a User Equipment (UE). The GMLC forwards this request to the AMF, which then coordinates with the Location Management Function (LMF) to determine the  precise location of the user equipment. Once identified, the location information is sent back to the GMLC.

The AMF can provide either the 'current location' or the 'current or last known location' for MT-LRs, offering flexibility based on the urgency and the activity state of the user equipment.

Key Integration Touchpoints for MT-LR

For the MT-LR process, the AMF primarily communicates with:

• GMLC: Initiates the location request.
• LMF: Determines the user-equipment location.
• gNB: The 5G Base Station, involved in user equipment positioning.

MT-LR Call Flow and Integration Challenges

The MT-LR process involves three major exchanges between the AMF, GMLC, and LMF:

1. Positioning Information Request Exchange (GMLC to AMF)
2. Determine Location Request (AMF to LMF)
3. User Equipment Positioning (LMF via AMF to gNB/UE and back)

Explanation of the these three stages and common integration challenges are explained here.

1. Positioning Information Request: GMLC to AMF

The MT-LR process begins when the GMLC sends a ProvidePosInfoRequest to the AMF. This request is crucial as it kicks off the entire location determination sequence. The AMF then coordinates with other network functions, like the LMF, to retrieve the location of the user equipment.

Troubleshooting Focus: UE Identifier in ProvidePosInfoRequest

A common integration issue arises with the UE identifier used in the ProvidePosInfoRequest (specifically, Namf_Location ProvidePositioningInfo).

• Specification Requirement: Historically, 3GPP specifications (TS 23.271, TS 23.273) mandated the use of SUPI (IMSI) as the primary identifier for location requests in the 5G system. The ueContextId in the resource URI {apiRoot}/namf-loc/<apiVersion>/{ueContextId} is expected to be similar in patterns like imsi-XXXX or imei-XXXX.
• Common Issue: GMLCs can incorrectly send a plain MSISDN instead of a SUPI (IMSI) or PEI (IMEI) in the ueContextId or within the request body. The AMF fails to decode and validate the message correctly in such cases.
• Resolution/Evolution: In Release 18.6.0 of the 3GPP specifications (29.518), the AMF service has been updated to accept Generic Public Subscription Identifier (GPSI), which includes MSISDN, as part of the Location Request. This is particularly important for locating inbound roamers using their MSISDN.

2. Determine Location Request: AMF to LMF

Post a successful ProvidePosInfoRequest, the AMF sends a Namf_Location DetermineLocationRequest to the LMF. This request contains essential information such as AMFID, correlationid, NCGI, PEI, SUPI, and ueConnectivityStates to assist the LMF in determining the location of the user equipment.

3. UE Positioning: LMF via AMF to gNB/UE

After the LMF processes the DetermineLocationRequest, it initiates the UE positioning procedure. The LMF sends an N1/N2 message to the AMF, which acts as a forwarder to the gNB (N2) or directly to the UE (N1). The AMF then receives the location information back from the gNB/UE and shares it with the LMF.

This forwarding mechanism is critical:

• NRPPa-PDU: The core payload containing positioning instructions or measurement requests is the New Radio Positioning Protocol A (NRPPa-PDU).
• Encapsulation: The NRPPa-PDU is encapsulated within an N2 container.
• Role of AMF: The AMF receives this N2 container from the LMF and constructs a downlinkUEAssociatedNRPPaTransport message to send to the gNB (as detailed in NGAP specs 38.413).
• API Context: The communication uses the Namf_Communication N1N2 Message Transfer (UE Specific) service operation (for example, /ue-contexts/{ueContextId}/n1-n2-messages). The request body is N1N2MessageTransferReqData.

Troubleshooting Focus: N1/N2 Container Transfer Format

A significant integration challenge here involves the message format for transferring N1/N2 containers:

• Expected Format: According to specifications, the N1N2MessageTransferReqData (which includes the N2 container with the NRPPa-PDU) must ideally be sent as a multipart/related message. This format allows for both JSON data and binary parts (like the N2 container).
• Common Issue: Despite the N2 container being present, AMF logs must show errors like:

"amf-rest-ep-1 [ERROR] [common_validation.go:288] [amf-rest-ep.amf-app.smf] NOT Received the Mandatory IE: Both N1 / N2 Container not received".

This often occurs because the LMF is not transferring the request body as multipart/related but instead uses an incorrect format (for example, line-based text data). The AMF fails to decode and validate the message correctly.

• Resolution: Ensure the LMF correctly formats the N1N2MessageTransferReqData as a multipart/related HTTP message, adhering to the 3GPP specifications.

Troubleshooting Focus: LCS Correlation ID

The LCS Correlation ID is an unique identifier used to link and track all messages and procedures related to a single Location Services (LCS) session (like an MT-LR) across different network functions (AMF, LMF, gNB). It ensures proper context for positioning requests.

• Specification: The LCS Correlation ID is applied when transferring LCS-related UE-Specific N1 and/or N2 messages for the ueContextId. It is defined in both the URI (cid in /ue-contexts/{ueContextId}/n1-n2-messages) and as a JSON IE (lcsCorrelationId) within the body.
• Common Issue: If the LMF sends an incorrect LCS Correlation ID, the AMF fails to process it, leading to errors such as:

"[ERROR] [amf-service.amf-app.n1n2] Invalid LCS correlation ID".

• Resolution: The AMF sends the initial LCS Correlation ID, and the LMF is expected to set its session ID to this value. This same correlation ID must then be consistently used across all interfaces (AMF to LMF, AMF to gNB) as a routing identifier. Verify that the LMF is correctly receiving and reusing the LCS Correlation ID provided by the AMF.

Conclusion

The MT-LR feature in the 5G AMF is crucial for location services. While the underlying call flow is standardized, successful integration and operation depend heavily on strict adherence to 3GPP specifications, especially concerning UE identifiers, message formatting for N1/N2 containers, and consistent use of the LCS Correlation ID.

Revision History

Revision	Publish Date	Comments
1.0	04-May-2026	Initial Release