HiCellTek HiCellTek
العودة إلى المدونة
الالتقاط السلبياختبار السيناريوهاتاختبار القيادةأحداث الشبكة

الالتقاط السلبي واختبار السيناريوهات: عندما تجمع أداة واحدة بين الاثنين

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

Takwa Sebai
Takwa Sebai
مؤسسة HiCellTek · أكثر من 15 عاماً في الاتصالات
٣ أبريل ٢٠٢٦ · 10 دقيقة قراءة

الساعة 9:17 صباحاً. مهندس RF يدخل موقف السيارات تحت الأرض لمركز تجاري من ثلاثة طوابق في ضواحي الرياض. يحمل هاتف القياس الخاص به مع حملة Scripted Testing قيد التشغيل: مكالمات VoLTE آلية كل 90 ثانية، Ping مستمر، Speed Test كل 5 دقائق. السيناريو يعمل. النتائج تُسجَّل. كل شيء يبدو طبيعياً.

في المستوى -2، مشترك حقيقي يحاول إجراء مكالمة VoLTE. المكالمة تفشل. الجهاز يرسل CM_DS_CALL_EVENT_ORIG، يتلقى رفضاً من الشبكة، ينفذ تراجعاً إلى CSFB، ويُنشئ المكالمة أخيراً على 3G مع تأخير 4.3 ثانية. المشترك يشعر بانقطاع. جودة تجربته تدهورت بشكل قابل للقياس.

سيناريو القياس لم يلتقط أياً من هذا. كان مشغولاً بتنفيذ تسلسل مكالمة VoLTE الخاص به، والتي اكتملت بنجاح في تلك اللحظة بالذات لأنها استخدمت قناة مختلفة وتوقيتاً مختلفاً.

هذا السيناريو ليس افتراضياً. إنه النقطة العمياء الهيكلية لكل أدوات اختبار القيادة التي تعتمد حصرياً على Scripted Testing.

الفجوة بين القياس المُتحكَّم فيه والتجربة الحقيقية

أدوات القياس التقليدية تعمل وفق مبدأ بسيط: المهندس يحدد سيناريو، الأداة تنفذه، والنتائج تُسجَّل. مكالمات VoLTE كل 60 ثانية. Speed Test لـ DL/UL كل 3 دقائق. Ping مستمر إلى خادم مرجعي. هذا النموذج عمل لعقدين.

لكن الشبكة التي يراها السيناريو ليست الشبكة التي يعيشها المشترك.

وفقاً لبيانات GSMA المنشورة في 2025، فإن 73% من مشكلات جودة التجربة التي يبلغ عنها المشتركون تحدث خارج نوافذ الاختبار المُعدَّة في حملات اختبار القيادة. تقارير Opensignal تؤكد الاتجاه: الفرق بين مؤشرات الأداء التي تقيسها أدوات الميدان وإدراك المشترك الحقيقي يمكن أن يصل إلى 35% في البيئات الحضرية الكثيفة ويتجاوز 50% في المناطق الداخلية ذات التغطية الهامشية.

السبب حسابي بحت. سيناريو ينفذ مكالمة VoLTE كل 90 ثانية يلتقط بالضبط 40 عينة في الساعة. جهاز المشترك الحقيقي يُولّد بين 200 و600 حدث شبكة في الساعة: انتقالات RRC، مفاوضات حاملة، تغييرات نطاق، Radio Link Failures جزئية، إجراءات NAS، تحديثات Tracking Area. كل ذلك يحدث بين عينات السيناريو. كل ذلك غير مرئي لأداة القياس.

Scripted Testing مقابل Passive Capture

Scripted Testing

  • مكالمات VoLTE مجدولة كل N ثانية
  • Speed Test لـ DL/UL على فترات ثابتة
  • Ping مستمر إلى خادم مرجعي
  • MOS محسوب على المكالمات الخاصة بالأداة
  • تحكم كامل في سيناريو الاختبار
  • يقيس فقط ما يأمر به السيناريو

Passive Capture

  • كل مكالمة VoLTE حقيقية تُكتشف تلقائياً
  • جلسات البيانات تُلتقط دون إعداد
  • SMS، RRC، NAS، Radio Link Failures تُسجَّل
  • MOS محسوب على حركة المشترك الحقيقية
  • صفر سيناريوهات، صفر إعداد مسبق
  • يلتقط كل ما يختبره الجهاز

