Sem fio/Mobilidade : Gateway GPRS Support Node (GGSN)

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

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (27 Agosto 2015) | Feedback

Introdução

Este documento descreve o comportamento do nó de apoio do General Packet Radio Service do gateway (GPRS) (GGSN) quando o nó de apoio do serviço GPRS (SGSN) não responde à requisição de eco do protocolo de tunelamento GPRS (GTP) que está enviada do GGSN.

Contribuído por Krishna Kishore, engenheiro de TAC da Cisco.

Informações de Apoio

Você pôde experimentar falhas de ativação altas do protocolo de dados de pacote (PDP) no GGSN durante um período de tempo em que o SGSN não respondesse às requisições de eco GTP. Estão aqui algumas perguntas que puderam elevarar nesta encenação:

  1. Criam PDP ou pedidos da atualização PDP do SGSN chegam no GGSN?

  2. Quando as requisições de eco GTP falham do GGSN ao SGSNs, como deve o GGSN se comportar se o contexto da atualização PDP que está enviado do GGSN não recebe uma resposta?

  3. Como um GGSN falha um PDP se não recebe uma resposta do eco GTP ou uma resposta para os mensagens request do NON-eco que chegam de um SGSN para aquele PDP?

  4. Como uma falta em respostas do eco/eco GTP afeta diretamente as falhas de ativação PDP?

Comportamento GGSN

Se as mensagens não chegam no GGSN, então o SGSN provoca um alarme de falha do trajeto e deixa-as cair silenciosamente. Adicionalmente, se não há nenhuma resposta do eco recebida para a requisição de eco que está iniciada pelo GGSN, indica que o par está para baixo, assim que o GGSN localmente cancela os atendimentos que são relacionados a esse par.

Na mostra o apoio detalha a saída do comando, ou a saída do comando verbose das estatísticas do gtpc da mostra, você pode ver os contadores do intervalo do req 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ê investiga as mensagens da requisição de eco que estão transferidas do GGSN ao SGSN, parece que o GGSN não recebe as respostas do eco. Você deve assegurar-se de que as mensagens não sejam deixado cair devido às questões de roteamento na rede ou que o SGSN não está disponível.

O problema mais comum é as falhas do trajeto do controle, que fazem com que um grande número SGSNs vagueando se torne inacessível.

Se há qualquer mensagem do controle GTP (tal como um pedido do contexto da atualização PDP) do GGSN que não recebe uma resposta depois que todas as tentativas são esgotadas, o GGSN pensa que o par é inacessível e rasga-o para baixo somente que a sessão particular relata a causa como uma falha do trajeto. O contexto PDP é suprimido no GGSN, mas o SGSN não é notificado. Esta 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

O GGSN rasga agora para baixo a sessão do contexto PDP e nunca notifica o SGSN ou o equipamento de usuário (UE). O SGSN ou o UE puderam provocar um pedido do contexto da atualização PDP, e o GGSN pôde rejeitá-lo com um código de causa 192 (inexistente).

Está aqui uma seção que seja tomada de TS 29.060:

  • Se um Gprs que apoia Node(GSN) recebe uma mensagem do plano do controle de protocolo do Tunelamento de Gprs (GTP-C) que pede a ação relativa a um contexto PDP que o nó de emissão acredita é na existência, mas aquele não está reconhecido pelo nó de recepção, o nó de recepção enviará para trás à fonte da mensagem, uma resposta com o valor de causa apropriado (“inexistente” ou “contexto não encontrado”).  O identificador do ponto final de túnel usado no mensagem de resposta será ajustado a todos os zero.
  • Se o SGSN recebe uma resposta do contexto da atualização PDP com um valor de causa “inexistente”, suprimirá do contexto PDP.

Erro do código de causa 192

Um código de causa 192 (ou inexistente) é um erro que seja enviado pelo GSNs na relação GN. É povoado na causa do elemento de informação das mensagens GTP.

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

  • Update_PDP_Context_Response

  • Delete_PDP_Context_Response

Nota: O identificador da extremidade do túnel (TEID) que é usado na mensagem que contém este erro será zero. Refira TS 29.060 para uns detalhes mais adicionais.

Este erro pode aparecer nas mensagens acima mencionadas quando está enviado por um GSN e não tem um contexto que corresponda a esse que é enviado pelo outro GSN. A supressão de GSNs o contexto PDP quando este erro for recebido.

Cenários de exemplo

