Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Abréviations

Problème

Dépannage

Informations sur l'emplacement de l'utilisateur

Identifier le type d'emplacement à partir d'ULI

Résolution

Introduction

Ce document décrit comment résoudre le problème des valeurs erronées dans le premier octet du champ User Location Information (ULI) de PDN-Gateway (PGW).

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- StarOS

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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.

Abréviations

APN

Nom du point d'accès

CDR

Enregistrement détaillé des appels

CGI

Identificateur global de la cellule

ECGI

CGI EUTRAN

UTRAN ÉLECTRONIQUE

Évoluer UTRAN

LSB

Bit le moins significatif

MSB

Bit le plus significatif

PDN

Réseau de données de paquets

PGW

Passerelle PDN

RA

Assurance du chiffre d'affaires

RAI

Identité de la zone de routage

SAI

Identificateur de zone de service

TAI

Identité de la zone de suivi

ULI

Informations sur l'emplacement de l'utilisateur

UTRAN

Système universel de télécommunications mobiles

Problème

Le fournisseur de services a soulevé ce problème avec préoccupation au sujet du mauvais traitement des CDR PGW pour certains abonnés 4G. Les CDR des abonnés problématiques avaient des valeurs erronées dans le tout premier octate du champ ULI.

Non-Problematic

==============

userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x

Problematic

===========

userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x

Ici, les deux premiers chiffres de l'octet un sur le champ ULI, les valeurs sont vues comme 82« au lieu de 18.

En raison de cette impression incorrecte dans les CDR, l'équipe d'évaluation du fournisseur de services n'a pas pu identifier le type de localisation des utilisateurs, qu'ils soient de type e-UTRAN(4G) ou GERAN/UTRAN(2G/3G), ce qui a causé des problèmes de chargement incorrects.

Dépannage

Le fournisseur de services est un opérateur mobile qui fournit des services sans fil mobiles aux utilisateurs finaux auxquels il appelle les abonnés mobiles.

Informations sur l'emplacement de l'utilisateur

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.

Conformément à la section 8.21 de 3GPP 29.274v12, l'ULI est codé comme suit :

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.

Identifier le type d'emplacement à partir d'ULI

Comme indiqué dans l'image précédente, le champ 5e octet d'ULI représente le type d'emplacement.

Chaque octet représente deux quarts, avec la même logique, le 5e octet a deux quarts, c'est-à-dire des plages de quarts-1 allant du bit-8 au bit-5 et de quarts-2 allant du bit-4 au bit-1.

Par conséquent, chaque fois que l'indicateur correspondant dans ces quarts dans le jeu 1, considérez les informations relatives au type d'emplacement présentes dans les champs correspondants suivants de l'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

Ainsi, selon cette image, pour les abonnés 4G ayant des informations ECGI dans CDR devrait représenter la valeur 18 au début du champ ULI. (Mais selon le problème signalé par vous, Cisco PGW imprime la valeur 82 dans les CDR PGW, ce qui est faux selon la réclamation de l'équipe RA.)

Des exemples de traces de PGW (sur GTPv2) confirment que ces valeurs proviennent de l'interface 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

Dans l'exemple précédent, la représentation hexadécimale des champs ULI marqués en vert gras (18) est la valeur des deux premiers quarts du 5e octet.

Et dans ce cas, PGW CDR imprime également les valeurs appropriées de l'ULI dans CDR (imprimé en sortie CDR sur 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

Résolution

En cas de problème, des valeurs similaires dans le champ Créer une demande de session (CSReq) sont affichées, qui est imprimée dans le suivi PGW, mais la sortie dans le champ CDR pour ULI ne reflète pas correctement l'emplacement. Voici la sortie :

<< ULI seen in CDR >> - - - Problematic scenario

userLocationInformation              123-456-1-8547

La sortie précédente crée un doute.

Une fois la configuration vérifiée à l'intérieur du groupe gtpp pour les utilisateurs APN affectés, le dictionnaire gtpp est mappé comme personnalisé33

gtpp group <name-default>

- -

gtpp dictionary custom33               - - - > dictionary mapped to this group

- -

#exit

Selon la recommandation, pour les champs CDR des abonnés 4G, le fournisseur de services doit utiliser un dictionnaire approprié qui contient tous les champs pour 4G. La valeur du dictionnaire de custom33 à custom24 a demandé à être modifiée.

gtpp group <name-default>

- -

gtpp dictionary custom24               - - - > New dictionary mapped to this group

- -

#exit

Une fois que le type de dictionnaire précédent dans le groupe gtpp a été modifié, votre équipe d'évaluation peut décoder correctement les champs ULI et le problème est résolu.