Congestionamento de STP, IMSIMGR sobre estado e oscilações de link SCTP na SGSN devido ao HLR MAP_RESET
Contents
Introduction
Este documento descreve um problema encontrado no nó de suporte GPRS (General Packet Radio Service) do ASR (Cisco 5000 Series. Algumas soluções possíveis para esse problema também são descritas.
Informações de Apoio
Esta cadeia específica de eventos no ASR SGSN é descrita neste documento:
- 21 de novembro, 6:25: Um MAP_RESET foi enviado pelo HLR (Home Location Register).
- 21 de novembro, 8:13 da manhã: Um alarme de congestionamento é acionado para o Ponto de Transferência de Sinal 2 (STP-2).
- 21 de novembro, 8:23: Um alarme de congestionamento é acionado para STP-1 e STP-2.
- 21 de novembro, 8:48: O International Mobile Subscriber Identity Manager (IMSIMGR) passa para o estado de aviso.
- 21 de novembro, 10:07: Os links são redefinidos do STP-2 para o SGSN.
- 21 de novembro, 10:15: Observou-se melhoria nas estatísticas de atualização de localização SGSN (LU).
- 21 de novembro, 10:00 10:30 AM: As estatísticas começam a melhorar às 10h.
- 21 de novembro, 11:15 : Observou-se um decréscimo nas estatísticas da SGSN LU.
- 21 de novembro, 11:41: A equipe do STP relata que o código de enlace de sinalização (SLC)-1 do STP-2 não recebe tráfego, o SLC é redefinido e o tráfego retorna ao normal.
- 21 de novembro, 11:42: Um alarme de congestionamento é acionado no SGSN para SLC-1 do STP.
- 21 de novembro, 12:00: Depois que o SLC-3 é redefinido, as estatísticas da LU GPRS melhoram.
Problema
Quando o HLR recebe a mensagem MAP_RESET, ele define um sinalizador para uma atualização de local GPRS (GLU). Quando o equipamento do usuário (UE) envia seus primeiros pacotes de uplink, o SGSN envia uma mensagem GLU para o HLR.
At 7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers: 2386266
Active: 2386266
sgsn-pdp-type-ipv4: 942114
Como mostrado na saída do exemplo, há 950.000 contextos de Protocolo de Dados de Pacotes (PDP - Packer Data Protocol) presentes no SGSN, e os UEs tentam navegar por eles à medida que o dia progride.
Quando os primeiros pacotes de uplink são recebidos, o SGSN dispara uma mensagem GLU. Como há centenas de milhares de UEs, o STP não pode lidar com a quantidade de tráfego que é gerado e se move para um estado de congestionamento perene.
As mensagens são enfileiradas no SGSN e o tempo limite máximo de retransmissão ocorre. Como todas as mensagens GLU não passam do SGSN para o HLR, o SGSN é forçado a desconectar os assinantes móveis e solicitar que eles se reconectem. Todos os assinantes desconectados tentam anexar, o que causa um aumento repentino no número de solicitações de anexo de entrada. Como a proteção contra sobrecarga de rede é aplicada, a maioria das tentativas de anexação é rejeitada devido a congestionamento e os assinantes móveis são forçados a fazer uma nova tentativa.
À medida que esta cadeia de eventos se desenrola, produz efeitos em cascata. Muitas mensagens SAI (Send Authentication Information), GLU messages e MAP-IMEI_CHECK estão travadas na fila SGSN ou são descartadas. Por esse motivo, todos os links STP-1 e STP-2 atingem um estado de congestionamento. Cada STP tem quatro links de sinalização, mas nesse cenário, os três primeiros links do STP-2 não se recuperam por muito tempo.
Aqui estão os alarmes de congestionamento, nos quais você pode ver que todos os links STP se movem para o estado de congestionamento em STP-2:
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-1 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-2 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:14 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-3 (point-code-782)
congested congLevel-1
Fri Nov 21 08:13:29 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:18:48 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:20:00 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:52 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:22:55 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:23:22 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:26:33 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:06 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 08:28:45 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Fri Nov 21 09:27:27 2014 Internal trap notification 1074 (M3UAPSPCongested)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congested congLevel-1
Como mostrado, apenas o PSP (Peer Server Process, processo de servidor par) 4 foi limpo e o restante ainda está no estado de congestionamento:
Fri Nov 21 08:18:47 2014 Internal trap notification 1075 (M3UAPSPCongestionCleared)
ss7-routing-domain-1 peer-server-2 peer-server-process-4 (point-code-782)
congestion cleared congLevel-0
Solução
Esta seção descreve como solucionar o problema descrito na seção anterior.
O link STP recebe muito tráfego
Conforme descrito na seção anterior, um link específico no STP recebe uma grande quantidade de tráfego. Você pode ver que os três primeiros enlaces no STP-2 se movem para o estado de congestionamento e nunca se recuperam, portanto, apenas um enlace está disponível e o alarme de congestionamento é cancelado em SLC-3 (ou peer-server-2-peer-server-process-4).
De acordo com o mecanismo de compartilhamento de carga SGSN, ele deve enviar os pacotes MTP (Message Transfer Part) Level 3 (MTP3) User Adaptation Layer (M3UA) igualmente em todos os quatro links. No entanto, a partir das armadilhas do Protocolo de Mensagem de Rede Simples (SNMP - Simple Network Message Protocol), os três primeiros links STP-2 são permanentemente congestionados, o que significa que todo o tráfego é roteado para o link SLC-3 (o único link STP disponível para rotear o tráfego). Isso explica por que a distribuição de tráfego é desviada entre os links STP-2.
Em situações de congestionamento, um ou mais links alternam entre estados congestionados e não congestionados, de modo que somente os links disponíveis compartilham o tráfego. Por esse motivo, há mais utilização em um dos links. Isso exige uma redefinição de link para recuperar os links.
A próxima saída mostra as estatísticas do nível M3UA e desanexar estatísticas. As estatísticas importantes a serem consideradas são a instância 4 do PSP STP-2, onde o tráfego anormal pode ser visto:
Time #1:ss7rd-m3ua-psp-data-tx #2:ss7rd-m3ua-psp-error-tx #3:ss7rd-m3ua-psp-data-rx
21-11-14 7:30 37409 0 37942
21-11-14 8:00 43677 0 43866
21-11-14 8:30 190414 0 71844
21-11-14 9:00 547418 0 104135
21-11-14 9:30 536019 0 102477
21-11-14 10:00 376797 0 132227
21-11-14 10:30 100394 0 97302
21-11-14 11:00 119652 0 114809
21-11-14 11:30 107073 0 95354
Aqui estão os dados do STP:
DATE TIME LSN LOC SLC LINK TX % RX %
11/21/2014 9:00 sgsncisco 5216 3 A IPVL 11.26 62.07
11/21/2014 9:00 sgsncisco 5213 0 A1 IPVL 11.29 4.86
11/21/2014 9:00 sgsncisco 5214 1 A1 IPVL 11.27 4.85
11/21/2014 9:00 sgsncisco 5215 2 A IPVL 11.23 4.7
Esta saída mostra os detalhes por segundo no momento do problema:
Time #13:2G-ms-init-detach #14:2G-nw-init-detach
21-11-14 6:30 136465 7400
21-11-14 7:00 149241 9557
21-11-14 7:30 165788 12630
21-11-14 8:00 179311 16963
21-11-14 8:30 125564 44759
21-11-14 9:00 112461 95299
21-11-14 9:30 240341 112461
21-11-14 10:00 288014 116298
21-11-14 10:30 203261 123300
21-11-14 11:00 67788 122945
Esta saída mostra os anexos por segundo, de acordo com o WEM:
Time #3:2G-total-attach-req-all Request/Second
21-11-14 8:00 738279 205.078
21-11-14 9:00 14053511 3903.753
21-11-14 10:00 24395071 6776.409
21-11-14 11:00 24663454 6850.959
21-11-14 12:00 17360687 4822.413
IMSIMGR no estado de aviso
Cada nova chamada de anexação IMSI/Packet Temporary Subscriber Identity (P-TMSI) e solicitação de atualização da área de roteamento (RAU) deve ser processada pelo IMSIMGR.
Com uma observação conservadora, o sistema recebe um valor máximo de 6.850 solicitações de anexação 2-G por segundo e cerca de 5.313 solicitações de anexação 3-G por segundo. O valor máximo que você pode definir para a proteção contra sobrecarga de rede é de 5.000 solicitações de conexão por segundo. Para manter o IMSIMGR em um estado operacional, o sistema não pode lidar com um número tão grande de chamadas dos UE.
Esse problema começa após 8 da manhã, quando o tamanho da fila atinge 1.500 solicitações de anexo por segundo:
network-overload-protection sgsn-new-connections-per-second 500 action
reject-with-cause congestion queue-size 1500 wait-time 5
Como há aproximadamente 12.000 solicitações de anexo por segundo, quase 9.000 chamadas são processadas pelo IMSIMGR e rejeitadas. Isso faz com que o processamento da CPU IMSIMGR atinja um estado alto.
Se o SGSN receber mais do que o número configurado de solicitações de anexação em um segundo, as solicitações serão armazenadas em buffer na fila de pacing e só serão descartadas quando o buffer sobrecarregar devido a uma alta taxa de vinculação de entrada. As mensagens na fila são processadas de acordo com um processo FIFO (First-In, First-Out) até que fiquem esgotadas quando o tempo de vida da mensagem na fila passar pelo tempo de espera configurado.
Ao escolher as opções de rejeição ou derivação com base na sua preferência, a Cisco recomenda que você use um código de causa de rejeição para indicar o congestionamento na rede, o que permite que você entenda as condições da rede antes de tentar um procedimento de uplink.
Falha de HLR
De acordo com a Especificação Técnica (TS - Technical Specification) 23.060 da 3ª geração do Projeto de Parceria (3GPP - 3rd Generation Partnership Project), esta seção descreve o comportamento da SGSN durante uma reinicialização da HLR. Sempre que o SGSN receber uma redefinição de MAP, ele deverá enviar uma solicitação de UL para o HLR de seus assinantes.
Quando um HLR é reiniciado, ele envia uma mensagem de redefinição para cada SGSN na qual uma ou mais de suas estações móveis (MSs) estão registradas. Isso faz com que a SGSN marque os contextos relevantes de gerenciamento móvel como inválidos se existir uma associação SGSN-to-Mobile Switching Center (MSC)/Visiting Location Register (VLR). Após o recebimento do primeiro quadro de Controle de Link Lógico (LLC - Logical Link Control) válido (para o modo A/Gb) ou após o recebimento do primeiro pacote válido do GPRS Tunneling Protocol User (GPT-U) ou mensagem de sinalização de uplink (para o modo Iu) de uma estação móvel marcada, a SGSN executa uma UL para a HLR, como na solicitação de anexo ou nos procedimentos de atualização da área de roteamento (RA - Inter-SGSN). Além disso, se o Sinalizador de Alerta não-GPRS (NGAF) estiver definido, o procedimento na cláusula de Alerta Não-GPRS será seguido. O procedimento UL e o procedimento para o MSC/VLR podem ser atrasados pela SGSN para uma configuração máxima do operador, dependendo da utilização dos recursos na altura, a fim de evitar uma carga de sinalização elevada.
Recomendações
A Cisco recomenda que você conclua estas etapas para resolver este problema:
- Aumente o número de novas conexões por segundo. Isso pode ser calculado com base no número médio de solicitações de anexação.
- Aumente as Transações por Segundo (TPS) no link STP para um valor ideal.
- Altere o valor padrão SCTP-RTO-MAX de 600 (600*100 = 60.000) para 5 (5*100 ms). Por exemplo, para dois STPs com 4.000 TPS, você pode suportar até 1.000 solicitações de anexação por segundo do SGSN.
Idealmente, cada STP tem quatro links para que 125 solicitações de anexação possam ser processadas por link STP. Isso é distribuído igualmente por todos os links STP. No entanto, se um dos links ficar inoperante, muitas tentativas de reconexão serão vistas, a fila ficará cheia e ocorrerão descartes de pacotes. Se mais links ficarem inoperantes, o tráfego será distribuído de forma desigual.
Fluxo de tráfico
O tráfego da UE não segue uma forma linear. Geralmente ocorre em uma intermitência e com muitas tentativas de reconexão. O SGSN envia tráfego em pacotes para o STP. Nesse momento, as quantidades de tráfego excedem o TPS configurado no STP. Isso faz com que alguns links no STP comecem a anunciar um tamanho de janela baixo se já processarem mais chamadas, e o SGSN começa a enfileirar os blocos de dados SCTP enfileirados. Em seguida, ele espera que o temporizador RTO MAX expire.
Se o STP enviar periodicamente um bom tamanho de janela anunciado, você poderá enviar mais blocos de dados SCTP se o valor SCTP_RTO_MAX for reduzido para cinco segundos ou menos. A fila é limpa mais rapidamente e um alarme de congestionamento M3UA não é disparado. Além disso, você não deve ver o flag de controle de fluxo interno disparado pelo SCTP para controlar o fluxo do pacote.
O SGSN envia apenas pacotes na quantidade que o STP pode aceitar, que se baseia no tamanho da janela anunciada. Se você aumentar o link TPS por STP, ele ajuda a evitar o congestionamento STP e reduz o temporizador SCTP_RTO_MAX.
Disparadores para Alarme Congestionado M3UA na SGSN
Se o tamanho da janela anunciada na mensagem SACK (Stream Control Transmission Protocol [protocolo de transmissão de controle de fluxo]) estiver próximo a zero (ou zero), o SGSN acionará um alarme M3UA para indicar que as mensagens não devem ser enviadas para esse ponto de extremidade do peer. Isso faz com que o link oscile ou entre em um estado congestionado. Como o SGSN envia um tamanho de janela maior, você continua a receber dados M3UA dos nós de mesmo nível, e esses pacotes podem ser descartados na fila de espera se o código de ponto de mesmo nível nunca sair do estado congestionado.
Aqui está um exemplo:
- O SCTP envia uma indicação de início de controle de fluxo para o M3UA.
- O M3UA define o sinalizador de congestionamento ativo para a associação e começa a pesquisar o SCTP periodicamente sobre seu status de controle de fluxo.
- Enquanto uma associação está no controle de fluxo, ela enfileira futuras solicitações de dados para essa associação até que a QUEUE_SIZE tenha atingido 8.000. Nesse momento, as mensagens futuras da associação são descartadas.
- Se o STP enviar um tamanho de janela anunciado corretamente, o M3UA tentará esvaziar as mensagens que estão na fila até atingir 5.000. O temporizador RTO também tem um papel nisso.
As mensagens SCTP são enfileiradas somente para as associações em que o sinalizador de controle de fluxo se torna Verdadeiro, e o SGSN é processado de acordo com a resposta STP:
*Peer Server Id : 2 Peer Server Process Id: 2
Association State : ESTABLISHED
Flow Control Flag : TRUE
Peer INIT Tag : 20229
SGSN INIT Tag : 3315914061
Next TSN to Assign to
Outgoing Data Chunk : 3418060778
Lowest cumulative TSN acknowledged : 3418060634
Cumulative Peer TSN arrived from peer : 103253660
Last Peer TSN sent in the SACK : 103253658
Self RWND : 1048576
Advertised RWND in received SACK : 8
Peer RWND(estimated) : 8
Retransmission counter : 0
Zero Window Probing Flag : FALSE
Last Tsn received during ZWnd Probing : 0
Bytes outstanding on all
addresses of this association : 19480
Congestion Queue Length : 143
Ordered TSN assignment Waiting QLen : 8050
Unordered TSN assignment Waiting QLen : 0
Total number of GAP ACKs Transmitted : 279
Total number of GAP ACKs Received : 58787
Path No. : 1
Current CWND : 11840
SSThresh : 11840
Partial Bytes Acked : 0
Bytes Outstanding for this Path : 19480
Current RTO for this Path(in ms) : 60000
Como mostrado, o motivo por trás do congestionamento é que o número total de blocos de saída excede o limite de 5.000 (8050+143=8193) e atinge o temporizador máximo de RTO de 60 segundos, o que resulta em solicitações de dados SCTP descartadas. Além disso, há um temporizador RTO mais alto.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
16-Apr-2015 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)