Identificar e solucionar problemas de fluxo de chamada MT-LR no AMF e problemas comuns de integração com LMF de terceiros, GMLC

Introdução

Este documento descreve a funcionalidade, integração e solução de problemas da AMF Mobile-Terminated Location Request (MT-LR) para engenheiros de rede.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento da funcionalidade do Access and Mobility Management Function (AMF)

Componentes Utilizados

As informações neste documento estão relacionadas ao Cisco AMF, que é o AMF na rede central 5G.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

Os serviços de localização são fundamentais nas redes móveis modernas, não apenas para a experiência do usuário, mas também para requisitos regulamentares críticos, como chamadas de emergência e interceptações legais. No núcleo 5G, o AMF desempenha um papel fundamental no tratamento dessas solicitações de localização.

O que é a solicitação de local com terminação móvel (MT-LR)?

O AMF suporta vários tipos de solicitações de localização, incluindo Network Induced Location Request (NI-LR) e MT-LR.

O MT-LR é iniciado quando uma entidade externa, normalmente o Gateway Mobile Location Center (GMLC), solicita a localização de um equipamento de usuário (UE). O GMLC encaminha esse pedido para o AMF, que então se coordena com a Location Management Function (LMF) para determinar a localização precisa do equipamento do usuário. Uma vez identificada, a informação de localização é enviada de volta ao GMLC.

O AMF pode fornecer o "local atual" ou o "local atual ou último local conhecido" para MT-LRs, oferecendo flexibilidade com base na urgência e no estado de atividade do equipamento do usuário.

Principais pontos de contato de integração para MT-LR

Para o processo MT-LR, o AMF comunica-se principalmente com:

• GMLC: Inicia a solicitação de localização.
• LMF: determina a localização do equipamento do usuário.
• gNB: Estação de base 5G, envolvida no posicionamento dos equipamentos do utilizador.

Desafios de fluxo de chamadas e integração do MT-LR

O processo MT-LR envolve três intercâmbios principais entre a AMF, a GMLC e a LMF:

1. Posicionamento do Information Request Exchange (GMLC para AMF)
2. Determinar Solicitação de Local (AMF para LMF)
3. Posicionamento do equipamento do usuário (LMF via AMF para gNB/UE e vice-versa)

A explicação dessas três etapas e os desafios comuns de integração são explicados aqui.

1. Solicitação de Informações de Posicionamento: GMLC para AMF

O processo MT-LR começa quando o GMLC envia um ProvidePosInfoRequest para o AMF. Essa solicitação é crucial, pois inicia toda a sequência de determinação do local. Em seguida, o AMF se coordena com outras funções de rede, como o LMF, para recuperar o local do equipamento do usuário.

Foco da solução de problemas: Identificador UE em ProvidePosInfoRequest

Um problema de integração comum surge com o identificador UE usado em ProvidePosInfoRequest (especificamente, Namf_Location ProvidePositioningInfo).

• Requisito de Especificação: Historicamente, as especificações 3GPP (TS 23.271, TS 23.273) determinavam o uso de SUPI (IMSI) como o identificador primário para solicitações de localização no sistema 5G. Espera-se que o ueContextId no URI do recurso {apiRoot}/namf-loc/<apiVersion>/{ueContextId} seja semelhante em padrões como imsi-XXXX ou imei-XXXX.
• Problema comum: os GMLCs podem enviar incorretamente um MSISDN simples em vez de um SUPI (IMSI) ou PEI (IMEI) no ueContextId ou dentro do corpo da solicitação. O AMF não consegue decodificar e validar a mensagem corretamente nesses casos.
• Resolução/Evolução: Na versão 18.6.0 das especificações 3GPP (29.518), o serviço AMF foi atualizado para aceitar o Generic Public Subscription Identifier (GPSI), que inclui o MSISDN, como parte da Solicitação de Localização. Isso é particularmente importante para localizar roamers de entrada usando seu MSISDN.

2. Determinar Solicitação de Local: AMF para LMF

Após uma ProvidePosInfoRequest bem-sucedida, o AMF envia um Namf_Location DetermineLocationRequest para o LMF. Essa solicitação contém informações essenciais, como AMFID, correlationId, NCGI, PEI, SUPI e ueConnectivityStates, para auxiliar o LMF a determinar a localização do equipamento do usuário.

