Risoluzione dei problemi relativi al flusso di chiamate MT-LR in AMF e problemi comuni di integrazione con LMF, GMLC di terze parti

Introduzione

Questo documento descrive la funzionalità, l'integrazione e la risoluzione dei problemi di AMF Mobile-Terminated Location Request (MT-LR) per i tecnici di rete.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza delle funzionalità di Access and Mobility Management Function (AMF)

Componenti usati

Le informazioni di questo documento sono in relazione con Cisco AMF che è l'AMF nella rete principale 5G.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

I servizi di posizione sono fondamentali nelle moderne reti mobili, non solo per l'esperienza dell'utente, ma anche per i requisiti normativi critici come le chiamate di emergenza e le intercettazioni legali. Nel core 5G, l'AMF svolge un ruolo fondamentale nella gestione di queste richieste di ubicazione.

Cos'è la richiesta di località terminata dal dispositivo mobile (MT-LR)?

L'AMF supporta vari tipi di richieste di ubicazione, tra cui la richiesta di ubicazione indotta dalla rete (NI-LR) e la MT-LR.

MT-LR viene avviato quando un'entità esterna, in genere il Gateway Mobile Location Center (GMLC), richiede la posizione di un'apparecchiatura utente (UE). Il GMLC inoltra questa richiesta all'AMF, che si coordina quindi con la funzione LMF (Location Management Function) per determinare la posizione esatta dell'apparecchiatura utente. Una volta identificate, le informazioni sulla posizione vengono rinviate alla GMLC.

L'AMF può fornire la "posizione corrente" o la "posizione corrente o l'ultima posizione conosciuta" per le MT-LR, offrendo flessibilità in base all'urgenza e allo stato di attività delle apparecchiature utente.

Touchpoint di integrazione dei tasti per MT-LR

Per il processo MT-LR, l'AMF comunica principalmente con:

• GMLC: avvia la richiesta di posizione.
• LMF: determina la posizione dell'apparecchiatura utente.
• gNB: Stazione base 5G, coinvolta nel posizionamento delle apparecchiature utente.

Sfide di flusso e integrazione delle chiamate MT-LR

Il processo MT-LR comporta tre importanti scambi tra AMF, GMLC e LMF:

1. Positioning Information Request Exchange (da GMLC ad AMF)
2. Determina richiesta ubicazione (da AMF a LMF)
3. Posizionamento dell'apparecchiatura utente (LMF via AMF a gNB/UE e retro)

In questa sezione vengono illustrati i motivi di queste tre fasi e le sfide comuni in materia di integrazione.

1. Richiesta di informazioni sul posizionamento: GMLC to AMF

Il processo MT-LR inizia quando il GMLC invia una ProvidePosInfoRequest all'AMF. Questa richiesta è fondamentale in quanto avvia l'intera sequenza di determinazione della posizione. L'AMF si coordina quindi con altre funzioni di rete, come l'LMF, per recuperare la posizione dell'apparecchiatura utente.

Focus sulla risoluzione dei problemi: Identificatore UE in ProvidePosInfoRequest

Un problema di integrazione comune si verifica con l'identificatore UE utilizzato in ProvidePosInfoRequest (in particolare, Namf_Location ProvidePositioningInfo).

• Requisito della specifica: in passato, le specifiche 3GPP (TS 23.271, TS 23.273) imponevano l'uso di SUPI (IMSI) come identificatore primario per le richieste di ubicazione nel sistema 5G. L'elemento ueContextId nell'URI di risorsa {apiRoot}/namf-loc/<apiVersion>/{ueContextId} dovrebbe essere simile in modelli come imsi-XXXX o imei-XXXX.
• Problema comune: i GMLC possono inviare in modo non corretto un MSISDN semplice anziché un SUPI (IMSI) o un PEI (IMEI) in ueContextId o nel corpo della richiesta. In questi casi, l'AMF non è in grado di decodificare e convalidare correttamente il messaggio.
• Risoluzione/evoluzione: nella release 18.6.0 delle specifiche 3GPP (29.518), il servizio AMF è stato aggiornato per accettare GPSI (Generic Public Subscription Identifier), che include MSISDN, come parte della richiesta di posizione. Ciò è particolarmente importante per individuare i router in ingresso che utilizzano la MSISDN.

2. Determinare la richiesta di ubicazione: da AMF a LMF

Dopo aver inserito una ProvidePosInfoRequest, l'AMF invia una Namf_Location DetermineLocationRequest all'LMF. Questa richiesta contiene informazioni essenziali come AMFID, correlationId, NCGI, PEI, SUPI e ueConnectivityStates per aiutare l'LMF a determinare la posizione dell'apparecchiatura utente.