تشريح الالتقاط السلبي DIAG-Native

الالتقاط السلبي ليس مرشحاً على سجلات موجودة. إنه اعتراض مباشر لرسائل التشخيص التي يُولّدها شريحة Qualcomm في كل معاملة شبكة. في كل مرة يرسل فيها المودم أو يستقبل رسالة RRC، في كل مرة تُنشأ أو تُحرَّر جلسة بيانات، في كل مرة يتفاوض فيها الجهاز على تغيير نطاق أو ينفذ إجراء NAS، تُصدر الشريحة سجل DIAG مع طابع زمني بالميلي ثانية، ومعرف بروتوكول، ومحتوى الرسالة الكامل.

الفرق مع النهج التقليدي جوهري. أداة Scripted Testing تبدأ إجراءً (الاتصال، إرسال بيانات، عمل Ping) وتقيس نتيجة ذلك الإجراء. الالتقاط السلبي لا يبدأ شيئاً. يراقب كل ما يفعله الجهاز من تلقاء نفسه، أو كل ما تأمره الشبكة بفعله، ويسجله بنفس دقة محلل البروتوكولات.

عملياً، هذا يعني أن مهندساً يُشغّل الالتقاط السلبي على هاتف أندرويد تجاري ويتركه في جيبه لمدة ساعة يحصل على سجل كامل لكل حدث شبكة اختبره ذلك الجهاز: كل انتقال من RRC_Connected إلى RRC_Idle، كل إعادة اختيار خلية، كل Radio Link Failure، كل إنشاء وتحرير لجلسة بيانات، كل إجراء Tracking Area Update.

تدفق الالتقاط السلبي DIAG-Native
1. شريحة Qualcomm تُولّد سجل DIAG لكل معاملة شبكة (RRC، NAS، CM، ESM)
2. محرك الالتقاط السلبي يعترض كل سجل في الوقت الفعلي، بدون Polling أو أخذ عينات
3. كل حدث يُصنَّف حسب طبقة البروتوكول (RRC، RACH، PHY، NAS، HO، CM) ويُختم زمنياً بالميلي ثانية
4. الأحداث تُعرض في الوقت الفعلي مع مؤشرات RF المرتبطة (RSRP، RSRQ، SNR، RSSI) للربط الفوري

لا يوجد Polling. لا يوجد أخذ عينات. لا يوجد Buffer بمقدار 500 ميلي ثانية يُنعّم الواقع. كل حدث يُلتقط في اللحظة التي تعالجه فيها الشريحة، بدقة الميلي ثانية.

التقارب: Scripted + Passive في جهاز واحد

هنا يصبح الفرق ملموساً. Scripted Testing والالتقاط السلبي ليسا بديلين. هما متكاملان، وقيمتهما الحقيقية تظهر عندما يعملان في وقت واحد على نفس الجهاز.

فلنتأمل سيناريو مهندس ينفذ حملة اختبار قيادة حضرية. سيناريوه الآلي يُطلق مكالمة VoLTE كل 60 ثانية و Speed Test كل 5 دقائق. تلك القياسات المُتحكَّم فيها تعطيه خط أساس للأداء: معدل نجاح المكالمات، MOS، Throughput لـ DL/UL، زمن الاستجابة.

لكن بينما ينفذ السيناريو تسلسله، يسجل الالتقاط السلبي بالتوازي كل ما تفعله الشبكة بالجهاز بين عينات السيناريو. إعادة اختيار خلية غير متوقعة بين مكالمتين مجدولتين. Radio Link Failure جزئي تعافى منه قبل العينة التالية للسيناريو. تغيير نطاق من Band 3 إلى Band 20 أدى إلى تدهور Throughput لمدة 12 ثانية، غير مرئي لـ Speed Test الذي نُفّذ بعد 3 دقائق.

النتيجة تشخيص مزدوج الدقة. القياسات المُتحكَّم فيها للسيناريو تعطي مؤشرات الأداء المرجعية. الالتقاط السلبي يكشف كل ما يحدث بين تلك القياسات. معاً، يُزيلان النقطة العمياء التي لا يستطيع أي نهج سدها بمفرده.

