Table des matières

Introduction

Informations générales

Problème

Solution

La liaison STP reçoit trop de trafic

IMSIMGR en état d'alerte

Défaillance HLR

Recommandations

Flux de trafic

Déclencheurs de l'alarme encombrée M3UA dans SGSN

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 :

1. 21 nov, 6:25 AM : Un MAP_RESET a été envoyé par le Home Location Register (HLR).

2. 21 nov, 8:13 AM : Une alarme d'encombrement est déclenchée pour le point de transfert de signal 2 (STP-2).

3. 21 nov, 8h23 : Une alarme d'encombrement est déclenchée pour STP-1 et STP-2.

4. 21 nov., 8h48 : Le gestionnaire d'identité d'abonné mobile international (IMSIMGR) passe à l'état d'avertissement.

5. 21 nov, 10:07 AM : Les liaisons sont réinitialisées de STP-2 vers le SGSN.

6. 21 nov, 10:15 AM : Une amélioration est observée dans les statistiques de mise à jour de l'emplacement SGSN (LU).

7. 21 nov, 10:00 â 10:30 : Les statistiques commencent à s'améliorer à 10:00.

8. 21 nov, 11:15 : Un déclin est observé dans les stats LU SGSN.

9. 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.

10. 21 nov, 11:42 AM : Une alarme d'encombrement est déclenchée sur SGSN pour SLC-1 du STP.

11. 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.

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

Recommandations

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

1. Augmentez le nombre de nouvelles connexions par seconde. Cette valeur peut être calculée en fonction du nombre moyen de demandes d'attachement.

2. Augmentez la valeur idéale du nombre de transactions par seconde (TPS) dans la liaison STP.

3. 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.

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

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 :

1. Le SCTP envoie une indication de début de contrôle de flux à l’UA M3A.

2. 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 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.

4. 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é.