المقدمة
يوضح هذا المستند كيفية أستكشاف أخطاء معدل نجاح الإرفاق 4G (ASR) وإصلاحها لمؤشرات الأداء الرئيسية (KPIs).
السيناريوهات المحتملة
يمكن أن ينتج انخفاض معدل ASR من الجيل الرابع عن عوامل متعددة:
- مشكلات الشبكة
- مشكلة خاصة بتدفق الاتصال
- مشاكل خاصة بالعقدة
- مشكلات التكوين
- مشاكل نهاية RAN
السجلات المطلوبة للتحليل الأولي
- توضح الرسومات البيانية لاتجاهات KPI التحلل.
- صيغة KPI المستخدمة للقياس.
- عدادات Raw Bulkstat وتسبب أتجاهات التعليمات البرمجية منذ بدء المشكلة.
- تم التقاط مثالين من Show Support Details (SSD) في فاصل زمني مدته 30 دقيقة أثناء الوقت المثير للمشاكل.
- تم تجميع Syslog من ساعتين قبل التحلل حتى الوقت الحالي.
- التقاط هذه السجلات:
Mon-sub/pro traces
Logging monitor msid <imsi>
تسلسل أستكشاف الأخطاء وإصلاحها
1. تحديد صيغة ASR:
1-((emm-msgtx-decode-failure+emm-msgtx-attach-rej-gw-reject+emm-msgtx-attach-rej-activation-reject+emm-msgtx-attach-rej-svc-temp-out-of-order+emm-msgtx-attach-rej-protocol-error+emm-msgtx-attach-auth-failed+attach-proc-fail-max-retx-auth-req+attach-proc-fail-max-retx-sec-mode-cmd+attach-proc-fail-max-retx-attach-accept+attach-proc-fail-setup-timeout-exp+attach-proc-fail-sctp-fail+attach-proc-fail-guard-timeout-exp+attach-proc-fail-max-retx-esm-info-req+emm-msgtx-attach-rej-gw-auth-failed+emm-msgtx-attach-rej-insuff-resources+emm-msgtx-attach-reject-congestion+emm-msgtx-attach-reject-severe-network-failure+emm-msgtx-network-failure ) / (epsattach-imsi-attempted+epsattach-guti-local-attempted+epsattach-guti-foreign-attempted+epsattach-ptmsi-attempted+combinedattach-imsi-attempted+combinedattach-guti-local-attached+combinedattach-guti-foreign-attempted+combinedattach-ptmsi-attempted))
تحذير: تختلف الصيغة بناء على طريقة "العملاء" لقياس مؤشرات الأداء الرئيسية.
2. استنادا إلى الصيغة، هناك العديد من العدادات المستخدمة لحساب ASR، لذلك من وحدات البلاك ستاتس، تحتاج إلى التحقق من إتجاه KPI لكل عداد.
3. الإتجاه السائد في مؤشر الأداء الرئيسي الذي يجب مقارنته بجداول زمنية لا تنطوي على مشاكل وجداول زمنية مثيرة للمشاكل.
4. بمجرد التعرف على عداد البلاك ستات المثير للمشاكل من صيغة مؤشر الأداء الرئيسي، يجب التحقق من كيفية تعريف هذا العداد استنادا إلى التدفق ومحاولة إنشاء نمط.
5. أيضا، قم بجمع أسباب قطع الاتصال من العقدة مع تكرارات متعددة وفترات زمنية تتراوح من 3 إلى 5 دقائق.
يمكنك العثور على دلتا أسباب قطع الاتصال من محركي أقراص مزودين بذاكرة مصنوعة من مكونات صلبة (SSD) تم تجميعهما في أختام زمنية مختلفة. يمكن إرجاع سبب انقطاع الاتصال الذي يزيد بسرعة من قطع اتصال دلتا إلى سبب انخفاض مؤشر الأداء الرئيسي. بالإضافة إلى ذلك، يتوفر وصف جميع عمليات قطع الاتصال في مرجع الإحصائيات والعدادات من Cisco؛ https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-23/Stat-Count-Reference/21-23-show-command-output/m_showsession.html.
show session disconnect-reasons verbose
فيما يلي مثال على خطوات أستكشاف الأخطاء وإصلاحها لمعالجة سيناريو انخفاض ناجم عن زيادة سبب قطع الاتصال "MME-HSS-User-Unknown". ارجع إلى https://www.cisco.com/c/en/us/support/docs/wireless/mme-mobility-management-entity/214633-troubleshoot-4g-asr-kpi-degradation-due.html.
6. تحقق من إحصائيات egtp استنادا إلى نوع العقدة.
--- SGW end -----
show egtpc statistics interface sgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only
show egtpc statistics interface sgw-egress path-failure-reasons
show egtpc statistics interface sgw-egress summary
show egtpc statistics interface sgw-egress verbose
show egtpc statistics interface sgw-egress sessmgr-only
---- PGW end -----
show egtpc statistics interface pgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only
--- MME end -----
show egtpc statistics interface mme path-failure-reasons
show egtpc statistics interface mme summary
show egtpc statistics interface mme verbose
show egtpc statistics interface mme sessmgr-only
7. لمزيد من التحليل واستكشاف أخطاء انخفاض مؤشر الأداء الرئيسي (KPI) وإصلاحها، يمكنك التقاط آثار المكالمات عبر بروتوكول Mon-sub/mon Pro والنظر في إستخدام أدوات خارجية للحصول على آثار Wireshark. تساعد هذه الآثار في التعرف على تدفق المكالمات المحدد الذي يسبب المشكلة.
الأوامر الخاصة بالتقاط مسارات Mon الفرعية هي كما يلي:
monitor subscriber imsi <IMSI number> ---------- verosity level +++++,A, S, X, Y, 19. 26, 33, 34, 35
More options can be enabled depending on the protocol or call flow we need to capture specifically
8. في الحالات التي لا يمكن فيها التقاط آثار مثل mon-sub بسبب نسبة مئوية دنيا من انخفاض مؤشر الأداء الرئيسي، قم بالتقاط سجلات تصحيح الأخطاء على مستوى النظام. أيضا، قم بالتقاط سجلات تصحيح الأخطاء للخادم و egptc، وإذا كانت المشكلة المشتبه بها تتضمن كيانات مثل HSS/RAN، قم بالتقاط سجلات تصحيح الأخطاء ل S1-AP/القطر بناء على المشكلة المحددة.
logging filter active facility sessmgr level debug
logging filter active facility egtpc level debug
logging filter active facility diameter level debug ----- depending on scenario
logging filter active facility s1-ap evel debug ----- depending on scenario
logging active ----------------- to enable
no logging active ------------- to disable
Note :: Debugging logs can increase CPU utilization so need to keep a watch while executing debugging logs
9. بمجرد أن تحصل على أي دليل من مصحح الأخطاء، بعد ذلك يمكنك أيضا التقاط ملف تخصيص لذلك الحدث المعين حيث ترى سجلات الأخطاء:
logging enable-debug facility sessmgr instance <instance-ID> eventid 11176 line-number 3219 collect-cores 1
For example :: consider we are getting below error log in debug logs which we suspect can be a cause of issue
and we don;t have any call trace
[egtpc 141027 info] [15/0/6045 <sessmgr:93> _handler_func.c:10068] [context: MME01, contextID: 6] [software internal user syslog] [mme-egress] Sending reject response for the message EGTP_MSG_UPDATE_BEARER_REQUEST with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE to <Host:x.x.x.x, Port:31456, seq_num:82011>
So in this error event
facility :: sessmgr
event ID = 141027
line number = 10068
هذه هي الخطوات المختلفة لاستكشاف أخطاء هذه المشكلة وإصلاحها.