Problemen oplossen met MT-LR-gespreksstroom in AMF en veelvoorkomende integratieproblemen met 3RD Party LMF, GMLC

Inleiding

Dit document beschrijft de AMF Mobile-Terminated Location Request (MT-LR)-functionaliteit, integratie en probleemoplossing voor netwerktechnici.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van de functionaliteit van de Access and Mobility Management Function (AMF)

Gebruikte componenten

De informatie in dit document heeft betrekking op Cisco AMF, de AMF in 5G Core Network.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Locatiediensten zijn van fundamenteel belang in moderne mobiele netwerken, niet alleen voor de gebruikerservaring, maar ook voor kritische wettelijke vereisten zoals noodoproepen en legale onderscheppingen. In de 5G-kern speelt de AMF een centrale rol bij het afhandelen van deze locatieverzoeken.

Wat is een Mobile-Terminated Location Request (MT-LR)?

Het AMF ondersteunt verschillende soorten locatieverzoeken, waaronder Network Induced Location Request (NI-LR) en MT-LR.

MT-LR wordt gestart wanneer een externe entiteit, meestal het Gateway Mobile Location Center (GMLC), de locatie van een gebruikersapparatuur (UE) opvraagt. De GMLC stuurt dit verzoek door naar de AMF, die vervolgens coördineert met de Location Management Function (LMF) om de precieze locatie van de gebruikersapparatuur te bepalen. Eenmaal geïdentificeerd, wordt de locatie-informatie teruggestuurd naar de GMLC.

Het AMF kan de 'huidige locatie' of de 'huidige of laatst bekende locatie' voor MT-LR's bieden, en biedt flexibiliteit op basis van de urgentie en de activiteitstoestand van de gebruikersapparatuur.

Belangrijkste integratie touchpoints voor MT-LR

Voor het MT-LR-proces communiceert de AMF voornamelijk met:

• GMLC: initieert het locatieverzoek.
• LMF: Bepaalt de locatie van de gebruikersapparatuur.
• gNB: Het 5G-basisstation, betrokken bij de positionering van gebruikersapparatuur.

MT-LR Call Flow en integratie uitdagingen

Het MT-LR-proces omvat drie belangrijke uitwisselingen tussen de AMF, GMLC en LMF:

1. Positionering Informatie Verzoek Uitwisseling (GMLC naar AMF)
2. Locatieaanvraag bepalen (van AMF naar LMF)
3. Positionering van gebruikersapparatuur (LMF via AMF naar gNB/UE en terug)

Hier wordt uitleg gegeven over deze drie fasen en over gemeenschappelijke integratie-uitdagingen.

1. Verzoek om positioneringsinformatie: GMLC naar AMF

Het MT-LR-proces begint wanneer de GMLC een ProvidePosInfoRequest naar het AMF stuurt. Dit verzoek is van cruciaal belang omdat het de hele locatiebepalingssequentie aftrapt. De AMF coördineert vervolgens met andere netwerkfuncties, zoals de LMF, om de locatie van de gebruikersapparatuur op te halen.

Focus op probleemoplossing: UE-ID in ProvidePosInfoRequest

Er doet zich een veelvoorkomend integratieprobleem voor met de UE-ID die wordt gebruikt in het ProvidePosInfoRequest (met name Name_Location ProvidePositioningInfo).

• Specificatievereiste: Historisch gezien verplichtten 3GPP-specificaties (TS 23.271, TS 23.273) het gebruik van SUPI (IMSI) als de primaire identificator voor locatieverzoeken in het 5G-systeem. De ueContextId in de resource URI {apiRoot}/namf-loc/<apiVersion>/{ueContextId} is naar verwachting vergelijkbaar in patronen zoals imsi-XXXX of imei-XXXX.
• Veelvoorkomende problemen: GMLC's kunnen een gewone MSISDN verzenden in plaats van een SUPI (IMSI) of PEI (IMEI) in de ueContextId of binnen de aanvraaginstantie. Het AMF kan het bericht in dergelijke gevallen niet correct decoderen en valideren.
• Resolutie/evolutie: In release 18.6.0 van de 3GPP-specificaties (29.518) is de AMF-service bijgewerkt om Generic Public Subscription Identifier (GPSI), inclusief MSISDN, te accepteren als onderdeel van het locatieverzoek. Dit is vooral belangrijk voor het lokaliseren van inkomende roamers met behulp van hun MSISDN.

2. Locatieverzoek bepalen: AMF naar LMF

