عندما يفتح جهاز UE تطبيق فيديو، يجب أن تنتقل حركة بيانات المستخدم الفعلية من gNB إلى UPF قبل أن تصل إلى شبكة البيانات. تتولى طبقة التحكم إنشاء PDU Session وتخصيص العناوين وتثبيت قواعد إعادة التوجيه، لكن البروتوكول الذي ينقل فعلياً حزم IP الخاصة بالمستخدم عبر طبقة المستخدم في شبكة الوصول والنواة 5G هو GTP-U. وفهم GTP-U يتطلب أكثر من مجرد تذكر «المنفذ UDP 2152» و«TEID». ففي 5G يمكن لنفق N3 واحد أن يحمل عدة QoS Flows، كما تعتمد مراقبة المسار ومعالجة الأنفاق غير المعروفة وتنظيف طبقة المستخدم بعد أحداث التنقل على رسائل إدارة GTP-U. وعند النظر إلى مكدس البروتوكولات والأنفاق وTEID وQFI وإجراءات الإدارة باعتبارها مساراً متكاملاً لطبقة المستخدم، يصبح فهم كيفية وصول حركة 5G فعلياً إلى UPF أسهل بكثير.

أين يقع GTP-U ضمن بنية 5G؟

يرمز GTP-U إلى GPRS Tunnelling Protocol for the User Plane. وفي بنية طبقة المستخدم في 5G يُستخدم أساساً لتغليف حركة المستخدم في الطبقات العليا ونقلها بين عقد طبقة المستخدم.

من منظور 5G Core، فإن أكثر واجهتين استخداماً لـ GTP-U هما N3 وN9. تربط N3 بين gNB وUPF وتحمل حركة المستخدم بين شبكة الوصول الراديوي و5G Core، بينما تُستخدم N9 بين وحدات UPF. وداخل RAN يمكن أيضاً استخدام GTP-U على Xn-U بين وحدات gNB.

يختلف ذلك بوضوح عن بنية طبقة التحكم في 5G. فوظائف الشبكة مثل AMF وSMF تستخدم واجهات قائمة على الخدمات تعتمد بدرجة كبيرة على HTTP/2، بينما يواصل مسار طبقة المستخدم استخدام GTP-U لحمل الحركة الفعلية للمشترك. إن الانتقال إلى Service-Based Architecture في 5G لا يعني أن طبقة المستخدم نفسها انتقلت إلى HTTP.

يعمل GTP-U فوق UDP ويستمر في استخدام المنفذ UDP 2152. وإذا نظرنا إلى مكدس البروتوكولات بدءاً من حزمة تطبيق المستخدم باتجاه الطبقات الأدنى، فيمكن فهم البنية على النحو التالي.

تتحول حركة التطبيق أولاً إلى حزمة TCP أو UDP، ثم إلى حزمة IP تخص UE. وبعد دخولها طبقة المستخدم في 5G تُغلَّف حزمة المستخدم الأصلية داخل GTP-U. بعد ذلك يُضاف رأس UDP خارجي ورأس IP خارجي وإطار Ethernet في الطبقات الأدنى لنقلها بين نقاط نهاية GTP-U.

وهذا يعني أن التقاط الحزم قد يتضمن مجموعتين مختلفتين من عناوين IP. تصف عناوين IP الداخلية الاتصال بين UE وخادم التطبيق في شبكة البيانات، بينما تُستخدم عناوين IP الخارجية بين نقاط نهاية أنفاق GTP-U مثل gNB وUPF. ويعد الخلط بين رؤوس IP الداخلية والخارجية سبباً شائعاً للالتباس عند استكشاف مشكلات حركة N3.

ما الفرق بين GTP Path وGTP Tunnel وTEID؟

تُعد GTP Path وGTP Tunnel وTunnel Endpoint وTEID مصطلحات مترابطة، لكنها تصف مستويات مختلفة في نموذج نقل GTP-U.

يمكن النظر إلى GTP Path باعتباره مسار اتصال غير قائم على إنشاء جلسة بين نقطتي نهاية لنفق GTP. فإذا كان gNB وUPF قادرين على تبادل حزم GTP-U عبر شبكة IP، فهذا يعني وجود GTP Path بين نقطتي النهاية. ويمكن لعدة أنفاق GTP-U مشاركة Path نفسه.