نتيجة MOS توضح هذا التكامل. Scripted Testing يحسب MOS على مكالمات VoLTE تبدأها الأداة نفسها: ظروف متحكَّم فيها، مدة محددة مسبقاً، Codec معروف. الالتقاط السلبي يُتيح حساب MOS على مكالمات VoLTE الحقيقية للمشترك، باستخدام خوارزمية ViSQOL من Google: نموذج Machine Learning إدراكي يُقيّم جودة الصوت دون الحاجة إلى إشارة مرجعية. الفرق بين MOS السيناريو (4.1) و MOS المكالمة الحقيقية للمشترك (3.2) هو بالضبط الفجوة التي لا تستطيع أدوات القياس التقليدية قياسها.

وكل هذا يعمل على هاتف أندرويد تجاري. بدون أجهزة مخصصة. بدون وحدة تحكم Rack-Mounted. بدون ترخيص لكل ميزة. جهاز واحد يفعل ما كان يتطلب سابقاً أداتين منفصلتين، ترخيصين، وغالباً جهازين فعليين.

ما تكشفه شاشة الأحداث في الظروف الحقيقية

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

لقطة الشاشة أدناه تُظهر جلسة حية: مكالمة VoLTE أجراها المستخدم (وليس سيناريو)، مع أحداث الشبكة المُلتقطة تلقائياً، ومؤشرات RF الحية في الأعلى، وفلاتر طبقات البروتوكول المُرمّزة بالألوان.

شاشة Events في HiCellTek — التقاط ميداني حي
10:24
100%
Params
Events
Settings
About
SIM 1
SIM 2
ECI: 24237067 TAC: 50437 eNB: 96185
4G
PCI 430 · 524
RSRP RSRQ SNR RSSI
-115
-13.6
-1.2
-82.5
RRC
RACH
PHY
NAS
HO
CM
Search events... 44
NAS10:22:17.773
#1636
LTE_ESM_OUTGOING_MSG
RRC10:22:15.845
#3191
NR_RADIO_LINK_FAILURE
RRC10:22:15.784
#1606
LTE_RRC_STATE_CHANGE
CM10:22:14.471
#521
CM_BAND_PREF
CM10:22:13.960
#1729
CM_DS_CALL_EVENT_ORIG
CM10:22:13.851
#2257
CM_SSAC_TIME
RRC10:22:13.089
#3191
NR_RADIO_LINK_FAILURE
RRC10:22:08.366
#1606
LTE_RRC_STATE_CHANGE

في جلسة ميدانية مدتها 25 دقيقة في بيئة حضرية، تعرض الشاشة 44 حدثاً ملتقطاً. كل حدث يحمل طابعاً زمنياً بدقة الميلي ثانية، ومعرف طبقة بروتوكول، وسياق RF في لحظة الحدث.

الأحداث تظهر مصنفة حسب طبقة البروتوكول، كل منها برمز لونه الخاص:

طبقات البروتوكول في الالتقاط السلبي
📡RRCRadio State / Connection
📶RACHRandom Access
🔢PHYPhysical Layer
🔀NASCore Signaling
🔄HOHandover / Mobility
📞CMCall Management

يظهر NR_RADIO_LINK_FAILURE بحدود حمراء عند 09:17:23.847. في تلك اللحظة، مؤشرات RF تُظهر RSRP = -115 dBm، RSRQ = -13.6 dB، SNR = -1.2 dB، RSSI = -82.5 dBm. الربط فوري: Radio Link Failure في NR مع SNR سلبي و RSRP هامشي يشيران إلى منطقة تغطية NR غير كافية حيث كان يجب على الجهاز تنفيذ Fallback إلى LTE مبكراً.

بعد ثلاث ثوانٍ، LTE_RRC_STATE_CHANGE يؤكد أن الجهاز سقط إلى LTE وأعاد إنشاء الاتصال. PCI الخلية LTE المستهدفة، و ECI، و TAC، و eNB ID مرئية جميعها، مما يسمح بتحديد الخلية التي هبط عليها الجهاز بدقة.

CM_DS_CALL_EVENT_ORIG عند 09:18:01.234 يسجل بدء مكالمة VoLTE من قبل مشترك. هذه المكالمة لم يبدأها أي سيناريو. إنها مكالمة حقيقية أجراها مستخدم الجهاز. نتيجتها، ومدتها، و Codec المستخدم، وجودة الصوت تُلتقط جميعها تلقائياً.

