Congestion STP, état IMSIMGR et volets de liaison SCTP dans SGSN en raison de HLR MAP_RESET

Introduction

Ce document décrit un problème rencontré sur le noeud de prise en charge du service GPRS (General Packet Radio Service) de la gamme Cisco 5000 ASR (Aggregated Services Router). Certaines solutions possibles à ce problème sont également décrites.

Informations générales

Cette chaîne spécifique d'événements sur le SGSN ASR est décrite dans ce document :

1. 21 novembre, 6 h 25 : MAP_RESET a été envoyé par le Registre de localisation résidentielle (HLR).
   
   
2. 21 novembre, 8 h 13 : Une alarme de congestion est déclenchée pour le point de transfert de signal 2 (STP-2).
   
   
3. 21 novembre, 8 h 23 : Une alarme de congestion est déclenchée pour STP-1 et STP-2.
   
   
4. 21 novembre, 8 h 48 : L'IMSIMGR (International Mobile Subscriber Identity Manager) passe à l'état Avertissement.
   
   
5. 21 novembre, 10:07 : Les liaisons sont réinitialisées de STP-2 vers le SGSN.
   
   
6. 21 novembre, 10 h 15 : L'amélioration est observée dans les statistiques de mise à jour de l'emplacement SGSN (LU).
   
   
7. 21 novembre, 10 h € 10 h 30 : Les statistiques commencent à s'améliorer à 10h00.
   
   
8. 21 novembre, 11 h 15 : Une baisse est observée dans les statistiques de la LU SGSN.
   
   
9. 21 novembre, 11 h 41 : L'équipe STP signale que le code de liaison de signalisation (SLC)-1 de STP-2 ne reçoit pas de trafic, que le SLC est réinitialisé et que le trafic revient à la normale.
   
   
10. 21 novembre, 11 h 42 : Une alarme de congestion est déclenchée sur SGSN pour SLC-1 du STP.
    
    
11. 21 novembre, 12h00 : Après la réinitialisation de SLC-3, les statistiques LU GPRS s'améliorent.

Problème

Lorsque le HLR reçoit le message MAP_RESET, il définit un indicateur pour une mise à jour de l'emplacement GPRS (GLU). Lorsque l'équipement utilisateur (UE) envoie ses premiers paquets de liaison ascendante, le SGSN envoie un message GLU au HLR.

At  7 AM SGSN , Nov 21st 2014 had
******** show subscriber summary *******
Total Subscribers:             2386266
Active:                        2386266
sgsn-pdp-type-ipv4:            942114

 
Comme le montre l'exemple de sortie, il y a 950 000 contextes PDP (Packer Data Protocol) présents sur le SGSN, et les UE tentent de les parcourir au fur et à mesure que la journée avance.

Lorsque les premiers paquets de liaison ascendante sont reçus, le SGSN déclenche un message GLU. Comme il existe des centaines de milliers d'UE, le STP ne peut pas gérer la quantité de trafic générée et se déplace dans un état de congestion permanent.

Les messages sont mis en file d'attente au niveau du SGSN et un délai maximal de retransmission se produit. Puisque tous les messages GLU ne passent pas du SGSN au HLR, le SGSN est forcé de détacher les abonnés mobiles et de demander qu'ils soient reconnectés. Tous les abonnés détachés tentent ensuite de se joindre, ce qui entraîne une augmentation soudaine du nombre de demandes de pièces jointes entrantes. Comme la protection contre la surcharge du réseau est appliquée, la plupart des tentatives de connexion sont rejetées en raison de la congestion et les abonnés mobiles sont forcés de faire une nouvelle tentative.

Au fur et à mesure que cette chaîne d'événements se déroule, elle produit des effets en cascade. De nombreux messages SAI (Send Authentication Information), GLU et MAP-IMEI_CHECK sont bloqués ou abandonnés dans la file d'attente SGSN. Pour cette raison, toutes les liaisons STP-1 et STP-2 atteignent un état d'encombrement. Chaque STP possède quatre liaisons de signalisation, mais dans ce scénario, les trois premières liaisons de STP-2 ne se restaurent pas très longtemps.

Voici les alarmes de congestion, dans lesquelles vous pouvez voir que toutes les liaisons STP passent à l'état d'encombrement sur 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

Comme indiqué, seul le processus Peer Server Process (PSP) 4 a été effacé et les autres sont toujours en état d'encombrement :

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

Solution

Cette section décrit comment résoudre le problème décrit dans la section précédente.

La liaison STP reçoit trop de trafic

Comme décrit dans la section précédente, une liaison particulière du STP reçoit une grande quantité de trafic. Vous pouvez voir que les trois premières liaisons dans STP-2 passent à l'état d'encombrement et ne se restaurent jamais, de sorte qu'une seule liaison est disponible et que l'alarme d'encombrement est effacée sur SLC-3 (ou peer-server-peer-2-server-process-4). 