Na een succesvol ProvidePosInfoRequest stuurt de AMF een Name_Location DetermineLocationRequest naar de LMF. Dit verzoek bevat essentiële informatie zoals AMFID, correlationid, NCGI, PEI, SUPI en ueConnectivityStates om de LMF te helpen bij het bepalen van de locatie van de gebruikersapparatuur.

3. UE-positionering: LMF via AMF naar gNB/UE

Nadat de LMF het DetermineLocationRequest heeft verwerkt, wordt de UE-plaatsingsprocedure gestart. De LMF verzendt een N1/N2-bericht naar de AMF, die fungeert als een forwarder naar de gNB (N2) of rechtstreeks naar de UE (N1). De AMF ontvangt de locatiegegevens vervolgens terug van de gNB/UE en deelt deze met de LMF.

Dit doorstuurmechanisme is van cruciaal belang:

• NRPPa-PDU: De kernlading met positioneringsinstructies of meetverzoeken is het nieuwe Radio Positioning Protocol A (NRPPa-PDU).
• Inkapseling: De NRPPa-PDU is ingekapseld in een N2 container.
• Rol van AMF: De AMF ontvangt deze N2-container van de LMF en construeert een downlinkUEAassociatedNRPPaTransport-bericht om naar de gNB te sturen (zoals beschreven in NGAP-specificaties 38.413).
• API Context: De communicatie maakt gebruik van de Namf_Communication N1N2 Message Transfer (UE Specific) service operatie (bijvoorbeeld, /ue-contexts/{ueContextId}/n1-n2-messages). De instantie die de aanvraag indient is N1N2MessageTransferReqData.

Focus op probleemoplossing: N1/N2 Container Transfer Format

Een belangrijke integratieuitdaging hierbij is het berichtformaat voor het overbrengen van N1/N2 containers:

• Verwacht formaat: volgens de specificaties moet de N1N2MessageTransferReqData (inclusief de N2-container met de NRPPa-PDU) idealiter worden verzonden als een multipart / gerelateerd bericht. Dit formaat maakt zowel JSON-gegevens als binaire onderdelen (zoals de N2-container) mogelijk.
• Veelvoorkomend probleem: Ondanks dat de N2-container aanwezig is, moeten AMF-logs fouten vertonen zoals:

"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".

Dit gebeurt vaak omdat de LMF de aanvraagbody niet als multipart / gerelateerd overdraagt, maar in plaats daarvan een onjuist formaat gebruikt (bijvoorbeeld regelgebaseerde tekstgegevens). Het AMF kan het bericht niet correct decoderen en valideren.

• Resolutie: Zorg ervoor dat de LMF de N1N2MessageTransferReqData correct formatteert als een multipart / gerelateerd HTTP-bericht, volgens de 3GPP-specificaties.

Focus op probleemoplossing: LCS-correlatie-ID

De LCS Correlation ID is een unieke identificatie die wordt gebruikt om alle berichten en procedures met betrekking tot een enkele LCS-sessie (zoals een MT-LR) te koppelen en te volgen over verschillende netwerkfuncties (AMF, LMF, gNB). Het zorgt voor een goede context voor het positioneren van verzoeken.

• Specificatie: De LCS Correlation ID wordt toegepast bij het overbrengen van LCS-gerelateerde UE-Specific N1- en/of N2-berichten voor de ueContextId. Het wordt gedefinieerd in zowel de URI (cid in /ue-contexten/{ueContextId}/n1-n2-berichten) en als een JSON IE (lcsCorrelationId) binnen het lichaam.
• Veelvoorkomend probleem: als de LMF een onjuiste LCS-correlatie-ID verzendt, kan de AMF deze niet verwerken, wat leidt tot fouten zoals:

"[ERROR] [amf-service.amf-app.n1n2] Ongeldige LCS-correlatie-ID".

• Resolutie: De AMF verzendt de initiële LCS Correlation ID en de LMF zal naar verwachting zijn sessie-ID op deze waarde instellen. Dezelfde correlatie-ID moet dan consequent worden gebruikt op alle interfaces (AMF naar LMF, AMF naar gNB) als routing-ID. Controleer of de LMF de door het AMF verstrekte LCS-correlatie-ID correct ontvangt en opnieuw gebruikt.

Conclusie

De MT-LR-functie in de 5G AMF is cruciaal voor locatiediensten. Hoewel de onderliggende oproepstroom gestandaardiseerd is, hangen succesvolle integratie en werking sterk af van strikte naleving van 3GPP-specificaties, met name met betrekking tot UE-identificatoren, berichtopmaak voor N1/N2-containers en consistent gebruik van de LCS Correlation ID.

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
1.0	04-May-2026	Eerste vrijgave