Dépannage du flux d'appels MT-LR dans AMF et des problèmes d'intégration courants avec LMF tiers, GMLC

Introduction

Ce document décrit les fonctionnalités MT-LR (Mobile-Terminated Location Request) AMF, l'intégration et le dépannage pour les ingénieurs réseau.

Conditions préalables

Exigences

Cisco vous recommande de connaître les fonctionnalités de la fonction de gestion de l'accès et de la mobilité (AMF)

Composants utilisés

Les informations contenues dans ce document concernent Cisco AMF, qui est l'AMF du réseau central 5G.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Les services de localisation sont fondamentaux dans les réseaux mobiles modernes, non seulement pour l'expérience utilisateur, mais également pour les exigences réglementaires critiques telles que les appels d'urgence et les interceptions légales. Dans le coeur de réseau 5G, l'AMF joue un rôle central dans la gestion de ces demandes de localisation.

Qu'est-ce que la demande de localisation de terminaison mobile (MT-LR) ?

L'AMF prend en charge divers types de demandes de localisation, notamment NI-LR (Network Induced Location Request) et MT-LR.

MT-LR est initié lorsqu'une entité externe, généralement le Gateway Mobile Location Center (GMLC), demande l'emplacement d'un équipement utilisateur (UE). Le GMLC transmet cette demande à l'AMF, qui coordonne ensuite avec la fonction de gestion de localisation (LMF) pour déterminer l'emplacement précis de l'équipement utilisateur. Une fois identifiées, les informations de localisation sont renvoyées au GMLC.

L'AMF peut fournir l'« emplacement actuel » ou le « dernier emplacement connu ou actuel » pour les MT-LR, offrant une souplesse en fonction de l'urgence et de l'état d'activité de l'équipement utilisateur.

Points de contact d'intégration clés pour MT-LR

Pour le processus MT-LR, l'Autorité communique principalement avec :

• GMLC : lance la demande d'emplacement.
• LMF : détermine l'emplacement de l'équipement utilisateur.
• gNB : la station d'accueil 5G, impliquée dans le positionnement de l'équipement utilisateur.

Défis liés au flux d'appels MT-LR et à l'intégration

Le processus MT-LR comprend trois échanges majeurs entre l'AMF, le GMLC et le LMF :

1. Échange de demandes d'informations de positionnement (GMLC à AMF)
2. Déterminer la demande d'emplacement (AMF à LMF)
3. Positionnement de l'équipement utilisateur (LMF via AMF vers gNB/UE et retour)

Une explication de ces trois étapes et des défis d'intégration communs est expliquée ici.

1. Demande d'informations de positionnement : GMLC à AMF

Le processus MT-LR débute lorsque le GMLC envoie une Demande de renseignements sur les points de vente à l'Autorité. Cette demande est cruciale car elle lance la séquence complète de détermination de localisation. L’AMF assure ensuite la coordination avec d’autres fonctions réseau, telles que la LMF, pour récupérer l’emplacement de l’équipement utilisateur.

Priorité au dépannage : Identificateur UE dans ProviderPosInfoRequest

Un problème d'intégration courant se pose avec l'identificateur UE utilisé dans la requête ProviderPosInfoRequest (en particulier, Namf_Location ProviderPositioningInfo).

• Spécifications requises : Historiquement, les spécifications 3GPP (TS 23.271, TS 23.273) imposaient l'utilisation de SUPI (IMSI) comme identifiant principal pour les demandes de localisation dans le système 5G. Le ueContextId dans l'URI de ressource {apiRoot}/namf-loc/<apiVersion>/{ueContextId} devrait être similaire dans des modèles comme imsi-XXXX ou imei-XXXX.
• Problème courant : les GMLC peuvent envoyer de manière incorrecte un MSISDN simple au lieu d'un SUPI (IMSI) ou d'un PEI (IMEI) dans le ueContextId ou dans le corps de la demande. L'AMF ne parvient pas à décoder et à valider correctement le message dans de tels cas.
• Résolution/Évolution : Dans la version 18.6.0 des spécifications 3GPP (29.518), le service AMF a été mis à jour pour accepter l'identificateur d'abonnement public générique (GPSI), qui inclut MSISDN, dans le cadre de la demande de localisation. Ceci est particulièrement important pour la localisation des itinérants entrants à l'aide de leur MSISDN.

2. Déterminez la demande d'emplacement : AMF à LMF