Conformément au mécanisme de partage de charge SGSN, il doit envoyer les paquets MTP (Message Transfer Part) MTP3 (MTP3) User Adaptation Layer (M3UA) de manière égale sur les quatre liaisons. Cependant, à partir des déroutements SNMP (Simple Network Message Protocol), les trois premières liaisons STP-2 sont encombrées de manière permanente, ce qui signifie que tout le trafic est acheminé vers la liaison SLC-3 (la seule liaison STP disponible pour le trafic de route). Ceci explique pourquoi la distribution du trafic est asymétrique entre les liaisons STP-2.

Dans les situations d’encombrement, une ou plusieurs liaisons basculent entre des états encombrés et non encombrés, de sorte que seules les liaisons disponibles partagent le trafic. Pour cette raison, il y a plus d'utilisation dans l'un des liens. Cela nécessite une réinitialisation de liaison afin de récupérer les liaisons.

Le résultat suivant présente les statistiques de niveau M3UA et les statistiques de détachement. Les statistiques importantes à considérer sont l'instance PSP STP-2 4, où le trafic anormal peut être vu : 

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

Voici les données 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

Ce résultat montre les détaches par seconde au moment du problème :

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

Ce résultat montre les pièces jointes par seconde, selon 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 en état d'alerte

Chaque nouvelle demande de mise à jour de zone de routage (RAU) et de connexion IMSI/Packet Temporaire Mobile Subscriber Identity (P-TMSI) doit être traitée par l'IMSIMGR.

Avec une observation prudente, le système reçoit une valeur maximale de 6 850 demandes d'attachement 2 G par seconde et environ 5 313 demandes d'attachement 3 G par seconde. La valeur maximale que vous pouvez définir pour la protection contre la surcharge du réseau est de 5 000 demandes d'attachement par seconde. Afin de maintenir l'IMSIMGR en état de fonctionnement, le système ne peut pas traiter un aussi grand nombre d'appels provenant des UE.

Ce problème commence après 8 heures du matin, lorsque la taille de la file d'attente atteint 1 500 demandes d'attachement par seconde :

network-overload-protection sgsn-new-connections-per-second 500 action
 reject-with-cause congestion queue-size 1500 wait-time 5

Comme il y a environ 12 000 demandes de pièces jointes par seconde, près de 9 000 appels sont traités par l'IMSIMGR et rejetés. Le traitement du processeur IMSIMGR atteint ainsi un état élevé.

Si le SGSN reçoit plus que le nombre configuré de demandes d'attachement en une seconde, les demandes sont mises en mémoire tampon dans la file d'attente de traitement et ne sont abandonnées que lorsque la mémoire tampon déborde en raison d'un taux d'attachement entrant élevé. Les messages de la file d'attente sont traités conformément à un processus FIFO (First-In, First-Out) jusqu'à expiration lorsque la durée de vie du message en file d'attente dépasse la durée d'attente configurée.

Lorsque vous choisissez les options de rejet ou de suppression en fonction de vos préférences, Cisco vous recommande d'utiliser un code de cause de rejet afin d'indiquer l'encombrement dans le réseau, ce qui vous permet de comprendre les conditions du réseau avant de tenter une procédure de liaison ascendante. 

Défaillance HLR

Conformément aux spécifications techniques (TS) 23.060 du 3e Generation Partnership Project (3GPP), cette section décrit le comportement du SGSN lors d'un redémarrage HLR. Chaque fois que le SGSN reçoit une réinitialisation MAP, il est attendu qu'il envoie une requête UL au HLR pour ses abonnés.

Lorsqu'un HLR redémarre, il envoie un message de réinitialisation à chaque SGSN auquel une ou plusieurs de ses stations mobiles (MS) sont enregistrées. Cela fait que le SGSN marque les contextes de gestion mobile pertinents comme non valides s'il existe une association SGSN-to-Mobile Switching Center (MSC)/Visting Location Register (VLR). Après réception de la première trame LLC (Logical Link Control) valide (pour le mode A/Gb) ou après réception du premier message de signalisation de paquet ou de liaison ascendante GPT-U (GPRS Tunneling Protocol User) valide (pour le mode Iu) d'une station mobile marquée, le SGSN effectue une UL au HLR comme dans les procédures de mise à jour de la demande de connexion ou de la zone de routage inter-SGSN. En outre, si l'indicateur d'alerte non GPRS (NGAF) est défini, la procédure de la clause d'alerte non GPRS est suivie. La procédure UL et la procédure vers le MSC/VLR peuvent être retardées par le SGSN pour une configuration d'opérateur maximale, en fonction de l'utilisation des ressources à ce moment-là afin d'éviter une charge de signalisation élevée.

