Fehlerbehebung bei MT-LR-Anruffluss in AMF und häufigen Integrationsproblemen mit LMF, GMLC von Drittanbietern

Einleitung

In diesem Dokument werden die Funktionen, die Integration und die Fehlerbehebung von AMF MT-LR (Mobile-Terminated Location Request) für Netzwerktechniker beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie die Funktionen der Access and Mobility Management Function (AMF) kennen.

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf Cisco AMF, das AMF im 5G-Core-Netzwerk.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Standortdienste sind in modernen mobilen Netzwerken nicht nur für die Benutzerfreundlichkeit von grundlegender Bedeutung, sondern auch für wichtige gesetzliche Anforderungen wie Notrufe und rechtmäßige Überwachung. Im 5G-Core spielt die AMF eine zentrale Rolle bei der Bearbeitung dieser Standortanfragen.

Was ist MT-LR (Mobile-Terminated Location Request)?

Die AMF unterstützt verschiedene Arten von Standortanfragen, darunter Network Induced Location Request (NI-LR) und MT-LR.

MT-LR wird initiiert, wenn eine externe Einheit, in der Regel das Gateway Mobile Location Center (GMLC), den Standort eines User Equipment (UE) anfordert. Das GMLC leitet diese Anfrage an die AMF weiter, die sich dann mit der Location Management Function (LMF) abstimmt, um den genauen Standort der Benutzergeräte zu ermitteln. Nach der Identifizierung werden die Standortinformationen zurück an den GMLC gesendet.

Die AMF kann für MT-LRs entweder den "aktuellen Standort" oder den "aktuellen oder letzten bekannten Standort" bereitstellen und bietet Flexibilität basierend auf der Dringlichkeit und dem Aktivitätsstatus der Benutzergeräte.

Wichtige Berührungspunkte für die Integration von MT-LR

Für den MT-LR-Prozess kommuniziert das AMF in erster Linie mit:

• GMLC: Initiiert die Standortanfrage.
• LMF: Bestimmt den Standort der Benutzergeräte.
• gNB: Die 5G-Basisstation für die Positionierung der Benutzergeräte.

MT-LR - Herausforderungen bei Anruffluss und Integration

Das MT-LR-Verfahren umfasst drei wichtige Austauschmaßnahmen zwischen dem AMF, dem GMLC und dem LMF:

1. Austausch von Positionierungsinformationen (GMLC an AMF)
2. Standortanforderung ermitteln (AMF an LMF)
3. Positionierung der Benutzerausrüstung (LMF über AMF zu gNB/UE und zurück)

Erläuterung dieser drei Stufen und gemeinsame Integrationsherausforderungen werden hier erläutert.

1. Informationsanfrage zur Positionierung: GMLC an AMF

Der MT-LR-Prozess beginnt, wenn das GMLC eine ProvidePosInfoRequest an die AMF sendet. Diese Anforderung ist von entscheidender Bedeutung, da sie die gesamte Standortbestimmungssequenz in Gang setzt. Anschließend stimmt sich die AMF mit anderen Netzwerkfunktionen wie der LMF ab, um den Standort der Benutzergeräte abzurufen.

Fehlerbehebung - Schwerpunkt: UE-Kennung in ProvidePosInfoRequest

Ein häufig auftretendes Integrationsproblem mit dem in ProvidePosInfoRequest verwendeten UE-Bezeichner (insbesondere Namf_Location ProvidePositioningInfo) tritt auf.

• Spezifikation Anforderung: In der Vergangenheit wurde in den 3GPP-Spezifikationen (TS 23.271, TS 23.273) die Verwendung von SUPI (IMSI) als primäre Kennung für Standortanfragen im 5G-System vorgeschrieben. Die ueContextId im Ressourcen-URI {apiRoot}/namf-loc/<apiVersion>/{ueContextId} sollte in Mustern wie imsi-XXXX oder imei-XXXX ähnlich sein.
• Häufiges Problem: GMLCs können fälschlicherweise eine einfache MSISDN statt einer SUPI (IMSI) oder PEI (IMEI) in der ueContextId oder innerhalb des Anforderungstextes senden. Die AMF kann die Nachricht in solchen Fällen nicht richtig decodieren und validieren.
• Auflösung/Weiterentwicklung: In Version 18.6.0 der 3GPP-Spezifikationen (29.518) wurde der AMF-Dienst aktualisiert, sodass er Generic Public Subscription Identifier (GPSI), einschließlich MSISDN, als Teil der Standortanfrage akzeptiert. Dies ist besonders wichtig, um eingehende Roamer mithilfe ihrer MSISDN zu finden.

2. Standortanforderung ermitteln: AMF zu LMF

Nach einer erfolgreichen ProvidePosInfoRequest sendet die AMF eine Namf_Location DetermineLocationRequest an die LMF. Diese Anforderung enthält wichtige Informationen wie AMFID, Correlation, NCGI, PEI, SUPI und UseConnectivityStates, die die LMF bei der Standortbestimmung der Benutzergeräte unterstützen.