3. Posizionamento UE: LMF tramite AMF su gNB/UE

Dopo l'elaborazione di DetermineLocationRequest da parte di LMF, viene avviata la procedura di posizionamento UE. L'LMF invia un messaggio N1/N2 all'AMF, che agisce da mittente per la gNB (N2) o direttamente all'UE (N1). L'AMF riceve quindi le informazioni sull'ubicazione dalla gNB/UE e le condivide con l'LMF.

Questo meccanismo di inoltro è fondamentale:

• NRPPa-PDU: Il payload principale contenente le istruzioni di posizionamento o le richieste di misurazione è il nuovo protocollo di posizionamento radio A (NRPPa-PDU).
• Incapsulamento: la NRPPa-PDU è incapsulata in un contenitore N2.
• Ruolo di AMF: l'AMF riceve questo contenitore N2 dall'LMF e realizza un messaggio downlinkUEAssociatedNRPPaTransport da inviare all'gNB (come descritto in NGAP specs 38.413).
• Contesto API: la comunicazione utilizza l'operazione del servizio Trasferimento messaggi N1N2 (specifico per l'UE) Namf_Communication, ad esempio /ue-context/{ueContextId}/n1-n2-messages. Il corpo della richiesta è N1N2MessageTransferReqData.

Focus sulla risoluzione dei problemi: Formato trasferimento contenitore N1/N2

Una sfida importante per l'integrazione riguarda il formato del messaggio per il trasferimento dei container N1/N2:

• Formato previsto: in base alle specifiche, N1N2MessageTransferReqData (che include il contenitore N2 con NRPPa-PDU) deve essere inviato idealmente come messaggio correlato a più parti. Questo formato consente sia i dati JSON che le parti binarie (come il contenitore N2).
• Problema comune: nonostante il contenitore N2 sia presente, i registri AMF devono mostrare errori quali:

"amf-rest-ep-1 [ERROR] [common_validation.go:288] [amf-rest-ep.amf-app.smf] NON ha ricevuto l'IE obbligatorio: Contenitore N1 / N2 non ricevuto".

Ciò si verifica spesso perché LMF non trasferisce il corpo della richiesta come parte multipla o correlato, ma utilizza un formato non corretto, ad esempio dati di testo basati su righe. L'AMF non è in grado di decodificare e convalidare correttamente il messaggio.

• Risoluzione: verificare che LMF formatti correttamente N1N2MessageTransferReqData come messaggio HTTP multipart/correlato, rispettando le specifiche 3GPP.

Focus sulla risoluzione dei problemi: ID correlazione LCS

L'ID di correlazione LCS è un identificatore univoco utilizzato per collegare e tenere traccia di tutti i messaggi e di tutte le procedure relativi a una singola sessione LCS (Location Services) (come MT-LR) in diverse funzioni di rete (AMF, LMF, gNB). Garantisce un contesto adeguato per le richieste di posizionamento.

• Specifica: l'ID di correlazione LCS viene applicato quando si trasferiscono messaggi N1 e/o N2 specifici di LCS per l'ID di contesto utente. È definito sia nell'URI (cid nei messaggi /ue-context/{ueContextId}/n1-n2) che come elemento IE JSON (lcsCorrelationId) all'interno del corpo.
• Problema comune: se il modulo LMF invia un ID di correlazione LCS non corretto, l'AMF non riesce a elaborarlo, generando errori quali:

"[ERRORE] [amf-service.amf-app.n1n2] ID correlazione LCS non valido".

• Risoluzione: l'AMF invia l'ID di correlazione LCS iniziale e l'LMF deve impostare il proprio ID di sessione su questo valore. Lo stesso ID di correlazione deve quindi essere utilizzato in modo coerente in tutte le interfacce (da AMF a LMF, da AMF a gNB) come identificativo di routing. Verificare che l'LMF riceva e riutilizzi correttamente l'ID di correlazione LCS fornito dall'AMF.

Conclusioni

La funzione MT-LR nell'AMF 5G è fondamentale per i servizi di localizzazione. Sebbene il flusso di chiamate sottostante sia standardizzato, la riuscita dell'integrazione e del funzionamento dipendono in larga misura dalla rigida conformità alle specifiche 3GPP, in particolare per quanto riguarda gli identificatori UE, la formattazione dei messaggi per i contenitori N1/N2 e l'utilizzo coerente dell'ID di correlazione LCS.

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
1.0	04-May-2026	Versione iniziale