تظهر مشكلة شائعة أثناء استكشاف أعطال مستوى المستخدم في 5G Core: يكون UE مسجلاً بصورة طبيعية، وتكون PDU Session قد أُنشئت، ويحدد PDR حركة البيانات بشكل صحيح، ويقوم FAR بتمرير الحزم عبر المسار المتوقع، ومع ذلك تظل عدادات الاستخدام الظاهرة لدى SMF دون تغيير. قد لا يتم تشغيل أحداث الفوترة، أو قد لا يستجيب التحكم في الحصة في الوقت المتوقع. وفي حالات كثيرة يكون تمرير الحزم نفسه يعمل بصورة صحيحة. ما ينقص هو آلية تخبر UPF بكيفية قياس استخدام مستوى المستخدم ومتى يجب إرسال نتيجة القياس إلى مستوى التحكم. هذه الآلية هي URR (Usage Reporting Rule) على واجهة N4.

لا تحدد URR إلى أين يجب تمرير الحزم، كما أنها لا تفرض حدود النطاق الترددي بصورة مباشرة. وبدلاً من ذلك، توضح لـUPF أي حركة بيانات مطابقة يجب قياسها، وكيف يجب قياس هذا الاستخدام، وتحت أي شروط ينبغي إرسال نتيجة القياس إلى مستوى التحكم. وبذلك تحول URR حركة بيانات مستوى المستخدم من بيانات يجري تمريرها فقط إلى بيانات يمكن قياس استخدامها أيضاً. تنفذ UPF القياس الفعلي، ويقوم SMF بتوفير شروط الإبلاغ عبر PFCP، بينما تشكل Usage Reports الناتجة حلقة تغذية راجعة مستمرة بين مستوى المستخدم ومستوى التحكم.

ما المشكلة التي تحلها URR ضمن إطار قواعد N4؟

أسهل طريقة لفهم URR هي فصل مسؤوليتها عن مسؤوليات PDR وFAR وQER. عندما تستقبل UPF حزمة، يحدد PDR أولاً نوع حركة البيانات التي تنتمي إليها. وبعد تصنيف الحزمة يقرر FAR كيفية التعامل معها وإلى أين يجب تمريرها. ويطبق QER معالجة QoS المطلوبة. أما URR فتجيب عن سؤال مختلف: ما مقدار حركة البيانات هذه الذي تم استخدامه فعلياً؟

يمكن تلخيص الأنواع الرئيسية لقواعد PFCP كما يلي:

PDR: ما نوع حركة البيانات هذه؟
FAR: كيف يجب التعامل مع الحزمة وإلى أين ينبغي تمريرها؟
QER: ما معالجة QoS التي يجب تطبيقها على هذه الحركة؟
URR: ما مقدار هذه الحركة الذي تم استخدامه، ومتى يجب الإبلاغ عن هذا الاستخدام؟

يجب ربط URR بـPDR ذي الصلة. والسبب مباشر: لا تستطيع UPF قياس «مقدار ما استهلكه المستخدم» بصورة ذات معنى ما لم تعرف أولاً أي الحزم تنتمي إلى ذلك UE أو الخدمة أو تدفق البيانات. وبعد أن يحدد PDR حركة البيانات، تستطيع URR المرتبطة به قياس استخدام الحزم المطابقة. وإذا احتوت PDU Session على عدة PDRs، فيمكن أيضاً استخدام URRs مختلفة لإنشاء علاقات أكثر دقة لقياس الاستخدام.

ولهذا السبب، لا يكون السؤال الأول عند استكشاف مشكلة URR عادةً «هل تم توفير URR؟»، بل يكون «أي PDR يطابق حركة البيانات الجاري قياسها، وما URR ID الذي يشير إليه هذا PDR؟» إذا كان هذا الارتباط مفقوداً أو غير صحيح فلن تعمل مراحل القياس والإبلاغ اللاحقة كما هو متوقع.

