排除AMF中的MT-LR呼叫流和常见的第3方LMF、GMLC集成问题

简介

本文档介绍面向网络工程师的AMF移动端接位置请求(MT-LR)功能、集成和故障排除。

先决条件

要求

思科建议您了解访问和移动管理功能(AMF)的功能

使用的组件

本文档中的信息与Cisco AMF有关，Cisco AMF是5G核心网络中的AMF。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

位置服务是现代移动网络的基础服务，不仅对于用户体验是如此，对于紧急呼叫和合法拦截等关键法规要求也是如此。在5G核心中，AMF在处理这些位置请求方面发挥着关键作用。

什么是移动端终止位置请求(MT-LR)?

AMF支持各种类型的位置请求，包括网络诱导位置请求(NI-LR)和MT-LR。

当外部实体(通常为网关移动位置中心(GMLC))请求用户设备(UE)的位置时，会启动MT-LR。 GMLC将此请求转发到AMF，AMF随后与位置管理功能(LMF)协调以确定用户设备的精确位置。一旦识别，位置信息将发送回GMLC。

AMF可为MT-LR提供“当前位置”或“当前或最后已知位置”，基于用户设备的紧急程度和活动状态提供灵活性。

MT-LR的主要集成接触点

对于MT-LR流程，AMF主要与：

• GMLC：启动位置请求。
• LMF：确定用户设备的位置。
• gNB：涉及用户设备定位的5G基站。

MT-LR呼叫流程和集成挑战

MT-LR流程涉及AMF、GMLC和LMF之间的三个主要交换：

1. 定位信息请求交换（GMLC到AMF）
2. 确定位置请求（AMF到LMF）
3. 用户设备定位（通过AMF到gNB/UE和背面LMF）

下面将解释这三个阶段以及常见的集成挑战。

1.定位信息请求：GMLC至AMF

GMLC向AMF发送ProvidePosInfoRequest时，MT-LR进程开始。此请求至关重要，因为它将启动整个位置确定序列。然后，AMF与其他网络功能（如LMF）协调以检索用户设备的位置。

故障排除重点：ProvidePosInfoRequest中的UE标识符

ProvidePosInfoRequest中使用的UE标识符（具体是Namf_Location ProvidedPositioningInfo）存在一个常见的集成问题。

• 规范要求：过去，3GPP规范(TS 23.271、TS 23.273)要求使用SUPI(IMSI)作为5G系统中位置请求的主要标识符。资源URI {apiRoot}/namf-loc/<apiVersion>/{ueContextId}中的ueContextId应类似于imsi-XXXX或imei-XXXX模式。
• 常见问题：GMLC可能错误地发送普通的MSISDN，而不是ueContextId或请求正文中的SUPI(IMSI)或PEI(IMEI)。在这种情况下，AMF无法正确解码和验证消息。
• 解决方案/发展：在3GPP规范(29.518)的版本18.6.0中，AMF服务已更新为接受通用公共订用标识符(GPSI)（包括MSISDN），作为位置请求的一部分。这对于使用其MSISDN定位入站漫游者尤其重要。

2.确定位置请求：AMF到LMF

在成功ProvidePosInfoRequest后，AMF会向LMF发送Namf_Location DetermineLocationRequest。此请求包含基本信息，如AMFID、correlationid、NCGI、PEI、SUPI和ueConnectivityStates，用于帮助LMF确定用户设备的位置。

3. UE定位：通过AMF到gNB/UE的LMF

在LMF处理DetermineLocationRequest后，它启动UE定位过程。LMF向AMF发送N1/N2消息，AMF充当到gNB(N2)或直接到UE(N1)的转发器。 然后，AMF从gNB/UE接收位置信息并将其与LMF共享。

此转发机制至关重要：

• NRPPa-PDU：包含定位指令或测量请求的核心负载是新的无线定位协议A(NRPPa-PDU)。
• 封装：NRPPa-PDU封装在N2容器中。
• AMF的角色：AMF从LMF接收此N2容器，并构造一个要发送到gNB的downlinkUEAssociatedNRPPaTransport消息（详见NGAP规范38.413）。
• API上下文：通信使用Namf_Communication N1N2消息传输（UE特定）服务操作（例如，/ue-contexts/{ueContextId}/n1-n2-messages）。 请求正文为N1N2MessageTransferReqData。

故障排除重点：N1/N2容器传输格式

这里的一个重要集成挑战涉及用于传输N1/N2容器的消息格式：

• 预期格式：根据规范，N1N2MessageTransferReqData（包括带NRPPa-PDU的N2容器）最好作为多部分/相关消息发送。此格式允许JSON数据和二进制部分（如N2容器）。
• 常见问题：尽管存在N2容器，但AMF日志必须显示以下错误：

"amf-rest-ep-1 [ERROR] [common_validation.go:288] [amf-rest-ep.amf-app.smf]未收到必备IE:未收到N1/N2容器”。

这通常是由于LMF没有将请求正文作为多部分/相关部分进行传输，而是使用了不正确的格式（例如，基于行的文本数据）。 AMF无法正确解码和验证消息。

• 解决方案：确保LMF将N1N2MessageTransferReqData正确格式化为多部分/相关HTTP消息，并符合3GPP规范。

故障排除重点：LCS关联ID

LCS关联ID是一个唯一的标识符，用于链接和跟踪与跨不同网络功能(AMF、LMF、gNB)的单个位置服务(LCS)会话（如MT-LR）相关的所有报文和过程。 它可确保定位请求的正确情景。

• 规格：在为ueContextId传输与LCS相关的UE特定N1和/或N2消息时应用LCS关联ID。它在URI（在/ue-contexts/{ueContextId}/n1-n2-messages中的cid）和正文中的JSON IE(lcsCorrelationId)中定义。
• 常见问题：如果LMF发送不正确的LCS关联ID，则AMF无法处理它，从而导致以下错误：

"[错误] [amf-service.amf-app.n1n2] LCS关联ID无效"。

• 解决方法：AMF发送初始LCS关联ID，LMF应将其会话ID设置为此值。然后，必须在所有接口（AMF到LMF、AMF到gNB）上一致地使用此相同的关联ID作为路由标识符。验证LMF是否正确接收和重新使用AMF提供的LCS关联ID。

结论

5G AMF中的MT-LR功能对位置服务至关重要。虽然基本的呼叫流程是标准化的，但成功的集成和操作在很大程度上取决于对3GPP规范的严格遵守，尤其是关于UE标识符、N1/N2容器的消息格式设置以及LCS关联ID的一致使用。

修订历史记录

版本	发布日期	备注
1.0	04-May-2026	初始版本