Esta seção descreve quatro encenações em que um erro do código de causa 192 pode ocorrer.

  • Encenação 1 – Uma falha do trajeto GTP-C ocorre entre o GSNs.

  • Encenação 2 – Uma requisição de eco/falha da resposta ocorre entre o GSNs.

  • Encenação 3 – Há uma versão 1 GTP (GTPv1) à edição da entrega da versão 0 GTP (GTPv0) que causa o erro. Está aqui um fluxo de chamadas da amostra para esta encenação:

    1. Um pedido do contexto da criação PDP com GTPv1 é estabelecido.

    2. A entrega GTPv1-to-GTPv0 ocorre.

    3. Chamar o GGSN está agora em GTPv0.

    4. O GGSN recebe o pedido do contexto da atualização PDP com um encabeçamento diferente de zero TEID e rejeita-o devido ao erro (inexistente).

      Nota: O SGSN deve ter esquecido o TEID, como o atendimento se moveu para GTPv0 (somente as fluxo-etiquetas existem para GTPv0, não TEIDs). Isto indica que o SGSN se aferrou ao atendimento GTPv1 mesmo depois a entrega a GTPv0.

  • Encenação 4 – O efeito fora de sincronia TEID é multiplicado. Aqui está um exemplo:

    1. O UE1 estabelece um contexto PDP; o SGSN distribui o Control-TEID-1 (C-TEID-1) como seu controle TEID para o GGSN no contexto sgsn-UE1-ctxt. Os C-TEID para todas as mensagens no GGSN que dirigem para o SGSN têm C-TEID-1.

    2. Os intervalos de um mensagem de sinalização (NON-eco) no SGSN, e o SGSN limpam esse contexto sgsn-UE1-ctxt localmente. Igualmente informa o controlador da rede de rádio (RNC) para limpar. Não informa o GGSN, porque trata o GGSN como para baixo. Agora não há nenhum contexto PDP para UE1 no SGSN, e o contexto PDP para o mesmo UE1 existe no GGSN com C-TEID-1. O C-TEID-1 vai para trás à cauda da lista livre.

    3. O UE2 então quer estabelecer um contexto PDP ao mesmo APN e passa com o mesmos SGSN e GGSN. No SGSN, o TEID é atribuído e um contexto sgsn-UE2-ctxt é enviado ao GGSN. Se o número de TEIDs livre é baixo, a seguir o TEID recentemente livrado está readjudicado ao contexto novo PDP. Neste caso, C-TEID-1 é readjudicado a UE2.

    4. No GGSN, há dois contextos com o C-TEID-1 como a GN C-TEID. O GGSN não verifica se haja uns TEID já atuais para o mesmos. O GGSN inicia então um contexto da supressão PDP (DPC) para UE1 para o SGSN.

    5. No SGSN, o C-TEID-1 é encontrado, junto com o contexto para ele, que é sgsn-UE2-Ctxt. Uma tentativa é feita a fim suprimir desse contexto e responder ao GGSN.

    6. Se há uns pedidos GGSN-iniciados (atualização/supressão PDP) para os outros contextos, o SGSN responde com uma causa não encontrada do contexto.

    7. O GGSN deixa cair essa resposta DPC para UE2 porque nunca enviou um pedido DPC para UE2.

    8. Há agora um segundo contexto no GGSN que não corresponde a nenhum contexto no SGSN.

    9. Se o mesmo C-TEID-1 é atribuído a um outro UE, o problema repete e combina a edição.

Está aqui uma seção que seja tomada de TS 29.060:

Resposta do eco

A mensagem será enviada como uma resposta a uma requisição de eco recebida.

O GSN que recebe uma resposta do eco de um par GSN comparará o valor de contador do reinício recebido com o valor de contador precedente do reinício armazenado para esse par GSN. Se nenhum valor precedente foi armazenado, o valor de contador do reinício recebido na resposta do eco será armazenado para o par GSN.

O valor de um contador do reinício armazenado previamente para um par GSN pode diferir do valor de contador do reinício recebido na resposta do eco desse par GSN. Neste caso, o GSN que enviou a resposta do eco será considerado como reiniciado pelo GSN que recebeu a resposta do eco. O valor de contador novo do reinício recebido será armazenado pela entidade de recepção, substituindo o valor armazenado previamente para o GSN de emissão.

Se o GSN de emissão é um GGSN e o GSN de recepção é um SGSN, o SGSN considerará todos os contextos PDP usando o GGSN como inativo. Para umas ações mais adicionais do SGSN refira a ó parceria da geração Project(3GPP) Specifications(TS) técnico a 23.007 [3].

Se o GSN de emissão é um SGSN e o GSN de recepção é um GGSN, o GGSN considerará todos os contextos PDP usando o SGSN como inativo. Para umas ações mais adicionais do GGSN refira 3GPP TS 23.007 [3].

Está aqui uma seção que seja tomada de 3GPP TS 23.007 V8.0:

Restauração dos dados no SGSN

Reinício do SGSN

Depois que um reinício SGSN, o SGSN suprime de toda a mobilidade Management(MM), PDP, multimédios transmitem os contextos dos serviços de transmissão múltipla (MBMS) UE, e do portador MBMS afetados pelo reinício. O armazenamento SGSN dos dados é temporário exceto como especificado neste subclause. O SGSN mantém na memória volátil um contador do reinício GGSN para cada GGSN com que o SGSN está no contato, e nos contadores do reinício da memória permanente SGSN que se relacionam a cada GGSN com que o SGSN está no contato. Os contadores do reinício SGSN estarão incrementados e todos os contadores do reinício GGSN serão cancelados imediatamente depois que o SGSN reiniciou.  O contador do reinício pode ser comum a todos os GGSN ou pode haver um contador separado para cada GGSN.

O GGSN executa uma função da votação (resposta da requisição de eco e do eco) para o SGSNs com que o GGSN está no contato. O contador do reinício SGSN será incluído na resposta do eco. Se o valor recebido no GGSN difere de esse armazenado para aquele SGSN, o GGSN considerará que o SGSN reiniciou (veja 3GPP TS 29.060). Os contadores do reinício GGSN estarão atualizados no SGSN ao valor recebido no primeiro mensagem de eco que vem de cada GGSN depois que o SGSN reiniciou.

Quando o GGSN detecta um reinício em um SGSN com que tem contextos PDP ativados, suprimirá de todos estes contextos PDP. Também, o valor novo do contador do reinício SGSN recebido na resposta do eco do SGSN reiniciado será atualizado no GGSN.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 119246