Dépanner une valeur incorrecte dans le champ du premier octet de l'ULI dans le CDR PGW pour les abonnés 4G

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.