Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Abreviaturas

Problema

Troubleshoot

Informações de localização do usuário

Identificar o tipo de local da ULI

Resolução

Introduction

Este documento descreve como solucionar o problema de valores incorretos no primeiro octeto do campo User Location Information (ULI) no PDN-Gateway (PGW).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

- StarOS

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Abreviaturas

APN

Nome do ponto de acesso

CDR

Registro de detalhes de chamadas

CGI

Identificador global de célula

ECGI

EUTRAN CGI

E-UTRAN

Evolua para a UTRAN

LSB

Bit menos significativo

MSB

Bit mais significativo

PDN

Rede de dados de pacote

PGW

Gateway de PDN

RA

Garantia de receita

RAI

Identidade da área de roteamento

SAI

Identificador de área de serviço

TAI

Identidade da área de rastreamento

ULI

Informações de localização do usuário

UTRAN

Sistema Universal de Telecomunicações Móveis

Problema

O provedor de serviços levantou esse problema com preocupação sobre o processamento incorreto de CDRs PGW para alguns assinantes 4G. Os CDRs de assinante problemáticos estavam tendo valores errados no primeiro octeto do campo ULI.

Non-Problematic

==============

userLocationInformation 1804f4790x1x0xfx7x0x2x1x1x

Problematic

===========

userLocationInformation 8204f4790x2x0xfx7x0x4x2x0x

Aqui, os dois primeiros dígitos do octeto um no campo ULI, os valores são vistos como 82"em vez de 18.

Devido a essa impressão incorreta nos CDRs, a equipe do RA do provedor de serviços não pôde identificar o tipo de local dos usuários, seja de e-UTRAN(4G) ou GERAN/UTRAN(2G/3G), causando problemas de cobrança incorretos.

Troubleshoot

Provedor de serviços é qualquer operadora móvel que fornece serviços sem fio móveis para usuários finais aos quais eles ligam para assinantes móveis.

Informações de localização do usuário

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.

De acordo com a seção 8.21 do 3GPP 29.274v12, o ULI é 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 o tipo de local da ULI

De acordo com a imagem anterior, o campo 5º Octeto de ULI representa o tipo de local.

Cada octeto representa dois nibbles, com a mesma lógica, o 5º octeto tem dois nibbles, ou seja, o nibble-1 varia de bit-8 a bit-5 e o nibble-2 varia de bit-4 a bit-1.

Portanto, sempre que o respectivo sinalizador nesses nibbles na definição 1, considere as informações relacionadas com o tipo de localização presentes nos próximos campos correspondentes da 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

Assim, de acordo com essa imagem, para assinantes 4G que tenham informações ECGI no CDR devem representar o valor 18 no início do campo ULI. (Mas de acordo com o problema relatado por você, o Cisco PGW imprime o valor 82 em CDRs PGW, o que está errado de acordo com a reivindicação da equipe de RA.)

Exemplos de rastreamentos de PGW (em GTPv2) confirmam que esses valores são da interface 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

No exemplo anterior, a representação hexadecimal dos campos ULI marcados em verde em negrito (18) é o valor dos dois primeiros nibbles do 5º octeto.

Nesse caso, o CDR de PGW também imprime valores corretos de ULI no CDR (impresso na saída CDR tirada no 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

Resolução

Em caso de problema, valores semelhantes em Create Session Request (CSReq) são vistos, que é impresso no rastreamento PGW, mas a saída no campo CDR para ULI não reflete corretamente o Local. Em vez disso, esta é a saída:

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

userLocationInformation              123-456-1-8547

A saída anterior cria uma dúvida.

Depois que a configuração é verificada dentro do grupo gtpp para usuários APN afetados, descobriu-se que o dicionário gtpp mapeado como custom33

gtpp group <name-default>

- -

gtpp dictionary custom33               - - - > dictionary mapped to this group

- -

#exit

Conforme recomendação, para campos CDR de assinantes 4G, o provedor de serviços deve usar um dicionário apropriado que contenha todos os campos para 4G. O valor do dicionário de custom33 a custom24 solicitou a alteração.

gtpp group <name-default>

- -

gtpp dictionary custom24               - - - > New dictionary mapped to this group

- -

#exit

Depois que o tipo de dicionário anterior no grupo gtpp for alterado, sua equipe de RA poderá decodificar os campos de ULI corretamente e o problema será resolvido.