Identificar e Solucionar Problemas de Valor Errado no Primeiro Octeto do Campo ULI em PGW CDR para Assinantes 4G

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.