3. Posicionamento UE: LMF via AMF para gNB/UE

Depois que o LMF processa DetermineLocationRequest, ele inicia o procedimento de posicionamento UE. O LMF envia uma mensagem N1/N2 para o AMF, que atua como um encaminhador para o gNB (N2) ou diretamente para o UE (N1). O FAM recebe então a informação de localização do gNB/UE e partilha-a com o FMM.

Este mecanismo de encaminhamento é crítico:

• NRPPa-PDU: A carga útil central que contém instruções de posicionamento ou solicitações de medição é o Novo Protocolo de Posicionamento de Rádio A (NRPPa-PDU).
• Encapsulamento: o NRPPa-PDU é encapsulado dentro de um contêiner N2.
• Função do AMF: o AMF recebe esse contêiner N2 do LMF e constrói uma mensagem downlinkUEAssociatedNRPPaTransport para enviar ao gNB (conforme detalhado nas especificações 38.413 do NGAP).
• Contexto de API: A comunicação usa a operação de serviço Transferência de Mensagem (Específico UE) Namf_Communication N1N2 (por exemplo, /ue-contexts/{ueContextId}/n1-n2-messages). O corpo da solicitação é N1N2MessageTransferReqData.

Foco da solução de problemas: Formato de transferência do contêiner N1/N2

Um desafio significativo de integração envolve o formato da mensagem para transferir contêineres N1/N2:

• Formato esperado: de acordo com as especificações, o N1N2MessageTransferReqData (que inclui o contêiner N2 com o NRPPa-PDU) deve ser idealmente enviado como uma mensagem multiparte/relacionada. Esse formato permite dados JSON e partes binárias (como o contêiner N2).
• Problema comum: apesar da presença do contêiner N2, os registros AMF devem mostrar erros como:

"amf-rest-ep-1 [ERRO] [common_validation.go:288] [amf-rest-ep.amf-app.smf] NÃO Recebeu a IE Obrigatória: Contêiner N1 / N2 não recebido".

Isso geralmente ocorre porque o LMF não está transferindo o corpo da solicitação como multiparte/relacionado, mas usa um formato incorreto (por exemplo, dados de texto baseados em linha). O AMF não consegue decodificar e validar a mensagem corretamente.

• Resolução: certifique-se de que o LMF formate corretamente o N1N2MessageTransferReqData como uma mensagem HTTP multiparte/relacionada, aderindo às especificações 3GPP.

Foco da solução de problemas: ID de correlação do LCS

A ID de correlação do LCS é um identificador exclusivo usado para vincular e rastrear todas as mensagens e procedimentos relacionados a uma única sessão de Location Services (LCS) (como um MT-LR) em diferentes funções de rede (AMF, LMF, gNB). Ele garante o contexto apropriado para o posicionamento das solicitações.

• Especificação: o ID de correlação do LCS é aplicado ao transferir mensagens N1 e/ou N2 específicas do UE relacionadas ao LCS para o ueContextId. Ele é definido no URI (cid em /ue-contexts/{ueContextId}/n1-n2-messages) e como um IE JSON (lcsCorrelationId) dentro do corpo.
• Problema comum: se o LMF enviar um ID de correlação LCS incorreto, o AMF não processará, levando a erros como:

"[ERROR] [amf-service.amf-app.n1n2] ID de correlação de LCS inválida".

• Resolução: o AMF envia a ID de correlação do LCS inicial e espera-se que o LMF defina sua ID de sessão com esse valor. Essa mesma ID de correlação deve ser usada consistentemente em todas as interfaces (AMF para LMF, AMF para gNB) como um identificador de roteamento. Verifique se o LMF está recebendo corretamente e reutilizando o ID de correlação do LCS fornecido pelo AMF.

Conclusão

O recurso MT-LR no 5G AMF é crucial para serviços de localização. Embora o fluxo de chamadas subjacente seja padronizado, a integração e a operação bem-sucedidas dependem muito da adesão estrita às especificações 3GPP, especialmente no que diz respeito aos identificadores UE, formatação de mensagens para contêineres N1/N2 e uso consistente da ID de correlação do LCS.

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	04-May-2026	Versão inicial