3. EU-Positionierung: LMF über AMF an gNB/UE

Nachdem der LMF die DetermineLocationRequest verarbeitet hat, wird die UE-Positionierungsprozedur gestartet. Die LMF sendet eine N1/N2-Nachricht an die AMF, die als Forwarder an den gNB (N2) oder direkt an das UE (N1) fungiert. Anschließend erhält die AMF die Standortinformationen vom gNB/UE zurück und gibt sie an die LMF weiter.

Dieser Weiterleitungsmechanismus ist von entscheidender Bedeutung:

• NRPPa-PDU: Die Kernnutzlast, die Positionierungsanweisungen oder Messanforderungen enthält, ist das Neue Funkpositionierungsprotokoll A (NRPPa-PDU).
• Kapselung: Die NRPPa-PDU wird in einen N2-Container gekapselt.
• Rolle von AMF: Die AMF empfängt diesen N2-Container von der LMF und erstellt eine Downlink-UEAssoziatedNRPPaTransport-Nachricht, die an die gNB gesendet wird (wie in NGAP-Spezifikationen 38.413 beschrieben).
• API-Kontext: Die Kommunikation verwendet den Service-Vorgang Namf_Communication N1N2 Message Transfer (UE-spezifisch) (z. B. /ue-contexts/{ueContextId}/n1-n2-messages). Der Anforderungstext lautet N1N2MessageTransferReqData.

Fehlerbehebung - Schwerpunkt: N1/N2-Container-Übertragungsformat

Eine wesentliche Integrationsherausforderung ist hierbei das Nachrichtenformat für die Übertragung von N1/N2-Containern:

• Erwartetes Format: Gemäß den Spezifikationen müssen die N1N2MessageTransferReqData (die den N2-Container mit der NRPPa-PDU enthält) idealerweise als mehrteilige/verknüpfte Nachricht gesendet werden. Dieses Format ermöglicht sowohl JSON-Daten als auch binäre Teile (wie den N2-Container).
• Häufiges Problem: Obwohl der N2-Container vorhanden ist, müssen AMF-Protokolle Fehler wie die folgenden aufweisen:

"amf-rest-ep-1 [FEHLER] [common_validation.go:288] [amf-rest-ep.amf-app.smf] hat das obligatorische IE NICHT erhalten: Beide N1 / N2 Container nicht empfangen".

Dies geschieht häufig, weil die LMF den Anforderungstext nicht als mehrteilig/bezogen überträgt, sondern ein falsches Format verwendet (z.B. zeilenbasierte Textdaten). Die AMF kann die Nachricht nicht richtig decodieren und validieren.

• Auflösung: Stellen Sie sicher, dass die LMF die N1N2MessageTransferReqData als mehrteilige/zugehörige HTTP-Nachricht entsprechend den 3GPP-Spezifikationen richtig formatiert.

Fehlerbehebung - Schwerpunkt: LCS-Korrelations-ID

Die LCS-Korrelations-ID ist eine eindeutige Kennung, die verwendet wird, um alle Nachrichten und Verfahren in Verbindung mit einer einzelnen LCS-Sitzung (wie MT-LR) über verschiedene Netzwerkfunktionen (AMF, LMF, gNB) zu verknüpfen und zu verfolgen. Es stellt den richtigen Kontext für Positionierungsanfragen sicher.

• Spezifikation: Die LCS-Korrelations-ID wird beim Übertragen von LCS-bezogenen UE-spezifischen N1- und/oder N2-Nachrichten für die ueContextId angewendet. Sie wird sowohl im URI (cid in /ue-contexts/{ueContextId}/n1-n2-messages) als auch als JSON IE (lcsCorrelationId) im Text definiert.
• Häufiges Problem: Wenn die LMF eine falsche LCS-Korrelations-ID sendet, kann sie von der AMF nicht verarbeitet werden. Dies führt zu Fehlern wie:

"[ERROR] [amf-service.amf-app.n1n2] Ungültige LCS-Korrelations-ID".

• Auflösung: Das AMF sendet die anfängliche LCS-Korrelations-ID, und es wird erwartet, dass das LMF seine Sitzungs-ID auf diesen Wert setzt. Dieselbe Korrelations-ID muss dann konsistent über alle Schnittstellen (AMF zu LMF, AMF zu gNB) als Routing-ID verwendet werden. Überprüfen Sie, ob die LMF die von der AMF bereitgestellte LCS-Korrelations-ID korrekt empfängt und wiederverwendet.

Schlussfolgerung

Die MT-LR-Funktion in 5G AMF ist für Standortdienste von entscheidender Bedeutung. Während der zugrunde liegende Anruffluss standardisiert ist, hängen erfolgreiche Integration und Betrieb in hohem Maße von der strikten Einhaltung der 3GPP-Spezifikationen ab, insbesondere in Bezug auf UE-Kennungen, Nachrichtenformatierung für N1/N2-Container und die konsistente Verwendung der LCS Correlation ID.

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	04-May-2026	Erstveröffentlichung