Encombrement STP, IMSIMGR au-dessus des instabilités d'état, et de lien de SCTP dans SGSN dû à HLR MAP_RESET

Introduction

Ce document décrit un problème qui est produit sur le Service général de radiocommunication par paquets (GPRS) de service prenant en charge le noeud (SGSN) du routeur de services agrégé par gamme Cisco 5000 (ASR). Quelques contournements possibles pour cette question sont également décrits.

Informations générales

Cette série d'événements spécifique sur l'ASR SGSN est décrite dans ce document :

1. Le 21 nov., 6:25 AM : Un MAP_RESET a été envoyé par le registre d'emplacement de la maison (HLR).
   
   
2. Le 21 nov., 8:13 AM : Une alarme d'encombrement est donnée pour le point de transfert de signal 2 (STP-2).
   
   
3. Le 21 nov., 8:23 AM : Une alarme d'encombrement est donnée pour STP-1 et STP-2.
   
   
4. Le 21 nov., 8:48 AM : Le gestionnaire d'identité d'abonné mobile internationale (IMSIMGR) entre dans l'état d'avertissement.
   
   
5. Le 21 nov., 10:07 AM : Les liens ont remis à l'état initial de STP-2 vers le SGSN.
   
   
6. Le 21 nov., 10:15 AM : On observe l'amélioration dans les stats de la mise à jour d'emplacement SGSN (LU).
   
   
7. Le 21 nov., 10:00 ? 10:30 AM : Les statistiques commencent à s'améliorer à 10:00 AM.
   
   
8. Le 21 nov., 11:15 AM : On observe une baisse dans les stats SGSN LU.
   
   
9. Le 21 nov., 11:41 AM : Les états d'équipe STP que code de lien de signalisation (SLC)-1 de STP-2 ne reçoit pas le trafic, le SLC est remis à l'état initial, et des retours du trafic à la normale.
   
   
10. Le 21 nov., 11:42 AM : Une alarme d'encombrement est donnée sur SGSN pour SLC-1 du STP.
    
    
11. Le 21 nov., 12:00 P.M. : Après que SLC-3 soit remis à l'état initial, les stats GPRS LU s'améliorent.

Problème

Quand le HLR reçoit le message MAP_RESET, il place un indicateur pour une mise à jour d'emplacement GPRS (GLU). Quand l'équipement de l'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

 
Suivant les indications de l'exemple de sortie, il y a 950,000 contextes du protocole de données d'emballeur (PDP) actuels sur le SGSN, et la tentative d'UEs de parcourir par eux comme progressions de jour.

Quand les premiers paquets de liaison ascendante sont reçus, le SGSN déclenche un message GLU. Puisqu'il y a des centaines de milliers d'UEs, le STP ne peut pas manipuler le niveau de trafic qui est généré et il entre dans un état éternel d'encombrement.

Des messages sont alignés au SGSN, et un délai d'attente maximum de retransmission se produit. Puisque tous les messages GLU ne passent pas du SGSN au HLR, le SGSN est forcé pour détacher les abonnés mobiles et pour demander qu'ils rattachent. Tous les abonnés isolés tentent alors de se relier, qui entraîne une surtension soudaine dans le nombre de demandes d'arrivée de connexion. Puisque la protection de surcharge de réseau est appliquée, la plupart des tentatives de se relier sont dues rejeté à l'encombrement et les abonnés mobiles sont forcés pour faire une nouvelle tentative.

Pendant que cette série d'événements dévoile, elle produit des affects montants en cascade. Beaucoup envoient des messages des informations d'authentification (SAI), des messages GLU, et des messages MAP-IMEI_CHECK sont coincés dans la file d'attente SGSN ou abandonnés. Pour cette raison, tous les liens STP-1 et STP-2 atteignez un état d'encombrement. Chaque STP a quatre liens de signalisation, mais dans ce scénario, les trois premiers liens de STP-2 ne récupèrent pas pour très long.

Voici les alarmes d'encombrement, dans lesquelles vous pouvez voir que tous les liens STP entrent dans 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 affiché, seulement le processus de serveur de pair (PSP) 4 a été effacé, et le repos sont toujours dans l'é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 dépanner la question qui est décrite dans la section précédente.

Le lien STP reçoit trop de trafic

Comme décrit dans la section précédente, un lien particulier dans le STP reçoit un grand nombre de trafic. Vous pouvez voir que les trois premiers liens dans STP-2 entrent dans l'état d'encombrement et ne récupèrent jamais, ainsi seulement un lien est disponible et l'alarme d'encombrement est effacée sur SLC-3 (ou peer-server-2-peer-server-process-4). 