Note: La sauvegarde périodique des données HLR vers un stockage non volatile est obligatoire, comme décrit dans la norme TS 23.007 [5].

Recommandations

Cisco vous recommande d'effectuer ces étapes afin de résoudre ce problème :

1. Augmenter le nombre de nouvelles connexions par seconde. Cela peut être calculé en fonction du nombre moyen de demandes d'attachement.
   
   
2. Augmenter les transactions par seconde (TPS) dans la liaison STP à une valeur idéale.
   
   
3. Remplacez la valeur SCTP-RTO-MAX par défaut de 600 (600*100 = 60 000) par 5 (5*100 ms). Par exemple, pour deux STP avec 4 000 TPS, vous pouvez prendre en charge jusqu'à 1 000 demandes d'attachement par seconde à partir du SGSN.

Note: Chaque demande d'attachement génère quatre transactions vers le STP, ce qui signifie que 1 000 demandes d'attachement par seconde aboutissent à 4 000 TPS.

Idéalement, chaque STP dispose de quatre liaisons, de sorte que 125 requêtes de connexion puissent être traitées par liaison STP. Ceci est réparti également sur toutes les liaisons STP. Cependant, si l’une des liaisons tombe en panne, de nombreuses tentatives de reconnexion sont vues, la file d’attente devient pleine et des abandons de paquets se produisent. Si d’autres liaisons tombent en panne, le trafic est distribué de manière inégale.

Flux de trafic

Le trafic UE ne suit pas une mode linéaire. Il se produit généralement en rafale et avec de nombreuses tentatives de reconnexion. Le SGSN envoie le trafic en paquets au STP. À ce moment-là, les volumes de trafic dépassent le TPS configuré sur le STP. Cela fait que certains liens du STP commencent à annoncer une taille de fenêtre faible s'ils traitent déjà plus d'appels, et le SGSN commence à mettre en file d'attente les segments de données SCTP qui sont mis en file d'attente. Il attend ensuite l'expiration du compteur RTO MAX.

Si le STP envoie régulièrement une taille de fenêtre annoncée correcte, vous devriez pouvoir envoyer plus de blocs de données SCTP si la valeur SCTP_RTO_MAX est réduite à cinq secondes ou moins. La file d'attente est effacée plus rapidement et une alarme de congestion M3UA n'est pas déclenchée. En outre, vous ne devriez pas voir l'indicateur de contrôle de flux interne déclenché par le SCTP afin de contrôler le flux de paquets.

Le SGSN envoie uniquement des paquets dans la quantité que le STP peut accepter, qui est basée sur la taille de fenêtre annoncée. Si vous augmentez le TPS par liaison STP, cela contribue à éviter la congestion STP et réduit le compteur SCTP_RTO_MAX.

Déclencheurs d'alarme encombrée M3UA dans SGSN

Si la taille de fenêtre annoncée dans le message SACK (Stream Control Transmission Protocol) est proche de zéro (ou zéro), le SGSN déclenche une alarme M3UA afin d'indiquer que les messages ne doivent pas être envoyés pour ce point de terminaison homologue. Cela entraîne le battement de la liaison ou le déplacement vers un état encombré. Puisque le SGSN envoie une taille de fenêtre supérieure, vous continuez à recevoir des données M3UA des noeuds homologues, et ces paquets peuvent être abandonnés dans la file d'attente si le code point homologue ne sort jamais de l'état encombré.

Voici un exemple :

1. Le SCTP envoie une indication de début de contrôle de flux au M3UA.
   
   
2. Le M3UA définit l'indicateur d'encombrement actif pour l'association et commence à interroger régulièrement le SCTP sur son état de contrôle de flux.
   
   
3. Lorsqu'une association est en contrôle de flux, elle met en file d'attente les futures demandes de données pour cette association jusqu'à ce que QUEUE_SIZE atteigne 8 000. À ce stade, les messages futurs de l'association sont ignorés.
   
   
4. Si le STP envoie une taille de fenêtre annoncée correcte, le M3UA tente de vider les messages mis en file d'attente jusqu'à ce qu'ils atteignent 5 000. Le compteur RTO joue également un rôle dans ce domaine.

Les messages SCTP sont mis en file d'attente uniquement pour les associations où l'indicateur de contrôle de flux devient True, et le SGSN traite ensuite conformément à la réponse 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

Comme indiqué, la raison de l'encombrement est que le nombre total de blocs sortants dépasse la limite de 5 000 (8 050+143=8 193) et atteint le compteur RTO maximal de 60 secondes, ce qui entraîne l'abandon des demandes de données SCTP. En outre, il y a un compteur RTO plus élevé.

Historique de révision