عند التقاط إشارات تسجيل 5G، من الشائع رؤية تسلسل كهذا على اتصال N2 نفسه: تظهر أولًا Initial UE Message، ثم Uplink NAS Transport وDownlink NAS Transport، ثم Initial Context Setup، وعندما يبدأ UE فعليًا في إنشاء اتصال البيانات تظهر PDU Session Resource Setup. فهم كل رسالة على حدة ليس صعبًا بدرجة كبيرة. الأصعب هو فهم سبب حدوثها بهذا الترتيب وما الذي يقوم به NGAP فعليًا عبر مستوى التحكم في 5G. ومن المفيد النظر إلى N2 باعتباره قناة تحكم مستمرة بين gNB وAMF. تنشئ عقد الشبكة العلاقة فيما بينها أولًا، ثم يُنشأ سياق UE، وبعد ذلك فقط تُجهز موارد RAN لجلسة PDU. وعندما يتحرك UE أو يدخل حالة الخمول أو تتغير معلمات الخدمة، يتم تشغيل إجراءات NGAP إضافية.
ما الدور الفعلي لواجهة N2؟
N2 هي واجهة مستوى التحكم بين gNB وAMF وتستخدم NGAP، أي NG Application Protocol (بروتوكول تطبيق NG). ومن الناحية الوظيفية، توجد أوجه تشابه بينها وبين واجهة S1-MME المستخدمة في 4G، لكنها تعمل ضمن بنية نظام 5G.
يُستخدم SCTP كطبقة نقل لـN2. يعمل NGAP فوق SCTP، بينما يمكن نقل رسائل NAS المتبادلة بين UE ونواة 5G بين gNB وAMF عبر NGAP. لذلك يمكن فهم مكدس بروتوكولات N2 النموذجي على النحو الآتي: يوفر IP قابلية الوصول الشبكي بين gNB وAMF، ويوفر SCTP ارتباط النقل الخاص بـN2، ويحمل NGAP إجراءات التحكم ومعلمات N2، بينما يُنقل 5G NAS عند الحاجة على هيئة NAS-PDU.
لا يحمل NGAP نفسه حركة مستوى المستخدم العادية الخاصة بـUE. تُنقل بيانات المستخدم الفعلية عادة عبر مستوى المستخدم N3. ويتولى N2 وظائف تحكم مثل إنشاء الموارد وإدارة سياق UE ونقل إشارات NAS وتنسيق التنقل. ومن الناحية الوظيفية، يدعم N2 إنشاء موارد NG-RAN المرتبطة بجلسات PDU وصيانتها وتحريرها، كما يشارك في إدارة سياق UE وإدارة التنقل ونقل إشارات NAS والتحكم في موارد مستوى المستخدم.
لماذا تُقسّم إجراءات NGAP إلى إجراءات مرتبطة بـUE وأخرى غير مرتبطة بـUE؟
عند بدء دراسة NGAP، قد يتحول الانتقال مباشرة إلى عشرات الإجراءات وأسماء الرسائل بسرعة إلى تمرين على الحفظ. النهج الأكثر عملية هو تحديد ما إذا كان الإجراء يتعلق بـUE محدد أولًا.
تعمل الإجراءات المرتبطة بـUE حول سياق مستخدم محدد أو جلسته أو حالة تنقله. وتشمل الأمثلة إدارة موارد جلسة PDU، وإدارة سياق UE، والتسليم، والاستدعاء، ونقل NAS، والإبلاغ عن الموقع، وإجراءات قدرات الراديو الخاصة بـUE. أما الإجراءات غير المرتبطة بـUE فتركز أساسًا على الحفاظ على العلاقة على مستوى العقد بين gNB وAMF. ومن أمثلتها المعتادة NG Setup وRAN Configuration Update وAMF Configuration Update وNG Reset وAMF Status Indication وOverload Start/Stop.
يفيد هذا التمييز كثيرًا عند استكشاف مشكلات التقاط الحزم. فإذا تأثر المستخدمون عبر gNB بالكامل، ينبغي فحص إجراءات مستوى العقد مثل SCTP وNG Setup وReset وحالة AMF أو معالجة الحمل الزائد أولًا. أما إذا تأثر UE واحد فقط، فينبغي تتبع معرّفات NGAP الخاصة بذلك UE ورسائل نقل NAS وإجراءات السياق وإشارات موارد جلسة PDU.
يمكن أيضًا تقسيم إجراءات NGAP إلى Class 1 وClass 2 وفقًا لما إذا كانت تتطلب استجابة. تتضمن إجراءات Class 1 عادة Request وResponse وقد تتضمن أيضًا نتيجة Failure. أما إجراءات Class 2 فلا تتطلب استجابة على مستوى الإجراء من الطرف المقابل. وفي استكشاف الأعطال عمليًا، يكون من المفيد عادة معرفة ما إذا كان الإجراء يتوقع نتيجة نجاح أو فشل بدلًا من حفظ فئة كل رسالة NGAP.
كيف يبني N2 الحالة من بدء تشغيل gNB حتى تسجيل UE؟
قبل ظهور أي UE، لا تكون المشكلة الأولى التي يجب على gNB حلها هي تسجيل المشترك، بل يجب أولًا التأكد من قدرته على الاتصال بـAMF بصورة صحيحة.
الخطوة الأولى عادة هي NG Setup. بعد إنشاء ارتباط SCTP بين gNB وAMF، يرسل gNB رسالة NG Setup Request. وإذا قبل AMF الاتصال، يعيد NG Setup Response. وفي نشر مجموعة AMF، قد يحتاج gNB إلى إنشاء علاقات N2 مع عدة AMF والحصول على معلومات تُستخدم لاحقًا في اختيار AMF. في هذه المرحلة تكون العلاقة على مستوى العقد فقط قد أُنشئت، ولا يوجد بعد سياق UE محدد.
عندما يبدأ UE التسجيل، تنتقل الإشارات إلى المستوى التالي. بعد استلام رسالة NAS الأولية من UE، يستطيع gNB تمريرها إلى AMF باستخدام Initial UE Message. وتُنقل إشارات NAS اللاحقة بين UE وAMF عادة عبر N2 باستخدام Uplink NAS Transport وDownlink NAS Transport. ومن المهم أن gNB لا يحتاج إلى تفسير كل منطق خدمات NAS. ففي جزء كبير من إشارات NAS، تتمثل مسؤوليته الرئيسية في تحديد سياق UE الصحيح وتسليم NAS-PDU إلى AMF المناسب.
مع تقدم التسجيل، يحتاج AMF أيضًا إلى أن ينشئ gNB سياق UE على جانب RAN. وهنا تظهر Initial Context Setup Request وInitial Context Setup Response. ويمكن أن تتضمن Initial Context Setup Request معلومات مهمة مرتبطة بـUE مثل Allowed NSSAI وGUAMI وUE Security Capabilities وMobility Restriction List وNAS-PDU. في هذه المرحلة، لا يعود gNB مجرد ناقل لإشارات NAS، بل يبدأ في إنشاء الحالة اللازمة لمواصلة خدمة ذلك UE.
كيف ينشئ NGAP موارد جلسة PDU عندما يبدأ UE في استخدام البيانات؟
نجاح التسجيل لا يعني أن جميع موارد مستوى المستخدم الخاصة بـUE أصبحت متاحة بالفعل. فعندما يحتاج UE إلى الوصول إلى شبكة بيانات وإنشاء جلسة PDU، يشارك N2 أيضًا في إعداد موارد RAN المقابلة.
من الإجراءات الأساسية PDU Session Resource Setup. يرسل AMF إلى gNB رسالة PDU Session Resource Setup Request. وتحمل هذه الرسالة إلى NG-RAN معلومات مرتبطة بجلسة PDU وتدفقات QoS الخاصة بها، مثل PDU Session ID وS-NSSAI ومعلومات نفق مستوى المستخدم وQoS Flow List. ثم يخصص gNB موارد الراديو المطلوبة وفق الظروف المحلية، مثل تكوين DRB اللازمة لتدفقات QoS وتجهيز اتصال مستوى المستخدم N3.
بعد اكتمال تخصيص الموارد، يرسل gNB إلى AMF رسالة PDU Session Resource Setup Response موضحًا الموارد التي أُنشئت بنجاح. وقد تتضمن الاستجابة معلومات مستوى المستخدم الخاصة بـgNB وتدفقات QoS التي قُبلت بنجاح.
هنا يختلط غالبًا دور N1 وN2 وN3. يحمل N1 معلومات جلسة PDU على طبقة NAS نحو UE. وينسق N2 موارد RAN وموارد مستوى المستخدم التي يجب على gNB إنشاؤها. أما N3 فيحمل حركة مستوى المستخدم الفعلية بعد أن تصبح تلك الموارد جاهزة.
لذلك لا ينبغي أن يتوقف استكشاف فشل جلسة PDU بمجرد أن تعيد طبقة NAS رسالة Accept. فإذا لم يكتمل إجراء PDU Session Resource Setup على N2 بنجاح، فقد يكون UE قد استلم معلمات الجلسة بينما لا يزال مستوى المستخدم غير عامل.
يستمر N2 في العمل بعد إنشاء جلسة PDU
لا يتوقف NGAP بمجرد تنشيط جلسة PDU. وما دام UE موجودًا في الشبكة، يمكن أن تؤدي تغييرات الحالة أو ظروف الخدمة إلى تشغيل إجراءات N2 إضافية.
عندما ينتقل UE إلى gNB آخر، قد يتم تشغيل تسليم قائم على N2 أو Xn. ويمكن أن يشمل تسليم N2 رسائل Handover Required وHandover Request وHandover Request Acknowledge وHandover Command وHandover Notify. وبعد إنشاء المسار الجديد، قد تتبعها Path Switch Request واستجابتها، بينما يتم تحرير سياق UE القديم على gNB المصدر.
إذا كان UE في حالة خمول ووصلت حركة هابطة، يستطيع AMF إرسال رسالة Paging إلى NG-RAN عبر NGAP، ثم ينفذ RAN إجراء الاستدعاء على جانب الراديو. ويُعد Paging إجراء NGAP أحادي الاتجاه نموذجيًا. وإذا احتاجت الشبكة إلى تعديل QoS أو موارد RAN أخرى، يمكن تشغيل PDU Session Resource Modify. وعندما لا تعود الجلسة مطلوبة، تُستخدم PDU Session Resource Release. ولذلك لا تتضمن دورة حياة N2 لجلسة PDU مرحلة Setup فقط، بل تشمل أيضًا Modify وRelease وNotify وإجراءات Indication ذات الصلة.
بالإضافة إلى إجراءات الخدمة المرتبطة بـUE، قد يرى المهندسون أيضًا رسائل إدارة الواجهة مثل NG Reset وError Indication وOverload Start وOverload Stop وAMF Status Indication وإجراءات تحديث التهيئة. وتفيد هذه الرسائل خصوصًا في تحديد ما إذا كانت المشكلة تؤثر في UE واحد أو تعكس تغييرًا أوسع في العلاقة بين عقد N2.
ما أفضل ترتيب لاستكشاف الأخطاء في التقاط حزم NGAP؟
يحتوي NGAP على عدد كبير من الرسائل، لكن استكشاف الأعطال عمليًا لا يتطلب مراجعة قائمة رسائل 3GPP من البداية إلى النهاية. الأفضل هو اتباع الترتيب الذي تُنشأ به حالة الشبكة.
الخطوة الأولى هي التحقق من SCTP. فإذا لم يتم إنشاء Transport Network Layer Association بين gNB وAMF بشكل صحيح، فلن تكون هناك فائدة كبيرة من تحليل إجراءات خدمة NGAP التي يفترض أن تأتي بعد ذلك.
الخطوة الثانية هي فحص NG Setup والتأكد من سلامة علاقة N2 على مستوى العقد. فإذا فشل NG Setup، فلا يكون من المنطقي عادة الانتقال مباشرة إلى استكشاف تسجيل UE.
الخطوة الثالثة هي تحديد UE بعينه. تحتوي رسائل NGAP المرتبطة بـUE عادة على قيم UE-NGAP-ID ذات الصلة. وينبغي أن يتتبع تحليل الحزم معرّفات UE نفسها عبر الزمن بدلًا من التصفية حسب نوع الرسالة فقط.
الخطوة الرابعة هي التأكد من نقل إشارات NAS بصورة صحيحة. تحقق مما إذا كانت Initial UE Message وUplink NAS Transport وDownlink NAS Transport تشكل تسلسلًا متصلًا. فإذا وصل NAS-PDU بالفعل إلى AMF من دون استجابة لاحقة، يختلف اتجاه التحقيق كثيرًا عن حالة لم يسلّم فيها gNB رسالة NAS من الأصل.
الخطوة الخامسة هي فحص إنشاء سياق UE. فإذا تقدم التسجيل إلى Initial Context Setup، راجع المعلمات في Request وتأكد من اكتمال Response بنجاح.
الخطوة السادسة هي فحص موارد جلسة PDU. فإذا كان UE مسجلًا لكنه لا يستطيع الوصول إلى شبكة البيانات، فركز على PDU Session Resource Setup Request/Response وعلى نتائج موارد جلسة PDU وتدفقات QoS المعادة.
إذا ظهرت المشكلة أثناء التنقل، فحوّل التحقيق إلى Handover وPath Switch وتحرير سياق UE القديم. وإذا تعذر الوصول إلى UE خامل بواسطة حركة هابطة، فركز على Paging.
اتباع السلسلة SCTP → NG Setup → تحديد UE → NAS → سياق UE → جلسة PDU → التنقل يكون عادة أكثر فاعلية بكثير في العمل الهندسي الحقيقي من محاولة حفظ عشرات أسماء رسائل NGAP.
الأسئلة الشائعة
ما العلاقة بين NGAP و5G NAS؟
NGAP هو بروتوكول طبقة التطبيق المستخدم على واجهة N2 بين gNB وAMF، بينما يحمل NAS إشارات التحكم بين UE ونواة 5G. وتُغلّف كثير من رسائل NAS على هيئة NAS-PDU داخل رسائل NGAP ويقوم gNB بتمريرها بين UE وAMF، ولذلك يعمل البروتوكولان على مستويين مختلفين.
هل تحمل واجهة N2 حركة الإنترنت الخاصة بـUE؟
لا. لا تُستخدم N2 كمسار مستوى المستخدم المعتاد لبيانات UE، بل تحمل إشارات مستوى التحكم. وتُنقل حركة المستخدم عادة بين gNB وUPF عبر N3، بينما يخبر NGAP شبكة RAN بالموارد ذات الصلة التي يجب إنشاؤها أو تعديلها أو تحريرها.
هل يعني نجاح NG Setup أن UE يستطيع التسجيل بصورة طبيعية؟
لا. ينشئ NG Setup فقط علاقة N2 على مستوى العقد بين gNB وAMF. وعند وصول UE محدد، يجب أيضًا أن تكتمل بنجاح Initial UE Message ونقل NAS وإنشاء سياق UE وإجراءات موارد جلسة PDU اللاحقة.
لماذا لا ينبغي الاعتماد على مرشحات نوع الرسالة وحدها عند استكشاف NGAP؟
يمكن لـgNB واحد معالجة عدد كبير من أجهزة UE في الوقت نفسه، وقد تظهر أنواع رسائل NGAP نفسها مرارًا لمستخدمين مختلفين. وقد تؤدي التصفية حسب اسم الرسالة فقط إلى خلط إجراءات غير مرتبطة بسهولة. لذلك ينبغي في استكشاف UE محدد الجمع بين قيم UE-NGAP-ID وتوقيت الرسائل وسياق NAS أو جلسة PDU ذي الصلة.