Selon le chargement SGSN partageant le mécanisme, il doit envoyer les paquets de la couche d'adaptation d'utilisateur du niveau 3 de la pièce de transfert des messages (MTP) (MTP3) (M3UA) également sur chacun des quatre liens. Cependant, des déroutements simples de Protocol de message réseau (SNMP), les trois premiers liens STP-2 sont éternel congestionnés, ainsi il signifie que tout les trafic est conduit au lien SLC-3 (le seul lien disponible STP pour conduire le trafic). Ceci explique pourquoi la distribution du trafic est biaisée entre les liens STP-2.

Dans des situations d'encombrement, un ou plusieurs liens alternent congestionné et les états non-congestionnés, ainsi seulement les liens disponibles partagent le trafic. Pour cette raison, il y a plus d'utilisation dans un des liens. Ceci exige d'un lien de remettre à l'état initial afin de récupérer les liens.

La prochaine sortie affiche les statistiques de niveau M3UA et détache des statistiques. Les importantes statistiques à considérer sont l'exemple 4 STP-2 PSP, 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

Cette sortie affiche que détache par seconde au moment de la question :

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

Cette sortie affiche les attachés 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 avertissent dedans l'état

Chaque nouvelle attache de l'identité d'abonné mobile provisoire de l'appel IMSI/Packet (P-TMSI) et l'acheminement de la demande de la mise à jour de zone (RAU) doivent être traités par l'IMSIMGR.

Avec une observation conservatrice, le système reçoit une valeur de crête de 6,850 demandes de l'attache 2-G par seconde et d'environ 5,313 demandes de l'attache 3-G par seconde. La valeur maximale que vous pouvez placer pour la protection de surcharge de réseau est 5,000 demandes d'attache par seconde. Afin de maintenir l'IMSIMGR dans un état fonctionnel, le système ne peut pas traiter de tels un grand nombre d'appels de l'UEs.

Cette question commence après 8h du matin, quand les portées 1,500 de taille de file d'attente relient des demandes par seconde :

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

Puisqu'il y a approximativement 12,000 demandes d'attache par seconde, presque 9,000 appels sont traités par l'IMSIMGR et rejetés. Ceci entraîne la CPU IMSIMGR traitant pour atteindre un état élevé.

Si le SGSN reçoit plus que le nombre configuré de demandes d'attache dans une deuxième, alors les demandes sont mises en mémoire tampon dans la file d'attente arpentante et seulement abandonnées quand les débordements de tampon dus à une attache d'arrivée élevée évaluent. Des messages dans la file d'attente sont traités selon un processus du first-in, first-out (FIFO) jusqu'à eux l'expiration où la vie en attente de message croise le temps d'attente configuré.

Quand vous choisissez les options d'anomalie ou de baisse basées sur votre préférence, Cisco recommande que vous employiez code de cause d'anomalie afin d'indiquer l'encombrement dans le réseau, qui te permet pour comprendre les conditions de réseau avant que vous tentiez une procédure de liaison ascendante. 

Panne HLR

Selon la 3ème spécification technique du projet de partenariat de génération (3GPP) (SOLIDES TOTAUX) 23.060, cette section décrit le comportement SGSN pendant une reprise HLR. Toutes les fois que le SGSN reçoit une remise de MAP, on s'attend à ce qu'il envoie une demande UL vers le HLR pour ses abonnés.

Quand les reprises HLR, il envoie un message de remise à chaque SGSN auxquels ou plus de ses postes mobiles (MSs) sont enregistrés. Ceci fait marquer le SGSN les contextes mobiles appropriés de Gestion comme non valides si une association SGSN-à-mobile du registre d'emplacement de centre de commutation (MSC) /Visiting (VLR) existe. Après que réception de la première trame valide de Contrôle de la liaison logique (LLC) (pour le mode A/Gb) ou après que la réception du premier GPRS valide perçant un tunnel le paquet ou la liaison ascendante de l'utilisateur de Protocol (GPT-U) signalant le message (pour le mode unité internationale) d'un poste mobile marqué, le SGSN exécute une UL au HLR comme dans la demande d'attache ou les procédures de acheminement inter-SGSN de mise à jour de zone (RA). En outre, si l'indicateur d'alerte de Non-GPRS (NGAF) est placé, la procédure dans la clause d'alerte de Non-GPRS est suivie. La procédure UL et la procédure vers le MSC/VLR pourraient être retardées par le SGSN pour une configuration maximum d'opérateur, dépendant sur l'utilisation des ressources à ce moment-là afin d'éviter le chargement de signalisation élevé.

