المحتويات

المقدمة

معلومات أساسية

المشكلة

الحل

يستلم إرتباط STP حركة مرور كثيرة

إيمسنجر في حالة التحذير

فشل HLR

توصيات

تدفق حركة المرور

مشغلات تنبيه M3UA المزدحم في SGSN

المقدمة

يصف هذا المستند مشكلة تتم مصادفتها على عقدة دعم (SGSN) خدمة حزمة الراديو العامة (GPRS) للخدمة من موجه الخدمات المجمعة (ASR) من سلسلة Cisco 5000. كما يتم وصف بعض الحلول الممكنة لهذه المسألة.

معلومات أساسية

يتم وصف هذه السلسلة المحددة من الأحداث في ASR SGSN في هذا المستند:

1. نوفمبر 21، 6:25 صباحا: تم إرسال MAP_RESET بواسطة سجل مواقع المنزل (HLR).

2. 21 نوفمبر، 8:13 صباحا: يتم رفع تنبيه الازدحام لنقطة نقل الإشارة 2 (STP-2).

3. 21 نوفمبر، 8:23 صباحا: يتم رفع تنبيه الازدحام لبروتوكول STP-1 و STP-2.

4. من 21 نوفمبر/تشرين الثاني، الساعة 8:48 صباحا: انتقل المدير الدولي لتحديد هوية المشترك عبر الهاتف المحمول (IMSIMGR) إلى حالة التحذير.

5. نوفمبر 21، الساعة 10:07 صباحا: إعادة تعيين الارتباطات من STP-2 إلى SGSN.

6. من 21 نوفمبر/تشرين الثاني، الساعة 10:15 صباحا: تمت ملاحظة التحسن في إحصائيات تحديث موقع SGSN (LU).

7. 21 نوفمبر، 10:00 الساعة 10:30 صباحا: تبدأ الإحصائيات بالتحسن في الساعة 10:00 صباحا.

8. من 21 نوفمبر، الساعة 11:15 صباحا: يلاحظ انخفاض في أرقام SGSN LU.

9. نوفمبر 21، 11:41 صباحا: يبلغ فريق بروتوكول الشجرة المتفرعة (STP) أن رمز إرتباط الإشارات (SLC)-1 الخاص ببروتوكول الشجرة المتفرعة (STP-2) لا يستقبل حركة مرور البيانات، ويتم إعادة تعيين وحدة التحكم في الوصول إلى الوضع SLC، وتعيد حركة مرور البيانات إلى وضعها الطبيعي.

10. 21 نوفمبر، 11:42 صباحا: يتم رفع تنبيه الازدحام على SGSN ل SLC-1 من STP.

11. من 21 نوفمبر/تشرين الثاني، الساعة 12:00 مساء: بعد إعادة ضبط SLC-3، تتحسن أوضاع GPRS LU.

المشكلة

عندما يستلم HLR رسالة MAP_RESET، فإنه يقوم بتعيين علامة لتحديث موقع GPRS (GLU). عندما ترسل أجهزة المستخدم (UE) حزم التوصيل الأولى، يرسل SGSN رسالة GLU إلى HLR.

At  7 AM SGSN , Nov 21st 2014 had

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

Total Subscribers:             2386266

Active:                        2386266

sgsn-pdp-type-ipv4:            942114

كما هو موضح في إخراج المثال، هناك 950000 سياق لبروتوكول بيانات الحزم (PDP) موجود على SGSN، وتحاول وحدات واجهة المستخدم الاستعراض الاستعراض خلالها مع تقدم اليوم.

عند إستقبال حزم الوصلة الأولى، يقوم SGSN بتشغيل رسالة GLU. ونظرا لوجود مئات الآلاف من أدوات التحكم في الشجرة المتفرعة (STP)، فلا يمكنه معالجة كمية حركة المرور التي يتم إنشاؤها والانتقال إلى حالة إزدحام دائمة.

يتم وضع الرسائل في قائمة الانتظار في SGSN، ويحدث الحد الأقصى لمهلة إعادة الإرسال. نظرا لأن جميع رسائل GLU لا تنتقل من SGSN إلى HLR، فيتم فرض SGSN على فصل مشتركي الهواتف المحمولة وطلب إعادة إرفاقهم. ثم يحاول كافة المشتركين المفصولين إرفاقها، مما يتسبب في زيادة مفاجئة في عدد طلبات المرفقات الواردة. ونظرا لتطبيق حماية الحمل الزائد للشبكة، يتم رفض معظم محاولات الإرفاق بسبب الازدحام ويتم إجبار المشتركين في الأجهزة المحمولة على إجراء محاولة جديدة.

