Fehlerbehebung: Falscher Wert im ersten Oktett des ULI-Felds im PGW CDR für 4G-Abonnenten

Einführung

In diesem Dokument wird beschrieben, wie das Problem falscher Werte im ersten Oktett des Felds User Location Information (ULI) im PDN-Gateway (PGW) behoben wird. 

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• StarOS

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Abkürzungen

APN	Name des Access Points
CDR	Datensatz für Anrufdetails
CGI	Globale Zellenkennung
ECGI	EUTRAN CGI
E-UTRAN	UTRAN ausbauen
LSB	Geringstes Bit
MSB	Wichtigstes Bit
PDN	Paketdatennetzwerk
PGW	PDN-Gateway
RA	Umsatzsicherung
RAI	Routing Area-Identität
SAI	Service Area Identifier
TAI	Tracking Area-Identität
ULI	Informationen zum Standort des Benutzers
UTRAN	Universelles mobiles Telekommunikationssystem

Problem

Der Service Provider hat dieses Problem mit Bedenken bezüglich der falschen Verarbeitung von PGW-CDRs für einige 4G-Abonnenten angesprochen. Die problematischen CDRs der Teilnehmer hatten falsche Werte im ersten Oktat des ULI-Felds in ihnen.

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

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

Hier, die ersten beiden Stellen des Oktetts eins auf dem ULI-Feld, werden die Werte als 82"anstelle von 18 gedruckt.

Aufgrund dieses falschen Drucks in CDRs konnte das RA-Team des Service Providers den Standort des Benutzers nicht ermitteln, ob es sich um e-UTRAN(4G) oder GERAN/UTRAN(2G/3G) handelte, die zu falschen Gebührenproblemen führten.

Fehlerbehebung

Service Provider sind alle Mobilfunkanbieter, die Mobilfunk-Dienste für Endbenutzer bereitstellen, an die sie Mobilfunkteilnehmer anrufen.

Informationen zum Standort des Benutzers

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.

Gemäß 3GPP 29.274v12, Abschnitt 8.21, wird das ULI wie folgt codiert:

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. 

Identifizieren des Standorttyps vom ULI

Wie im vorhergehenden Bild, stellt das 5. Oktett des ULI-Felds den Standorttyp dar.

Jedes Oktett repräsentiert zwei Nibel, mit der gleichen Logik, 5. Oktett hat zwei nibbles, das ist nibble-1 Bereich von bit-8 bis bit-5 und nibble-2 Bereich von bit-4 bis bit-1.

Wenn also die jeweilige Flagge in diesen Einstiegsfeldern in 1 angezeigt wird, berücksichtigen Sie die standortbezogenen Informationen, die in den nächsten übereinstimmenden Feldern des ULI vorhanden sind.

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

Entsprechend diesem Bild sollte für 4G-Abonnenten, die ECGI-Informationen in CDR haben, der Wert 18 am Anfang des ULI-Felds stehen. (Entsprechend dem von Ihnen gemeldeten Problem gibt das Cisco PGW den Wert 82 in den PGW-CDRs aus, was laut Aussage des RA-Teams falsch ist.)

Beispielspuren vom PGW (auf GTPv2) bestätigen, dass diese Werte von der S5-Schnittstelle stammen.

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

Im vorherigen Beispiel ist die Hex-Darstellung der mit Fett Grün (18) gekennzeichneten ULI-Felder der Wert der ersten beiden Klammern des 5. Oktetts.

In diesem Fall gibt der PGW-CDR auch die korrekten Werte für das ULI in CDR aus (gedruckt in CDR-Ausgabe auf dem 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

Auflösung

Im Problemfall werden ähnliche Werte in Create Session Request (CSReq) angezeigt, die in PGW-Trace gedruckt werden, aber die Ausgabe in CDR für ULI-Feld spiegelt den Location nicht richtig wider. Dies ist stattdessen die Ausgabe:

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

  userLocationInformation              123-456-1-8547

Die vorhergehende Ausgabe lässt Zweifel aufkommen.

Nachdem die Konfiguration innerhalb der gtpp-Gruppe für betroffene APN-Benutzer überprüft wurde, wird festgestellt, dass das gtpp-Wörterbuch als custom33 zugeordnet ist.

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

Entsprechend der Empfehlung sollte der Service Provider für 4G-Abonnenten-CDR-Felder ein geeignetes Wörterbuch verwenden, das alle Felder für 4G enthält. Der Wörterbuchwert von custom33 in custom24 soll geändert werden.

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

Nachdem der vorhergehende Wörterbuchtyp in der gtpp-Gruppe geändert wurde, kann Ihr RA-Team die ULI-Felder ordnungsgemäß entschlüsseln und das Problem wird behoben.