本檔案介紹網路工程師的AMF行動端接位置請求(MT-LR)功能、整合和疑難排解。
思科建議您瞭解存取和行動化管理功能(AMF)的功能
本文中的資訊與思科AMF有關,思科AMF是5G核心網中的AMF。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
位置服務在現代行動網路中至關重要,這不僅是為了使用者體驗,也是為了緊急呼叫和合法攔截等關鍵監管要求。在5G核心中,AMF在處理這些位置請求方面發揮著關鍵作用。
AMF支援各種型別的位置請求,包括網路誘導位置請求(NI-LR)和MT-LR。
當外部實體(通常是網關移動位置中心(GMLC))請求使用者裝置(UE)的位置時,MT-LR被啟動。 GMLC將該請求轉發到AMF,AMF與位置管理功能(LMF)協調以確定使用者裝置的精確位置。一旦識別,位置資訊被傳送回GMLC。
AMF可以為MT-LR提供「當前位置」或「當前或最後已知位置」,基於使用者裝置的緊急性和活動狀態提供靈活性。
對於MT-LR流程,AMF主要與:
MT-LR流程涉及到AMF、GMLC和LMF之間的三個主要交換:
下面將解釋這三個階段以及常見的整合挑戰。
GMLC向AMF傳送ProvidePosInfoRequest時,MT-LR進程開始。此請求至關重要,因為它啟動了整個位置確定序列。然後,AMF與其他網路功能(例如LMF)協調,以檢索使用者裝置的位置。
ProvidePosInfoRequest中使用的UE識別符號(具體是Namf_Location ProvidePositioningInfo)存在一個常見的整合問題。
發佈成功的ProvidePosInfoRequest後,AMF會向LMF傳送Namf_Location DetermineLocationRequest。此請求包含基本資訊,如AMFID、correlationid、NCGI、PEI、SUPI和ueConnectivityStates,用於幫助LMF確定使用者裝置的位置。
在LMF處理DetermineLocationRequest之後,它啟動UE定位過程。LMF向AMF傳送N1/N2消息,所述AMF充當到gNB(N2)或者直接到UE(N1)的轉發器。 然後,AMF從gNB/UE接收位置資訊並將其與LMF共用。
此轉發機制至關重要:
這裡的一個重要整合挑戰涉及用於傳輸N1/N2容器的報文格式:
"amf-rest-ep-1 [ERROR] [common_validation.go:288] [amf-rest-ep.amf-app.smf]未收到強制IE:未收到N1/N2容器」。
這通常是由於LMF沒有將請求正文作為多部分/相關內容進行傳輸,而是使用了不正確的格式(例如,基於行的文本資料)。 AMF無法正確解碼和驗證消息。
LCS Correlation ID是一個唯一的識別符號,用於連結和跟蹤與單個位置服務(LCS)會話(如MT-LR)相關的跨不同網路功能(AMF、LMF、gNB)的所有報文和過程。 它可確保定位請求的正確上下文。
「[錯誤] [amf-service.amf-app.n1n2] LCS關聯ID無效」。
5G AMF中的MT-LR功能對位置服務至關重要。雖然基礎呼叫流是標準化的,但成功的整合和操作在很大程度上取決於對3GPP規範的嚴格遵守,尤其是關於UE識別符號、N1/N2容器的消息格式設定以及LCS相關ID的一致使用。
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
04-May-2026
|
初始版本 |