إزدحام بروتوكول الشجرة المتفرعة (STP)، واتصال عبر الحالة، وتقاطعات إرتباط SCTP في SGSN بسبب HLR Map_Reset
المحتويات
المقدمة
يصف هذا المستند مشكلة تتم مصادفتها على عقدة دعم (SGSN) خدمة حزمة الراديو العامة (GPRS) للخدمة من موجه الخدمات المجمعة (ASR) من سلسلة Cisco 5000. كما يتم وصف بعض الحلول الممكنة لهذه المسألة.
معلومات أساسية
يتم وصف هذه السلسلة المحددة من الأحداث في ASR SGSN في هذا المستند:
- نوفمبر 21، 6:25 صباحا: تم إرسال MAP_RESET بواسطة سجل مواقع المنزل (HLR).
- 21 نوفمبر، 8:13 صباحا: يتم رفع تنبيه الازدحام لنقطة نقل الإشارة 2 (STP-2).
- 21 نوفمبر، 8:23 صباحا: يتم رفع تنبيه الازدحام لبروتوكول STP-1 و STP-2.
- من 21 نوفمبر/تشرين الثاني، الساعة 8:48 صباحا: انتقل المدير الدولي لتحديد هوية المشترك عبر الهاتف المحمول (IMSIMGR) إلى حالة التحذير.
- نوفمبر 21، الساعة 10:07 صباحا: إعادة تعيين الارتباطات من STP-2 إلى SGSN.
- من 21 نوفمبر/تشرين الثاني، الساعة 10:15 صباحا: تمت ملاحظة التحسن في إحصائيات تحديث موقع SGSN (LU).
- 21 نوفمبر، 10:00 الساعة 10:30 صباحا: تبدأ الإحصائيات بالتحسن في الساعة 10:00 صباحا.
- من 21 نوفمبر، الساعة 11:15 صباحا: يلاحظ انخفاض في أرقام SGSN LU.
- نوفمبر 21، 11:41 صباحا: يبلغ فريق بروتوكول الشجرة المتفرعة (STP) أن رمز إرتباط الإشارات (SLC)-1 الخاص ببروتوكول الشجرة المتفرعة (STP-2) لا يستقبل حركة مرور البيانات، ويتم إعادة تعيين وحدة التحكم في الوصول إلى الوضع SLC، وتعيد حركة مرور البيانات إلى وضعها الطبيعي.
- 21 نوفمبر، 11:42 صباحا: يتم رفع تنبيه الازدحام على SGSN ل SLC-1 من STP.
- من 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 للحصول على تكوين المشغل الأقصى، ويتوقف ذلك على إستخدام الموارد في ذلك الوقت من أجل تجنب حمل الإشارات العالي.
توصيات
cisco يوصي أن أنت أتمت هذا steps in order to حللت هذا إصدار:
- زيادة عدد الاتصالات الجديدة في الثانية. ويمكن حساب ذلك استنادا إلى متوسط عدد طلبات الإرفاق.
- زيادة الحركات في الثانية (TPS) في إرتباط بروتوكول الشجرة المتفرعة (STP) إلى قيمة مثالية.
- قم بتغيير قيمة SCTP-RTO-MAX الافتراضية التي تبلغ 600 (600*100 = 60000) إلى 5 (5*100 مللي ثانية). على سبيل المثال، بالنسبة لبروتوكول الشجرة المتفرعة (STP) بمعدل 4000 تيرابت في الثانية، يمكنك دعم ما يصل إلى 1000 طلب إرفاق في الثانية من بروتوكول SGSN.
من الناحية المثالية، يحتوي كل بروتوكول الشجرة المتفرعة (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 من العقد النظيرة، وتلك الحزم قد يتم إسقاطها في قائمة الانتظار إذا لم يظهر رمز نقطة النظير أبدا من الحالة المزدحمة.
فيما يلي مثال:
- يرسل SCTP إشارة بدء التحكم في التدفق إلى M3UA.
- يقوم M3UA بتعيين علامة الازدحام النشطة للاقتران ويبدأ في إستطلاع SCTP بشكل دوري حول حالة التحكم في التدفق.
- بينما يوجد اقتران قيد التحكم في التدفق، فإنه يقوم بقوائم انتظار طلبات البيانات المستقبلية لذلك الاقتران حتى يصل QUEUE_SIZE إلى 8000. وعند تلك النقطة، يجري تجاهل الرسائل المستقبلية للاقتران.
- إذا كان بروتوكول الشجرة المتفرعة (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 أعلى.
محفوظات المراجعة
| المراجعة | تاريخ النشر | التعليقات |
|---|---|---|
1.0 |
16-Apr-2015 |
الإصدار الأولي |
التعليقات