في وقت لاحق من الجلسة، LTE_ESM_OUTGOING_MSG يكشف إجراء إنشاء جلسة بيانات. CM_BAND_PREF يُظهر تغيير تفضيل النطاق. CM_SSAC_TIME يشير إلى قيد زمني للتحكم في الوصول الخاص بالخدمة (Service Specific Access Control)، الذي في ظروف الازدحام يمكن أن يحجب مكالمات VoLTE للمشترك دون أن يكتشف ذلك أي سيناريو اختبار قيادة.

الشاشة تدعم البحث النصي والتصفية حسب طبقة البروتوكول. دعم Dual SIM يسمح بالتمييز بين أحداث كل شريحة. هوية الخلية الكاملة (PCI، ECI، TAC، eNB) ترافق كل حدث للتحديد الجغرافي الدقيق.

ما الذي يتغير عملياً في ممارسة اختبار القيادة

الجمع بين Scripted Testing والالتقاط السلبي في جهاز أندرويد واحد ليس تحسيناً تدريجياً. إنه تغيير جذري في ما يستطيع مهندس RF تشخيصه في الميدان.

مع Scripted Testing وحده، يحصل المهندس على صورة دورية لأداء الشبكة: مكالمة كل دقيقة، Throughput كل 5 دقائق، Ping مستمر. الفواصل بين العينات هي نقاط عمياء. إذا استمرت مشكلة 8 ثوانٍ وحدثت بين عينتين من السيناريو، فهي غير موجودة في بيانات الحملة.

مع إضافة الالتقاط السلبي، تتوقف تلك الفواصل عن كونها نقاطاً عمياء. كل انتقال RRC، كل Radio Link Failure، كل إعادة اختيار خلية، كل إجراء NAS يُسجَّل بطابع زمني بالميلي ثانية. يستطيع المهندس إعادة بناء التسلسل الكامل للأحداث التي أدت إلى تدهور ما، وليس مجرد ملاحظة النتيجة النهائية.

الأثر التشغيلي مباشر. مشغل ينفذ حملات اختبار قيادة بـ Scripted Testing فقط يحتاج لمضاعفة حملاته لزيادة التغطية الزمنية لقياساته. سيناريوهات أكثر، تكرار أعلى، أجهزة أكثر، تراخيص أكثر. مشغل يجمع بين Scripted و Passive يحصل على تغطية زمنية 100% من اللحظة الأولى: كل حدث يُلتقط، كل ثانية موثقة.

وهذا التقارب يحدث على جهاز يحمله المهندس بالفعل في جيبه. هاتف أندرويد تجاري بشريحة Qualcomm، بدون تعديلات على الأجهزة، بدون Dongles خارجية، بدون وحدات تحكم Rack، بدون تراخيص لكل ميزة مُكدَّسة.

تقنية DIAG-Native. صُمِّمت وطُوِّرت في فرنسا. سيادة تكنولوجية مُطبَّقة على تشخيص الشبكات.

السؤال المفتوح

إذا حدث Radio Link Failure مدته 3 ثوانٍ بين عينتين من سيناريو بفاصل 60 ثانية، ولم تلتقطه أي أداة اختبار قيادة، هل حدث فعلاً؟

بالنسبة لشبكة المشغل، نعم. بالنسبة للمشترك الذي فقد مكالمته، نعم. بالنسبة لمؤشرات أداء حملة اختبار القيادة، لا.

الالتقاط السلبي لا يحل محل Scripted Testing. إنه يُكمله. يسد الفجوة بين ما نقيسه وما يختبره المشترك. ويفعل ذلك على الجهاز الوحيد المهم: الهاتف الذي يحمله المهندس بالفعل في يده.

ما هو أكثر حدث شبكة غير متوقع اكتشفته في الميدان، حدث لم يكن أي سيناريو ليلتقطه؟

مشاركة: LinkedIn X
Takwa Sebai
Takwa Sebai

مؤسسة HiCellTek. أكثر من 15 عاماً في الاتصالات — جانب المشغل، جانب المصنع، جانب الميدان. تبني الأداة الميدانية التي يستحقها مهندسو RF.

هل أنت مستعد للميدان؟

اطلب عرضاً توضيحياً مخصصاً لـ HiCellTek — تشخيص شبكات 2G/3G/4G/5G على Android.