Comportamento GGSN com falhas de ativação PDP e sem respostas de eco GTP

Introduction

Este documento descreve o comportamento do Gateway General Packet Radio Service (GPRS) Supporting Node (GGSN) quando o Serving GPRS Support Node (SGSN) não responde à solicitação de eco GPRS Tunneling Protocol (GTP) enviada do GGSN.

Informações de Apoio

Você pode experimentar falhas de ativação do protocolo de dados de pacote (PDP - Packet Data Protocol) no GGSN durante um período em que o SGSN não responde às solicitações de eco de GTP. Aqui estão algumas questões que podem surgir neste cenário:

1. As solicitações Create PDP ou Update PDP do SGSN chegam ao GGSN?
   
   
2. Quando as solicitações de eco GTP falham do GGSN para os SGSNs, como o GGSN deve se comportar se o contexto Update PDP enviado do GGSN não receber uma resposta?
   
   
3. Como um GGSN falha em um PDP se ele não recebe uma resposta de eco GTP ou uma resposta para as mensagens de solicitação de não eco que chegam de um SGSN para esse PDP?
   
   
4. Como uma falta nas respostas de eco/não eco de GTP afeta diretamente as falhas de ativação de PDP?

Comportamento GGSN

Se as mensagens não chegarem ao GGSN, o SGSN dispara um alarme de falha de caminho e as descarta silenciosamente. Além disso, se não houver resposta de eco recebida para a solicitação de eco que é iniciada pela GGSN, ela indica que o peer está inativo, de modo que a GGSN limpa localmente as chamadas relacionadas a esse peer.

Na saída do comando show support details, ou na saída do comando show gtpc statistics verbose, você pode exibir os contadores de Tempo Limite de Solicitação de GGSN:

#show gtpc statistics verbose 

SGSN Restart:                       Timeout:
    Create PDP Req:                 5   GTPC Echo Timeout:          149160
    Update PDP Req:                 0   GTPU Echo Timeout:               0
    Echo Response:                312   GGSN Req Timeout:            24182

Path Management Messages:
  Echo Request RX:         34006780   Echo Response TX:         34006780
  Echo Request TX:         29603851   Echo Response RX:         29537123

Se você investigar as mensagens de echo request que são transferidas do GGSN para o SGSN, parece que o GGSN não recebe as respostas de echo. Você deve garantir que as mensagens não sejam descartadas devido a problemas de roteamento na rede ou que o SGSN não esteja disponível.

O problema mais comum são as falhas de caminho de controle, que fazem com que um grande número de SGSNs de roaming se tornem inalcançáveis.

Se houver alguma mensagem de controle GTP (como uma solicitação de contexto PDP de atualização) do GGSN que não receba uma resposta depois que todas as tentativas forem esgotadas, o GGSN acha que o peer está inacessível e apenas aquela sessão específica relata a causa como Falha de Caminho. O contexto PDP é excluído na GGSN, mas a SGSN não é notificada. Essa contagem é identificada com estas estatísticas:

SGSN Restart:                       Timeout:
    Create PDP Req:                 5   GTPC Echo Timeout:          149160
    Update PDP Req:                 0   GTPU Echo Timeout:               0
    Echo Response:                312   GGSN Req Timeout:            24182


Update PDP Context Denied:
  No Resources:                 500   No Memory:                       0
  System Failure:                 0   Non-existent:                55460

A GGSN agora derruba a sessão de contexto PDP e nunca notifica a SGSN ou o Equipamento de Usuário (UE). A SGSN ou UE pode disparar uma solicitação de contexto PDP de atualização, e a GGSN pode rejeitá-la com um Código de Causa 192 (inexistente).

Esta é uma seção retirada do TS 29.060:

