Congestionamento de STP, IMSIMGR sobre estado e Flaps de enlace de SCTP em SGSN devido a HLR MAP_RESET
Contents
Introdução
Este documento descreve um problema que é encontrado no nó de suporte (SGSN) do Service General Packet Radio Service (GPRS) do Cisco 5000 Series Aggregated Services Router (ASR). 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 AM: um MAP_RESET foi enviado pelo Home Location Register (HLR).
- 21 de novembro, 8:13 AM: Um alarme de congestionamento é acionado para o Ponto de Transferência de Sinal 2 (STP-2).
- 21 de novembro, 8:23 AM: Um alarme de congestionamento é acionado para STP-1 e STP-2.
- 21 de novembro, 8:48 AM: O International Mobile Subscriber Identity Manager (IMSIMGR) entra no estado de aviso.
- 21 de novembro, 10:07 AM: Os links são redefinidos do STP-2 para o SGSN.
- 21 de novembro, 10:15 AM: Melhorias são observadas nas estatísticas da SGSN Location Update (LU).
- 21 de novembro, 10:00 â 10:30 AM: As estatísticas começam a melhorar às 10:00 am.
- 21 de novembro, 11:15 AM : Um declínio é observado nas estatísticas SGSN LU.
- 21 de novembro, 11:41 AM: A equipe de STP relata que o Signaling Link Code (SLC)-1 de STP-2 não recebe tráfego, o SLC é redefinido e o tráfego retorna ao normal.
- 21 de novembro, 11:42 AM: Um alarme de congestionamento é acionado em SGSN para SLC-1 do STP.
- 21 de novembro, 12:00 PM: 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 flag para uma GLU (GPRS Location Update - Atualização de Local GPRS). Quando o equipamento de usuário (UE) envia seus primeiros pacotes de uplink, o SGSN envia uma mensagem GLU ao 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 Packer Data Protocol (PDP) presentes no SGSN, e os UEs tentam navegar por eles à medida que o dia avança.
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 é gerada e entra em um estado de congestionamento perene.
As mensagens são enfileiradas no SGSN e um 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-se, 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 conexão é rejeitada devido ao 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 Send Authentication Information (SAI), mensagens GLU e mensagens MAP-IMEI_CHECK ficam presas 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 no 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) 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 enlace 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 links no STP-2 entram no estado de congestionamento e nunca são recuperados, portanto, apenas um link está disponível e o alarme de congestionamento é cancelado no 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 Nível 3 (MTP3) User Adaptation Layer (M3UA) igualmente em todos os quatro enlaces. No entanto, a partir das interceptações do Protocolo de Mensagem de Rede Simples (SNMP - Simple Network Message Protocol), os três primeiros enlaces do STP-2 estão congestionados permanentemente, o que significa que todo o tráfego é roteado para o enlace do SLC-3 (o único enlace do STP disponível para rotear o tráfego). Isso explica por que a distribuição de tráfego é distorcida 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 apenas 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 as estatísticas de desanexação. As estatísticas importantes a serem consideradas são a instância 4 do STP-2 PSP, 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 as desconexões 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 as conexões 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 em Estado de Aviso
Cada nova solicitação de IMSI/Packet Temporary Mobile Subscriber Identity (P-TMSI) e Routing Area Update (RAU) de chamada deve ser processada pelo IMSIMGR.
Com uma observação conservadora, o sistema recebe um valor de pico de 6.850 solicitações de conexão 2-G por segundo e cerca de 5.313 solicitações de conexã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 anexadas por segundo. Para manter o IMSIMGR em um estado operável, o sistema não pode lidar com um número tão grande de chamadas dos UEs.
Esse problema começa após as 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 conexão por segundo, quase 9.000 chamadas são processadas pelo IMSIMGR e rejeitadas. Isso faz com que o processamento da CPU do 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 ritmo e só serão descartadas quando o buffer estourar devido a uma alta taxa de anexação de entrada. As mensagens na fila são processadas de acordo com um processo First-In, First-Out (FIFO) até expirarem quando o tempo de vida da mensagem na fila ultrapassar o tempo de espera configurado.
Quando você escolhe as opções de rejeição ou eliminação com base em 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ê compreenda as condições da rede antes de tentar um procedimento de uplink.
Falha de HLR
De acordo com a Especificação Técnica (TS) 23.060 do 3rd Generation Partnership Project (3GPP), esta seção descreve o comportamento da SGSN durante uma reinicialização do HLR. Sempre que o SGSN recebe uma reinicialização de MAP, espera-se enviar uma solicitação de UL para o HLR para seus assinantes.
Quando um HLR é reiniciado, ele envia uma mensagem de redefinição para cada SGSN ao qual uma ou mais de suas estações móveis (MSs) estão registradas. Isso faz com que o SGSN marque os contextos relevantes de Gerenciamento Móvel como inválidos se existir uma associação SGSN-para-Centro de Switching Móvel (MSC)/Registro de Localização Visitante (VLR). Após o recebimento do primeiro quadro válido de Controle Lógico de Enlace (LLC - Logical Link Control) (para o modo A/Gb) ou após o recebimento do primeiro pacote GPRS Tunneling Protocol User (GPT-U - GPRS Tunneling Protocol User) válido ou mensagem de sinalização de uplink (para o modo Iu) de uma estação móvel marcada, o SGSN executa um UL para o HLR, como nos procedimentos de solicitação de conexão ou de atualização da área de roteamento (RA - Routing Area) inter-SGSN. Além disso, se o Non-GPRS Alert Flag (NGAF) for definido, o procedimento na cláusula Non-GPRS Alert será seguido. O procedimento UL e o procedimento para a MSC/VLR podem ser atrasados pela SGSN para uma configuração máxima do operador, dependendo da utilização de recursos nessa 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 anexo.
- 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 anexo por segundo do SGSN.
Idealmente, cada STP tem quatro links para que 125 solicitações de anexo possam ser processadas por link STP. Isso é distribuído igualmente por todos os links STP. No entanto, se um dos links ficar inativo, muitas tentativas de reconexão serão vistas, a fila ficará cheia e ocorrerão descartes de pacotes. Se mais links ficarem inativos, o tráfego será distribuído de forma desigual.
Fluxo de tráfico
O tráfego UE não segue uma forma linear. Geralmente ocorre em uma rajada 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 tamanho de janela baixo se já processarem mais chamadas, e o SGSN começa a enfileirar os blocos de dados SCTP que estão enfileirados. Em seguida, ele espera até que o temporizador RTO MAX expire.
Se o STP enviar periodicamente um tamanho de janela bem anunciado, você poderá enviar mais blocos de dados SCTP se o valor de 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 indicador de controle de fluxo interno disparado pelo SCTP para controlar o fluxo do pacote.
O SGSN envia somente pacotes na quantidade que o STP pode aceitar, que é baseada no tamanho da janela anunciada. Se você aumentar o TPS por link STP, isso ajudará a evitar o congestionamento de STP e reduzirá o temporizador SCTP_RTO_MAX.
Disparadores para Alarme Congestionado M3UA em SGSN
Se o tamanho da janela anunciada na mensagem de Confirmação Seletiva (SACK) do Protocolo de Transmissão de Controle de Fluxo (SCTP - Stream Control Transmission Protocol) estiver próximo de zero (ou zero), o SGSN acionará um alarme M3UA para indicar que as mensagens não devem ser enviadas para esse ponto final 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 peer, e esses pacotes podem ser descartados na fila de espera se o código de ponto de peer 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 sondar o SCTP periodicamente sobre seu status de controle de fluxo.
- Enquanto uma associação estiver no controle de fluxo, ela enfileirará futuras solicitações de dados para essa associação até que QUEUE_SIZE atinja 8.000. Nesse ponto, as mensagens futuras da associação serão descartadas.
- Se o STP enviar um tamanho de janela anunciado adequado, o M3UA tentará esvaziar as mensagens que estão na fila até atingir 5.000. O temporizador de RTO também desempenha um papel nisso.
As mensagens SCTP são enfileiradas somente para as associações onde o indicador de controle de fluxo se torna Verdadeiro, e o SGSN então processa 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 de RTO mais alto.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
16-Apr-2015 |
Versão inicial |
Feedback