Inhoud

Inleiding

Achtergrondinformatie

Probleem

Oplossing

STP-link ontvangt te veel verkeer

IMSIMGR in de staat van waarschuwing

HLR-fout

Aanbevelingen

verkeersstroom

Triggers voor M3UA gecongested Alarm bij SGSN

Inleiding

Dit document beschrijft een probleem dat wordt aangetroffen op het Support Node (GPRS) van de Cisco 5000 Series geaggregeerde services router (ASR). Hierin worden ook een aantal mogelijke reparaties aan dit onderwerp beschreven.

Achtergrondinformatie

Deze specifieke reeks gebeurtenissen op het ASR SGSN wordt in dit document beschreven:

1. 21 nov., 6:25 uur: Een MAP_RESET is verzonden door het register van de Thuislocatie (HLR).

2. 21 nov., 8:13 uur: Een congestiealarm wordt verhoogd voor Signal Transfer Point 2 (STP-2).

3. 21 nov., 8:23 uur: Een congestiealarm wordt verhoogd voor STP-1 en STP-2.

4. 21 nov., 8:48: De International Mobile Subscriber Identity Manager (IMSIMGR) gaat naar de waarschuwingsstatus.

5. 21 nov., 10:07: De verbindingen die zijn hersteld van STP-2 naar het SGSN.

6. 21 nov., 10:15: Verbetering wordt waargenomen in de SGSN Location Update (LU) status.

7. 21 nov., 10:00 keer  10:30 : De statistieken beginnen om 10.00 uur te verbeteren.

8. 21 nov., 11:15 uur : Een afname wordt waargenomen in de SGSN LU staten.

9. 21 nov., 11:41 Het STP-team rapporteert dat Signaling Link Code (SLC)-1 van STP-2 geen verkeer ontvangt, de SLC wordt teruggezet en het verkeer keert terug naar de normale toestand.

10. 21 nov., 11:42 Een congestiealarm wordt verhoogd op SGSN voor SLC-1 van de STP.

11. 21 nov., 12:00 uur: Nadat SLC-3 is gereset verbeteren de GPRS LU status.

Probleem

Wanneer de HLR het MAP_RESET bericht ontvangt, wordt er een vlag ingesteld voor een GPRS Location Update (GLU). Wanneer de gebruikersapparatuur (UE) de eerste pakketten met uplinks verstuurt, verstuurt de SGN een GLU-bericht naar de HLR.

At  7 AM SGSN , Nov 21st 2014 had

******** show subscriber summary *******

Total Subscribers:             2386266

Active:                        2386266

sgsn-pdp-type-ipv4:            942114

Zoals wordt getoond in de voorbeelduitvoer, zijn er 950.000 Packer Data Protocol (PDP)-contexten aanwezig op het SGSN en de UEs proberen door hen te bladeren naarmate de dag vordert.

Wanneer de eerste uplink-pakketten worden ontvangen, leidt SGN een GLU-bericht in. Aangezien er honderdduizenden EU's zijn, kan STP niet omgaan met de hoeveelheid verkeer die wordt gegenereerd en kan het zich in een permanente congestiestand begeven.

Berichten worden in de wachtrij geplaatst bij het SGSN, en er vindt een maximale uitzendtijd plaats. Aangezien alle GLU-berichten niet van het SGSN naar de HLR gaan, is het SGSN gedwongen de mobiele abonnees te ontsluiten en te vragen dat ze een stap verder gaan. Alle uitbestede abonnees proberen dan toe te voegen, wat een plotselinge toename van het aantal inkomende koppelingsverzoeken veroorzaakt. Aangezien de bescherming tegen overbelasting op het netwerk wordt toegepast, worden de meeste pogingen om het netwerk toe te voegen afgewezen wegens congestie en worden de mobiele abonnees gedwongen een nieuwe poging te doen.

Als deze keten van gebeurtenissen zich ontwikkelt, veroorzaakt het cascading-effecten. Velen Verzend de berichten van de Verificatie (SAI), de GPRU berichten, en de berichten van de MAP-IMEI_CHECK worden vastgehouden in de SGN rij of gedaald. Om deze reden, bereiken alle STP-1 en STP-2 links een congestiestatus. Elke STP heeft vier signaleringslinks, maar in dit scenario herstellen de eerste drie koppelingen van STP-2 niet heel lang.

Hier zijn de congestiealarmen, waarin je kunt zien dat alle STP links naar de congestiestand op STP-2 bewegen:

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

Zoals aangetoond is alleen Peer Server PROCES (PSP) 4 gewist en is de rest nog steeds in de congestiestatus:

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

Oplossing

In deze sectie wordt beschreven hoe u problemen kunt oplossen bij de kwestie die in de vorige sectie wordt beschreven.

STP-link ontvangt te veel verkeer