وبينما تتكشف هذه السلسلة من الأحداث، فإنها تنتج تأثيرات متتالية. حيث يعلق العديد من رسائل معلومات المصادقة (SAI) ورسائل GLU ورسائل MAP-IMEI_CHECK في قائمة انتظار SGSN أو يتم إسقاطها. ولهذا السبب، تصل جميع إرتباطات STP-1 و STP-2 إلى حالة إزدحام. يحتوي كل بروتوكول الشجرة المتفرعة (STP) على أربعة إرتباطات إرسال إشارات، ولكن في هذا السيناريو، لا تسترد الارتباطات الثلاثة الأولى من بروتوكول الشجرة المتفرعة (STP-2) لمدة طويلة للغاية.

فيما يلي تنبيهات الازدحام، التي يمكنك فيها رؤية نقل جميع روابط بروتوكول الشجرة المتفرعة (STP) إلى حالة الازدحام على بروتوكول 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

كما هو موضح، تم مسح عملية خادم النظير (PSP) رقم 4 فقط، ولا يزال الباقي في حالة الازدحام:

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

الحل

يوضح هذا القسم كيفية أستكشاف المشكلة الموضحة في القسم السابق وإصلاحها.

يستلم إرتباط STP حركة مرور كثيرة

كما هو موضح في القسم السابق، يستقبل إرتباط واحد معين في بروتوكول الشجرة المتفرعة (STP) كمية كبيرة من حركة المرور. يمكنك أن ترى أن الروابط الثلاثة الأولى في STP-2 تنتقل إلى حالة الازدحام ولا تتعافى مطلقا، لذلك يتوفر إرتباط واحد فقط ويتم مسح تنبيه الازدحام على SLC-3 (أو peer-server-2-peer-server-process-4).

وفقا لآلية مشاركة حمل SGSN، يجب أن يرسل جزء نقل الرسائل (MTP) المستوى 3 (MTP3) حزم طبقة ملاءمة المستخدم (M3UA) بشكل متساو على جميع الارتباطات الأربعة. ومع ذلك، من إختبارات بروتوكول رسائل الشبكة البسيط (SNMP)، تكون إرتباطات STP-2 الثلاثة الأولى مزدحمة بشكل دائم، وهو ما يعني توجيه جميع حركة مرور البيانات إلى إرتباط SLC-3 (إرتباط STP الوحيد المتوفر لحركة مرور المسار). وهذا يفسر سبب انحراف توزيع حركة المرور بين إرتباطات STP-2.

في حالات الازدحام، يتبدل رابط واحد أو أكثر بين حالات الازدحام وعدم الازدحام، لذلك فقط الروابط المتاحة تتشارك في حركة المرور. لهذا السبب، هناك إستخدام أكثر في أحد الارتباطات. وهذا يتطلب إعادة تعيين الارتباط من أجل إسترداد الارتباطات.

يوضح الإخراج التالي إحصائيات مستوى M3UA وإحصائيات الفصل. الإحصائيات الهامة التي يجب أخذها في الاعتبار هي نموذج STP-2 PSP 4، حيث يمكن رؤية حركة المرور غير العادية:

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