• Se um Gprs Supporting Node (GSN) receber uma mensagem Gprs Tunneling Protocol-Control plane (GTP-C) solicitando ação relacionada a um contexto PDP que o nó emissor acredita que existe, mas que não é reconhecida pelo nó receptor, o nó receptor enviará de volta para a origem da mensagem, uma resposta com o valor de causa apropriado (não existente ou "Contexto não encontrado").  O identificador de ponto final do túnel utilizado na mensagem de resposta deve ser definido para todos os zeros.
• Se o SGSN receber uma Resposta de contexto PDP de atualização com um valor de Causa "Não existe", ele apagar o contexto PDP.

Erro de Código de Causa 192

Um código de causa 192 (ou inexistente) é um erro enviado pelos GSNs na interface Gn. Ele é preenchido no elemento de informação Causa de mensagens GTP.

Estas são as mensagens GTP que podem ter um erro de código de causa 192:

• Update_PDP_Context_Response
  
  
• Delete_PDP_Context_Response

Note: O TEID (Tunnel End Identifier) usado na mensagem que contém este erro será zero. Consulte o TS 29.060 para obter mais detalhes.

Esse erro pode aparecer nas mensagens acima quando é enviado por uma GSN e não tem um contexto que corresponda ao que é enviado pela outra GSN. Os GSNs excluem o contexto PDP quando esse erro é recebido.

Cenários de exemplo

Esta seção descreve quatro cenários nos quais um erro de código de causa 192 pode ocorrer.

• Cenário 1 - Ocorre uma falha de caminho GTP-C entre os GSNs.
  
  
• Cenário 2 - Ocorre uma falha de solicitação/resposta de eco entre as GSNs.
  
  
• Cenário 3 - Há um problema de transferência GTP Versão 1 (GTPv1) para GTP Versão 0 (GTPv0) que causa o erro. Aqui está um exemplo de fluxo de chamada para este cenário:
  
  
  1. Uma solicitação de criação de contexto PDP com GTPv1 é estabelecida.
     
     
  2. A transferência GTPv1 para GTPv0 ocorre.
     
     
  3. A chamada no GGSN está agora em GTPv0.
     
     
  4. O GGSN recebe a solicitação de contexto PDP de atualização com um TEID de cabeçalho diferente de zero e rejeita-a devido ao erro (inexistente).

     Note: A SGSN deve ter esquecido o TEID, à medida que a chamada é movida para GTPv0 (existem apenas rótulos de fluxo para GTPv0, não para TEIDs). Isso indica que a SGSN permaneceu na chamada GTPv1 mesmo após a transferência para GTPv0.

• Cenário 4 - O efeito TEID fora de sincronização é multiplicado. Aqui está um exemplo:
  
  
  1. A UE1 estabelece um contexto PDP; o SGSN aloca o Control-TEID-1 (C-TEID-1) como seu controle TEID em direção ao GGSN no contexto sgsn-UE1-ctxt. O C-TEID para todas as mensagens no GGSN que vão em direção ao SGSN têm C-TEID-1.
     
     
  2. Uma mensagem de sinalização (não-eco) expira no SGSN, e o SGSN limpa esse contexto sgsn-UE1-ctxt localmente. Ele também informa o Radio Network Controller (RNC) para limpar. Ele não informa o GGSN, pois trata o GGSN como desativado. Agora não há contexto PDP para UE1 na SGSN, e o contexto PDP para o mesmo UE1 existe na GGSN com C-TEID-1. O C-TEID-1 volta para o fim da lista livre.
     
     
  3. Em seguida, a UE2 deseja estabelecer um contexto PDP para o mesmo APN e passa pelo mesmo SGSN e GGSN. No SGSN, o TEID é alocado e um contexto sgsn-UE2-ctxt é enviado ao GGSN. Se o número de TEIDs livres for baixo, o TEID recém-liberado será realocado para o novo contexto de PDP. Nesse caso, C-TEID-1 é realocado para UE2.
     
     
  4. Na GGSN, há dois contextos com C-TEID-1 como o C-TEID Gn. O GGSN não verifica se já existe um TEID para o mesmo. O GGSN, então, inicia um DPC (Delete PDP Context) para UE1 em direção ao SGSN.
     
     
  5. No SGSN, o C-TEID-1 é encontrado, junto com o contexto para ele, que é sgsn-UE2-Ctxt. É feita uma tentativa para excluir esse contexto e responder à GGSN.
     
     
  6. Se houver solicitações iniciadas pelo GGSN (atualizar/excluir PDP) para os outros contextos, o SGSN responde com um Contexto não encontrado por causa.
     
     
  7. O GGSN descarta essa resposta de DPC para UE2 porque nunca enviou uma solicitação de DPC para UE2.
     
     
  8. Existe agora um segundo contexto sobre a GGSN que não corresponde a nenhum contexto sobre a SGSN.
     
     
  9. Se o mesmo C-TEID-1 for atribuído a outro UE, o problema repetirá e agravará o problema.