Zoals beschreven in de vorige sectie, ontvangt één bepaalde link in de STP een grote hoeveelheid verkeer. U kunt zien dat de eerste drie verbindingen in STP-2 naar de staat van de congestie bewegen en nooit herstellen, zodat slechts één verbinding beschikbaar is en het congestiealarm op SLC-3 (of peer-server-2-peer-server-proces-4) wordt gewist.

Overeenkomstig het SGN load sharing mechanisme moet het Message Transfer Part (MTP) Level 3 (MTP3) User Adapter Layer (M3UA) op alle vier koppelingen naar elkaar sturen. Echter, van de vallen Simple Network Message Protocol (SNMP) zijn de eerste drie STP-2 links per jaar gestreept, wat betekent dat al het verkeer naar de SLC-3 link wordt routeverkeer (de enige beschikbare STP-link). Dit verklaart waarom de verkeersdistributie tussen de STP-2 links scheefgetrokken is.

In congestiesituaties, één of meer verbindingen tussen verstopte en niet-verstopte staten, dus alleen de beschikbare verbindingen delen het verkeer. Om deze reden is er meer gebruik in één van de links. Hiervoor is een link nodig die is hersteld om de koppelingen te herstellen.

De volgende output toont de M3UA-statistieken en de zoekstatistieken. De belangrijke statistieken die in overweging moeten worden genomen zijn STP-2 PSP instantie 4, waar abnormaal verkeer kan worden gezien:

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

Hier zijn de STP-gegevens:

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

In deze output worden de details per seconde weergegeven op het moment van de uitgifte:

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

In deze uitvoer worden de bijlagen per seconde per WEM weergegeven:

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 in de staat van waarschuwing

Elk nieuw vraag IMSI/Packet Tijdelijke Mobiele Subscriber Identity (P-TMSI) hevelen en Routing Area Update (RAU) moet worden verwerkt door het IMSIMGR.

Met een conservatieve waarneming ontvangt het systeem een piekwaarde van 6.850 2-G-verzoeken per seconde en ongeveer 5.313 3-G-verzoeken per seconde. De maximum waarde die u kunt instellen voor de bescherming tegen netwerkoverbelasting is 5.000 verzoeken per seconde. Om IMSIMGR in een opereerbare staat te houden, kan het systeem niet met zo'n groot aantal oproepen van de EU's omgaan.

Dit probleem begint na 8.00 uur, wanneer de wachtrijgrootte 1.500 aanvragen per seconde bereikt:

network-overload-protection sgsn-new-connections-per-second 500 action

reject-with-cause congestion queue-size 1500 wait-time 5

Aangezien er ongeveer 12.000 verzoeken per seconde zijn, worden bijna 9.000 oproepen verwerkt door het IMSIMGR en verworpen. Dit zorgt ervoor dat de IMSIMGR CPU-verwerking een hoge status heeft.

Als het SGSN meer dan het geconfigureerde aantal verzoeken in een seconde ontvangt, worden de verzoeken in de verpakkingsrij gebufferd en alleen gedaald wanneer de buffer overstroomt door een hoge inbound-snelheid. Berichten in de wachtrij worden verwerkt in overeenstemming met een First-In, First-Out (FIFO)-proces tot zij verouderd zijn wanneer de wachttijd van het in de wachtrij gestelde bericht wordt overschreden.

Wanneer u de opties afwijzen of laten vallen op basis van uw voorkeur, raadt Cisco u aan een code van de afwijzende oorzaak te gebruiken om congestie in het netwerk aan te duiden, die u toestaat om de netwerkvoorwaarden te begrijpen alvorens u een uplink procedure probeert.

HLR-fout

In dit deel wordt het SGSN-gedrag tijdens een herstart van de HLR beschreven in het kader van het derde-Generation Partnership Project (3GPP) Technical Specification (TS) 23.060. Wanneer het SGSN een MAP-reset ontvangt, wordt verwacht dat het een UL-verzoek naar de HLR voor zijn abonnees zal sturen.

Wanneer een HLR opnieuw begint, verstuurt het een resetbericht naar elk SGSN waaraan een of meer van zijn Mobiele Stations (MS) zijn geregistreerd. Dit zorgt ervoor dat het SGSN de relevante mobiele beheercontexten ongeldig markeert als er een SGN-to-Mobile Switching Center (MSC)/Visiting Location Register (VLR) vereniging bestaat. Na ontvangst van het eerste geldige Logical Link Control (LLC) frame (voor A/Gb-modus) of na ontvangst van het eerste geldige GPRS Tunneling Protocol User (GPT-U)-pakket of het uplink-signaleringsbericht (voor Iu-modus) van een gemarkeerd mobiel station voert het SGN een UL uit naar de HLR zoals in het attach-verzoek of de interSGN-procedures voor routing Area (RA). Als de niet-GPRS-alarmvlag (NGAF) is ingesteld, wordt ook de procedure van de niet-GPRS-alarmclausule gevolgd. De UL-procedure en de procedure ten aanzien van de MSC/VLR kunnen door het SGSN worden uitgesteld voor een maximale configuratie van de exploitant, afhankelijk van het gebruik van middelen op dat moment om een hoge signaalbelasting te voorkomen.

