Congestion STP, état de dépassement IMSIMGR et battements de liaison SCTP dans SGSN en raison de HLR MAP_RESET
Table des matières
Introduction
Ce document décrit un problème rencontré sur le noeud de prise en charge GPRS (Packet Radio Service) de service général (SGSN) du routeur à services agrégés de la gamme Cisco 5000. Certaines solutions de contournement possibles pour 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 :
- 21 nov, 6:25 AM : Un MAP_RESET a été envoyé par le Home Location Register (HLR).
- 21 nov, 8:13 AM : Une alarme d'encombrement est déclenchée pour le point de transfert de signal 2 (STP-2).
- 21 nov, 8h23 : Une alarme d'encombrement est déclenchée pour STP-1 et STP-2.
- 21 nov., 8h48 : Le gestionnaire d'identité d'abonné mobile international (IMSIMGR) passe à l'état d'avertissement.
- 21 nov, 10:07 AM : Les liaisons sont réinitialisées de STP-2 vers le SGSN.
- 21 nov, 10:15 AM : Une amélioration est observée dans les statistiques de mise à jour de l'emplacement SGSN (LU).
- 21 nov, 10:00 â 10:30 : Les statistiques commencent à s'améliorer à 10:00.
- 21 nov, 11:15 : Un déclin est observé dans les stats LU SGSN.
- 21 nov, 11:41 AM : L'équipe STP signale que le SLC-1 de STP-2 ne reçoit pas de trafic, que le SLC est réinitialisé et que le trafic revient à la normale.
- 21 nov, 11:42 AM : Une alarme d'encombrement est déclenchée sur SGSN pour SLC-1 du STP.
- 21 nov, 12:00 PM : Après la réinitialisation du SLC-3, les statistiques GPRS LU s'améliorent.
Problème
Lorsque le HLR reçoit le message MAP_RESET, il définit un indicateur pour une GLU (GPRS Location Update). 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 y a des centaines de milliers d'UE, le STP ne peut pas gérer la quantité de trafic qui est générée et il passe dans un état d'encombrement 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 se rattachent à nouveau. Tous les abonnés détachés tentent alors de joindre, ce qui provoque une augmentation soudaine du nombre de demandes de pièce jointe entrantes. Etant donné que la protection contre la surcharge du réseau est appliquée, la plupart des tentatives de connexion sont rejetées en raison d'un encombrement et les abonnés mobiles sont forcés d'effectuer une nouvelle tentative.
À mesure que cette chaîne d'événements se développe, elle produit des effets en cascade. De nombreux messages SAI (Send Authentication Information), GLU et MAP-IMEI_CHECK sont bloqués dans la file d'attente SGSN ou abandonnés. Pour cette raison, toutes les liaisons STP-1 et STP-2 atteignent un état d'encombrement. Chaque STP a 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 d'encombrement, 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 de serveur homologue (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 protocole STP reçoit un trafic important. Vous pouvez voir que les trois premières liaisons du protocole STP-2 passent à l'état d'encombrement et ne récupèrent jamais, de sorte qu'une seule liaison est disponible et que l'alarme d'encombrement est effacée sur SLC-3 (ou peer-server-2-peer-server-process-4).
Selon le mécanisme de partage de charge SGSN, il doit envoyer les paquets de la couche d'adaptation utilisateur (M3UA) de niveau 3 (MTP3) de la partie de transfert de message (MTP) (MTP3) 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 constamment encombrées, ce qui signifie que tout le trafic est routé vers la liaison SLC-3 (la seule liaison STP disponible pour router le trafic). Ceci explique pourquoi la distribution du trafic est asymétrique entre les liaisons STP-2.
Dans les situations d’encombrement, une ou plusieurs liaisons passent de l’état encombré à l’état non encombré, de sorte que seules les liaisons disponibles partagent le trafic. Pour cette raison, il y a plus d'utilisation dans l'une des liaisons. 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 de détachement. Les statistiques importantes à prendre en compte sont l'instance 4 PSP STP-2, où un 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étachements 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 connexions par seconde, conformément à 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 d'identification d'abonné mobile temporaire IMSI/paquet (P-TMSI) jointe et de mise à jour de la zone de routage (RAU) doit être traitée par l'IMSIMGR.
Avec une observation prudente, le système reçoit une valeur de crête 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 dans un état opérationnel, le système ne peut pas traiter un nombre aussi important 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 d'attachement par seconde, près de 9 000 appels sont traités par l'IMSIMGR et rejetés. Le traitement du processeur IMSIMGR atteint alors 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 stimulation et abandonnées uniquement lorsque la mémoire tampon déborde en raison d'un taux d'attachement entrant élevé. Les messages dans la file d'attente sont traités selon un processus FIFO (First-In, First-Out) jusqu'à ce qu'ils expirent lorsque la durée de vie des messages en file d'attente dépasse le temps d'attente configuré.
Lorsque vous choisissez les options de rejet ou d'abandon en fonction de vos préférences, Cisco vous recommande d'utiliser un code de cause de rejet afin d'indiquer l'encombrement du 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 à la spécification technique (TS) 23.060 du 3rd 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 censé envoyer 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. Le SGSN marque alors les contextes de gestion mobile pertinents comme étant invalides si une association SGSN-Mobile Switching Center (MSC)/Visiting Location Register (VLR) existe. 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 paquet GPT-U (GPRS Tunneling Protocol User) valide ou du premier message de signalisation de liaison montante (pour le mode Iu) en provenance d'une station mobile marquée, le SGSN effectue une UL vers le HLR comme dans les procédures de demande d'attachement ou de mise à jour de zone de routage inter-SGSN (RA). En outre, si l'indicateur d'alerte non-GPRS (NGAF) est défini, la procédure de la clause Non-GPRS Alert 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.
Recommandations
Cisco vous recommande d'effectuer les étapes suivantes afin de résoudre ce problème :
- Augmentez le nombre de nouvelles connexions par seconde. Cette valeur peut être calculée en fonction du nombre moyen de demandes d'attachement.
- Augmentez la valeur idéale du nombre de transactions par seconde (TPS) dans la liaison STP.
- Modifiez la valeur par défaut SCTP-RTO-MAX de 600 (600*100 = 60 000) à 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.
Idéalement, chaque protocole STP possède quatre liaisons, ce qui permet de traiter 125 demandes d'attachement par liaison STP. Cette répartition est identique sur toutes les liaisons STP. Cependant, si l’une des liaisons est interrompue, de nombreuses tentatives de reconnexion sont observées, la file d’attente est pleine et les paquets sont abandonnés. Si d’autres liaisons tombent en panne, le trafic est distribué de manière inégale.
Flux de trafic
Le trafic UE n'est pas linéaire. Elle se produit généralement en rafale et avec de nombreuses tentatives de reconnexion. Le SGSN envoie le trafic par groupes au STP. À ce moment, les quantités de trafic dépassent les TPS configurées sur le STP. Cela fait que certaines liaisons du STP commencent à annoncer une taille de fenêtre faible si elles 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 minuteur RTO MAX.
Si le STP envoie périodiquement une bonne taille de fenêtre annoncée, alors vous devriez être capable d'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 d'encombrement 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 nombre de TPS par liaison STP, cela permet d'éviter l'encombrement STP et réduit le minuteur SCTP_RTO_MAX.
Déclencheurs de l'alarme encombrée M3UA dans SGSN
Si la taille de fenêtre annoncée dans le message d'accusé de réception sélectif SCTP (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 d'extrémité homologue. La liaison est alors instable ou passe à l’état encombré. Puisque le SGSN envoie une taille de fenêtre plus élevée, vous continuez à recevoir des données M3UA des noeuds homologues, et ces paquets pourraient être abandonnés dans la file d'attente si le code de point homologue ne sort jamais de l'état encombré.
Voici un exemple :
- Le SCTP envoie une indication de début de contrôle de flux à l’UA M3A.
- 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.
- Lorsqu'une association est dans le 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.
- Si le STP envoie une taille de fenêtre annoncée correcte, M3UA tente de vider les messages qui sont en file d'attente jusqu'à ce qu'il atteigne 5 000. Le temporisateur RTO joue également un rôle à cet égard.
Les messages SCTP sont mis en file d'attente seulement 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 segments sortants dépasse la limite de 5 000 (8 050+143=8 193) et atteint le minuteur RTO maximum de 60 secondes, ce qui entraîne l'abandon des demandes de données SCTP. En outre, il existe un compteur RTO plus élevé.
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
16-Apr-2015 |
Première publication |
Commentaires