يمثل GTP Tunnel نفقاً منطقياً أكثر تحديداً في طبقة المستخدم. ويُعرَّف نفق GTP-U باستخدام مزيج من TEID وعنونة IP ومعلومات نقل UDP، بينما تُعرَّف نقطة نهاية النفق نفسها بعنوان IP للعقدة ومنفذ UDP.

يعد TEID، أي Tunnel Endpoint Identifier، أحد أهم الحقول في GTP-U. وفي الرأس الأساسي لـ GTPv1-U يبلغ طول TEID أربعة بايتات. وعندما تصل حزمة GTP-U إلى العقدة المستقبلة، تستخدم العقدة TEID مع سياق النفق المحلي لتحديد نفق طبقة المستخدم الذي تنتمي إليه الحزمة، وتحديد PDU Session أو سياق إعادة التوجيه الذي ينبغي أن يعالجها.

ولهذا لا ينبغي تفسير TEID بمعزل عن السياق. فقد تظهر القيمة الرقمية نفسها لـ TEID في سياقات أنفاق مختلفة. وإذا كانت الحزم تنتمي إلى نقاط نهاية GTP مختلفة أو إلى اتجاهات مختلفة، فلا يعني ذلك بالضرورة أنها جزء من النفق نفسه.

وهناك مصطلحان إضافيان مفيدان عند النظر إلى الحمولة نفسها. يمثل T-PDU بيانات المستخدم الأصلية من الطبقة العليا، بينما يمثل G-PDU الـ T-PDU بعد إضافة رأس GTP-U. لذلك فإن ما يُنقل عبر N3 ليس حزمة IP الخام الخاصة بـ UE فقط، بل G-PDU مغلفاً داخل GTP-U.

ولا يقتصر GTP-U على نقل بيانات المستخدم، بل يضم رسائل إدارة خاصة به. لذلك فإن ظهور المنفذ UDP 2152 في التقاط الحزم لا يعني تلقائياً أن الحزمة تخص حركة تطبيق المستخدم. فرسائل Echo Request وEcho Response وError Indication وEnd Marker وغيرها من رسائل GTP-U تستخدم إطار البروتوكول نفسه.

لماذا يحتاج 5G إلى QFI مع وجود TEID؟

إذا تم تعلم GTP-U أولاً من منظور 4G، فمن السهل افتراض أن تحديد TEID يكفي لتحديد الحامل. لكن هذا الافتراض لم يعد مكتملاً في 5G.

تعتمد بنية QoS في 4G على EPS Bearers. ولكل حامل سياق نقل خاص به في طبقة المستخدم وأنفاق GTP-U مستقلة، لذلك يساعد النفق وTEID بصورة طبيعية على تمييز حركة الحوامل المختلفة.

يغيّر 5G نموذج QoS إلى PDU Session مع QoS Flow. فقد تحتوي PDU Session واحدة على QoS Flow واحد أو أكثر، كما يمكن لـ DRB حمل QoS Flow واحد أو أكثر. ومع ذلك لا تنشئ N3 نفق GTP-U منفصلاً لكل QoS Flow داخل PDU Session نفسها.

وبعبارة أخرى، يستطيع TEID تحديد نفق GTP-U المرتبط بـ PDU Session، لكن قد تستمر عدة QoS Flows في مشاركة النفق نفسه.

وهنا يظهر سؤال آخر: كيف تعرف العقدة المستقبلة إلى أي QoS Flow تنتمي حزمة بعينها؟

هذا أحد الأسباب الرئيسية لاستخدام رأس التوسعة PDU Session Container. يستخدم 5G رأس توسعة GTP-U هذا لحمل معلومات طبقة المستخدم المرتبطة بـ PDU Session، بما في ذلك QFI، أي QoS Flow Identifier.

QFI هو معرّف بطول 6 بت يُستخدم لتحديد QoS Flow. وعند تحليل حركة 5G N3 يمكن فهم TEID وQFI على مستويين مختلفين:

يحدد TEID نفق GTP-U أو سياق PDU Session، بينما يحدد QFI الـ QoS Flow المحدد الذي يُنقل داخل ذلك النفق.

يمكن لـ PDU Session Container في الوصلة الهابطة أيضاً حمل معلومات مثل RQI وPPI. يُستخدم RQI للإشارات المتعلقة بـ Reflective QoS، بينما يرتبط PPI بـ Paging Policy Differentiation ويمكن أن يدعم معالجة مختلفة للنداء لأنواع مختلفة من الحركة داخل PDU Session نفسها.