Esta é uma seção retirada do TS 29.060:

Resposta de eco

A mensagem será enviada em resposta a um pedido de eco recebido.

O GSN que recebe uma Resposta de Eco de um peer GSN deve comparar o valor de Contador de Reinicialização recebido com o valor anterior de Contador de Reinicialização armazenado para esse peer GSN. Se nenhum valor anterior tiver sido armazenado, o valor de Contador de Reinício recebido na Resposta de Eco será armazenado para o correspondente GSN.

O valor de um Contador de Reinicialização armazenado anteriormente para um peer GSN pode ser diferente do valor de Contador de Reinicialização recebido na Resposta de Eco desse peer GSN. Neste caso, a GSN que enviou a Resposta de Eco será considerada como reiniciada pela GSN que recebeu a Resposta de Eco. O novo valor de Contador de Reinício recebido deve ser armazenado pela entidade receptora, substituindo o valor anteriormente armazenado para a GSN de envio.

Se o GSN emissor for um GGSN e o GSN receptor for um SGSN, o SGSN considerará todos os contextos PDP utilizando o GGSN como inativo. Para mais ações da SGSN, consultar a 3ª Geração de Especificações Técnicas do Projeto de Parceria (3GPP) 23.007 [3].

Se a GSN de envio for uma SGSN e a GSN de recepção for uma GGSN, a GGSN considerará todos os contextos PDP utilizando a SGSN como inativa. Para mais ações da GGSN, consultar a 3GPP TS 23.007 [3].

Esta é uma seção tirada do 3GPP TS 23.007 V8.0:

Restauração de dados na SGSN

Reinicialização da SGSN

Após uma reinicialização de SGSN, o SGSN exclui todos os contextos de Gerenciamento de Mobilidade (MM), PDP, Serviços de Multicast de Broadcast Multimídia (MBMS) UE e Portador de MBMS afetados pela reinicialização. O armazenamento SGSN de dados é volátil, exceto conforme especificado nesta subcláusula. A SGSN mantém na memória volátil um contador de reinicialização GGSN para cada GGSN com a qual a SGSN está em contato, e em contadores de reinicialização SGSN de memória não volátil que se relacionam a cada GSN com a qual a SGSN está em contato. Os contadores de reinício SGSN devem ser incrementados e todos os contadores de reinício GGSN devem ser limpos imediatamente após o reinício da SGSN.  O contador de reinicialização pode ser comum a todas as GGSNs ou pode haver um contador separado para cada GGSN.

O GGSN executa uma função de pesquisa (solicitação de eco e resposta de eco) para as SGSNs com as quais o GGSN está em contato. O contador de reinicialização SGSN deve ser incluído na resposta de eco. Se o valor recebido na GGSN for diferente do armazenado para essa SGSN, a GGSN considerará que a SGSN foi reiniciada (ver 3GPP TS 29.060). Os contadores de reinício GGSN devem ser atualizados na SGSN para o valor recebido na primeira mensagem de eco proveniente de cada GGSN após o reinício da SGSN.

Quando a GGSN detectar um reinício numa SGSN com a qual tem contexto(s) PDP ativado, deve eliminar todos estes contextos PDP . Além disso, o novo valor do contador de reinício SGSN recebido na resposta de eco da SGSN reiniciada deve ser atualizado na GGSN.