Solucione problemas do AVP Visited-Network-Identifier ausente na solicitação de notificação

Introdução

Este documento descreve como solucionar problemas do VNI ausente sob a mensagem "Notify request" entre MME e HSS sobre a interface S6a.

Pré-requisitos

Especificações técnicas 3GPP - 29.272, 29.229

 Solicitação de Comentários (RFC) - 6733

Requisitos

A Cisco recomenda que você tenha conhecimento do guia de administração do StarOS-Mobility Management Entity (MME).

Componentes Utilizados

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

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Overview

Notification Request and Answer (NOR/NOA) é uma das mensagens mais simples sobre a interface S6a/S6d. A ideia básica dessa mensagem é informar o Home Subscriber Server (HSS) sobre a alteração nas informações de Rede e Equipamento do Usuário.

O procedimento de notificação é usado entre o MME e o HSS, também entre o nó de suporte do GPRS de serviço (SGSN) e o HSS para notificar o HSS sobre:

• Atribuição/alteração/remoção de Gateway (GW) de Rede de Dados de Pacotes (PDN) para um Nome de Ponto de Acesso (APN)
• Quando uma atualização de local inter-MME não ocorre, mas o HSS precisa ser notificado sobre a necessidade de enviar um local de cancelamento para o SGSN atual.
• A UE (Entidade do Usuário) tem capacidade de memória disponível para receber uma ou mais mensagens curtas
• A UE tornou-se novamente acessível

Formato de mensagem de NOR-NOA

< Notify-Request> ::= < Diameter Header: 323, REQ, PXY, 16777251 >
                      < Session-Id >
                      [ Vendor-Specific-Application-Id ]
                      { Auth-Session-State }
                      { Origin-Host }
                      { Origin-Realm }
                       [ Destination-Host ]
                                                 { Destination-Realm }

                      { User-Name }
                    * [ Supported-Features ]
                      [ Terminal-Information ]
                      [ MIP6-Agent-Info ]
                      [ Visited-Network-Identifier ]
                      [ Context-Identifier ]
                      [Service-Selection]
                      [ Alert-Reason ]
                      [ UE-SRVCC-Capability ]
                      [ NOR-Flags ]
                   [Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ]
                    *[ AVP ]


< Notify-Answer> ::= < Diameter Header: 323, PXY, 16777251 >
                     < Session-Id >
                     [ Vendor-Specific-Application-Id ]
                     [ Result-Code ]
                     [ Experimental-Result ]
                     { Auth-Session-State }
                     { Origin-Host }
                     { Origin-Realm }
                     [ OC-Supported-Features ]
                     [ OC-OLR ]
                    *[ Supported-Features ]
                    *[ AVP ]
                    *[ Failed-AVP ]

Processo

1. Início: O processo é normalmente iniciado pelo MME quando ocorre um evento relevante relacionado com a UE.
2. Mensagem NOR: O MME envia uma mensagem NOR ao HSS. Esta mensagem inclui os identificadores necessários, como a International Mobile Subscriber Identity (IMSI) e detalhes do evento ou alteração.
3. Processamento por HSS: O HSS processa a solicitação, atualiza seus registros e pode executar outras ações conforme necessário com base nas informações recebidas.
4. Notificar resposta: O HSS envia uma Notify Response de volta ao MME, confirmando a atualização e incluindo quaisquer dados ou instruções adicionais necessários.

Qual é a função do identificador de rede visitado AVP?

O Par de Valores de Atributos (AVP) do Identificador de Rede Visitado (VNI) é do tipo Cadeia de Caracteres de Octeto. Este AVP contém um identificador que ajuda a rede doméstica a identificar a rede visitada (por exemplo, o nome de domínio da rede visitada).

O VNI AVP serve para identificar a rede onde o usuário está localizado atualmente, ou "visitando", e é usado principalmente em cenários de roaming. Essas informações são cruciais para:

• Decisões de roteamento: Garantir que as solicitações e respostas sejam roteadas corretamente entre a rede residencial e a rede visitada.
• Aplicação de políticas: Aplicação de políticas de rede e regras de tarifação apropriadas com base na localização do usuário e nos acordos da rede visitada com a rede doméstica.

referência 3gpp para Visited-Network-Identifier AVP

Fluxo de chamada

NOR call-flow

Fluxo de chamada de solicitação de notificação/resposta

1. Disparador de Evento no MME

• Ocorre um evento de assinante no MME que exige a notificação do HSS. Por exemplo:
• Uma atualização de local
• Uma alteração na rede visitada (por exemplo, roaming)
• Uma atualização de status de assinatura (por exemplo, ativa ou inativa)
• O MME prepara uma mensagem NOR

2. MME envia Notify-Request

• O MME constrói a mensagem NOR com estes AVPs chave:
  • Contém o nome de domínio da ID da Rede Móvel Terrestre Pública (PLMN) da rede visitada onde o assinante está localizado no momento.
• ID da sessão: Identificador exclusivo da sessão de Diâmetro
• Origem-Host e Origem-Território: Identifica o MME como remetente
• Destination-Host e Destination-Realm: Identifica o HSS como o destinatário
• IMSI (identificador de usuário): O identificador exclusivo do assinante
• VNI
• Auth-Session-State Indica se a sessão é stateful ou stateless

3. HSS recebe e processa solicitação de notificação

