Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Abreviaturas

Problema

Troubleshoot

Información de ubicación del usuario

Identificar el tipo de ubicación de ULI

Resolución

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.