فيما يلي بيانات بروتوكول الشجرة المتفرعة (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

يوضح هذا الإخراج الفواصل في الثانية في وقت الإصدار:

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

يوضح هذا الإخراج الملحقات في الثانية، حسب 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

إيمسنجر في حالة التحذير

يجب أن تتم معالجة كل مكالمة جديدة لطلب تحديث منطقة التوجيه (RAU)/IMSI/Packet Temporary Mobile Subscriber Identity (P-TMSI) بواسطة IMSIMGR.

وبملاحظة متحفظة، يتلقى النظام قيمة قصوى تبلغ 6 850 طلبا من الطلبات الملحقة 2 غرام في الثانية وحوالي 5 313 طلبا من الطلبات الملحقة 3 زاي في الثانية. الحد الأقصى للقيمة التي يمكنك تعيينها لحماية الحمل الزائد للشبكة هو 5000 طلب إرفاق في الثانية. لإبقاء IMSIMGR في حالة قابلة للتشغيل، لا يستطيع النظام معالجة هذا العدد الكبير من المكالمات من UEs.

تبدأ هذه المشكلة بعد الساعة 8 صباحا، عندما يصل حجم قائمة الانتظار إلى 1500 طلب إرفاق في الثانية:

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

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

ونظرا لوجود نحو 12 000 طلب مرفق في الثانية، يقوم نظام المعلومات الإدارية المتكامل بتجهيز ما يقرب من 9 000 مكالمة ورفض هذه المكالمات. وهذا يتسبب في وصول معالجة وحدة المعالجة المركزية (CPU) الخاصة ب IMSIMGR إلى حالة عالية.

إذا كان SGSN يتلقى أكثر من عدد الطلبات التي تم تكوينها للإرفاق في ثانية، فسيتم تخزين الطلبات مؤقتا في قائمة انتظار الحزم ثم إسقاطها فقط عندما يتم تجاوز سعة التخزين المؤقت بسبب معدل إرفاق داخلي مرتفع. تتم معالجة الرسائل الموجودة في قائمة الانتظار وفقا لعملية "أول دخول وأول خروج" (FIFO) حتى تنتهي صلاحيتها عندما يتجاوز العمر الافتراضي للرسائل الموجودة في قائمة الانتظار وقت الانتظار الذي تم تكوينه.

عندما تختار خيارات الرفض أو الإسقاط بناء على تفضيلاتك، توصيك Cisco باستخدام رمز سبب الرفض للإشارة إلى الازدحام في الشبكة، والذي يسمح لك بفهم شروط الشبكة قبل أن تحاول إجراء التوصيل.

فشل HLR

طبقا للمواصفات الفنية (TS) 23.060 الخاصة بمشروع الشراكة من الجيل الثالث (3GPP)، يصف هذا القسم سلوك SGSN أثناء إعادة تشغيل HLR. كلما تلقت SGSN إعادة تعيين خريطة، من المتوقع أن ترسل طلب UL إلى HLR للمشتركين فيها.

عند إعادة تشغيل HLR، فإنها ترسل رسالة إعادة تعيين إلى كل SGSN يتم تسجيل محطة أو أكثر من محطات التنقل الخاصة بها (MSs) إليها. وهذا يتسبب في قيام SGSN بوضع علامة غير صحيحة على سياقات إدارة الأجهزة المحمولة ذات الصلة في حالة وجود اقتران SGSN-to-Mobile Switching Center (MSC)/Visit Location Register (VLR). بعد إستلام أول إطار صالح للتحكم في الارتباط المنطقي (LLC) (لوضع A/GB) أو بعد إستلام أول حزمة صالحة لمستخدم بروتوكول GPRS للاتصال النفقي (GPT-U) أو رسالة إرسال إشارات الوصلة (لوضع IU) من محطة متنقلة مميزة، يقوم SGSN بتنفيذ UL إلى HLR كما هو الحال في إجراءات تحديث طلب الإرفاق أو منطقة توجيه SGSN (RA). وفي حالة تعيين علامة تنبيه NGAF (غير GPRS) أيضا، يتم اتباع الإجراء الوارد في عبارة تنبيه GPRS. قد يتم تأخير إجراء UL والإجراء الخاص ب MSC/VLR من قبل SGSN للحصول على تكوين المشغل الأقصى، ويتوقف ذلك على إستخدام الموارد في ذلك الوقت من أجل تجنب حمل الإشارات العالي.

ملاحظة: يلزم إجراء نسخ إحتياطي دوري لبيانات المستويات المرتفعة للغاية (HLR) للتخزين غير المتطاير، كما هو موضح في المعيار TS 23.007 [5].

توصيات

cisco يوصي أن أنت أتمت هذا steps in order to حللت هذا إصدار:

1. زيادة عدد الاتصالات الجديدة في الثانية. ويمكن حساب ذلك استنادا إلى متوسط عدد طلبات الإرفاق.

2. زيادة الحركات في الثانية (TPS) في إرتباط بروتوكول الشجرة المتفرعة (STP) إلى قيمة مثالية.

3. قم بتغيير قيمة SCTP-RTO-MAX الافتراضية التي تبلغ 600 (600*100 = 60000) إلى 5 (5*100 مللي ثانية). على سبيل المثال، بالنسبة لبروتوكول الشجرة المتفرعة (STP) بمعدل 4000 تيرابت في الثانية، يمكنك دعم ما يصل إلى 1000 طلب إرفاق في الثانية من بروتوكول SGSN.

ملاحظة: ينتج عن كل طلب مرفق أربع معاملات تجاه بروتوكول الشجرة المتفرعة (STP)، مما يعني أن 1 000 طلب إرفاق في الثانية ينتج عنه 4 000 طلب/ثانية.

من الناحية المثالية، يحتوي كل بروتوكول الشجرة المتفرعة (STP) على أربعة إرتباطات بحيث يمكن معالجة 125 طلب إرفاق لكل إرتباط بروتوكول الشجرة المتفرعة (STP). يتم توزيع هذا بشكل متساو عبر جميع إرتباطات بروتوكول الشجرة المتفرعة (STP). ومع ذلك، إذا سقط أحد الروابط، تظهر العديد من محاولات إعادة التوصيل، وتمتلئ قائمة الانتظار، وتظهر مرتجعات الحزم. إذا انخفض المزيد من الروابط، يتم توزيع حركة المرور بشكل غير متساو.

تدفق حركة المرور

لا تتبع حركة مرور UE نمط خطي. عادة ما يحدث ذلك في انفجار ومع العديد من محاولات إعادة التوصيل. يرسل SGSN حركة مرور في حزم إلى بروتوكول الشجرة المتفرعة (STP). في ذلك الوقت، تتجاوز مبالغ حركة المرور وحدات TPS التي تم تكوينها على بروتوكول الشجرة المتفرعة (STP). وهذا يتسبب في بدء بعض الارتباطات في بروتوكول الشجرة المتفرعة (STP) في الإعلان عن انخفاض حجم النافذة إذا كانت تعالج بالفعل المزيد من المكالمات، ويبدأ SGSN في وضع مجموعات بيانات SCTP في قائمة الانتظار. ثم تنتظر انتهاء صلاحية مؤقت RTO MAX.

إذا كان بروتوكول الشجرة المتفرعة (STP) يرسل بشكل دوري حجم نافذة معلن عنه جيدا، فيجب أن تكون قادرا على إرسال المزيد من مجموعات بيانات SCTP إذا تم خفض قيمة SCTP_RTO_MAX إلى خمس ثوان أو أقل. يتم مسح قائمة الانتظار بشكل أسرع ولا يتم تشغيل تنبيه إزدحام M3UA. وبالإضافة إلى ذلك، يجب ألا ترى علامة التحكم في التدفق الداخلي التي يتم تشغيلها بواسطة SCTP للتحكم في تدفق الحزمة.

يرسل SGSN الحزم بالمبلغ الذي يمكن أن يقبله بروتوكول الشجرة المتفرعة (STP)، والذي يستند إلى حجم النافذة المعلن. إذا قمت بزيادة بروتوكول TPS لكل إرتباط بروتوكول الشجرة المتفرعة (STP)، فإنه يساعد على تجنب إزدحام بروتوكول الشجرة المتفرعة (STP) وتقليل مؤقت SCTP_RTO_MAX.

مشغلات تنبيه M3UA المزدحم في SGSN

إذا كان حجم النافذة المعلن عنها في رسالة الإقرار الانتقائي (SACK) لبروتوكول التحكم في البث (SCTP) قريبا من صفر (أو صفر)، فعندئذ يقوم SGSN برفع تنبيه M3UA للإشارة إلى أنه يجب عدم إرسال الرسائل لنقطة نهاية النظير هذه. وهذا يتسبب في رفرفة الارتباط أو انتقاله إلى حالة إزدحام. بما أن SGSN يرسل حجم نافذة أعلى، أنت تستمر في إستلام بيانات M3UA من العقد النظيرة، وتلك الحزم قد يتم إسقاطها في قائمة الانتظار إذا لم يظهر رمز نقطة النظير أبدا من الحالة المزدحمة.

فيما يلي مثال:

1. يرسل SCTP إشارة بدء التحكم في التدفق إلى M3UA.

2. يقوم M3UA بتعيين علامة الازدحام النشطة للاقتران ويبدأ في إستطلاع SCTP بشكل دوري حول حالة التحكم في التدفق.

3. بينما يوجد اقتران قيد التحكم في التدفق، فإنه يقوم بقوائم انتظار طلبات البيانات المستقبلية لذلك الاقتران حتى يصل QUEUE_SIZE إلى 8000. وعند تلك النقطة، يجري تجاهل الرسائل المستقبلية للاقتران.

4. إذا كان بروتوكول الشجرة المتفرعة (STP) يرسل حجم نافذة معلن عنه بشكل مناسب، فيحاول M3UA إفراغ الرسائل التي يتم وضعها في قائمة الانتظار حتى تصل إلى 5000. يلعب مؤقت RTO أيضا دورا في ذلك.

يتم وضع رسائل SCTP في قائمة الانتظار فقط لتلك الاقترانات التي تصبح فيها علامة التحكم في التدفق صحيحة، ويقوم SGSN بعد ذلك بمعالجة الرسائل وفقا لاستجابة بروتوكول الشجرة المتفرعة (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

كما هو موضح، فإن السبب وراء الازدحام هو أن العدد الإجمالي للأجزاء الصادرة يتجاوز الحد البالغ 5000 (8050+143=8193) ويصيب الحد الأقصى لتوقيت إعادة التوجيه السريع (RTO) لمدة 60 ثانية، مما ينتج عنه طلبات بيانات SCTP مهملة. أيضا، هناك مؤقت RTO أعلى.