أحد أكثر الأخطاء شيوعًا أثناء استكشاف الأعطال ميدانيًا هو رؤية RRC Release والافتراض أن إلغاء تسجيل UE قد اكتمل بالفعل. قد يكون الاتصال الراديوي قد انقطع فعلًا وقد يكون UE قد توقف عن إرسال البيانات، لكن سياق التسجيل في AMF، وجلسة PDU في SMF، وجلسة N4 في UPF، وارتباطات السياسات في PCF، وسجلات التسجيل في UDM لا تختفي جميعها في اللحظة نفسها لمجرد أن «الإشارة اختفت». ما يهم في تتبع الإشارات هو سلسلة التنظيف بين وظائف الشبكة التي تلي Deregistration Request: كيف يحدد AMF نطاق إلغاء التسجيل، وكيف يوجّه SMF الـUPF لإزالة موارد مستوى المستخدم، وإلى أي مدى يجب تحرير ارتباطات PCF وUDM.
إلغاء التسجيل الذي يبدأه UE هو إجراء منضبط لإخراج UE المسجل مسبقًا من 5GS. يبدأ بطلب NAS Deregistration Request وقد يتضمن تحرير جلسات PDU، وحذف جلسات N4 وأنفاق مستوى المستخدم في UPF، وإنهاء ارتباطات SM Policy وAM Policy، وإزالة حالة التسجيل ذات الصلة في UDM، ثم تحرير اتصال الإشارات بين UE وشبكة الوصول. قد يبدو إلغاء التسجيل العادي وإيقاف التشغيل متشابهين في الجزء الأول من الإجراء، لكنهما ينتهيان بطريقة مختلفة: أحدهما ينتظر Deregistration Accept، بينما الآخر لا يبقى متصلًا لمجرد تلقي التأكيد. من السهل إغفال هذا الاختلاف عند تحليل التتبعات.
لماذا يُعد إلغاء التسجيل أكثر من مجرد وضع UE في حالة غير متصل؟
بعد أن يكمل UE إجراء Initial Registration وينشئ جلسة PDU، لا يحتفظ 5GC بمجرد علامة واحدة تفيد بأنه «متصل». يحتفظ AMF بسياق التسجيل والتنقل، ويدير SMF سياق جلسة PDU، ويحتفظ UPF بجلسة N4 إلى جانب موارد تحويل مستوى المستخدم مثل FAR وQER وURR، ويخزن UDM علاقات تسجيل AMF وSMF، وقد يحتفظ PCF بارتباطات سياسات AM أو UE أو SM.
إذا اختفى UE ببساطة من الشبكة، فلن تتم إزالة هذه الموارد تلقائيًا في اللحظة نفسها. ويصبح ذلك مهمًا بشكل خاص عند استمرار وجود جلسة PDU واحدة أو أكثر. يجب على الشبكة معرفة الجلسات التي ينبغي تحريرها، وقواعد مستوى المستخدم التي ينبغي حذفها، والاشتراكات أو ارتباطات السياسات التي لم يعد هناك سبب للاحتفاظ بها.
لذلك ينفذ إلغاء التسجيل الذي يبدأه UE عملية تفكيك منظّم لحالة التسجيل والموارد المرتبطة بها:
يشير UE إلى ضرورة إنهاء تسجيل 5GS الحالي
→ يحدد AMF نطاق إلغاء التسجيل
→ يتم تحرير جلسات PDU ذات الصلة
→ يوجّه SMF الـUPF لإزالة موارد مستوى المستخدم
→ تُحذف ارتباطات الجلسات والسياسات
→ تُزال حالة التسجيل
→ يُحرر اتصال الإشارات من جهة الوصول
لهذا السبب لا ينبغي الخلط بين إلغاء التسجيل وRRC Release أو تحرير اتصال N2 العادي. فتحرير اتصال RAN يعني فقط أن اتصال إشارات الوصول الحالي قد انتهى. أما إلغاء التسجيل فيعمل على مستوى أعلى ويزيل علاقة تسجيل 5GS مع حالة الجلسات والسياسات المرتبطة بها. إذا أظهر التتبع RRC Release فقط، فقد يؤدي اعتبار UE قد أُلغي تسجيله بالفعل إلى الخلط بين «تحرير اتصال الوصول» و«إزالة التسجيل».
كيف يحدد Deregistration Request طريقة خروج UE ونوع الوصول الذي يغادره؟
عندما يغادر UE شبكة 5GS بصورة نشطة، يرسل إلى AMF رسالة NAS Deregistration Request. ولتحليل الإشارات، لا تكون الخطوة الأولى هي البحث عما إذا كانت رسائل PFCP ستظهر لاحقًا، بل فحص Deregistration type وAccess Type الموجودين في الطلب.
يخبر Deregistration type الشبكة أولًا ما إذا كان الإجراء حالة إيقاف التشغيل. ومن منظور هندسي، يظهر إلغاء التسجيل الذي يبدأه UE عادة في حالتين: إلغاء تسجيل عادي يخرج فيه UE بصورة منظّمة، وإيقاف التشغيل يشير فيه UE إلى أنه على وشك إيقاف التشغيل أو الدخول في حالة إغلاق مماثلة.
يجيب Access Type عن سؤال مختلف: أي نوع وصول يتم إلغاء تسجيله فعليًا؟ يمكن لـUE إلغاء التسجيل من وصول 3GPP فقط، أو من وصول غير 3GPP فقط، أو قد يشمل الإجراء النوعين عندما يكون كلا نوعي الوصول في PLMN نفسها مخدومين بواسطة AMF نفسه، بحسب الحالة. لذلك لا يعني «إلغاء تسجيل UE» دائمًا إزالة كل حالات الوصول المرتبطة بذلك UE دفعة واحدة.
يحمل Deregistration Request أيضًا معلومات هوية UE. عند توفر 5G-GUTI صالح، يمكن لـUE استخدامه لمساعدة AMF على ربط رسالة NAS بسياق UE القائم. وإذا لم يتوفر 5G-GUTI صالح، تعتمد معالجة الهوية على هوية 5GS المتاحة حاليًا لـUE. ومن منظور AMF، فإن ربط رسالة NAS هذه بصورة صحيحة بسياق UE القائم شرط أساسي لتحرير جلسات PDU وارتباطات السياسات الصحيحة.
في إلغاء التسجيل العادي يرسل UE الطلب وينتظر تأكيد الشبكة على اكتمال العملية. أما في إيقاف التشغيل فالهدف هو إيصال إشارة «سأغادر» بأسرع ما يمكن ثم متابعة الإغلاق، ولذلك تختلف المعالجة. قد يستخدم إلغاء التسجيل العادي المؤقت T3521 لمراقبة الفترة التي ينتظر فيها UE رسالة Deregistration Accept، بينما لا ينتظر إجراء إيقاف التشغيل تأكيد الشبكة بالطريقة نفسها.
لماذا يتحقق AMF أولًا مما إذا كان UE لا يزال يملك جلسة PDU؟
بعد تلقي Deregistration Request، يكون أحد القرارات الأساسية لـAMF هو تحديد ما إذا كانت لا تزال هناك جلسات PDU منشأة على الوصول المستهدف.
إذا لم يكن لدى UE جلسة PDU ذات صلة، فلا توجد جلسة مستوى مستخدم منفصلة ينبغي تفكيكها، وبالتالي يمكن أن يكون الإجراء أقصر بكثير. أما إذا بقيت جلسة PDU واحدة أو أكثر نشطة، فلا يمكن لـAMF حذف سياق التسجيل الخاص به فقط، لأن SMF وUPF سيستمران في اعتبار تلك الجلسات قائمة.
لكل جلسة PDU يجب تحريرها، يستطيع AMF استدعاء Nsmf_PDUSession_ReleaseSMContext نحو SMF المقابل. ويمكن فهم ذلك بوصفه تعليمات صريحة من AMF إلى طبقة إدارة الجلسات: يغادر UE الوصول المستهدف، ولذلك لم يعد ينبغي الحفاظ على SM Context المرتبط. بعد تلقي هذه التعليمات فقط يستطيع SMF متابعة حذف جلسة N4 وإنهاء ارتباطات السياسات وتنظيف حالة التسجيل ذات الصلة في UDM.
يوضح ذلك أيضًا الفرق بين إلغاء التسجيل والتحرير المستقل لجلسة PDU. فتحرير جلسة PDU واحدة لا يعني أن UE يغادر 5GS؛ بل يمكن أن يبقى في حالة 5GS Registered. أما عندما يبدأ UE إلغاء التسجيل، فيجب عادة تنظيف جلسات PDU المرتبطة بالوصول المستهدف كجزء من إجراء إلغاء التسجيل الأوسع.
لذلك إذا أظهر التتبع Deregistration Request ولم يظهر بعده Nsmf_PDUSession_ReleaseSMContext، فلا ينبغي اعتبار ذلك فورًا نقصًا في الإشارات. يجب أولًا التأكد مما إذا كان UE يمتلك فعلًا جلسة PDU منشأة على Access Type المعني. فإذا لم تكن هناك جلسة PDU أصلًا، فقد يكون عدم وجود إجراء تحرير N4 هو السلوك المطلوب تمامًا.
كيف يقوم SMF وUPF فعليًا بتفكيك مستوى المستخدم؟
بعد أن يرسل AMF طلب تحرير جلسة PDU إلى SMF، يصبح SMF مسؤولًا عن إزالة موارد مستوى المستخدم المرتبطة. وإذا كانت هناك جلسة في UPF، يقوم SMF بتحريرها عبر واجهة N4.
في حالة نموذجية يرسل SMF PFCP Session Deletion Request. يستخدم UPF قيمة F-SEID المقابلة أو سياق جلسة N4 لإزالة حالة التحويل الخاصة بالمستخدم، ثم يعيد PFCP Session Deletion Response. بعد ذلك تُزال أنفاق مستوى المستخدم وقواعد التحويل والسياق المرتبط بجلسة PDU. ولا يقتصر التنظيف على نفق واحد؛ بل يزيل أيضًا حالة القواعد المرتبطة بتلك الجلسة N4، بما في ذلك FAR وQER وURR وأي قواعد أخرى تنطبق.
يمكن تلخيص علاقة التحكم كما يلي:
UE → AMF: أريد إلغاء التسجيل
→ AMF → SMF: حرر سياق جلسة PDU لهذا UE
→ SMF → UPF: احذف جلسة N4 وموارد مستوى المستخدم
→ UPF → SMF: تأكيد الحذف
→ SMF → AMF: اكتمل تحرير SM Context
إذا كانت الجلسة تستخدم PCC ديناميكيًا، فقد يحتاج SMF أيضًا إلى إنهاء ارتباط SM Policy المقابل، مثلًا عبر Npcf_SMPolicyControl_Delete. وعندما تكون الجلسة المحررة هي آخر جلسة PDU يديرها ذلك SMF للـDNN والـS-NSSAI المعنيين، فقد يلغي SMF أيضًا اشتراكه في تغييرات Session Management Subscription Data في UDM ويستخدم Nudm_UECM_Deregistration لإزالة الارتباط بين SMF والـDNN/PDU Session المقابلة من UDM.
من منظور تتبع UPF، فإن النقطة التي يصل فيها إلغاء التسجيل فعليًا إلى مستوى المستخدم ليست NAS Deregistration Request نفسه، بل تحرير جلسة N4 اللاحق. ولا تُزال موارد التحويل التابعة لجلسة PDU الأصلية من مستوى المستخدم فعليًا إلا بعد اكتمال هذه الخطوة.
لماذا لا يزال UDM وPCF يحتاجان إلى تنظيف إضافي للسياق؟
بعد اكتمال تحرير جلسة PDU قد يكون مستوى المستخدم قد اختفى بالفعل، لكن بعض ارتباطات مستوى التحكم قد تبقى داخل 5GC. ولكي يكتمل إلغاء التسجيل بالكامل، يجب على الشبكة تحديد أي الاشتراكات والتسجيلات وعلاقات السياسات ما زالت صالحة وأيها ينبغي إزالته.
من جهة إدارة الجلسات، إذا لم يعد SMF يخدم آخر جلسة PDU للمستخدم بالنسبة إلى DNN وS-NSSAI المعنيين، فيمكنه إلغاء اشتراكه في تحديثات SM Data في UDM وإزالة SMF Registration المرتبط. يمنع ذلك UDM من الاستمرار في إرسال تحديثات Session Management إلى SMF لم يعد يخدم تلك الجلسة.
من جهة سياسة الوصول والتنقل، إذا لم يعد UE مسجلًا عبر أي Access Type ذي صلة وكان هناك AM Policy Association بين AMF وPCF، فيجب على AMF إنهاء ذلك الارتباط. وإذا وجد UE Policy Association فينبغي تحريره أيضًا عند تحقق الشروط المناسبة. وإذا لم يعد AMF يحتفظ بأي تسجيل صالح لذلك UE، فقد يلزم أيضًا إزالة علاقة تسجيل AMF في UDM عبر Nudm_UECM_Deregistration.
هناك حد مهم هنا: لا ينبغي افتراض أن كل سياق PCF وUDM يجب أن يختفي لمجرد حدوث إجراء إلغاء تسجيل واحد. إذا ظل UE مسجلًا عبر Access Type آخر، أو كان SMF نفسه لا يزال يدير جلسات PDU أخرى ذات صلة بذلك UE، فقد تظل بعض الارتباطات مطلوبة.
لذلك فإن تنظيف إلغاء التسجيل ليس مجرد تسلسل ثابت من طلبات DELETE. بل يتبع مبدأً واحدًا: أزل فقط الحالة التي فقدت معناها التشغيلي بسبب هذا الإلغاء، مع الحفاظ على السياق الذي ما زال مستخدمًا بواسطة وصول أو جلسة أخرى. وهذه من أكثر النقاط التي يسهل إساءة تفسيرها في البيئات متعددة الوصول ومتعددة جلسات PDU.
لماذا ينتهي إلغاء التسجيل العادي وإيقاف التشغيل بصورة مختلفة؟
قد يؤدي كل من إلغاء التسجيل العادي وإيقاف التشغيل إلى تحرير جلسات PDU وموارد الشبكة الأساسية في الجزء الأول من الإجراء، لكنهما يختلفان في كيفية اكتمال العملية من جهة UE.
في إجراء إلغاء التسجيل العادي، ينتظر UE بعد إرسال Deregistration Request تأكيد الشبكة. وعندما يكمل AMF المعالجة اللازمة، يعيد Deregistration Accept، ليبلغ UE صراحة بأن الشبكة قبلت إلغاء التسجيل. ويمكن لآليات NAS مثل T3521 مراقبة فترة الانتظار هذه. وإذا انتهت مدة T3521، يتبع UE آلية إعادة الإرسال أو معالجة الاستثناء المحددة في البروتوكول بدلًا من افتراض أن إلغاء التسجيل قد اكتمل.
إذا كان إلغاء التسجيل يخص وصول 3GPP وما زال هناك اتصال إشارات N2 بين AMF وNG-RAN، فيمكن لـAMF بعد ذلك متابعة N2 UE Context Release لإنهاء اتصال الإشارات المقابل على جهة الوصول.
أما إيقاف التشغيل فيختلف. فـUE على وشك إيقاف التشغيل، ولذلك لا توجد فائدة كبيرة من إبقائه متصلًا فقط لانتظار رسالة تأكيد. عندما يشير Deregistration type إلى إيقاف التشغيل، لا يعالج AMF جهة UE بالطريقة نفسها كما في إلغاء التسجيل العادي من خلال اشتراط Deregistration Accept قبل خروج UE. وبعد أن يبذل UE أفضل محاولة لإرسال Deregistration Request، يمكنه متابعة عملية الإغلاق.
ويصبح هذا الاختلاف مهمًا بصورة خاصة في تتبعات الحزم:
إلغاء تسجيل عادي
Deregistration Request
→ تحرر الشبكة الأساسية الموارد ذات الصلة
→ Deregistration Accept
→ تحرير الإشارات / AN
إيقاف التشغيل
Deregistration Request
→ تحرر الشبكة الأساسية الموارد ذات الصلة
→ لا ينتظر UE رسالة Deregistration Accept قبل إكمال إيقاف التشغيل
لذلك فإن غياب Deregistration Accept من تتبع إيقاف التشغيل لا يعني تلقائيًا أن الإجراء فشل. تتمثل الخطوة الأولى في التحقق مما إذا كان Deregistration type هو إلغاء تسجيل عادي أم إيقاف التشغيل. وإذا كان UE قد أوقف التشغيل بالفعل، أو فقد الرابط الراديوي، أو لم يكن لديه وقت كافٍ لاستقبال الرد، فقد تعتمد الشبكة لاحقًا على آليات مثل Mobile Reachable Timer وImplicit Deregistration لمعالجة الاختفاء غير الطبيعي لـUE.
الأسئلة الشائعة
هل يضمن UE إيصال Deregistration Request إلى AMF عند إيقاف التشغيل؟
لا. تم تصميم إجراء إيقاف التشغيل بحيث يبذل UE أفضل محاولة لإرسال طلب إلغاء التسجيل قبل الإغلاق، لكن الشبكة قد لا تستلمه مطلقًا إذا كان UE قد فقد التغطية بالفعل، أو فشل الرابط الراديوي، أو انقطعت الطاقة فجأة. ولهذا لا يزال 5GC يحتاج إلى آليات على جانب الشبكة مثل Mobile Reachable Timer وImplicit Deregistration للتعامل مع وحدات UE التي تختفي بصورة غير متوقعة.
هل يؤدي إلغاء تسجيل UE دائمًا إلى PFCP Session Deletion؟
لا. إذا لم توجد جلسة PDU منشأة على Access Type المستهدف، فلا توجد جلسة N4 مقابلة في مستوى المستخدم ليتم تحريرها، ولذلك قد لا تظهر خطوات SMF وUPF المرتبطة بتنظيف جلسة PDU. لا تكون PFCP Session Deletion مطلوبة إلا عندما توجد فعلًا جلسة PDU ذات صلة وموارد مستوى المستخدم التابعة لها.
هل إلغاء التسجيل وتحرير جلسة PDU هما الإجراء نفسه؟
لا. يؤدي تحرير جلسة PDU إلى إزالة جلسة بيانات محددة بينما يمكن أن يبقى UE في حالة 5GS Registered. أما إلغاء التسجيل فيزيل علاقة تسجيل UE مع 5GS. وعندما يلغي UE تسجيله، يجب عادة تحرير جلسات PDU القائمة باعتبارها موارد مرتبطة، لكن الإجراءين يعملان على مستويين مختلفين ولهما هدفان مختلفان.
لماذا قد يبقى بعض سياق UDM أو PCF بعد إلغاء تسجيل UE؟
تحقق أولًا من Access Type الذي ينطبق عليه إلغاء التسجيل وما إذا كان UE ما زال مسجلًا عبر وصول آخر. إذا كان لدى UE وصول صالح آخر، أو جلسات PDU أخرى ما زالت مستخدمة، أو علاقات سياسات ما زالت مطلوبة، فقد يلزم الاحتفاظ ببعض السياق. لا ينبغي تفسير إلغاء التسجيل على أنه حذف غير مشروط لكل حالة تخص UE في كامل 5GC.
