قد يكون أحد سيناريوهات استكشاف أعطال مستوى المستخدم في 5G مربكًا في البداية: يتم إنشاء PDU Session بنجاح، ويحصل UE على عنوان IP، وتطابق PDR المرور المتوقع، وتحتوي FAR على FORW، وقد تبدأ الحزم بالفعل في التدفق. ومع ذلك قد يظل المستخدم يعاني من تخزين مؤقت للفيديو، أو معدلات تنزيل أقل من المتوقع، أو مرور يعمل في اتجاه واحد فقط.
عندما يحدث ذلك، قد لا يكشف فحص PDR وFAR وحدهما السبب. فقد لا تكون المشكلة مرتبطة بـ ما إذا كان المرور قد تم تحديده أو إلى أين تم توجيه الحزمة، بل بـ سياسة QoS التي طبقتها UPF بعد السماح بالتوجيه. ضمن إطار قواعد PFCP على واجهة N4، تكون QER (QoS Enforcement Rule، قاعدة تطبيق QoS) مسؤولة عن تطبيق سياسات QoS هذه داخل UPF. ويمكنها التحكم في السماح بمرور البيانات، وتقييد معدلات uplink أو downlink، وربط المرور بـQoS Flow، وتطبيق علامات على مستوى النقل. لذلك يجب تحليل PDR وFAR وQER معًا لفهم السلوك الكامل لمستوى المستخدم.
لماذا تظل QER ضرورية بعد أن تعمل PDR وFAR بصورة صحيحة؟
أسهل طريقة لفهم QER هي فصل مسؤوليات قواعد UPF المختلفة.
تجيب PDR أولًا عن السؤال «ما نوع هذا المرور؟». وتستخدم شروطًا مثل PDI وعنوان IP الخاص بـUE وF-TEID وSDF Filter لاكتشاف الحزم وتصنيفها. وبعد تحديد المرور، تجيب FAR عن السؤال التالي: «ماذا يجب أن يحدث لهذه الحزمة وإلى أين ينبغي توجيهها؟»
لكن السماح بتوجيه الحزمة لا يعني أنها تستطيع المرور بلا قيود. فإذا كانت الشبكة ما زالت بحاجة إلى التحكم في المعدل أو التحكم في البوابة أو الربط بـQoS Flow أو العلامات على مستوى النقل، فيجب على UPF تطبيق QER المرتبطة.
لذلك يمكن تبسيط تسلسل المعالجة النموذجي كما يلي:
PDR تحدد المرور → FAR تحدد إجراء التوجيه → QER تطبق سياسة QoS.
هذه القواعد لا تستبدل بعضها بعضًا، بل تعمل معًا. فقد تطابق الحزمة PDR بصورة صحيحة وتكون مسموحة من FAR، لكنها تظل خاضعة لحدود المعدل أو شروط التحكم في البوابة المحددة بواسطة QER. ومن دون QER قد تعرف UPF أن الحزمة يجب أن تُوجَّه، لكنها لن تملك مستوى السياسة نفسه الذي يصف كيفية معاملة ذلك المرور من منظور QoS.
متى يتم تثبيت QER ولماذا يمكن تحديثها لاحقًا؟
عادةً ما تقوم SMF بتزويد UPF بقاعدة QER أثناء PFCP Session Establishment كجزء من قواعد مستوى المستخدم الخاصة بـPDU Session. وهي ليست قاعدة QoS تنشئها UPF بصورة مستقلة بعد مراقبة المرور. يحدد مستوى التحكم سلوك QoS الذي يجب تطبيقه، بينما تنفذ UPF القاعدة الناتجة.
لا يلزم أن تبقى QER دون تغيير طوال مدة الجلسة. فإذا تغيرت السياسة أثناء تشغيل الخدمة، يمكن لـSMF تحديث QER موجودة من خلال PFCP Session Modification. ولذلك قد تؤدي تغييرات سياسة الاشتراك أو سياسة التطبيق أو قرارات أخرى في مستوى التحكم إلى حدود معدلات جديدة، أو حالات Gate مختلفة، أو تغيير الربط بـQoS Flow، أو معلمات QoS أخرى.
لهذا السبب لا ينبغي أن يتوقف استكشاف الأعطال عند Create QER الأولية. فإذا ظهرت مشكلة QoS بعد أن ظلت الجلسة تعمل لبعض الوقت، فيجب أيضًا فحص معلومات Update QER اللاحقة ومقارنتها بالقيم الأصلية.
من منظور مستوى التحكم، قد تأتي سياسة QoS التي تستخدمها SMF من إعداد محلي أو من معلومات سياسة مرتبطة بـPCF. وعندما تصل السياسة إلى واجهة N4، يتم تمثيلها كقواعد PFCP تستطيع UPF تطبيقها. وبحسب تصميم الخدمة، يمكن تطبيق QoS على مستوى PDU Session أو QoS Flow أو على مرور SDF أو تطبيق أكثر تحديدًا.
كيف يمكن لـGate Status حجب المرور حتى عندما تبدو الجلسة طبيعية؟
Gate Status من أكثر معلمات QER مباشرة لأنه يمكن أن يغير فورًا ما إذا كان المرور مسموحًا بالعبور.
يمكن التحكم في حالتي Gate للـuplink والـdownlink بصورة مستقلة. عندما تكون Gate في حالة OPEN، يُسمح للمرور في ذلك الاتجاه بالاستمرار. وعندما تكون CLOSED، تحجب قاعدة تطبيق QoS المرور في ذلك الاتجاه.
لذلك قد يبدو تسلسل استكشاف الأعطال النموذجي كما يلي:
تم إنشاء PDU Session بنجاح؛
حصل UE على عنوان IP؛
PDR تطابق بصورة صحيحة؛
FAR تحتوي على FORW؛
لكن مرور التطبيق ما زال لا يعمل.
في هذه المرحلة يجب فحص UL Gate وDL Gate في QER المرتبطة. وبما أن الاتجاهين يتم التحكم فيهما بصورة منفصلة، فقد تكون إحدى البوابتين OPEN والأخرى CLOSED. وقد يظهر العرض على شكل مشكلة أحادية الاتجاه في مستوى المستخدم: يستطيع UE استقبال downlink لكنه لا يستطيع إرسال uplink بنجاح، أو العكس.
ولهذا تُعد QER قاعدة تطبيق وليست مجرد سمة وصفية لـQoS. إذ يمكن لإعداداتها أن تحدد مباشرة ما إذا كان مرور معين مسموحًا له بالاستمرار عبر UPF.
ما الذي تتحكم فيه MBR وGBR وPacket Rate؟
تجيب Gate Status عن السؤال «هل يمكن للمرور أن يعبر؟». أما المعلمات المرتبطة بالمعدل فتجيب عن سؤال مختلف: «ما كمية المرور المسموح بها وبأي معدل؟». ويمكن لـQER تطبيق حدود تعتمد على معدل البت وكذلك على معدل الحزم.
أقصى معدل بت (MBR)
تحدد MBR أقصى معدل بت للمرور المطابق، ويمكن ضبطها بصورة مستقلة للـuplink والـdownlink. وفي بيئة 5GC قد يتعلق الحد المطبق بقيد على مستوى الجلسة، أو QoS Flow معين، أو تدفق مرور أكثر تحديدًا بحسب تصميم القواعد.
إذا كان المستخدم يستطيع الوصول إلى الخدمة بصورة طبيعية لكن معدل النقل الفعلي يتوقف باستمرار قرب سقف متكرر، فإن MBR في QER المرتبطة من المعلمات التي تستحق الفحص.
من السهل الخلط بين MBR وسعة الجانب الراديوي. فظروف الراديو الجيدة وعرض النطاق الكافي في النقل لا يضمنان قدرة التطبيق على استخدام كامل السعة الفيزيائية. فإذا طُلب من UPF تطبيق MBR أقل، سيظل معدل النقل الفعلي في مستوى المستخدم خاضعًا لذلك الحد. لذلك ينبغي أن يشمل استكشاف انخفاض معدل النقل الفعلي قواعد QoS على N4 لا أن يركز فقط على أداء الراديو.
معدل البت المضمون (GBR)
تصف GBR معدل البت المضمون المرتبط بمرور يحتاج إلى مستوى محدد من ضمان الموارد. ويمكن أيضًا تحديدها بصورة مستقلة للـuplink والـdownlink.
قد تكون GBR مهمة للخدمات التي تتطلب أداءً أكثر قابلية للتنبؤ، مثل بعض تطبيقات الصوت والفيديو في الوقت الحقيقي أو الخدمات الأخرى الحساسة لـQoS. ولا ينبغي تفسيرها كرقم منفصل؛ بل يجب أيضًا مراعاة QoS Flow المقابل وسياسة QoS الأوسع.
مفاهيميًا، تحدد MBR الحد الأعلى للمعدل المسموح، بينما تصف GBR متطلب المعدل المضمون المرتبط بسياسة الخدمة.
معدل الحزم
لا يمكن وصف بعض أنواع المرور بصورة كافية باستخدام معدل البت وحده. ويمكن أن تتضمن QER أيضًا معلمات Packet Rate التي تقيد عدد الحزم المسموح بها خلال فترة زمنية محددة.
قد يكون ذلك مهمًا لأحمال العمل التي تولد الكثير من الحزم الصغيرة، مثل معاملات DNS أو رسائل إبقاء الاتصال لأجهزة IoT أو المرور الشبيه بالإشارات. فقد يظل إجمالي معدل البت منخفضًا نسبيًا بينما يرتفع عدد الحزم في الثانية. في هذه الحالات، قد لا يفسر فحص MBR وحده سلوك QoS الملحوظ.
عند بلوغ حد Packet Rate، قد يعاني المستخدم من زيادة التأخير أو بطء الاستجابة أو فشل الطلبات، حتى عندما يبدو استهلاك عرض النطاق الإجمالي معتدلًا.
ما دور QFI وFlow Level Marking وPPI داخل QER؟
QER أكثر من مجرد محدد سرعة. فبالإضافة إلى Gate Status وMBR وGBR، يمكنها حمل معلمات مرتبطة بتحديد QoS Flow ومعالجة الحزم. وتساعد هذه المعلمات معًا في تحديد كيفية التعامل مع المرور عبر مستوى المستخدم.
QoS Flow Identifier (QFI)
تحدد QFI أحد QoS Flows. ويمكن أن تحتوي PDU Session واحدة على عدة QoS Flows بحيث يحصل كل نوع من مرور الخدمات على معالجة QoS مختلفة.
من منظور مستوى المستخدم، تحدد QFI أي QoS Flow ترتبط به الحزمة. وداخل QER يمكن استخدام هذا المعرّف لربط سلوك تطبيق QoS المناسب بـQoS Flow المقابل.
إذا لم تتطابق QFI المرتبطة بالقاعدة مع تصميم الخدمة المقصود، فقد يرتبط المرور بـQoS Flow غير متوقع حتى لو بدت معلمات المعدل صحيحة. وقد يؤدي ذلك إلى معالجة موارد مختلفة عما صُممت الخدمة لاستقباله.
DL Flow Level Marking
يمكن لـQER أن توجه UPF لتطبيق marking على مستوى التدفق على مرور downlink، مثل ضبط قيمة DSCP لشبكة نقل IP.
لا تحدد هذه العلامة أي QoS Flow في 5G تنتمي إليه الحزمة. بل تؤثر في كيفية تحديد الحزمة ومعالجتها بعد دخولها شبكة نقل IP.
إذا كانت العلامة على مستوى النقل غير صحيحة، فقد يكون QoS في 5G مهيأ بصورة صحيحة بينما تواصل شبكة النقل اللاحقة معالجة الحزمة بأولوية غير مقصودة.
Paging Policy Indicator (PPI)
يرتبط PPI بمعالجة سياسة النداء لمرور downlink. ويمكن لـQER توفير معلومات مرتبطة بسياسة النداء في سيناريوهات التوجيه المناسبة حتى تتم معاملة أنواع المرور المختلفة بصورة مختلفة عند دخول النداء في العملية.
بالنسبة إلى UE غير الموجود حاليًا في حالة نشطة لمستوى المستخدم، قد تكون لأنواع مختلفة من مرور downlink تأثيرات مختلفة على النداء. ويوفر PPI معلومات يمكن استخدامها كجزء من هذه المعالجة المتمايزة.
Averaging Window
لا يمكن دائمًا أن يستند تطبيق المعدل إلى ملاحظة لحظية لحزمة واحدة. تحدد Averaging Window الفترة الزمنية التي يتم خلالها تقييم السلوك المرتبط بمعدل البت.
تستجيب النافذة الأقصر بسرعة أكبر للمرور المتدفق على شكل دفعات، بينما تنتج النافذة الأطول متوسطًا أكثر سلاسة وقد تتعامل مع دفعات قصيرة بصورة مختلفة. ولهذا لا ينبغي أن يركز تحليل QER على QER ID وMBR فقط، إذ قد يعتمد سلوك QoS النهائي على تعاون عدة معلمات.
كيف يمكن استخدام رسائل PFCP للتحقق مما إذا كانت QER تعمل كما هو متوقع؟
الطريقة الأكثر فائدة لتحليل QER ليست حفظ كل عنصر معلومات، بل ربط قاعدة PFCP بأعراض الخدمة الفعلية.
على سبيل المثال، قد تحتوي Create QER على:
QER ID = 1؛
UL Gate = OPEN؛
DL Gate = OPEN؛
UL MBR = 100000 kbps؛
DL MBR = 150000 kbps.
هذه القيم مجرد مثال، لكنها توضح نقطة مهمة: كون Gate في حالة OPEN لا يعني عدم وجود قيود QoS. يمكن السماح للمرور بالعبور مع بقائه خاضعًا لتطبيق MBR.
يمكن أن يتبع استكشاف الأعطال العملي الخطوات التالية:
حدد PDR أولًا. حدد أي PDR تطابق بالفعل المرور المتأثر. فإذا تم اختيار PDR خاطئة، فلن تُطبق QER المتوقعة بصورة صحيحة.
تحقق من QER ID التي تشير إليها PDR. لا تفحص كل QER في جلسة PFCP من دون سياق. حدد أولًا QER المرتبطة فعلًا بالمرور الجاري تحليله.
راجع Create QER وUpdate QER. أكد ما إذا كانت القاعدة الفعالة حاليًا قد تغيرت من خلال PFCP Session Modification لاحقة. فقد تظهر مشكلة QoS بسبب تحديث لاحق، لا بسبب إعداد الجلسة الأصلي.
تحقق من Gate Status. تحقق من حالتي Gate للـuplink والـdownlink بصورة منفصلة. إغلاق Gate في اتجاه واحد فقط يمكن أن يؤدي إلى فشل خدمة أحادي الاتجاه.
تحقق من MBR وGBR وPacket Rate. قارن الحدود المهيأة مع معدل النقل الفعلي الملحوظ أو سلوك الحزم، خصوصًا إذا كانت الخدمة تتوقف باستمرار قرب معدل ثابت.
تحقق من QFI ومعلمات QoS الأخرى. تأكد من أن QoS Flow المقصود والعلامة والإعدادات المرتبطة بـالنداء تطابق تصميم الخدمة.
قارن القاعدة بمرور مستوى المستخدم الفعلي. يوضح PFCP ما يُتوقع أن تطبقه UPF، بينما توضح اختبارات معدل النقل الفعلي ولقطات الحزم ما حدث فعليًا. وغالبًا ما يكون الفرق بين الاثنين هو أفضل دليل لاستكشاف الأعطال.
هذه الطريقة أكثر موثوقية من تفسير حقل QER واحد بمعزل عن غيره. توضح إشارات PFCP ما الذي ينبغي على UPF تطبيقه، بينما توضح اختبارات مستوى المستخدم النتيجة التي تمت ملاحظتها فعليًا. ومقارنة المنظورين هي المفتاح لتحديد ما إذا كانت QER تعمل كما هو مقصود.
الأسئلة الشائعة
ما الفرق الرئيسي بين QER وFAR؟
تحدد FAR بصورة أساسية كيفية معالجة الحزمة المطابقة وإلى أين يجب توجيهها، بما في ذلك إجراءات مثل FORW وDROP وBUFF. أما QER فتطبق سلوكًا متعلقًا بـQoS مثل التحكم في البوابة وحدود المعدل والربط بـQoS Flow والعلامات على مستوى النقل. وعادةً ما تعمل القاعدتان بعد أن تحدد PDR المرور. ويمكن تبسيط العلاقة هكذا: تحدد FAR إلى أين وكيف يتم توجيه الحزمة، بينما تحدد QER معالجة QoS التي تنطبق على ذلك المرور.
لماذا يمكن أن يظل معدل النقل الفعلي لدى المستخدم منخفضًا عندما تكون Gate Status في حالة OPEN؟
تعني OPEN فقط أن المرور مسموح له بالعبور في ذلك الاتجاه، ولا تلغي قيود QoS الأخرى. يجب الاستمرار في فحص MBR وGBR وPacket Rate وQoS Flow المرتبط. إذا كانت MBR مضبوطة تحت سعة الراديو أو النقل المتاحة، فقد يظل معدل النقل الفعلي محدودًا حتى عندما تكون البوابتان مفتوحتين بالكامل.
هل يمكن إنشاء QER فقط أثناء PFCP Session Establishment؟
لا. يمكن إنشاء QER أثناء PFCP Session Establishment ثم تعديلها لاحقًا من خلال PFCP Session Modification. وإذا تغير سلوك QoS بعد أن تكون الجلسة قد بدأت بالفعل، فيجب مراجعة Update QER اللاحقة بدلًا من تحليل Create QER الأولية فقط.
هل QFI وQER الشيء نفسه؟
لا. QFI هي معرّف QoS Flow، بينما QER قاعدة تطبيق QoS تنفذها UPF. ويمكن لـQER احتواء معلومات QFI أو الإشارة إليها لربط معالجة QoS معينة بـQoS Flow المقابل. تحدد QFI أي QoS Flow معني، بينما تحدد QER كيفية تطبيق تحكم QoS على المرور.
لماذا يمكن أن يفشل المرور رغم تطابق PDR وسماح FAR بالتوجيه؟
لأن معالجة مستوى المستخدم لا تنتهي بالضرورة عند FAR. بعد السماح بالتوجيه قد تستمر QER المرتبطة في تطبيق Gate Status وMBR وGBR وPacket Rate أو قيود QoS أخرى. لذلك ينبغي أن يتعامل استكشاف الأعطال مع PDR وFAR وQER كسلسلة معالجة متصلة. وأي عدم تطابق في إحدى هذه المراحل يمكن أن يؤثر في النتيجة النهائية للخدمة.
