Solución de problemas de valor incorrecto en el primer octeto del campo ULI en PGW CDR para suscriptores 4G

Introducción

Este documento describe cómo resolver el problema de valores erróneos en el primer octeto del campo User Location Information (ULI) en PDN-Gateway (PGW). 

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• StarOS

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Abreviaturas

APN	Nombre del punto de acceso
CDR	Registro de detalles de llamada
CGI	Identificador global de celda
ECGI	EUTRAN CGI
E-UTRAN	Evolución de UTRAN
LSB	Bit menos significativo
MSB	Bit más significativo
PDN	Red de datos de paquetes
PGW	Gateway PDN
RA	Garantía de ingresos
RAI	Identidad de área de routing
SAI	Identificador de área de servicio
TAI	Identidad de área de seguimiento
ULI	Información de ubicación del usuario
UTRAN	Sistema Universal de Telecomunicaciones Móviles

Problema

El proveedor de servicios planteó este problema con preocupación acerca del procesamiento incorrecto de los CDR PGW para algunos suscriptores 4G. Los CDR de suscriptores problemáticos tenían valores erróneos en el primer octato del campo ULI en ellos.

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

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

Aquí, los dos primeros dígitos del octeto uno en el campo ULI, los valores se ven impresos como 82"en lugar de 18.

Debido a esta impresión incorrecta en los CDR, el equipo de RA del proveedor de servicios no pudo identificar el tipo de ubicación del usuario si era de e-UTRAN(4G) o GERAN/UTRAN(2G/3G) lo que causaba problemas de carga incorrectos.

Troubleshoot

Proveedor de servicios es cualquier operador móvil que proporciona servicios inalámbricos móviles a los usuarios finales a los que llaman suscriptores móviles.

Información de ubicación del usuario

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.

Según la sección 8.21 de 3GPP 29.274v12, el ULI está codificado como:

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. 

Identificar el tipo de ubicación de ULI

Según la imagen anterior, el campo 5th Octet of ULI representa el tipo de ubicación.

Cada octeto representa dos nibbles, con la misma lógica, 5th Octet tiene dos nibbles, es decir, nibble-1 varía de bit-8 a bit-5 y nibble-2 varía de bit-4 a bit-1.

Por consiguiente, siempre que el indicador correspondiente de estos nibbles en el conjunto 1, considere la información relacionada con el tipo de ubicación presente en los siguientes campos coincidentes de 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

Por lo tanto, según esta imagen, para los suscriptores 4G que tengan información ECGI en CDR debe representar el valor 18 al principio del campo ULI. (Pero según el problema informado por usted, Cisco PGW imprime el valor 82 en los CDR de PGW, lo que es incorrecto según la reclamación del equipo de RA.)

Los seguimientos de ejemplo de PGW (en GTPv2) confirman que estos valores provienen de la interfaz 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

En el ejemplo anterior, la representación hexadecimal de los campos ULI marcados en Negrita Verde (18) es el valor de los dos primeros nibbles del quinto octeto.

Y en este caso, PGW CDR también imprime valores adecuados de ULI en CDR (impreso en la salida CDR tomada en 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

Resolución

En caso de problema, se ven valores similares en Create Session Request (CSReq), que se imprime en PGW trace, pero el resultado en CDR para el campo ULI no refleja correctamente la ubicación. En su lugar, éste es el resultado:

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

  userLocationInformation              123-456-1-8547

El resultado anterior crea una duda.

Después de verificar la configuración desde el interior del grupo gtpp para los usuarios APN afectados, se encuentra que el diccionario gtpp asignado como custom33

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

Según la recomendación, para los campos CDR de suscriptores 4G, el proveedor de servicios debe utilizar un diccionario apropiado que contenga todos los campos para 4G. El valor del diccionario de custom33 a custom24 solicitó ser cambiado.

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

Después de cambiar el tipo de diccionario anterior en el grupo gtpp, su equipo de RA puede descodificar los campos ULI correctamente y el problema se resuelve.