يشير البت E في الرأس الأساسي لـ GTP-U إلى ما إذا كان هناك Extension Header تالٍ. وهذا يعني أن حزم GTP-U لا تحمل بالضرورة رؤوس التوسعة نفسها. وتعتمد موجودية PDU Session Container على الحزمة والوظيفة التي يجري تنفيذها.

ماذا يحدث فعلياً لحزمة مستخدم N3؟

تصبح المفاهيم السابقة أسهل بكثير عندما نضعها ضمن تدفق فعلي لحزمة في الوصلة الصاعدة.

لنفترض أن UE يصل إلى خدمة فيديو عبر الإنترنت. ينشئ UE أولاً حركة التطبيق، التي تُنقل عبر TCP أو UDP ثم توضع داخل حزمة IP عادية. وفي رأس IP الداخلي يكون عنوان المصدر هو عنوان IP المخصص لـ UE، بينما يعود عنوان الوجهة إلى خادم التطبيق على الإنترنت.

عندما تصل الحزمة إلى gNB، لا يقوم gNB ببساطة بإعادة توجيه حزمة IP الخاصة بـ UE مباشرة إلى UPF، بل يطبق تغليف GTP-U استناداً إلى سياق طبقة المستخدم الحالي لـ PDU Session.

يحتوي رأس GTP-U على TEID المناسب. وإذا احتاجت الحزمة إلى تحديد QoS Flow معين، فيمكن لـ PDU Session Container أيضاً حمل QFI. ثم يضيف gNB رأس UDP مع منفذ وجهة 2152، يتبعه رأس IP الخارجي.

عند هذه النقطة لا تعود عناوين IP الخارجية تصف الاتصال بين UE والإنترنت، بل تمثل علاقة النقل بين واجهة N3 في gNB وواجهة N3 في UPF.

عندما تصل الحزمة إلى UPF تنعكس العملية. يستقبل UPF الحزمة بناءً على معلومات النقل الخارجية، ويقرأ TEID لتحديد سياق نفق طبقة المستخدم الصحيح، ويعالج QFI ومعلومات التوسعة الأخرى عند الحاجة، ثم يزيل تغليف GTP-U ويعيد توجيه حزمة IP الأصلية الخاصة بـ UE نحو شبكة البيانات.

عند استكشاف مشكلات حركة N3 باستخدام Wireshark أو أداة أخرى لتحليل الحزم، من المفيد العمل من الخارج إلى الداخل. ابدأ بالتحقق من عناوين IP الخارجية لـ gNB وUPF، ثم المنفذ UDP 2152، وبعده TEID وPDU Session Container وQFI عند وجودهما، وبعد ذلك فقط افحص IP الداخلي للمستخدم وTCP أو UDP وحركة طبقة التطبيق.

وغالباً ما تكون هذه الطريقة أكثر فعالية من البدء بحزمة التطبيق، لأن كثيراً من أعطال N3 تنتج عن سياق النفق أو TEID أو مشكلات نقاط النهاية، وليس عن تطبيق المستخدم نفسه.

لماذا يحتاج GTP-U إلى رسائل إدارة خاصة به؟

مع أن GTP-U بروتوكول لطبقة المستخدم، فإنه لا يقتصر على رسائل G-PDU الخاصة ببيانات المستخدم. فهو يحدد أيضاً رسائل لإدارة المسار والنفق تساعد على إبقاء نقل طبقة المستخدم في حالة تشغيل.

Echo Request وEcho Response يتحققان من توفر المسار

يُستخدم Echo Request للتحقق مما إذا كان GTP Path وعقدة GTP النظيرة قابلين للوصول ويعملان بصورة طبيعية. وترد العقدة النظيرة برسالة Echo Response.

تختبر هذه الرسائل العلاقة الأساسية بين نقطتي نهاية GTP. فإذا فشل gNB مراراً في تلقي Echo Responses من UPF، فقد لا تقتصر المشكلة على UE واحد أو PDU Session واحدة، بل قد تشير إلى مشكلة في GTP Path نفسه أو في العقدة النظيرة.

يعرّف GTP-U أيضاً رسالة Supported Extension Headers Notification التي تسمح للعقدة بالإعلان عن رؤوس توسعة GTP التي تدعمها. ويصبح ذلك مهماً عندما تعتمد وظائف طبقة المستخدم 5G على رؤوس توسعة مثل PDU Session Container.