Remarque: La sauvegarde périodique des données HLR à la mémoire permanente est obligatoire, comme décrit dans les SOLIDES TOTAUX 23.007 [5].

Recommandations

Cisco recommande que vous vous terminiez ces étapes afin de résoudre ce problème :

1. Augmentez le nombre de nouvelles connexions par seconde. Ceci peut être calculé a basé sur le nombre moyen de demandes d'attache.
   
   
2. Augmentez les transactions par seconde (TPS) dans le lien STP à une valeur idéale.
   
   
3. Changez la valeur du par défaut SCTP-RTO-MAX de 600 (600*100 = 60,000) à 5 (ms 5*100). Par exemple, pour deux STPs avec 4,000 TPS, vous pouvez prendre en charge jusqu'à 1,000 demandes d'attache par seconde du SGSN.

Remarque: Chaque demande d'attache a comme conséquence quatre transactions vers le STP, ainsi il signifie que 1,000 demandes d'attache par seconde a comme conséquence 4,000 TPS.

Dans le meilleur des cas, chaque STP a quatre liens de sorte que 125 demandes d'attache puissent être traitées par lien STP. Ceci est distribué également à travers tous les liens STP. Cependant, si un des liens descend, beaucoup de tentatives de reconnexion sont vues, la file d'attente devient complètement, et les rejets de paquet se produisent. Si plus de liens descendent, alors le trafic est inégalement distribué.

La circulation

Le trafic UE ne suit pas une mode Linéaire. Il se produit habituellement dans une rafale et avec beaucoup de tentatives de reconnexion. Le SGSN envoie le trafic par paquets au STP. À ce moment-là, les montants du trafic dépassent le TPS configuré sur le STP. Ceci fait commencer quelques liens dans le STP à annoncer la basse taille de la fenêtre s'ils traitent déjà plus d'appels, et le SGSN commence à aligner les blocs de données de SCTP qui sont alignés. Il attend alors le temporisateur RTO max pour expirer.

Si le STP envoie périodiquement une bonne taille de la fenêtre annoncée, alors vous devriez pouvoir envoyer plus de blocs de données de SCTP si la valeur SCTP_RTO_MAX est réduite à cinq secondes ou moins. La file d'attente est plus rapide effacé et une alarme d'encombrement M3UA n'est pas déclenchée. Supplémentaire, vous ne devriez pas voir l'indicateur de contrôle de flux interne déclenché par le SCTP afin de contrôler l'écoulement de paquet.

Le SGSN envoie seulement des paquets dans la quantité que le STP peut recevoir, qui est basé sur la taille de la fenêtre annoncée. Si vous augmentez le TPS par lien STP, il aide à éviter l'encombrement STP et réduit le temporisateur SCTP_RTO_MAX.

Déclencheurs pour l'alarme congestionnée par M3UA dans SGSN

Si la taille de la fenêtre annoncée dans le message sélectif d'accusé de réception de Protocole SCTP (Stream Control Transmission Protocol) (SAC) est proche de zéro (ou de zéro), alors le SGSN donne une alarme M3UA afin d'indiquer que des messages ne devraient pas être envoyés pour ce point final de pair. Ceci fait agiter ou entrer le lien dans un état congestionné. Puisque le SGSN envoie une taille de la fenêtre plus élevée, vous continuez à recevoir des données M3UA des pair-Noeuds, et ces paquets pourraient être lâchés dans la file d'attente attendante si le code de point de pair ne sort jamais de l'état congestionné.

Voici un exemple :

1. Le SCTP envoie une indication de début de contrôle de flux au M3UA.
   
   
2. Le M3UA place l'indicateur actif d'encombrement pour l'association et commence à voter le SCTP périodiquement au sujet de son état de contrôle de flux.
   
   
3. Tandis qu'une association est dans le contrôle de flux, elle aligne de futures demandes de données de cette association jusqu'à ce que le QUEUE_SIZE ait atteint 8,000. À ce moment là, de futurs messages pour l'association sont jetés.
   
   
4. Si le STP envoie une taille de la fenêtre annoncée appropriée, alors les tentatives M3UA de vider les messages qui sont alignés jusqu'à ce qu'ils atteignent 5,000. Le temporisateur RTO joue également un rôle en cela.

Les messages de SCTP sont alignés seulement pour associations où l'indicateur de contrôle de flux devient vrai, et les processus SGSN puis selon 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 affiché, la raison derrière l'encombrement est que le nombre total de blocs sortants dépasse la limite 5,000 (8050+143=8193) et frappe le 60-deuxième temporisateur maximum RTO, qui a comme conséquence des demandes jetées de données de SCTP. En outre, il y a un temporisateur plus élevé RTO.