كيف تحدد URR ما الذي تقيسه UPF؟

URR ليست مجرد عداد بسيط لحركة البيانات. أحد العناصر الأولى التي يتم تحديدها في Create URR هو Measurement Method، وهو الذي يخبر UPF بنوع الاستخدام المطلوب قياسه. ووفقاً لمتطلبات الخدمة يمكن أن يعتمد القياس على حجم حركة البيانات أو الوقت أو الأحداث.

بالنسبة لخدمات البيانات بالحزم الشائعة، يكون القياس المعتمد على الحجم غالباً الأسهل ملاحظة. تستطيع UPF قياس حجم حركة البيانات في الوصلة الصاعدة والوصلة الهابطة والحجم الإجمالي، بينما تحدد الحقول ذات الصلة في Volume Measurement الإحصاءات التي يتم تضمينها. ويتراكم حجم الحركة بالبايت، لذلك يمكن لـURR قياس إجمالي الاستخدام أو التمييز بين حركة UL وDL وفقاً للإعداد.

إذا كانت الإمكانية المطلوبة مفعلة، فيمكن أن يشمل القياس أيضاً عدد الحزم. على سبيل المثال، يمكن لعلامة MNOP في Measurement Information أن تطلب من UPF قياس عدد حزم الوصلة الصاعدة والوصلة الهابطة والعدد الإجمالي للحزم. وفي هذه الحالة لا يرى المشغل عدد البايتات المنقولة فقط، بل يرى أيضاً عدد الحزم التي تمت معالجتها خلال فترة القياس.

يركز القياس المعتمد على الوقت على مدة الخدمة. وبحسب الإعداد يمكن أن يشمل معلمات مثل Time Threshold وTime Quota وInactivity Detection Time وآلية قياس الوقت المطبقة. أما القياس المعتمد على الأحداث فيمكنه عد أحداث خدمة محددة وإرسال تقرير عند وصول عدد الأحداث إلى قيمة محددة.

وبذلك تجيب Measurement Method عن أهم سؤال أساسي في URR: ما المقصود بـ«الاستخدام» في هذه القاعدة؟ إذا لم يتم تحديد ذلك أولاً فمن السهل الخلط بين Threshold وQuota وReporting Trigger عند تحليل رسائل PFCP. تؤثر طريقة القياس المختارة بصورة مباشرة في نوع العدادات التي تحتفظ بها UPF، وفي تنسيق Usage Report، وفي كيفية تفسير SMF للنتيجة.

يحدد Reporting Trigger متى يجب على UPF إرسال تقرير

طريقة القياس وحدها ليست كافية. فإذا استمرت UPF في تجميع العدادات دون أي شرط للإبلاغ، فلن تكون هناك نقطة محددة يتعين عندها على SMF استلام النتيجة. ولذلك تعد Reporting Triggers جزءاً أساسياً آخر من آلية URR.

يمكن دمج هذه المحفزات وفقاً لسياسة الشبكة. يمكن استخدام PERIO للإبلاغ الدوري. ويشير VOLTH إلى ضرورة إنشاء تقرير عند بلوغ حد للحجم. أما TIMTH فينطبق على حد زمني. ويمكن لـSTART وSTOPT تشغيل Usage Reports عندما تكتشف UPF بدء حركة البيانات أو توقفها.

ترتبط مجموعة أخرى من المحفزات بدرجة أكبر بالتحكم في الحصص. يرتبط VOLQU بشروط حصة الحجم، وTIMQU بشروط حصة الوقت، وEVEQU بشروط حصة الأحداث. ويمكن أيضاً استخدام Quota Holding Time عندما تكون الحصة قد مُنحت لكن المشترك لا يولد أي حركة بيانات على مستوى المستخدم خلال مدة محددة.

من المهم بصورة خاصة التمييز بين Threshold وQuota، لأن لكل منهما غرضاً مختلفاً في PFCP، وغالباً ما يحدث خلط بينهما أثناء تحليل التتبعات:

