Resolución de problemas de flujo de llamadas MT-LR en AMF y problemas comunes de integración con LMF, GMLC de terceros

Introducción

Este documento describe la funcionalidad, integración y solución de problemas de AMF Mobile-Terminated Location Request (MT-LR) para ingenieros de redes.

Prerequisites

Requirements

Cisco recomienda que conozca la funcionalidad de la función de gestión de acceso y movilidad (AMF)

Componentes Utilizados

La información de este documento está relacionada con Cisco AMF, que es el AMF en la red de núcleo 5G.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Los servicios de ubicación son fundamentales en las redes móviles modernas, no solo para la experiencia del usuario, sino también para los requisitos normativos fundamentales, como las llamadas de emergencia y las interceptaciones legales. En el núcleo 5G, el AMF desempeña un papel fundamental a la hora de gestionar estas solicitudes de ubicación.

¿Qué es la solicitud de ubicación con terminación móvil (MT-LR)?

El AMF admite varios tipos de solicitudes de ubicación, incluidas las solicitudes de ubicación inducida por la red (NI-LR) y MT-LR.

MT-LR se inicia cuando una entidad externa, normalmente el Gateway Mobile Location Center (GMLC), solicita la ubicación de un equipo de usuario (UE). El GMLC reenvía esta solicitud al AMF, que luego se coordina con la función de gestión de la ubicación (LMF) para determinar la ubicación exacta del equipo del usuario. Una vez identificada, la información de ubicación se envía de vuelta al GMLC.

El AMF puede proporcionar la "ubicación actual" o la "ubicación actual o la última ubicación conocida" para MT-LR, ofreciendo flexibilidad basada en la urgencia y el estado de actividad del equipo del usuario.

Puntos de contacto clave de integración para MT-LR

Para el proceso MT-LR, el AMF se comunica principalmente con:

• GMLC: Inicia la solicitud de ubicación.
• LMF: Determina la ubicación del equipo del usuario.
• gNB: La estación base 5G, involucrada en el posicionamiento de equipos de usuario.

Retos de integración y flujo de llamadas MT-LR

El proceso MT-LR implica tres intercambios principales entre AMF, GMLC y LMF:

1. Intercambio de solicitudes de información de posicionamiento (GMLC a AMF)
2. Determinación de la solicitud de ubicación (AMF a LMF)
3. Posicionamiento del equipo del usuario (LMF mediante AMF a gNB/UE y viceversa)

A continuación se explican estas tres etapas y los retos comunes de integración.

1. Solicitud de información de posicionamiento: GMLC a AMF

El proceso MT-LR comienza cuando el GMLC envía una solicitud de ProvidersInfoal AMF. Esta solicitud es crucial, ya que inicia toda la secuencia de determinación de la ubicación. A continuación, el AMF se coordina con otras funciones de red, como el LMF, para recuperar la ubicación del equipo del usuario.

Enfoque de resolución de problemas: Identificador UE en ProviderPosInfoRequest

Un problema común de integración surge con el identificador UE utilizado en la solicitud de ProviderPosInfo (específicamente, Name_Location, ProviderPositioningInfo).

• Requisito de especificación: históricamente, las especificaciones 3GPP (TS 23.271, TS 23.273) exigían el uso de SUPI (IMSI) como identificador principal para las solicitudes de ubicación en el sistema 5G. Se espera que ueContextId en el URI de recurso {apiRoot}/namf-loc/<apiVersion>/{ueContextId} sea similar en patrones como imsi-XXXX o imei-XXXX.
• Problema común: los GMLC pueden enviar incorrectamente una MSISDN simple en lugar de un SUPI (IMSI) o PEI (IMEI) en el ueContextId o dentro del cuerpo de la solicitud. El AMF no puede decodificar y validar el mensaje correctamente en estos casos.
• Resolución/Evolución: en la versión 18.6.0 de las especificaciones 3GPP (29.518), el servicio AMF se ha actualizado para aceptar el identificador de suscripción pública genérico (GPSI), que incluye MSISDN, como parte de la solicitud de ubicación. Esto es particularmente importante para localizar a los itinerantes entrantes usando su MSISDN.

2. Determine la solicitud de ubicación: AMF a LMF

Si se publica correctamente una solicitud de ProviderPosInfoRequest, el AMF envía una solicitud de DetermineLocationName_Location al LMF. Esta solicitud contiene información esencial como AMFID, correlacionid, NCGI, PEI, SUPI y useConnectivityStates para ayudar al LMF a determinar la ubicación del equipo del usuario.