Opmerking: De periodieke back-up van de HLR-gegevens naar niet-vluchtige opslag is verplicht, zoals beschreven in TS 23.007 [5].

Aanbevelingen

Cisco raadt u aan deze stappen te voltooien om dit probleem op te lossen:

1. Vergroot het aantal nieuwe verbindingen per seconde. Dit kan worden berekend op basis van het gemiddelde aantal verzoeken om bijlagen.

2. Verhoog de Transacties per seconde (TPS) in de STP-link naar een ideale waarde.

3. Verander de standaard SCTP-RTO-MAX waarde van 600 (600*100 = 60.000) naar 5 (5*100 ms). Bijvoorbeeld, voor twee STP's met 4.000 TPS, kunt u tot 1.000 verzoeken per seconde van het SGN steunen.

Opmerking: Elk aanhechtingsverzoek resulteert in vier transacties naar de STP, wat betekent dat 1.000 verzoeken per seconde met 4.000 TPS worden gevoegd.

Idealiter heeft elke STP vier links zodat er 125 attach aanvragen kunnen worden verwerkt per STP-link. Dit wordt gelijkelijk verdeeld over alle STP-koppelingen. Als een van de koppelingen echter naar beneden gaat, worden er veel herverbindingspogingen gezien, wordt de rij vol en worden er pakketjes weggegooid. Als er meer links naar beneden gaan, is het verkeer ongelijk verdeeld.

verkeersstroom

Het EU-verkeer volgt niet lineair. Het gebeurt meestal bij een breuk en met veel herverbindingspogingen. Het SGSN stuurt het verkeer in bundels naar het STP. Op dat moment overtreft de verkeersbedragen de geconfigureerde TPS in de STP. Dit veroorzaakt sommige verbindingen in STP om te beginnen met het adverteren van lage venstergrootte als zij reeds meer oproepen verwerken en SGN begint de SCTP gegevensgroepen in een rij te zetten die in de wachtrij staan. Het wacht vervolgens op de RTO MAX-timer.

Als STP periodiek een goede geadverteerde venstergrootte verstuurt, dan zou u meer SCTP gegevensgroepen moeten kunnen verzenden als de SCTP_RTO_MAX waarde verminderd is tot vijf seconden of minder. De wachtrij wordt sneller gewist en er wordt geen M3UA-congestiealarm geactiveerd. Daarnaast dient u de vlag Interne Flow Control niet te zien die door SCTP is geactiveerd om de pakketstroom te kunnen controleren.

SGN stuurt alleen pakketten in de hoeveelheid die STP kan accepteren, die gebaseerd is op de geadverteerde venstergrootte. Als u de TPS per STP-link verhoogt, helpt het om STP-congestie te voorkomen en wordt de SCTP_RTO_MAX-timer beperkt.

Triggers voor M3UA gecongested Alarm bij SGSN

Als de geadverteerde venstergrootte in het bericht van de Selectieve Erkenning (SCTP) van het Protocol van de Controle van de Besturing (SACK) dichtbij nul (of nul) is, dan verhoogt SGN een M3UA alarm om aan te geven dat de berichten niet voor dat peer eindpunt moeten worden verzonden. Dit veroorzaakt de koppeling naar flap of verplaats naar een verstopte status. Aangezien SG een hogere venstergrootte verstuurt, blijf u M3UA gegevens van de peer-knopen ontvangen, en die pakketten kunnen in de wachtrij worden geworpen als de peer point code nooit uit de verstopte staat komt.

Hierna volgt een voorbeeld:

1. SCTP stuurt een stroomregelingindicatie naar M3UA.

2. M3UA stelt de actieve vlag van de congestie voor de associatie in en begint periodiek de SCTP over zijn status van de stroomcontrole te vragen.

3. Terwijl een vereniging in flow control is, wachtrij staat voor toekomstige data verzoeken om die associatie tot de QUEUE_SIZE 8.000 heeft bereikt. Op dat moment worden toekomstige berichten voor de associatie weggegooid.

4. Als STP een correct geadverteerd venstergrootte verstuurt, dan probeert M3UA de berichten leeg te maken die in de wachtrij staan tot 5.000. De RTO-timer speelt ook een rol in dit venster.

De SCTP-berichten worden alleen in de wachtrij geplaatst voor verenigingen waar de flow control flag True wordt, en SGSN verwerkt vervolgens volgens de STP-respons:

*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

Zoals aangetoond is de reden achter de congestie dat het totale aantal uitgaande eenheden de limiet van 5.000 overschrijdt (8050+143=8193) en de maximale timer van 60 seconden van RTO bereikt, wat resulteert in afgedankte SCTP-gegevensverzoeken. Er is ook een hogere RTO-timer.