يرتبط Threshold أساساً بـمتى يجب الإبلاغ عن نتيجة القياس، بينما ترتبط Quota بدرجة أكبر بـمقدار الموارد المتبقية والمتاحة للاستخدام. إذا أظهر تتبع PFCP فقط أن VOLTH أو VOLQU مضبوط، ولم يفحص المهندس معلمة Threshold أو Quota المقابلة، فمن السهل إساءة فهم منطق الخدمة الفعلي.

على سبيل المثال، إذا تم إعداد VOLTH لكن Volume Threshold المقابل لم يُحدد بصورة صحيحة، فلن يكون لدى UPF حد ذو معنى لحركة البيانات يمكن عنده تشغيل التقرير المتوقع.

كيف ترسل UPF نتائج الاستخدام إلى SMF؟

تشكل آلية URR حلقة تغذية راجعة مكتملة عبر إجراء PFCP Session Report. بمجرد تحقق شرط للإبلاغ تحدده URR، لا تحتاج UPF بالضرورة إلى انتظار SMF حتى يستعلم عن العدادات. يمكنها إرسال PFCP Session Report Request إلى SMF.

عندما يشير Report Type إلى أن الرسالة تحتوي على Usage Report، يستطيع SMF التعرف على الحدث باعتباره تقريراً عن استخدام المستخدم. وتوجد عدة حقول مهمة بصورة خاصة أثناء التحليل. يحدد URR ID القاعدة التي أنشأت التقرير. ويحدد UR-SEQN تسلسل Usage Report الخاص بتلك URR. أما Usage Report Trigger فيوضح سبب إنشاء التقرير.

تظهر قيم القياس الفعلية بعد ذلك في الحقول التي تتوافق مع Measurement Method. في القياس المعتمد على الحجم يمكن أن يتضمن Volume Measurement قيم الاستخدام الإجمالي والوصلة الصاعدة والوصلة الهابطة. وفي القياس المعتمد على الوقت تصبح Duration Measurement أكثر أهمية. كما تساعد حقول مثل Start Time وEnd Time وTime of First Packet وTime of Last Packet في تحديد فترة القياس الدقيقة التي يغطيها التقرير.

لا يعني استلام Usage Report بالضرورة انتهاء العملية. فبحسب منطق الخدمة يمكن لـSMF أن يواصل العمل بإرسال PFCP Session Modification لتحديث URR، مثل تغيير حد الإبلاغ أو تخصيص حصة جديدة أو تعديل شروط التقرير التالي.

يمكن تلخيص سير عمل URR الكامل كما يلي:

يوفر SMF قاعدة URR → تقيس UPF حركة البيانات المطابقة → يتحقق شرط Reporting Trigger → ترسل UPF تقرير Usage Report → يعالج SMF نتيجة الاستخدام → يتم تحديث URR عند الحاجة.

لذلك لا يقتصر الإبلاغ عن الاستخدام على رفع UPF لقيمة عداد. إنه عملية ديناميكية يحدد فيها مستوى التحكم سياسة القياس، وينفذ مستوى المستخدم عملية القياس، ثم تعاد النتيجة باستمرار إلى مستوى التحكم. وأي مشكلة في أي مرحلة قد تؤدي إلى قيم استخدام غير دقيقة أو تقارير مفقودة.

كيف يؤدي Volume Threshold إلى تشغيل Usage Report فعلي؟

يصبح منطق URR أسهل للفهم عند وضعه في سيناريو عملي لحركة البيانات. لنفترض أن SMF ينشئ URR أثناء PFCP Session Establishment ويوجه UPF إلى استخدام قياس معتمد على الحجم لحركة البيانات التي يطابقها PDR محدد. ويتم تفعيل VOLTH باعتباره Reporting Trigger.

