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.
Cette chaîne spécifique d'événements sur le SGSN ASR est décrite dans ce document :
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
Cette section décrit comment résoudre le problème décrit dans la section précédente.
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
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.
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.
Cisco vous recommande d'effectuer ces étapes afin de résoudre ce problème :
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.
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.
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 :
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é.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
16-Apr-2015 |
Première publication |