Troubleshoot Wrong Value in First Octet of ULI Field in PGW CDR for 4G Subscribers

Introduction

This document describes how to troubleshoot the problem of wrong values in the first octet of the User Location Information (ULI) field in PDN-Gateway (PGW). 

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

• StarOS

Components Used

This document is not restricted to specific software and hardware versions.

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. If your network is live, ensure that you understand the potential impact of any command.

Abbreviations

Problem

Service Provider raised this issue with concern about the wrong processing of PGW CDRs for some 4G subscribers. The problematic subscriber CDRs were having wrong values in very first octate of ULI field in them.

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

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

Here, the 1st two digits of octet one on ULI field, the values are seen printed as 82"instead of 18.

Because of this wrong printing in CDRs, Service Provider's RA team was unable to identify the users' Location type whether they were of e-UTRAN(4G) or GERAN/UTRAN(2G/3G) causing wrong charging issues.

Troubleshoot

Service Provider is any mobile operator that provides Mobile Wireless services to end users to whom they call Mobile subscribers.

User Location Information

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.

As per 3GPP 29.274v12 section 8.21, the ULI is coded as:

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. 

Identify the Location Type from ULI

As per the preceding image, the 5th Octet of ULI field represents the location type.

Each octet represents two nibbles, with the same logic, 5th Octet has two nibbles, that is nibble-1 ranges from bit-8 to bit-5 and nibble-2 ranges from bit-4 to bit-1.

Accordingly, whenever the respective flag in these nibbles in set 1, consider the location type related information present in the next matching fields of 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

So, as per this image, for 4G subscribers having ECGI information in CDR should represent value 18 at the beginning of the ULI field. (But as per the issue reported by you, Cisco PGW prints the value 82 in PGW CDRs, which is wrong as per RA team's claim.)

Sample traces from PGW (on GTPv2) confirms these values are from the S5 interface.

<< 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 the preceding example, the Hex representation of ULI fields marked in Bold Green (18) is the value of the first two nibbles of the 5th octet.

And in this case, PGW CDR also prints proper values of ULI in CDR (printed in CDR output taken on 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

Resolution

In case of a problem, similar values in Create Session Request (CSReq) are seen, which gets printed in PGW trace, but the output in CDR for ULI field does not properly reflect the Location. Instead, this is the output:

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

  userLocationInformation              123-456-1-8547

The preceding output creates a doubt.

After the configuration is checked from inside the gtpp group for affected APN users, it is found that the gtpp dictionary mapped as custom33

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

As per recommendation, for 4G subscribers CDR fields, Service Provider should use an appropriate dictionary that contains all field for 4G. The dictionary value from custom33 to custom24 requested to be changed.

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

After the preceding dictionary type in gtpp group is changed, your RA team is able to decode the ULI fields properly and the issue is resolved.