إذا تم إعداد Volume Threshold لـTOVOL بقيمة 10240 بايت، فهذا لا يعني أن المستخدم مسموح له باستهلاك 10240 بايت فقط كحد أقصى. بل يعني: عندما يصل الحجم الإجمالي المقاس لحركة الوصلة الصاعدة والوصلة الهابطة إلى هذا الحد، يجب على UPF إنشاء Usage Report.

عندما يبدأ UE في توليد حركة البيانات، تستمر UPF في تمرير الحزم بصورة طبيعية بينما تقوم أيضاً بتجميع عدادات الاستخدام المحددة في URR. وعند بلوغ الحجم المتراكم حد الإبلاغ ترسل UPF رسالة PFCP Session Report Request. يحدد Usage Report المحفز VOLTH باعتباره سبب التشغيل، بينما يحتوي Volume Measurement على إجمالي الاستخدام الفعلي وقيم الوصلة الصاعدة والوصلة الهابطة المطبقة.

لا يجب أن تتوقف القيمة النهائية المبلغ عنها عند 10240 بايت بالضبط. تقيم UPF الحد أثناء معالجة حزم فعلية، وقد تنقل حزمة كاملة الاستخدام المتراكم مباشرة من قيمة أقل من الحد إلى قيمة أعلى منه. ولذلك فإن ظهور قيمة في Usage Report أعلى قليلاً من Threshold المحدد لا يعد تناقضاً.

ويقود ذلك إلى مبدأ مهم عند تحليل سلوك URR: Threshold هو حد للإبلاغ، وليس آلية تقطع القيمة المقاسة عند رقم دقيق. وإذا تم إعداد Quota في الوقت نفسه فقد يؤدي نفاد الحصة إلى تشغيل سلوك تحكم إضافي، لكن ينبغي تحليل ذلك كمسار تحكم منفصل بدلاً من الخلط بينه وبين تقرير بسيط قائم على الحد.

يجب أن يتبع استكشاف أعطال URR أربع طبقات: الارتباط والقياس والتشغيل والإبلاغ

قد يكون من الصعب ملاحظة مشكلات URR لأن خدمة مستوى المستخدم نفسها قد تبدو طبيعية تماماً. يستطيع UE الوصول إلى الشبكة، ويطابق PDR حركة البيانات بصورة صحيحة، ويواصل FAR تمرير الحزم، بينما تظل عدادات الاستخدام الظاهرة في النظام الخلفي غير صحيحة، أو لا يتم إنشاء Usage Report، أو لا يقع حدث مستوى التحكم المتوقع بعد بلوغ الحد.

ولهذا السبب لا ينبغي أن يبدأ استكشاف أعطال URR بالسؤال «هل يستطيع المستخدم الوصول إلى الشبكة؟». بل يجب تتبع سلسلة قياس الاستخدام بالكامل.

ابدأ بتأكيد ارتباط PDR بـURR

ابدأ بتحديد PDR الذي يطابق حركة البيانات فعلياً، ثم أكد URR ID المرتبط به. قد تحتوي PFCP Session واحدة على عدة PDRs وعدة URRs. تحليل URR غير الصحيحة لن يفسر نتائج الاستخدام الحالية حتى إذا بدت جميع معلمات تلك URR صحيحة.

تتمثل مشكلة نموذجية في أن شرط المطابقة الخاص بـPDR قد تغير بينما تظل URR مرتبطة بـPDR ID سابق. في هذه الحالة يكون هدف القياس نفسه قد ابتعد عن حركة البيانات الفعلية.

ثم تحقق من Measurement Method واتجاه القياس

تحقق مما إذا كانت URR مضبوطة على قياس Volume أوDuration أوEvent. وإذا كان القياس معتمداً على الحجم، فتحقق أيضاً مما إذا كانت القاعدة تقيس Total أوUL أوDL أو عدد الحزم.