Lorsque l'AMF envoie une requête ProviderPosInfoRequest, elle envoie une requête Namf_Location DetermineLocationRequest à la LMF. Cette demande contient des informations essentielles, telles que AMFID, corRelationid, NCGI, PEI, SUPI et ueConnectivityStates, afin d’aider le LMF à déterminer l’emplacement de l’équipement utilisateur.

3. Positionnement de l’UE : LMF via AMF vers gNB/UE

Une fois que la LMF a traité la demande DetermineLocationRequest, elle lance la procédure de positionnement UE. La LMF envoie un message N1/N2 à l'AMF, qui agit comme un transmetteur vers le gNB (N2) ou directement vers l'UE (N1). L'AMF reçoit ensuite les informations de localisation en retour du gNB/UE et les partage avec le LMF.

Ce mécanisme de transfert est essentiel :

• NRPPa-PDU : la charge utile principale contenant les instructions de positionnement ou les demandes de mesure est le nouveau protocole de positionnement radio A (NRPPa-PDU).
• Encapsulation : la NRPPa-PDU est encapsulée dans un conteneur N2.
• Rôle de l'AMF : L'AMF reçoit ce conteneur N2 du LMF et construit un message DownlinkUEAssociatedNRPPaTransport à envoyer au gNB (comme détaillé dans les spécifications NGAP 38.413).
• Contexte API : la communication utilise l'opération de service de transfert de messages (spécifique à l'UE) Namf_Communication N1N2 (par exemple, /ue-contextes/{ueContextId}/n1-n2-messages). Le corps de la demande est N1N2MessageTransferReqData.

Priorité au dépannage : Format de transfert de conteneur N1/N2

Le format du message pour le transfert des conteneurs N1/N2 constitue ici un défi d’intégration important :

• Format attendu : selon les spécifications, les données N1N2MessageTransferReqData (qui incluent le conteneur N2 avec la NRPPa-PDU) doivent idéalement être envoyées sous forme de message en plusieurs parties/associé. Ce format permet à la fois les données JSON et les parties binaires (comme le conteneur N2).
• Problème courant : bien que le conteneur N2 soit présent, les journaux AMF doivent afficher des erreurs telles que :

"amf-rest-ep-1 [ERROR] [common_validation.go:288] [amf-rest-ep.amf-app.smf] NOT Received the Mandatory IE: Les deux conteneurs N1 / N2 n'ont pas été reçus".

Cela se produit souvent parce que le LMF ne transfère pas le corps de la requête comme multipart/related mais utilise plutôt un format incorrect (par exemple, des données de texte basées sur des lignes). L'Autorité ne parvient pas à décoder et à valider correctement le message.

• Résolution : assurez-vous que le LMF formate correctement les données N1N2MessageTransferReqData en tant que message HTTP en plusieurs parties/associé, conformément aux spécifications 3GPP.

Priorité au dépannage : ID de corrélation LCS

L'ID de corrélation LCS est un identifiant unique utilisé pour lier et suivre tous les messages et procédures liés à une session LCS (Location Services) unique (comme un MT-LR) sur différentes fonctions réseau (AMF, LMF, gNB). Il assure un contexte approprié pour les demandes de positionnement.

• Spécification : l'ID de corrélation LCS est appliqué lors du transfert des messages UE-Specific N1 et/ou N2 liés à LCS pour ueContextId. Il est défini à la fois dans l'URI (cid dans /ue-contextes/{ueContextId}/n1-n2-messages) et en tant qu'IE JSON (lcsCorrelationId) dans le corps.
• Problème courant : si le LMF envoie un ID de corrélation LCS incorrect, l'AMF ne le traite pas, ce qui entraîne des erreurs telles que :

"[ERREUR] [amf-service.amf-app.n1n2] ID de corrélation LCS non valide".

• Résolution : l'AMF envoie l'ID de corrélation LCS initial, et le LMF est censé régler son ID de session sur cette valeur. Ce même ID de corrélation doit ensuite être utilisé de manière cohérente sur toutes les interfaces (AMF à LMF, AMF à gNB) comme identificateur de routage. Vérifiez que le LMF reçoit et réutilise correctement l'ID de corrélation LCS fourni par l'AMF.

Conclusion

La fonctionnalité MT-LR de l'AMF 5G est essentielle pour les services de localisation. Bien que le flux d'appels sous-jacent soit standardisé, l'intégration et le fonctionnement dépendent fortement du respect strict des spécifications 3GPP, en particulier en ce qui concerne les identificateurs UE, le formatage des messages pour les conteneurs N1/N2 et l'utilisation cohérente de l'ID de corrélation LCS.

Historique de révision

Révision	Date de publication	Commentaires
1.0	04-May-2026	Première publication