• O HSS processa o NOR e valida seus AVPs:
• Verifique o IMSI para localizar o registro do assinante.
• Valida o VNI para garantir que ele corresponda a uma rede conhecida e com suporte.
• Atualiza os dados do assinante para refletir a nova rede visitada ou o status.
• Se a validação for bem-sucedida, o HSS prepara uma resposta bem-sucedida.
• Se houver problemas (por exemplo, ausência de VNI), o HSS prepara uma resposta de erro.

4. HSS envia notificação de resposta (NOA)

• O HSS envia uma mensagem NOA para o MME:
  • DIAMETER_SUCCESS (2001): Indica processamento bem-sucedido
  • DIAMETER_INVALID_AVP_VALUE (5004): Se o VNI for inválido
  • DIAMETER_MISSING_AVP (5005): Se o VNI estiver ausente, mas for necessário
  • Contém o VNI AVP se ele causou a falha
• Código de resultado
• Falha no AVP (se aplicável)

5. O MME trata a notificação-resposta

• Ao receber o NOA:
• Se o Código de Resultado for bem-sucedido, o MME continuará suas operações
• Se um erro for indicado, o MME analisa o AVP com falha (se houver) para identificar o problema

Troubleshooting

• O aspecto principal é verificar se a 'solicitação de notificação' está 'habilitada' em todos os 'serviços HSS'. Você pode fazer o mesmo executando esta CLI:
  
  

******** show hss-peer-service service all *******

Service name                    : hss<>
Notify Request Message          : Enable
Service name                    : hss<>
Notify Request Message          : Enable

• Depois que isso for verificado, você poderá solicitar esses registros para fazer troubleshooting adicional do problema:
  
  

1. Request “config verbose”

2. Monitor Subscriber with all the required options:
       monitor subscriber <imsi>, along with 19,33,34,35,A,S,X,Y,+++

3. Debug logs:

       logging filter active facility diameter level debug
       logging filter active facility sessmgr level debug
       logging filter active facility mme-app level debug
       logging active
        no logging active // to deactivate


4. Logging monitor:

       configure
        logging monitor msid <imsi>
       exit

5. Request  syslogs which captures the issue.

Cenário Problemático

Pcap problemático

Nesta referência, a Captura de pacotes (PCAP), você pode ver o 'visited-network-Identifier' ausente em 'notify-answer'.

O pacote 190 é a 'Solicitação de notificação' e 191 é a 'Resposta de notificação'.

O código do resultado do diâmetro neste cenário é 'Diameter_Missing_AVP', post que você também pode ver o 'Failed AVP' que aponta para 'Visited-Network-Identifier' que por sua vez exibe 'data empty'.

Note: O AVP com Falha é um AVP Agrupado que fornece informações de depuração quando uma solicitação é rejeitada ou não é totalmente processada devido a um erro em um AVP específico.

Algumas razões para um Failed-AVP incluem:

· Um AVP que não é construído corretamente

· Um AVP não reconhecido ou não suportado

· Um valor AVP inválido

· Um AVP necessário ausente

· Um AVP que é explicitamente excluído

· Um AVP restrito a 0, 1 ou 0-1 ocorrências, mas há duas ou mais ocorrências

Para fazer troubleshooting adicional do problema, você deve garantir que prossiga com todos os logs solicitados.

Como insistimos anteriormente, primeiro você deve verificar a configuração hss-peer-service do nó problemático.

Configuração de referência:

hss-peer-service <>
      diameter hss-endpoint <>
      no diameter update-dictionary-avps
      --- more lines ---
    exit

Nessa configuração, você pode ver que não havia 'no meter-dicionário-avps'. O problema era evidente quando não havia um dicionário de atualização mapeado para qualquer um dos lançamentos 3gpp. Além disso, você pode encontrar alguns cenários em que o 'diâmetro update-dictionary-avps 3gpp-r9/10' da CLI está presente e ainda assim o problema é evidente.

Portanto, ele foi atualizado para a versão mais recente de acordo com o guia de administração do StarOS para corrigir o problema, que é a versão 11.

Esta é a configuração de referência:

Mode

Exec > Global Configuration > Context Configuration > HSS Peer Service Configuration

configure > context context_name > hss-peer-service service_name

Entering the above command sequence results in the following prompt:

[context_name]host_name(config-hss-peer-service)#


Syntax

diameter update-dictionary-avps { 3gpp-r10 | 3gpp-r11 | 3gpp-r9 }

no diameter update-dictionary-avps

no

Sets the command to the default value where Release 8 ('standard') dictionary is used for backward compatibility of previous releases.

3gpp-r10

Configures the MME /SGSN to signal additional AVPs to HSS in support of Release 10 of 3GPP 29.272.

3gpp-r11

Configures the MME /SGSN to signal additional AVPs to HSS in support of Release 11 of 3GPP 29.272.

Using this keyword is necessary to enable the MME to fully support inclusion of the Additional Mobile Station ISDN (A-MSISDN) flag of the Feature List AVP in Update Location Request (ULR) messages sent over the S6a interface to the HSS at the time a UE Attaches. For more information about supporting A-MSISDN, refer to the information for the a-msisdn command in the Call-Control Profile configuration mode.

3gpp-r9

Configures the MME/SGSN to signal Release 9 AVPs to HSS.


Usage Guidelines

Use this command to configure the 3GPP release that should be supported for this HSS peer service.

This command is only applicable for the 'standard' diameter dictionary as defined in the diameter hss-dictionary command.