هذه الخطوة مهمة بصورة خاصة عندما لا تتوافق إحصاءات الوصلة الصاعدة والهابطة مع المتوقع. بعض الأعطال الظاهرية تحدث ببساطة لأن URR تقيس اتجاهاً واحداً فقط، بينما تمر حركة الاختبار في الاتجاه الآخر، فيظل العداد المتوقع دون تغيير.

تحقق من Reporting Trigger وThreshold المقابل

إذا لم تنشئ UPF تقريراً، فتأكد من المحفز الذي طلبه مستوى التحكم فعلياً. قد يؤدي إعداد VOLTH من دون Volume Threshold مناسب، أو توقع تقارير دورية عندما لا يكون PERIO مفعلاً، إلى نتائج تختلف عن سلوك الخدمة المقصود.

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

وأخيراً تتبع PFCP Session Report

بعد تحقق شرط التشغيل، تأكد مما إذا كانت UPF ترسل Usage Report المتوقع. راجع Report Type وURR ID وUR-SEQN وUsage Report Trigger مقابل PFCP Session الحالية.

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

إذا كانت المشكلة تتعلق بالقياس قبل تطبيق QoS أو بعده، فيجب أيضاً فحص العلامات ذات الصلة في Measurement Information وUsage Information. لا تمثل URR رقماً منفرداً معزولاً. فترة القياس الزمنية، وحركة البيانات التي يتم قياسها، ومرحلة المعالجة التي يحدث فيها القياس كلها تؤثر في كيفية تفسير قيمة الاستخدام النهائية.

كثير من الحالات التي «لا تتطابق فيها قيمة الاستخدام» لا تنتج عن خطأ في عداد UPF، بل عن عدم تطابق بين نطاق القياس الفعلي ونطاق المحاسبة المتوقع.

تحول URR حركة مستوى المستخدم إلى معلومات قابلة للقياس لصالح مستوى التحكم

تصف PDR وFAR وQER بصورة أساسية كيفية تحديد الحزم وتمريرها وإخضاعها لمعالجة QoS داخل UPF. وتضيف URR قدرة أساسية أخرى: تمكن مستوى التحكم من معرفة مقدار حركة مستوى المستخدم التي تم استهلاكها فعلياً.

تستخدم URR Measurement Method لتحديد نطاق القياس، وReporting Trigger لتحديد وقت الحاجة إلى تقرير، ومعلمات مثل Threshold وQuota وMonitoring Time للتحكم في المراحل المختلفة لقياس الاستخدام. وعند تحقق الشرط المطلوب ترسل UPF النتيجة إلى SMF ضمن PFCP Usage Report، وبعد ذلك يستطيع مستوى التحكم تحديث URR أو تنفيذ إجراء سياسة آخر عند الحاجة.

لذلك فإن الطريقة الأكثر عملية لفهم URR ليست حفظ عشرات Information Elements، بل تتبع سلسلة كاملة واحدة:

يختار PDR حركة البيانات المطلوب قياسها → تحدد URR طريقة القياس → تقيس UPF الاستخدام باستمرار → يحدد Reporting Trigger متى يتم الإبلاغ → يعيد Usage Report النتيجة إلى SMF → يحدث SMF سياسة التحكم عند الحاجة.

عندما تصبح هذه السلسلة واضحة، لا تعود معلمات مثل Volume Threshold وVolume Quota وMeasurement Period وMonitoring Time ومختلف Reporting Triggers تبدو كحقول PFCP منفصلة. بل تصبح نقاط تحكم مختلفة داخل آلية واحدة لقياس استخدام 5G والإبلاغ عنه.

بالنسبة للخدمات التي تتطلب فوترة تعتمد على الاستخدام، أو إدارة الحصص في الوقت الفعلي، أو تعديل السياسات وفقاً للاستهلاك، توفر هذه الآلية الأساس الذي يجعل مستوى المستخدم في 5G قادراً ليس فقط على تمرير حركة البيانات، بل أيضاً قابلاً للقياس والتحكم.

الأسئلة الشائعة