Risoluzione dei problemi relativi al valore errato nel primo ottetto del campo ULI in PGW CDR per gli abbonati 4G
Sommario
Introduzione
In questo documento viene descritto come risolvere il problema dei valori errati nel primo ottetto del campo User Location Information (ULI) in PDN-Gateway (PGW).
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- StarOS
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware.
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.
Abbreviazioni
| APN | Nome Access Point |
| CDR | Record dettagli chiamata |
| CGI | Identificatore globale cella |
| ECGI | EUTRAN CGI |
| E-UTRAN | Evolve UTRAN |
| LSB | Bit meno significativo |
| MSB | Bit più significativo |
| PDN | Packet Data Network |
| PGW | PDN Gateway |
| RA | Assicurazione ricavi |
| RAI | Identità area di routing |
| SAI | Identificatore area di assistenza |
| TAI | Identità area di rilevamento |
| ULI | Informazioni sulla posizione dell'utente |
| UTRAN | Sistema universale di telecomunicazioni mobili |
Problema
Il provider di servizi ha sollevato il problema con preoccupazione in merito all'elaborazione errata dei CDR PGW per alcuni abbonati 4G. I CDR degli abbonati problematici contenevano valori errati nel primo ottato del campo ULI.
Non-Problematic ============== userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x Problematic =========== userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x
Qui, le prime due cifre dell'ottetto uno sul campo ULI, i valori sono visti stampati come 82"invece di 18.
A causa di questa stampa errata nei CDR, il team RA del provider di servizi non è stato in grado di identificare il tipo di ubicazione degli utenti, che si tratti di e-UTRAN(4G) o GERAN/UTRAN(2G/3G), causando problemi di carica errati.
Risoluzione dei problemi
Provider di servizi è qualsiasi operatore di telefonia mobile che fornisce servizi Mobile Wireless agli utenti finali a cui chiamano abbonati Mobile.
Informazioni sulla posizione dell'utente
This field contains the User Location Information of the MS as defined in TS 29.060 for GPRS case, and in TS 29.274 for EPC case (e.g. CGI, SAI, RAI TAI and ECGI), if available.
This field is provided by the SGSN/MME and transferred to the S-GW/P-GW during the IP-CAN bearer activation/modification. User Location Information contains the location (e.g. CGI/SAI, ECGI/TAI or RAI) where the UE is located while opening the respective CDR.
The flags ECGI, TAI, RAI, SAI and CGI in octet 5 indicate if the corresponding fields are present in the IE or not. If one of these flags is set to "0", the corresponding field is not present at all.
Come indicato nella sezione 8.21 del 3GPP 29.274v12, l'ULI è codificato come segue:
This IE shall contain only one identity of the same type (for example, more than one CGI cannot be included), but ULI IE may contain more than one identity of a different type (e.g. ECGI and TAI). The flags LAI, ECGI, TAI, RAI, SAI and CGI in octet 5 indicate if the corresponding type shall be present in a respective field or not.
If one of these flags is set to "0", the corresponding field shall not be present at all.
If more than one identity of different type is present, then they shall be sorted in the following order: CGI, SAI, RAI, TAI, ECGI, LAI.
Identificare il tipo di ubicazione da ULI
Come nell'immagine precedente, il campo 5° ottetto di ULI rappresenta il tipo di posizione.
Ogni ottetto rappresenta due nibble, con la stessa logica, il 5º ottetto ha due nibble, cioè nibble-1 va da bit-8 a bit-5 e nibble-2 va da bit-4 a bit-1.
Di conseguenza, ogni volta che il rispettivo flag in questi nibble nel set 1, considera le informazioni relative al tipo di posizione presenti nei successivi campi corrispondenti di ULI.
For example (for octet 5):
When 1st bit of nibble-1 (LSB) is set "1" in 5th Octet, it should reflect ECGI information in respective octet (e to e+6)
When 4th bit of nibble-2 (MSB) is set "1" in 5th Octet, it should reflect TAI information in respective octet (d to d+4)
See the pictorial representation in Figure-2
In base a questa immagine, per gli abbonati 4G che dispongono di informazioni ECGI in CDR, il valore dovrebbe essere 18 all'inizio del campo ULI. (Tuttavia, in base al problema segnalato dall'utente, Cisco PGW stampa il valore 82 nei record di registrazione dettagli chiamata PGW, che è errato in base all'affermazione del team RA.)
Tracce di esempio da PGW (su GTPv2) confermano che questi valori provengono dall'interfaccia S5.
<< ULI seen in CSReq>>
USER LOCATION INFO:
Type: 86 Length: 13 Inst: 0
Value:
Location type: TAI
MCC: 123
MNC: 456
TAC: 0x1
Location type: ECGI
MCC: 123
MNC: 456
ECI: 0x0000001
Hex: 5600 0D00 1821 6354 0001 2163 5400 0000
01
Nell'esempio precedente, la rappresentazione esadecimale dei campi ULI contrassegnati in grassetto verde (18) è il valore dei primi due nibble del quinto ottetto.
E in questo caso, i valori appropriati di ULI vengono stampati anche in CDR (stampato in output CDR su PGW)
<< ULI seen in CDR >> - - - Non-Problematic scenario
userLocationInformation
Location Type TAI
MCC 123
MNC 456
TAC 0x1
Location Type ECGI
MCC 123
MNC 456
ECI 0x0000001
Risoluzione
In caso di problemi, vengono visualizzati valori simili in Crea richiesta sessione (CSReq), che vengono stampati nella traccia PGW, ma l'output in CDR per il campo ULI non riflette correttamente la posizione. Al contrario, questo è l'output:
<< ULI seen in CDR >> - - - Problematic scenario userLocationInformation 123-456-1-8547
L'output precedente crea un dubbio.
Dopo aver controllato la configurazione dall'interno del gruppo gtpp per gli utenti APN interessati, si rileva che il dizionario gtpp è mappato come custom33
gtpp group <name-default>
- -
gtpp dictionary custom33 - - - > dictionary mapped to this group
- -
#exit
Come da raccomandazione, per i campi CDR degli abbonati 4G, il provider di servizi deve utilizzare un dizionario appropriato che contenga tutti i campi per 4G. Il valore del dizionario da custom33 a custom24 ha richiesto la modifica.
gtpp group <name-default>
- -
gtpp dictionary custom24 - - - > New dictionary mapped to this group
- -
#exit
Dopo aver modificato il tipo di dizionario precedente nel gruppo gtpp, il team di Autorità registrazione è in grado di decodificare correttamente i campi ULI e il problema viene risolto.
Feedback