يبدو أحد سيناريوهات استكشاف الأعطال الشائعة في شبكات 5G بسيطًا في البداية: يسجل UE بنجاح، ويتم إنشاء PDU Session، ويُخصص عنوان IP بصورة صحيحة، ومع ذلك يفشل الوصول إلى الويب ولا يعمل حتى اختبار Ping الأساسي. وقد تُظهر لقطات الحزم وصول المرور إلى UPF عبر N3، من دون خروج حزمة مقابلة عبر المسار المتوقع. وإذا ظل التحليل مركزًا فقط على إشارات AMF ونتيجة إنشاء PDU Session، فقد يصعب عزل السبب الحقيقي.
إن إنشاء PDU Session بنجاح لا يعني تلقائيًا أن مسار توجيه مستوى المستخدم أصبح جاهزًا للعمل. بعد استقبال الحزمة، تستخدم UPF أولًا PDR لتحديد المرور، ثم تطبق FAR (Forwarding Action Rule، قاعدة إجراء التوجيه) المرتبطة لتحديد ما يحدث بعد ذلك: توجيه الحزمة أو إسقاطها أو تخزينها مؤقتًا أو إنشاء نسخة منها. ويمكن لـFAR أيضًا تحديد واجهة الوجهة وما إذا كان يلزم إنشاء ترويسة خارجية لنفق GTP-U.
من منظور استكشاف الأعطال، يفيد هذا الفصل بين الأدوار: تجيب PDR عن السؤال «إلى أي جلسة وأي تدفق مرور تنتمي هذه الحزمة؟»، بينما تجيب FAR عن السؤال «بعد تحديد الحزمة، ماذا يجب أن تفعل بها UPF؟» وعندما تبدو إجراءات مستوى التحكم طبيعية لكن مرور المستخدم يستمر في الفشل، تصبح FAR على واجهة N4 نقطة مهمة يجب فحصها.
لماذا لا يضمن نجاح PDU Session اتصال مستوى المستخدم؟
إن اكتمال إجراء PDU Session Establishment يؤكد فقط تهيئة موارد الجلسة المطلوبة في مستوى التحكم. أما مرور التطبيقات الفعلي فما زال يعتمد على مسار مستوى المستخدم الكامل الذي يشمل gNB وN3 وUPF وN6.
في PDU Session نموذجية للإنترنت، ينتقل مرور uplink من UE إلى gNB، ويُغلف داخل نفق GTP-U، ثم يصل إلى UPF عبر N3. يجب على UPF إزالة الترويسة الخارجية المناسبة للنفق، وتحديد المرور، ثم توجيه الحزمة الأصلية نحو شبكة البيانات. أما downlink فيعمل بالاتجاه العكسي: يدخل المرور إلى UPF من N6، وتحدد UPF الـPDU Session المقابلة، وتحصل على معلومات نفق مستوى المستخدم في gNB، وتضيف الترويسة الخارجية المطلوبة لـGTP-U، ثم ترسل الحزمة إلى gNB عبر N3.
لا يصبح سلوك التوجيه هذا متاحًا لمجرد إنشاء PDU Session. يجب على SMF تزويد UPF بقواعد PFCP المناسبة عبر N4. تقوم PDR بتحديد المرور المطابق، بينما تحدد FAR إجراء التوجيه الذي سيُطبق بعد تصنيف المرور. ويلزم كلا النوعين من القواعد لمعالجة مستوى المستخدم بصورة صحيحة.
عندما تبدو جميع إشارات مستوى التحكم طبيعية بينما تظل الخدمة غير متاحة، يمكن تقسيم المشكلة إلى سؤالين أساسيين:
هل تحدد PDR المرور الحالي بصورة صحيحة؟
بعد تحديد الحزمة، هل تحتوي FAR المرتبطة على معلمات المعالجة والتوجيه الصحيحة؟
غالبًا ما يكون التركيز على العلاقة بين PDR وFAR أكثر كفاءة من إعادة مراجعة إجراء إنشاء PDU Session كاملًا من البداية في كل مرة.
ماذا تطلب FAR فعليًا من UPF أن تفعل؟
FAR هي قاعدة توجيه ضمن إطار PFCP. تقوم SMF بتزويد UPF بها عبر N4، وتُربط بالمرور من خلال FAR ID الذي تشير إليه PDR. وعندما تطابق الحزمة تلك PDR، تنفذ UPF سلوك المعالجة المحدد في FAR المشار إليها.
يمكن أن تحتوي FAR على عدة Information Elements. وفي استكشاف أعطال مستوى المستخدم، تكون الحقول التالية مهمة بصورة خاصة:
| معلمة FAR | الوظيفة الرئيسية |
|---|---|
| FAR ID | يعرّف مثيل FAR بشكل فريد لكي تتمكن PDR من الإشارة إلى قاعدة التوجيه الصحيحة |
| Apply Action | يحدد الإجراء الأساسي للحزمة، بما في ذلك التوجيه أو الإسقاط أو التخزين المؤقت أو التكرار |
| Forwarding Parameters | تحدد الوجهة وNetwork Instance وتغليف النفق والمعلمات الأخرى المستخدمة عندما يكون التوجيه مطلوبًا |
| Duplicating Parameters | تحدد كيفية توجيه النسخة المكررة من الحزمة عند تفعيل تكرار المرور |
| BAR ID | يشير إلى Buffering Action Rule المستخدمة للتحكم في سلوك تخزين الحزم مؤقتًا |
عمليًا، تعد Apply Action وForwarding Parameters أكثر عنصرين عرضة للخلط. تجيب Apply Action عن «ما الإجراء الذي ينبغي تنفيذه؟»، بينما تجيب Forwarding Parameters عن «إذا كان سيتم توجيه الحزمة، فكيف وإلى أين يجب إرسالها؟»
إن ظهور علامة FORW في Apply Action لا يثبت وحده اكتمال مسار downlink. فما زال من الضروري أن تكون Destination Interface وNetwork Instance ومعلومات Outer Header Creation وبقية معلمات التوجيه المرتبطة صحيحة.
كيف تحدد Apply Action أول خطوة في معالجة الحزمة؟
تُمثل Apply Action بمجموعة من أعلام البت التي توجه UPF إلى العمليات الأساسية التي يجب تطبيقها على الحزم المطابقة. وهذه الأعلام ليست مجرد خيارات متنافية؛ بل يجب تفسير معناها ضمن سياق جلسة PFCP وسيناريو الخدمة.
DROP: إسقاط الحزمة المطابقة.
FORW: توجيه الحزمة وفق Forwarding Parameters المطبقة.
BUFF: تخزين الحزمة مؤقتًا بدلًا من توجيهها فورًا.
NOCP: يستخدم في سيناريوهات التخزين المؤقت لإخطار مستوى التحكم عند وصول بيانات downlink تحتاج إلى التخزين المؤقت.
DUPL: إنشاء نسخة مكررة من الحزمة ومعالجة تلك النسخة وفق Duplicating Parameters.
لماذا نحتاج إلى BUFF وNOCP؟
تظهر حالة نموذجية عندما يكون UE في وضع الخمول ولا يتوفر مسار downlink فوري لمستوى المستخدم. قد يكون مرور downlink قد وصل بالفعل إلى UPF، لكنه لا يستطيع الوصول إلى UE بعد. يمكن لـUPF تخزين الحزمة مؤقتًا واستخدام سلوك إشعار مستوى التحكم المرتبط عند الحاجة، حتى تبدأ إجراءات لاحقة مثل paging أو استعادة مسار مستوى المستخدم.
يشير BUFF فقط إلى ضرورة التخزين المؤقت. أما تفاصيل كيفية تنفيذ التخزين فترتبط بـBAR، لذلك لا ينبغي أن يعتمد استكشاف الأعطال على علامة BUFF وحدها.
لماذا يعني DUPL أكثر من مجرد «إعادة توجيه الحزمة مرة أخرى»؟
ينشئ DUPL نسخة مستقلة من الحزمة. تستمر الحزمة الأصلية في مسار المعالجة المعتاد، بينما يتم التحكم في النسخة المكررة بصورة مستقلة بواسطة Duplicating Parameters. ويمكن للنسخة استخدام Destination Interface مختلفة أو إعداد مختلف للترويسة الخارجية أو Transport Level Marking أو Forwarding Policy.
لذلك لا ينبغي افتراض أن المرور المرآتي أو المكرر يتبع تلقائيًا المسار نفسه الذي يتبعه مرور الخدمة الأصلي. ويجب فحص معلمات التكرار بصورة منفصلة.
كيف تحدد Forwarding Parameters الوجهة الفعلية للحزمة؟
عندما تتضمن Apply Action قيمة FORW، تحدد Forwarding Parameters مسار التوجيه الفعلي. وتوجد عدة حقول مهمة بصورة خاصة عند استكشاف أعطال مستوى المستخدم.
Destination Interface
تحدد Destination Interface الواجهة المنطقية التي يجب على UPF إرسال الحزمة إليها بعد المعالجة. وفي سيناريو downlink نموذجي تضبط على Access، أي أن الحزمة يجب أن تُوجه نحو gNB. أما مرور uplink فعادةً ما يُوجه نحو جانب Core.
يمكن أن تؤدي Destination Interface غير الصحيحة إلى عطل يصعب اكتشافه: تطابق PDR الحزمة بصورة صحيحة، لكن الحزمة تُرسل إلى واجهة منطقية خاطئة، بينما قد لا يظهر مستوى التحكم أي خطأ واضح.
Network Instance
تحدد Network Instance سياق الشبكة المنطقي المستخدم للتوجيه. وتكون مهمة بصورة خاصة في البيئات التي تحتوي على عدة DNNs أو شرائح أو شبكات بيانات ويجب إبقاء المرور منفصلًا بينها.
عند استكشاف اتصال N6 أو خدمات الشبكات الخاصة، لا يكفي التحقق من إمكانية الوصول المادي. يجب أيضًا أن تطابق Network Instance في FAR إعداد UPF المقابل. وقد يمنع عدم التطابق توجيه المرور إلى سياق الشبكة المتوقع.
Outer Header Creation
تعد Outer Header Creation من المعلمات الأساسية لتوجيه downlink عبر N3. تحتوي الحزمة الداخلة إلى UPF من N6 على حمولة UE الأصلية. وقبل إرسالها إلى gNB عبر N3، تحتاج UPF إلى إضافة التغليف الخارجي المطلوب GTP-U/UDP/IP.
توفر Outer Header Creation المعلومات اللازمة لهذه العملية، بما في ذلك عنوان مستوى المستخدم في gNB وTEID لنفق N3 ونوع الترويسة الخارجية.
يمكن تتبع كثير من الحالات التي يصل فيها مرور downlink إلى UPF لكن لا تظهر حزمة مقابلة على N3 إلى معلومات مفقودة أو خاطئة في هذا الجزء من FAR، مثل TEID غير صحيح أو عنوان gNB خاطئ.
معلمات Forwarding Parameters أخرى
يمكن أن تتضمن Forwarding Parameters أيضًا Redirect Information وTransport Level Marking وForwarding Policy وHeader Enrichment وLinked Traffic Endpoint ID وProxying وDestination Interface Type ومعلومات اختيارية أخرى.
يمكن استخدام Transport Level Marking لتطبيق وسم DSCP المطلوب على الحزم الموجهة. ويمكن لـForwarding Policy الإشارة إلى سياسة توجيه مهيأة محليًا في UPF. ويدعم Header Enrichment معالجة إضافية للترويسات في الخدمات المناسبة. ولا تحتوي كل FAR على جميع Information Elements هذه؛ فالمحتوى الفعلي يعتمد على إشارات PFCP ومتطلبات الخدمة.
لماذا قد يتم تحديث FAR الخاصة بالـdownlink بعد إنشاء الجلسة؟
أثناء إجراء PDU Session Establishment الأولي، يمكن لـSMF إنشاء أول PDRs وFARs في UPF. ولكن في تلك اللحظة قد لا يكون gNB قد أكمل تخصيص موارد مستوى المستخدم للـdownlink على N3. ولذلك قد لا يكون TEID النهائي للنفق وعنوان مستوى المستخدم في gNB متاحين بعد لـSMF.
بعد أن يخصص gNB تلك الموارد وتصبح معلومات مستوى المستخدم المقابلة على N3 متاحة لـSMF، يمكن لـSMF إرسال PFCP Session Modification لتحديث FAR الموجودة في UPF بمعلمات نفق downlink المطلوبة.
يمكن أن تتضمن FAR المحدثة للـdownlink معلومات التوجيه الأساسية التالية:
Destination Interface = Access، بما يشير إلى التوجيه نحو جانب الوصول؛
قيمة Network Instanceالمطبقة؛
Outer Header Creation = GTP-U/UDP/IPv4 أو نوع ترويسة خارجية آخر مناسب؛
عنوان IP لمستوى المستخدم N3 في gNB وTEID المخصص للنفق.
لهذا السبب لا ينبغي أن يتوقف استكشاف الأعطال بعد فحص PFCP Session Establishment Request فقط. قد تحتوي FAR الأولية على إجراء التوجيه الأساسي فقط، بينما يمكن إضافة المعلومات اللازمة لإنشاء نفق N3 الفعلي للـdownlink لاحقًا من خلال PFCP Session Modification.
إذا تم تجاهل هذا التحديث اللاحق أثناء التحليل، فمن السهل اعتبار عملية التزويد المرحلي الطبيعية للقواعد على أنها إعداد FAR مفقود أو غير مكتمل.
كيف تعيد FAR مرور downlink إلى نفق N3؟
يساعد تتبع مسار حزمة downlink بالكامل على فهم دور FAR بشكل أوضح.
تصل حزمة من خادم خارجي إلى UPF عبر N6. تستخدم UPF قاعدة PDR لتحديد المرور وربطه بالـPDU Session الصحيحة، ثم تقرأ FAR التي تشير إليها تلك PDR.
إذا كانت Apply Action تتضمن FORW، تقيّم UPF الـForwarding Parameters. ويعني ضبط Destination Interface على Access أن الحزمة يجب أن تُرسل نحو جانب الوصول الراديوي. وتحتوي Outer Header Creation على عنوان نفق gNB وTEID اللازمين لإنشاء الترويسة الخارجية GTP-U. بعد ذلك تغلف UPF الحزمة الأصلية وترسلها إلى gNB عبر N3.
يمكن تلخيص المسار الكامل كما يلي:
تصل حزمة downlink على N6 → تحدد PDR مرور UE → تطبق FAR قيمة FORW → تحصل UPF على معلمات نفق gNB N3 → تنشئ UPF الترويسة الخارجية GTP-U → تُرسل الحزمة إلى gNB عبر N3.
يوضح ذلك أيضًا الفرق بين FAR وGTP-U. فـGTP-U هو بروتوكول النفق الذي يحمل بيانات المستخدم، بينما FAR هي قاعدة القرار في UPF التي تتحكم في ما إذا كان يجب إنشاء ترويسة خارجية للنفق، وما معلومات النفق التي ينبغي استخدامها، وأي واجهة منطقية يجب أن تستقبل الحزمة.
لذلك فإن TEID غير الصحيح الظاهر في لقطة N3 ليس سوى العرض المرئي للمشكلة. يجب أن يعود التحقيق إلى مستوى التحكم: هل خصص gNB معلومات مستوى المستخدم الصحيحة؟ هل استلمتها SMF بصورة صحيحة؟ وهل كُتبت بعد ذلك في FAR المناسبة عبر تحديث N4؟
كيف يمكن استخدام FAR لاستكشاف PDU Session قائمة لكن من دون اتصال بيانات؟
إذا كان تسجيل UE طبيعيًا وتم إنشاء PDU Session لكن الخدمة لا تزال لا تعمل، فيمكن اتباع التسلسل الفعلي لمعالجة الحزم داخل UPF بدلًا من إعادة تشغيل إجراء التسجيل بالكامل من البداية.
تسلسل عملي لاستكشاف FAR هو:
التأكد من وصول الحزمة إلى UPF. إذا لم تصل أي حزمة على N3 أو N6، فالمشكلة تقع قبل FAR ويجب أولًا فحص UE أو gNB أو مسار النقل.
التأكد من أن PDR تطابق الحزمة. لا يكون لدى FAR أي مرور لمعالجته ما لم يتم أولًا تحديد الحزمة بواسطة PDR المرتبطة.
التحقق من FAR ID التي تشير إليها PDR. التأكد من أن الحزمة المطابقة بصورة صحيحة غير مرتبطة بقاعدة توجيه خاطئة.
فحص Apply Action. تحديد ما إذا كان السلوك المهيأ هو FORW أو DROP أو BUFF أو مجموعة من الأعلام المناسبة.
فحص Destination Interface وNetwork Instance. التأكد من إرسال الحزمة نحو الاتجاه المنطقي وسياق الشبكة الصحيحين.
فحص Outer Header Creation. بالنسبة إلى مرور N3 للـdownlink، يجب التحقق من عنوان gNB وTEID ونوع الترويسة الخارجية.
مراجعة رسائل PFCP Session Modification. لا تكتفِ بفحص Create FAR الأولية. تأكد من أن معلومات نفق gNB تم تحديثها لاحقًا داخل UPF.
مقارنة لقطات حزم N3 وN6. مقارنة السلوك المتوقع وفق قواعد PFCP بالحزم التي أرسلتها UPF فعليًا.
الميزة الرئيسية لهذا الأسلوب هي أن قواعد مستوى التحكم ولقطات حزم مستوى المستخدم تستطيع التحقق من بعضها البعض. توضح إشارات PFCP كيف ينبغي لـUPF أن توجه الحزمة، بينما توضح لقطات N3 وN6 ما الذي قامت به UPF فعليًا .
عندما لا يتطابق المنظوران، يمكن عادةً حصر نطاق العطل في واحد من ثلاثة مجالات: تزويد خاطئ لقواعد N4، تنفيذ غير صحيح للقواعد داخل UPF، أو مشكلة في مسار نقل مستوى المستخدم. وهذا أكثر كفاءة بكثير من البحث في كامل 5G Core دون اتجاه واضح.
الأسئلة الشائعة
ما الفرق الرئيسي بين FAR وPDR؟
تقوم PDR باكتشاف الحزم وتصنيفها، وتجيب عن أسئلة مثل الجلسة وتدفق المرور اللذين تنتمي إليهما الحزمة. أما FAR فتحدد ما يحدث بعد المطابقة، بما في ذلك كيفية معالجة الحزمة والجهة التي يجب توجيهها إليها. وتشير PDR إلى FAR المقابلة عبر FAR ID.
لماذا قد يفشل التوجيه حتى عندما تتضمن Apply Action قيمة FORW؟
تشير FORW فقط إلى ضرورة تنفيذ التوجيه. أما نجاحه فيعتمد أيضًا على Forwarding Parameters المرتبطة. فإذا كانت Destination Interface أو Network Instance أو معلومات Outer Header Creation غير صحيحة، فقد تفشل الحزمة في الوصول إلى الوجهة المتوقعة. ومن الأمثلة النموذجية TEID غير الصحيح على N3 أو عنوان مستوى المستخدم في gNB غير الصحيح.
لماذا تفتقر FAR في أول PFCP Session Establishment أحيانًا إلى معلومات نفق N3 الكاملة؟
إن إنشاء PDU Session إجراء متعدد المراحل. وعند إنشاء جلسة PFCP الأولية، قد لا يكون gNB قد خصص بعد موارد مستوى المستخدم النهائية للـdownlink على N3. وبعد توفر عنوان نفق gNB وTEID، يمكن لـSMF تحديث FAR عبر PFCP Session Modification. لذلك يجب أن يتابع استكشاف الأعطال تبادلات N4 اللاحقة بالإضافة إلى رسالة الإنشاء الأولية.
ما العلاقة بين Outer Header Creation وPDR Outer Header Removal؟
تُطبق الوظيفتان على اتجاهين متعاكسين في معالجة النفق. فبالنسبة إلى مرور uplink القادم من N3، تستخدم Outer Header Removal لإزالة الترويسة الخارجية المناسبة لـGTP-U. وبالنسبة إلى مرور downlink الخارج من UPF نحو N3، توفر Outer Header Creation في FAR المعلومات اللازمة لإنشاء ترويسة GTP-U خارجية جديدة. وبذلك تدعمان اتجاهي تغليف وفك تغليف نفق مستوى المستخدم.
إذا كان TEID على N3 خاطئًا، فهل يجب أن يركز استكشاف الأعطال على GTP-U فقط؟
لا. إن لقطة حزم N3 تظهر فقط أن TEID المستخدم غير صحيح. تنشأ معلومات النفق في gNB، ثم تعالجها SMF، وبعد ذلك يتم تزويد FAR بها عبر N4. لذلك يجب تتبع تخصيص gNB والمعلومات التي استلمتها SMF وتحديث FAR ضمن إجراء PFCP Session Modification لتحديد السبب الفعلي.
