排除AMF中的MT-LR呼叫流程和常見的第3方LMF、GMLC整合問題

簡介

本檔案介紹網路工程師的AMF行動端接位置請求(MT-LR)功能、整合和疑難排解。

必要條件

需求

思科建議您瞭解存取和行動化管理功能(AMF)的功能

採用元件

本文中的資訊與思科AMF有關，思科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 ProvidePositioningInfo）存在一個常見的整合問題。

• 規格要求：過去，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容器，並構造一個下行鏈路UEAsoliatedNRPPaTransport消息以傳送到gNB（詳見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按照3GPP規範將N1N2MessageTransferReqData正確格式化為多部分/相關的HTTP消息。

故障排除重點：LCS關聯ID

LCS Correlation ID是一個唯一的識別符號，用於連結和跟蹤與單個位置服務(LCS)會話（如MT-LR）相關的跨不同網路功能(AMF、LMF、gNB)的所有報文和過程。 它可確保定位請求的正確上下文。

• 規格：在為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	初始版本