Probleemoplossing met fout waarde in eerste okt van ULI-veld in PGW CDR voor 4G-abonnees

Inleiding

Dit document beschrijft hoe u het probleem met verkeerde waarden in het eerste vak van het veld User Location Information (ULI) in PDN-gateway (PGW) kunt oplossen. 

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• StarOS

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Afkortingen

APN	Naam van access point
CDR	Call Detail-record
CGI	Geldelijke identificatie van cellen
ECGI	EUTRAN CGI
E-UTRAN	Evolve UTRAN
LSB	minste significante bit
MSB	Belangrijkste bit
PDN	Packet Data Network
PGW	PDN-gateway
RA	Inkomensgarantie
RAI	Routing Area Identity Services
SAI	Identificatie van servicegebied
TAI	Identificatie van het traceringsgebied
ULI	Informatie over gebruikerslocatie
UTRAN	Universele mobiele telecommunicatie-systeem

Probleem

Serviceprovider heeft deze kwestie met bezorgdheid naar voren gebracht over de verkeerde verwerking van PGW-CDR’s voor een aantal 4G-abonnees. De problematische CDR's van abonnees hadden foutieve waarden in de eerste fase van het ULI-veld in het ULI-veld.

Non-Problematic
==============
userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x

Problematic
===========
userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x

Hier worden de 1ste twee cijfers van octet één op ULI veld weergegeven als 82"in plaats van 18.

Vanwege deze verkeerde afdruk in CDR’s kon het RA-team van de serviceproviders het locatietype van de gebruikers niet identificeren, noch zij van e-UTRAN(4G) of van GERAN/UTRAN (2G/3G) waren, wat tot foutieve heffingskwesties leidde.

Problemen oplossen

Serviceprovider is een mobiele operator die mobiele draadloze services aanbiedt aan eindgebruikers die mobiele abonnees bellen.

Informatie over gebruikerslocatie

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.

Overeenkomstig rubriek 8.21 van 3GPP 29.274v12 wordt de ULI gecodeerd als:

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. 

Identificeer het type locatie van ULI

Overeenkomstig de bovenstaande afbeelding vertegenwoordigt het 5e octet van het ULI-veld het locatietype.

Elke octet vertegenwoordigt twee knabels, met dezelfde logica, heeft 5th Octet twee knabbels, dat is nibble-1 bereik van bit-8 tot bit-5 en nibble-2 bereik van bit-4 tot bit-1.

Daarom moet, telkens als de desbetreffende vlag in deze onderdelen in set 1 is, rekening worden gehouden met de locatietype-gerelateerde informatie die aanwezig is in de volgende matchingvelden van 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

Dus, zoals in deze afbeelding, zouden voor 4G-abonnees die ECGI informatie in CDR hebben waarde 18 moeten vertegenwoordigen aan het begin van het ULI-veld. (Maar zoals bij het door u gemelde probleem, drukt Cisco PGW de waarde 82 in PGW CDRs af, wat fout is in de claim van het RA team.)

Monster sporen van PGW (op GTPv2) bevestigen deze waarden van de S5 interface zijn.

<< 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

In het voorgaande voorbeeld is de Hex-weergave van ULI-velden die zijn gemarkeerd in Bold Green (18) de waarde van de eerste twee knabels van het 5e octet.

In dit geval drukt PGW CDR ook echte waarden van ULI in CDR af (afgedrukt in CDR-uitvoer op 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

Resolutie

In het geval van een probleem worden soortgelijke waarden in Session Application (CSReq) gestart, die in PGW-sporen worden afgedrukt, maar de uitvoer in CDR voor ULI-veld geeft niet correct de locatie weer. In plaats daarvan, is dit de output:

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

  userLocationInformation              123-456-1-8547

De vorige productie wekt twijfel.

Nadat de configuratie vanuit de gtpp-groep is ingeschakeld voor getroffen APN-gebruikers, is gebleken dat het gtpp-woordenboek is toegewezen als op maat33

    gtpp group <name-default>
      - -
      gtpp dictionary custom33               - - - > dictionary mapped to this group
      - -
    #exit

Overeenkomstig de aanbeveling moet de serviceprovider voor 4G-abonnees in CDR-velden een geschikt woordenboek gebruiken dat alle veld voor 4G bevat. De woordenboekwaarde van Douane33 in douane24 verzocht om te worden gewijzigd.

    gtpp group <name-default>
      - -
      gtpp dictionary custom24               - - - > New dictionary mapped to this group
      - -
    #exit

Nadat het bovenstaande woordenboektype in de gtpp-groep is gewijzigd, kan uw RA-team de ULI-velden goed decoderen en is de kwestie opgelost.