Error Indication يتعامل مع TEID غير المعروف

إذا استقبلت نقطة نهاية GTP رسالة G-PDU لكنها لم تجد EPS Bearer محلياً أو سياق PDU Session يطابق TEID المستلم، وكان TEID غير صفري، فيمكنها إرسال Error Indication إلى الطرف النظير.

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

إذا ظهرت رسائل Error Indication بصورة متكررة أثناء استكشاف الأعطال، فينبغي أولاً التحقق من اتساق حالة TEID على الطرفين، ومن أن تحديث PDU Session أو إجراء تنقل أو تغيير مسار طبقة المستخدم لم يترك الطرفين خارج المزامنة.

End Marker يساعد على إنهاء تحويل مسار طبقة المستخدم

يرتبط End Marker عادة بالتنقل وتحويل مسار طبقة المستخدم. فهو يشير إلى أن آخر G-PDU على مسار GTP-U القديم قد أُرسل، وأن حركة المستخدم التالية ينبغي ألا تستمر على ذلك المسار السابق.

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

لذلك لا يمثل End Marker مجرد إشعار «حذف نفق». بل يعمل كعلامة حدود للمسار القديم في طبقة المستخدم، ويخبر الطرف المستقبل بأن آخر حزمة على ذلك المسار قد وصلت بالفعل.

عند النظر إلى هذه الآليات معاً، يصبح دور GTP-U أكثر وضوحاً. فهو ليس مجرد بروتوكول يضيف TEID أمام حزمة IP الخاصة بالمستخدم، بل يوفر إطاراً متكاملاً لأنفاق طبقة المستخدم يمكن تحديده ومراقبته وإدارته وتحديثه مع تغير حالة الشبكة.

لذلك فإن التسلسل العملي لاستكشاف مشكلات GTP-U في 5G هو: التأكد أولاً من سلامة نقاط نهاية GTP وPath، ثم التحقق من TEID وسياق Tunnel، وفحص PDU Session Container وQFI عند الحاجة، وأخيراً الانتقال إلى حركة المستخدم الأصلية. وإذا حدثت المشكلة أثناء التنقل أو تحديث المسار، فيجب أيضاً مراجعة رسائل Error Indication وEnd Marker.

وباتباع هذا الترتيب تتحول عملية التقاط N3 من مجموعة كبيرة من حزم UDP 2152 إلى مسار إعادة توجيه لطبقة المستخدم يمكن إعادة بنائه طبقة بعد طبقة.

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

هل تحمل كل حزمة على المنفذ UDP 2152 حركة مستخدم؟

لا. تحمل رسائل G-PDU بيانات طبقة المستخدم عبر GTP-U والمنفذ UDP 2152، لكن رسائل إدارة GTP-U مثل Echo Request وEcho Response وError Indication وEnd Marker وSupported Extension Headers Notification تستخدم أيضاً إطار البروتوكول نفسه. ويجب فحص GTP-U Message Type لتحديد ما تمثله الحزمة فعلياً.

هل يجب أن يكون TEID فريداً على مستوى شبكة 5G بالكامل؟

لا. لا ينبغي التعامل مع TEID بوصفه معرّفاً فريداً عالمياً على مستوى الشبكة كلها. فتحديد نفق GTP-U يعتمد أيضاً على نقاط نهاية النفق وعنونة IP ومعلومات النقل والاتجاه. لذلك ينبغي أن يأخذ استكشاف الأعطال سياق النفق كاملاً في الاعتبار بدلاً من مقارنة قيم TEID وحدها.

هل تتضمن كل حزمة 5G GTP-U ‏PDU Session Container؟

لا. PDU Session Container هو رأس توسعة في GTP-U، وتعتمد موجوديته على الحزمة والوظيفة المنفذة. ويشير البت E في الرأس الأساسي لـ GTP-U إلى ما إذا كانت هناك Extension Headers إضافية، لذلك لا تملك جميع حزم N3 بنية الرأس نفسها.

هل يعني End Marker أن PDU Session بالكامل قد تم تحريرها؟

ليس بالضرورة. يشير End Marker أساساً إلى انتهاء الحركة على مسار معين لطبقة المستخدم GTP-U، ويظهر عادة أثناء تبديل المسار بعد أحداث التنقل. فهو يحدد نهاية الحركة على ذلك المسار، ولا يمثل إجراء تحرير PDU Session بالكامل.