قد يعرض الهاتف الذكي رمز 5G بالفعل، ومع ذلك تظل صفحات الويب غير قابلة للتحميل. عند حدوث ذلك، تكون أول خطوة غالباً هي فحص إجراء Registration: هل اكتمل 5G-AKA؟ هل تم استلام Registration Accept؟ هل انتهت مهلة T3512؟ بعد إجراء هذه الفحوصات قد يبدو إجراء Registration طبيعياً تماماً، بينما تظل خدمة البيانات غير عاملة.
في كثير من الحالات لا تكون المشكلة في Registration، بل في PDU Session. يجيب Registration عن السؤال: «هل يستطيع UE التسجيل في 5GS؟»، بينما يجيب PDU Session Establishment عن السؤال التالي: «هل يستطيع UE الوصول فعلياً إلى شبكة بيانات؟». يتتبع هذا المقال إجراء إنشاء جلسة PDU من البداية إلى النهاية: كيف يطلب UE جلسة، وكيف يختار AMF وظيفة SMF، وكيف يسترجع SMF معلومات الاشتراك والسياسات، وكيف تتم تهيئة UPF، وكيف يكتمل في النهاية نفق N3.
بعد أن يكمل UE عملية 5GS Registration، يكون لدى AMF بالفعل هوية المستخدم وسياق الحركة والأمان ومعلومات الاشتراك ذات الصلة. لكن نجاح التسجيل لا يعني أن مسار مستوى المستخدم قد تم إنشاؤه بالفعل. فقد يظل UE من دون مسار نشط إلى الإنترنت أو إلى شبكة بيانات خاصة بالمؤسسة.
PDU Session Establishment هو ما ينقل UE من حالة «مسجل» إلى حالة «قادر على حمل حركة بيانات التطبيقات». يطلب UE جلسة، وتختار الشبكة SMF وUPF، وتسترجع بيانات الاشتراك المرتبطة بـ DNN وS-NSSAI، وتحصل على سياسة الجلسة، وتثبت قواعد PFCP في UPF، وتنسق مع gNB لإنشاء نفق N3. وفي نهاية الإجراء يصبح لدى UE عنوان IP وقواعد QoS ومسار في مستوى المستخدم نحو Data Network.
يصبح فهم الإجراء أسهل عندما لا يُنظر إليه على أنه رسالة NAS منفصلة واحدة. فهناك ثلاثة أمور تحدث معاً: إدارة الجلسة، والتحكم في السياسات، وتهيئة موارد مستوى المستخدم. وفي النهاية تتكامل هذه العناصر لتكوين PDU Session قابلة للاستخدام.
الحد الوظيفي بين جلسة PDU والتسجيل في 5GS
في 5GC يكون الفصل بين Registration وPDU Session واضحاً: الأول ينشئ تسجيل الجهاز في الشبكة، بينما تنشئ الثانية اتصال البيانات.
يحدد Registration ما إذا كان UE يستطيع الدخول إلى 5GS. يتحقق AMF من هوية UE، وينفذ المصادقة، وينشئ أمان NAS، ويسترجع بيانات الاشتراك المتعلقة بالحركة، وينشئ السياق المطلوب لإدارة RM (Registration Management) وCM (Connection Management). وبعد اكتمال هذه الخطوات تُنشأ علاقة الإدارة بين UE والشبكة الأساسية.
ترتبط PDU Session بخدمة البيانات الفعلية. فإذا احتاج UE إلى الوصول إلى الإنترنت أو اتصال IMS أو شبكة خاصة بالمؤسسة، فلن يكون Registration وحده كافياً. إذ لا تزال الشبكة بحاجة إلى تحديد DNN المستخدم، وS-NSSAI المطبق، وSMF الذي يتحكم في الجلسة، وUPF الذي يحمل مستوى المستخدم، ومعلمات QoS وعرض النطاق المصرح بها.
تساعد المقارنة مع EPC على تذكر هذا الفرق. يستخدم LTE مفهومي PDN Connection وEPS Bearer. أما في 5GC فيُستبدل هذا النموذج بـ PDU Session + QoS Flow. وبعد إنشاء PDU Session تنشئ الشبكة قواعد QoS وموارد QoS Flow بدلاً من Default EPS Bearer بأسلوب LTE.
ومن النقاط المهمة أيضاً أن PDU Session لا يلزم أن تُنشأ في الوقت نفسه مع Registration الأولي. فقد يكمل UE عملية Registration ويظل من دون PDU Session إلى أن يحتاج أحد التطبيقات فعلياً إلى خدمة بيانات. على سبيل المثال، قد يسجل الجهاز عند تشغيله، لكن PDU Session قد لا تُنشأ إلا عندما يفتح المستخدم تطبيق فيديو بعد نصف ساعة.
يفيد هذا الفصل أثناء تحليل سجلات الإشارات. فإذا اكتمل Registration بنجاح بينما لم يكتمل PDU Session Establishment، فإن إعادة فحص 5G-AKA أو Registration Accept أو T3512 مراراً لن تحل عادة مشكلة خدمة البيانات، لأن التحقيق يركز حينها على الإجراء الخطأ.
DNN وS-NSSAI ونوع الطلب في طلب جلسة PDU
يبدأ PDU Session Establishment برسالة NAS يرسلها UE. ولا يقتصر PDU Session Establishment Request على إبلاغ الشبكة الأساسية ببساطة: «أحتاج إلى الوصول للبيانات». فلعناصر المعلومات الموجودة في الطلب تأثير في اختيار NF اللاحق وتهيئة الجلسة.
قد يتضمن الطلب الأولي النموذجي PDU Session ID وRequest Type وPDU Session Type وSSC Mode وDNN وS-NSSAI.
PDU Session ID يميز بين الجلسات المتعددة التابعة لـ UE نفسه. ويمكن لـ UE واحد الاحتفاظ بعدة PDU Sessions في الوقت نفسه، مثل جلسة للوصول إلى الإنترنت وأخرى لشبكة خاصة بالمؤسسة. يحدد SUPI هوية المشترك، لكنه لا يحدد بمفرده أي PDU Session محددة تتم معالجتها حالياً.
DNN يحدد Data Network التي يريد UE الوصول إليها. وقد تستخدم خدمة الإنترنت الخاصة بالمشغل وIMS وشبكات المؤسسات DNNs مختلفة. كما يشارك DNN لاحقاً في اختيار SMF واختيار UPF وقرارات السياسات.
S-NSSAI يربط الجلسة بـ Network Slice معين. ويتعين على AMF وSMF تحديد ما إذا كان الـ slice المطلوب متوافقاً مع اشتراك المستخدم وDNN المطلوب وقدرات الشبكة المنشورة.
Request Type يحدد سياق الطلب. فإلى جانب إنشاء PDU Session جديدة، قد يرتبط الإجراء أيضاً بجلسة قائمة أو بتغيير في الوصول أو بسيناريوهات خدمات الطوارئ. لذلك لا ينبغي أثناء تحليل السجلات افتراض أن ظهور PDU Session Establishment Request يعني السيناريو نفسه في كل مرة.
الحالة الأكثر شيوعاً هي Initial Request: يكون UE قد أكمل Registration بالفعل ويقوم الآن بإنشاء PDU Session جديدة لـ DNN محدد. ويقود سياق الجلسة هذا اختيار SMF واسترجاع بيانات الاشتراك من UDM والتحكم في السياسات عبر PCF وإنشاء موارد UPF.
اختيار SMF وإنشاء SM Context بواسطة AMF
تصل رسالة NAS الخاصة بإدارة الجلسة من UE أولاً إلى gNB، ثم تُرسل إلى AMF عبر NGAP مع معلومات مرتبطة بالوصول مثل NR-CGI وTAI. ولا يتخذ gNB قرارات التحكم الخاصة بـ PDU Session؛ بل ينقل معلومات NAS نحو الشبكة الأساسية.
بعد استلام الطلب، يحتاج AMF إلى تحديد SMF قادر على خدمة S-NSSAI وDNN المطلوبين.
في بنية 5GC القائمة على الخدمات يمكن لـ AMF استخدام NRF لاكتشاف NF. وقد تتضمن معايير الاكتشاف نوع NF المستهدف، وخدمة Nsmf_PDUSession المطلوبة، وS-NSSAI، وDNN، وServing PLMN. يعيد NRF مثيلات SMF المرشحة، وبعد ذلك يختار AMF وظيفة SMF الفعلية التي ستقدم الخدمة وفقاً لسياسة الشبكة.
بعد ذلك يستدعي AMF خدمة PDU Session في SMF لإنشاء SM Context. وبالإضافة إلى SUPI وPDU Session ID وDNN وS-NSSAI، يحمل الطلب PDU Session Establishment Request الأصلي الخاص بـ UE على شكل معلومات N1 SM.
من هذه النقطة ينتقل مركز التحكم في الجلسة من AMF إلى SMF. يستمر AMF في إدارة الوصول والحركة وفي تمرير إشارات N1 SM بين UE وSMF، لكن SMF يصبح مسؤولاً عن تحديد كيفية إنشاء PDU Session، وأي UPF يتم اختياره، وأي سياسات تطبق، وكيف تتم تهيئة قواعد مستوى المستخدم.
هناك نقطة عملية مهمة في استكشاف الأعطال: قد لا يتطابق عدد معاملات NRF الظاهرة في شبكة تجارية تماماً مع مخطط إشارات مرجعي. فقد تكون نتائج اكتشاف NF مخزنة مؤقتاً، أو تُستخدم تهيئة ثابتة، أو يتولى SCP توجيه الخدمات. والسؤال الأهم ليس ما إذا كان استعلام NRF معيناً يظهر في السجل، بل ما إذا كان SMF المختار يدعم فعلياً DNN وS-NSSAI وقدرات الخدمة المطلوبة.
بيانات اشتراك UDM ومعالجة سياسة الجلسة في PCF
بمجرد أن يفهم SMF نوع الجلسة التي يطلبها UE، لا يمكنه إنشاء مستوى المستخدم فوراً. بل يحتاج أولاً إلى تحديد نوع PDU Session المصرح فعلياً للمشترك بإنشائها.
في الإجراء النموذجي يحدد SMF وظيفة UDM المناسبة، ويسجل نفسه بوصفه SMF الذي يخدم SUPI وPDU Session، ويسترجع Session Management Subscription Data المرتبطة بـ S-NSSAI وDNN المطلوبين.
قد تحتوي بيانات الاشتراك على PDU Session Type المسموح به، وSSC Mode، وSession-AMBR، وإعدادات QoS الافتراضية ذات الصلة. تحدد هذه القيم حدود الجلسة على مستوى المشترك. فعلى سبيل المثال، إذا طلب UE جلسة PDU من نوع IPv4، فيظل على SMF التحقق من أن DNN يسمح بهذا PDU Session Type وأن SSC Mode المطلوب مسموح به.
يمكن لـ SMF أيضاً الاشتراك في تغييرات بيانات اشتراك SM. وإذا تم تعديل اشتراك إدارة الجلسة ذي الصلة لاحقاً في UDM، فيمكن لـ UDM إخطار SMF الذي يقدم الخدمة عبر Callback URI المسجل.
إذا كان النشر يستخدم Dynamic SM Policy Control، يختار SMF وظيفة PCF وينشئ SM Policy Association. ويقدم SMF سياقاً مثل SUPI وPDU Session ID وDNN وS-NSSAI وموقع UE ومعلمات QoS المشترك بها. ثم يعيد PCF سياسة الجلسة المصرح بها، التي قد تشمل Session-AMBR وQoS الافتراضي وقواعد سياسة أخرى مطبقة.
يمكن النظر إلى هذه المرحلة على أنها نقطة التقاء لمعلمات الجلسة:
طلب خدمة UE → حدود اشتراك UDM → تفويض سياسة PCF → يثبت SMF معلمات التحكم النهائية للجلسة
تستند قواعد QoS والتوجيه التي يتم تثبيتها لاحقاً في UPF إلى هذه النتائج.
إنشاء جلسة N4 وتثبيت قواعد مستوى المستخدم في UPF
بعد تحديد معلمات الجلسة، يختار SMF وظيفة UPF قادرة على خدمة DNN وS-NSSAI وموقع UE المطلوبين، ثم ينشئ PFCP Session عبر واجهة N4.
يُعد PFCP Session Establishment Request من أهم النقاط في إجراء PDU Session Establishment. وحتى هذه المرحلة تكون الشبكة قد تعاملت في الغالب مع متطلبات خدمة مجردة. وعند N4 تتحول تلك المتطلبات إلى قواعد يستطيع UPF تنفيذها على حزم المستخدم الفعلية.
يمكن لـ SMF تثبيت قواعد PDR وFAR وQER وURR في UPF:
PDR: تحدد لـ UPF كيفية التعرف على الحزم التي تنتمي إلى PDU Session أو إلى تدفق حركة بيانات معين؛
FAR: تحدد ما يجب فعله بالحزم المطابقة، مثل إعادة التوجيه أو الإسقاط أو التخزين المؤقت أو أي إجراء مناسب آخر؛
QER: تطبق ضوابط QoS المطلوبة في UPF؛
URR: تحدد متطلبات قياس استخدام مستوى المستخدم وإعداد التقارير عنه.
لا ينبغي التعامل مع هذه القواعد على أنها أربع وظائف منفصلة لا علاقة بينها. فهي مجتمعة تحدد كيفية معالجة UPF لحركة البيانات. يحدد PDR تدفق الحزم ويرتبط بقواعد FAR وQER وURR المطبقة لكي يعرف UPF وجهة الحزم، وضوابط QoS التي يجب تطبيقها، وما إذا كان يلزم قياس الاستخدام.
عندما يقبل UPF عملية PFCP Session Establishment، يعيد F-SEID الخاص به ومعلمات مستوى المستخدم التي أنشأها. ومن أهم النتائج عنوان مستوى المستخدم من جهة UPF وTEID المستخدمان مع N3.
إلا أن مسار التنزيل قد لا يكون مكتملاً في هذه النقطة، لأن gNB لم ينته بعد من تخصيص موارد N3. لذلك لا ينتهي PDU Session Establishment بطلب PFCP واحد؛ إذ لا يزال الإجراء يحتاج إلى أن يكمل RAN الجزء الخاص به من إعداد مستوى المستخدم.
إشارات N1/N2 تستكمل نفق N3 وإعداد QoS Flow
بعد جاهزية الموارد من جهة UPF، يحتاج SMF إلى إعادة مجموعتين مختلفتين من المعلومات عبر AMF.
الأولى هي N1 SM information التي تصل في النهاية إلى UE. وتتضمن PDU Session Establishment Accept إلى جانب المعلمات التي يحتاجها UE بعد إنشاء الجلسة، مثل PDU Session Type وSSC Mode وDNN وS-NSSAI وعنوان IP الخاص بـ UE وSession-AMBR وقاعدة QoS الافتراضية.
الثانية هي N2 SM information الموجهة إلى gNB. وهي توضح لـ RAN أي PDU Session يتم إنشاؤها، وأي QoS Flows تشارك فيها، وأي عنوان IP خاص بـ UPF وTEID يجب استخدامهما على N3.
يرسل AMF إلى gNB عبر NGAP طلب PDU Session Resource Setup Request. يخصص gNB موارد الراديو وN3 المطلوبة ويمرر PDU Session Establishment Accept إلى UE.
بعد إعداد الموارد يعيد gNB رسالة PDU Session Resource Setup Response التي تتضمن عنوان مستوى المستخدم N3 الخاص به وTEID، بالإضافة إلى معلومات عن QoS Flows التي تم إنشاؤها بنجاح.
توجد هنا نقطة مهمة تتعلق بالتوقيت. فعندما أنشأ SMF جلسة PFCP في البداية، كان يعرف معلومات N3 من جهة UPF، لكنه ربما لم يكن يعرف بعد معلومات النفق النهائية من جهة gNB. وبعد أن يعيد gNB عنوان N3 وTEID الخاصين به، يمرر AMF هذه المعلومات إلى SMF. ثم يستخدم SMF PFCP Session Modification لتحديث FAR المناسب في UPF بحيث يمكن تغليف حزم التنزيل داخل نفق GTP-U الصحيح المتجه إلى gNB.
عند هذه النقطة يكتمل مسارا الرفع والتنزيل في مستوى المستخدم:
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
لهذا السبب فإن استلام PDU Session Establishment Accept وحده لا يثبت أن جميع عناصر مستوى المستخدم صحيحة. فلا يزال من الضروري التحقق من معلمات نفق N3 وPFCP Session Modification والقواعد النهائية في UPF مقارنة بعملية تمرير الحزم الفعلية.
استكشاف أخطاء الإشارات أثناء إنشاء جلسة PDU
يتضمن PDU Session Establishment عدداً كبيراً من وظائف الشبكة. وقد يصبح استكشاف الأعطال عبر مقارنة كل رسالة منذ أول حزمة أمراً مربكاً بسرعة. والطريقة الأكثر كفاءة هي تقسيم الإجراء إلى عدة نقاط تحقق وتضييق نطاق العطل خطوة بخطوة.
التحقق من وصول طلب الجلسة إلى AMF بصورة صحيحة
تأكد أولاً من أن UE قد أكمل 5GS Registration المطلوب. بعد ذلك افحص PDU Session Establishment Request وتحقق من أن PDU Session ID وRequest Type وDNN وS-NSSAI وPDU Session Type وSSC Mode مناسبة. فإذا كان الطلب يحتوي بالفعل على معلمة غير صالحة عند نقطة الدخول، فلن يتمكن SMF وUPF السليمان من إنشاء الجلسة المطلوبة.
التحقق من أن SMF ينشئ SM Context صالحاً
بعد ذلك تحقق من أن AMF يختار SMF مناسباً وأن Create SM Context ينجح. الهدف ليس مجرد العثور على رسالة NRF في السجل، بل التأكد من أن SMF المختار يدعم DNN وS-NSSAI وقدرات الخدمة المطلوبة.
ثم تحقق من أن بيانات اشتراك SM التي يعيدها UDM تسمح بـ PDU Session المطلوبة، وأن سياسة PCF متوافقة مع تهيئة QoS المتوقعة.
التحقق من اكتمال موارد UPF وN3
إذا كان مستوى التحكم قد أعاد بالفعل PDU Session Establishment Accept، لكن UE لا يزال غير قادر على تمرير البيانات، فيجب نقل التحقيق إلى N4 وN3.
تحقق من العناصر التالية بالترتيب:
ما إذا كان PFCP Session Establishment ينجح وينشئ UPF الجلسة المقابلة؛
ما إذا كانت قواعد PDR وFAR وQER وغيرها متوافقة مع اتجاه حركة البيانات المتوقع؛
ما إذا كان gNB يعيد بنجاح عنوان IP الخاص بمستوى المستخدم N3 وTEID؛
ما إذا كان SMF يحدث UPF بمعلومات نفق gNB من خلال PFCP Session Modification؛
ما إذا كانت حزم GTP-U التي تستخدم TEID المتوقع تظهر فعلياً على N3؛
ما إذا كان UPF يستطيع إرسال واستقبال حركة البيانات بنجاح نحو Data Network المستهدفة عبر N6.
يساعد اتباع هذا التسلسل على حصر المشكلة في NAS أو SBI أو N4 أو N3 أو تمرير الحزم في UPF، بدلاً من التعامل مع 5GC بالكامل كنطاق عطل واحد غير مميز.
الأسئلة الشائعة
لماذا يمكن لـ UE إكمال تسجيل 5G ومع ذلك يظل غير قادر على الوصول إلى الإنترنت؟
ينشئ Registration سياق الوصول والهوية والأمان والحركة بين UE و5GC، لكنه لا ينشئ مسار بيانات المستخدم تلقائياً. وقبل أن يتمكن UE من الوصول إلى الإنترنت أو إلى Data Network أخرى، فإنه يظل بحاجة إلى PDU Session حتى يستطيع SMF تهيئة معلمات الجلسة وموارد UPF ومستوى المستخدم N3.
هل يتم دائماً إنشاء PDU Session عند تشغيل UE؟
لا. يمكن إنشاء PDU Session في وقت قريب من Registration، كما يمكن بدء إنشائها لاحقاً عندما يحتاج UE فعلياً إلى خدمة بيانات. يسمح 5GS لـ UE بالبقاء مسجلاً من دون PDU Session نشطة، ولذلك لا ينبغي اعتبار اكتمال Registration وPDU Session Establishment الحدث نفسه.
هل نجاح PDU Session Establishment يضمن أن UE يستطيع الوصول إلى الإنترنت؟
لا. إن PDU Session Establishment Accept على مستوى NAS وحده لا يمثل دليلاً كافياً على نجاح اتصال البيانات. تعتمد حركة بيانات المستخدم الفعلية أيضاً على نفق N3 بين gNB وUPF، وقواعد PDR/FAR/QER في UPF، واتصال N6، وData Network المستهدفة. فقد يحصل UE على عنوان IP بينما يظل تمرير مستوى المستخدم غير صحيح.
لماذا يحدث PFCP Session Modification بعد PFCP Session Establishment؟
عند إنشاء PFCP Session الأولية في UPF، ربما لا يكون gNB قد أكمل بعد تخصيص موارد N3، ولذلك قد لا يعرف SMF بعد عنوان IP النهائي لمستوى المستخدم في gNB وTEID. وبعد أن يعيد gNB هذه القيم في PDU Session Resource Setup Response، يحدث SMF قواعد UPF المقابلة عبر PFCP Session Modification حتى يمكن إرسال حركة التنزيل عبر نفق N3 GTP-U الصحيح.
هل QFI في PDU Session وQER على واجهة N4 هما المفهوم نفسه؟
لا. يحدد QFI هوية QoS Flow في 5GS، بينما QER هي QoS Enforcement Rule يهيئها SMF في UPF عبر N4. تشارك QER في تطبيق QoS ويمكن ربطها بـ QFI عند الحاجة، لكن QFI نفسه ليس QER ولا ينبغي اعتبار المفهومين قابلين للتبادل.