3. Posicionamiento UE: LMF a través de AMF a gNB/UE

Después de que el LMF procesa la solicitud DetermineLocationRequest, inicia el procedimiento de posicionamiento UE. El LMF envía un mensaje N1/N2 al AMF, que actúa como reenviador al gNB (N2) o directamente a la UE (N1). A continuación, el AMF recibe la información de ubicación del gNB/UE y la comparte con el LMF.

Este mecanismo de reenvío es fundamental:

• NRPPa-PDU: la carga útil principal que contiene instrucciones de posicionamiento o solicitudes de medición es el nuevo protocolo de posicionamiento de radio A (NRPPa-PDU).
• Encapsulación: el NRPPa-PDU se encapsula dentro de un contenedor N2.
• Función de AMF: el AMF recibe este contenedor N2 del LMF y crea un mensaje downlinkUEAssociatedNRPPaTransport para enviarlo al gNB (como se detalla en las especificaciones de NGAP 38.413).
• Contexto de API: la comunicación utiliza la operación de servicio de transferencia de mensajes N1N2 (específica de UE) Name_Communication (por ejemplo, /ue-contexts/{ueContextId}/n1-n2-messages). El cuerpo de la solicitud es N1N2MessageTransferReqData.

Enfoque de resolución de problemas: Formato de transferencia de contenedor N1/N2

Un reto importante de integración aquí es el formato del mensaje para la transferencia de contenedores N1/N2:

• Formato esperado: de acuerdo con las especificaciones, lo ideal es que N1N2MessageTransferReqData (que incluye el contenedor N2 con NRPPa-PDU) se envíe como un mensaje relacionado o de varias partes. Este formato permite tanto los datos JSON como las partes binarias (como el contenedor N2).
• Problema común: a pesar de que el contenedor N2 está presente, los registros de AMF deben mostrar errores como:

"amf-rest-ep-1 [ERROR] [common_validation.go:288] [amf-rest-ep.amf-app.smf] NO se ha recibido el IE obligatorio: Contenedor N1 / N2 no recibido".

Esto ocurre a menudo porque el LMF no transfiere el cuerpo de la solicitud como multiparte/relacionado, sino que utiliza un formato incorrecto (por ejemplo, datos de texto basados en línea). El AMF no puede descodificar y validar el mensaje correctamente.

• Resolución: asegúrese de que el LMF formatee correctamente el mensaje HTTP N1N2MessageTransferReqData como un mensaje HTTP multiparte/relacionado, cumpliendo con las especificaciones 3GPP.

Enfoque de resolución de problemas: ID de correlación de LCS

El ID de correlación de LCS es un identificador único que se utiliza para vincular y realizar un seguimiento de todos los mensajes y procedimientos relacionados con una sesión de servicios de ubicación (LCS) única (como un MT-LR) en diferentes funciones de red (AMF, LMF, gNB). Garantiza un contexto adecuado para posicionar las solicitudes.

• Especificación: el ID de correlación de LCS se aplica cuando se transfieren mensajes UE-Specific N1 o N2 relacionados con LCS para ueContextId. Se define tanto en el URI (cid en /ue-contexts/{ueContextId}/n1-n2-messages) como en el IE JSON (lcsCorrelationId) dentro del cuerpo.
• Problema común: si el LMF envía un ID de correlación de LCS incorrecto, el AMF no puede procesarlo, lo que genera errores como:

"[ERROR] [amf-service.amf-app.n1n2] Id. de correlación de LCS no válido".

• Resolución: el AMF envía el ID de correlación de LCS inicial y se espera que el LMF establezca su ID de sesión en este valor. Este mismo ID de correlación se debe utilizar de forma coherente en todas las interfaces (AMF a LMF, AMF a gNB) como identificador de routing. Verifique que el LMF reciba y reutilice correctamente el ID de correlación de LCS proporcionado por el AMF.

Conclusión

La función MT-LR en el AMF 5G es crucial para los servicios de ubicación. Aunque el flujo de llamadas subyacente está estandarizado, la integración y el funcionamiento correctos dependen en gran medida del cumplimiento estricto de las especificaciones 3GPP, especialmente en lo que respecta a los identificadores UE, el formato de mensajes para los contenedores N1/N2 y el uso coherente de la ID de correlación de LCS.

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
1.0	04-May-2026	Versión inicial