عند الساعة 3:00 صباحًا، ترسل بوابة صناعية تعمل بتقنية 5G رسالة Registration Request إلى AMF. لم يتغير TAI منذ التسجيل السابق، و5G-GUTI هو نفسه، ولم يتغير AMF المُقدِّم للخدمة، وربما لم يرسل الجهاز أي بيانات صاعدة منذ عدة ساعات. من منظور إدارة التنقل فقط، لا يحمل الطلب أي معلومات موقع جديدة وقد يبدو وكأنه تسجيل مكرر. لكن حقل نوع التسجيل يحدد بوضوح أنه تحديث تسجيل دوري. ما يحتاج AMF إلى تأكيده ليس المكان الذي انتقل إليه UE، بل أمرًا أكثر أساسية: هل ما زال UE حاضرًا، وهل ينبغي اعتباره قابلًا للوصول عبر النداء، وهل يجب الاستمرار في الاحتفاظ بسياق تسجيله؟
في إدارة التسجيل ضمن 5GC، يعالج تحديث التسجيل بسبب التنقل وتحديث التسجيل الدوري مشكلتين مختلفتين. الأول يُشغَّل بسبب التنقل ويركز على تحديث الموقع والتوجيه، بينما يُشغَّل الثاني عند انتهاء T3512 ويركز على التأكيد الدوري لحالة التسجيل وإمكانية الوصول إلى UE. قد يحتاج UE الذي يبقى في CM-IDLE مدة طويلة إلى الاتصال بالشبكة عند انتهاء T3512 حتى إذا ظل ضمن منطقة التسجيل نفسها وتحت AMF المُقدِّم للخدمة نفسه ولم يتغير موقعه. من خلال هذا التفاعل، تحدّث الشبكة تصورها لإمكانية الوصول إلى UE، وإذا استمر غيابه يمكنها في النهاية تحرير سياق تسجيل قديم عبر إلغاء التسجيل الضمني. لذلك، مفتاح فهم تحديث التسجيل الدوري ليس ما إذا كانت Registration Request تحمل موقعًا جديدًا، بل كيفية إدارة T3512، وكيف يطلق UE الإجراء في CM-IDLE، وكيف يفسر AMF حقل نوع التسجيل وسياق UE، وكيف تتعامل الشبكة مع UE لم ينفذ التحديث في الوقت المحدد.
لماذا نحتاج إلى تحديث تسجيل دوري إذا لم يتحرك UE؟
بعد إتمام التسجيل الأولي، يدخل UE حالة 5GS Registered. لكن كلمة «مسجل» لا تعني أن UE يحافظ باستمرار على اتصال إشارات NAS مع AMF. تدخل كثير من الهواتف الذكية وأجهزة إنترنت الأشياء والأجهزة الطرفية ذات حركة البيانات المنخفضة إلى CM-IDLE عند غياب نشاط البيانات أو الإشارات، بهدف تقليل استهلاك موارد الراديو والشبكة الأساسية.
من منظور UE، يوفر البقاء غير نشط لفترات طويلة الموارد. أما من منظور 5GC، فينشأ سؤال مهم: آخر مرة عرف فيها AMF أن UE متاح ربما كانت قبل عشرات الدقائق أو حتى ساعات. منذ ذلك الحين قد يكون UE قد أُطفئ، أو فقد التغطية، أو نفدت بطاريته، أو قد يكون ببساطة ما يزال متمركزًا طبيعيًا على الشبكة من دون توليد أي حركة بيانات.
إذا احتفظت الشبكة الأساسية بتسجيل UE إلى أجل غير مسمى، فقد تواصل الاحتفاظ بسياق قديم لجهاز لم يعد قابلًا للوصول. وإذا أزالت السياق بسرعة مفرطة، فقد تضطر جهاز UE ما يزال مسجلًا بصورة طبيعية إلى إنشاء تسجيل جديد من دون حاجة.
يوازن تحديث التسجيل الدوري بين هذين المطلبين. تستخدم الشبكة T3512 لإبلاغ UE بالمدة التي يمكن أن يبقى خلالها من دون تفاعل 5GMM آخر ذي صلة قبل أن يبدأ تحديث تسجيل دوريًا.
لذلك يمكن النظر إلى الإجراء على أنه تحقق دوري من الحالة بين UE و5GC:
UE مسجل بالفعل
→ يبقى UE في CM-IDLE لفترة ممتدة
→ يستمر T3512 في العد
→ ينتهي T3512
→ يعيد UE إنشاء اتصال إشارات NAS
→ يبدأ UE تحديث التسجيل الدوري
→ يؤكد AMF حالة التسجيل ويحدّثها
الهدف الأساسي ليس الإبلاغ عن حركة جديدة بين المناطق، بل منع UE والشبكة من البقاء إلى أجل غير مسمى بحالتين غير متزامنتين بشأن ما إذا كان سياق التسجيل الحالي ما يزال صالحًا.

متى يبدأ T3512 فعليًا في العد؟
T3512 ليس مجرد مؤقت محلي يختاره UE. تتحكم الشبكة في قيمته، ويمكن لـ AMF إرسال قيمة مؤقت التسجيل الدوري إلى UE ضمن رسالة Registration Accept. ما لم يتلق UE قيمة جديدة لاحقًا، فإنه يستمر في استخدام إعداد T3512 المخزن.
القيمة الافتراضية لـ T3512 وفق 3GPP هي 54 دقيقة، لكن ذلك لا يعني أن كل UE في كل شبكة 5G تجارية يجري تحديثًا كل 54 دقيقة. يستطيع AMF تعيين قيمة مختلفة وفق إعداد الشبكة وسلوك UE ومعلومات الاشتراك والسياسة. إذا عطلت الشبكة T3512 أو ضبطته على صفر، فلن يتم تنفيذ تحديث التسجيل الدوري المقابل.
في سيناريو شائع لوصول 3GPP، إذا لم تستخدم الشبكة قدرة مؤقت التسجيل الدوري الصارم، يبدأ UE أو يعيد تشغيل T3512 عند انتقاله من 5GMM-CONNECTED إلى 5GMM-IDLE. وعندما يعود UE إلى 5GMM-CONNECTED، يتوقف المؤقت عادة. هذا مهم لأن تحديث التسجيل الدوري لا يُنشأ ببساطة وفق ساعة مطلقة بغض النظر عن نشاط UE.
لنفترض أن UE أكمل التسجيل عند 09:00، ثم حرر اتصال إشارات NAS ودخل CM-IDLE مع ضبط T3512 على 54 دقيقة. إذا لم يحدث تفاعل آخر يوقف المؤقت أو يعيد تشغيله أو يغيره، فمن المتوقع أن يدخل UE إجراء تحديث التسجيل الدوري عند انتهاء المؤقت.
يمكن للسلوك المحدد في إصدارات أحدث من المواصفات أن يدعم أيضًا مؤقت تسجيل دوري صارم. في هذا الوضع قد يبدأ T3512 بعد إكمال التسجيل بنجاح، ولا يتوقف لمجرد دخول UE إلى 5GMM-CONNECTED. وإذا انتهى المؤقت بينما UE في الحالة المتصلة، فقد يُعاد تشغيله، بينما يستمر التعامل مع تحديث التسجيل الدوري الفعلي وفق حالة 5GMM الحالية.
لذلك، ظهور «T3512 = 54 دقيقة» في Registration Accept لا يعني تلقائيًا أن Registration Request يجب أن تظهر بعد 54 دقيقة بالضبط. يجب أن يراعي تحليل الإشارات أيضًا ما إذا دخل UE حالة CONNECTED خلال تلك الفترة، وما إذا حدث تسجيل آخر، وما إذا كان الوضع الدوري الصارم مفعّلًا، وما إذا جرى تحديث المؤقت أو تعطيله.
كيف تختلف Registration Request الدورية عن التسجيل الأولي؟
عند انتهاء T3512، يحتاج UE إلى إعادة إنشاء اتصال طبقة التحكم مع الشبكة. وبعد استعادة مسار إشارات NAS عبر gNB، يرسل gNB إلى AMF رسالة NGAP Initial UE Message تحمل معلومات الموقع الحالية لـ UE ورسالة NAS Registration Request.
أهم عنصر معلومات في تحليل الإشارات هو 5GS registration type (نوع تسجيل 5GS) داخل Registration Request. في هذا الإجراء يُضبط على periodic registration updating (تحديث التسجيل الدوري)، ليبلغ AMF بوضوح أن UE لا يلتحق بـ 5GS للمرة الأولى، ولا يحدّث تسجيله لأنه خرج من منطقة التسجيل، بل يجدد تسجيلًا قائمًا بصورة دورية.
يحمل UE عادة أيضًا 5G-GUTI الحالي حتى يتمكن AMF من ربط الطلب بسرعة بسياق UE موجود. وقد تتضمن الرسالة معلومات مثل Last Visited Registered TAI وUE Security Capability وPDU Session Status لمساعدة الشبكة على مطابقة حالة التنقل والجلسات التي يحتفظ بها UE حاليًا.
وبذلك يمكن التمييز منذ بداية مسار الإشارات بين ثلاثة سيناريوهات لـ Registration Request يسهل الخلط بينها:
التسجيل الأولي: يحتاج UE إلى إنشاء علاقة تسجيل جديدة مع 5GS
تحديث التسجيل بسبب التنقل: تغير موقع تنقل UE أو شروط منطقة التسجيل
تحديث التسجيل الدوري: تحتاج علاقة التسجيل الحالية إلى تجديد دوري
تستخدم الإجراءات الثلاثة Registration Request، لكن أسباب تشغيلها مختلفة جذريًا. عند تحليل إشارات التسجيل في 5GC، لا يكفي رؤية اسم الرسالة «Registration Request» لتحديد الإجراء. أول عنصر يجب فحصه هو نوع تسجيل 5GS.
لماذا يمكن أن يكون التحديث قصيرًا جدًا عندما لا يتغير AMF المُقدِّم للخدمة؟
إحدى أهم خصائص تحديث التسجيل الدوري ليست عدد رسائل الإشارات الجديدة التي يضيفها، بل مدى اختصاره مقارنة بالتسجيل الأولي عندما يظل السياق الحالي صالحًا.
لنفترض أن UE ما يزال ضمن نطاق خدمة AMF نفسه، ولم يحدث تغيير في AMF، وما يزال سياق UE وسياق الأمان المنشآن سابقًا صالحين للاستخدام، ولا يوجد تغيير في الاشتراك أو السياسة يتطلب معالجة إضافية. عندما يستقبل AMF رسالة Registration Request التي تحمل 5G-GUTI الحالي، يمكنه استخدام معلومات GUAMI المرتبطة بهذه الهوية لتحديد أن UE ما يزال مخدومًا محليًا واسترجاع سياق UE المقابل.
في هذه الظروف، لا يلزم بالضرورة تكرار كثير من الإجراءات التي تظهر عادة في التسجيل الأولي الكامل.
إذا كانت الهوية وحالة الأمان ما تزالان صالحتين، فقد لا تكون هناك حاجة إلى إجراء 5G-AKA كامل، ولذلك قد لا يظهر AUSF في مسار الإشارات. وبما أن AMF المُقدِّم للخدمة لم يتغير، فلا يلزم بالضرورة أن يسجل AMF نفسه من جديد لدى UDM أو يسترجع ملف الاشتراك الكامل لمجرد حدوث تحديث دوري. وإذا لم تتغير منطقة الوصول أو السياسة، فقد لا تكون هناك حاجة إلى إجراء PCF AM Policy جديد أيضًا. وإذا لم تكن هناك حاجة لاختيار AUSF أو UDM أو PCF جديد، فقد لا تظهر إجراءات الاكتشاف المقابلة عبر NRF.
لذلك قد يبدو مسار الإشارات المبسط النموذجي كما يلي:
UE
→ gNB: إعادة إنشاء الوصول
→ AMF: Initial UE Message + Periodic Registration Request
→ AMF: استرجاع سياق UE الحالي باستخدام 5G-GUTI
→ gNB / UE: Registration Accept
→ UE: Registration Complete عند الحاجة
عبارة «قد لا يكون مطلوبًا» مهمة. يتيح إطار التسجيل في 3GPP للشبكة تنفيذ أي معالجة للهوية أو الأمان أو الاشتراك أو السياسة تكون ضرورية للسياق الحالي. لذلك لا ينبغي تفسير مسار مبسط في شبكة تجارية على أنه تسلسل إلزامي ثابت لكل تحديث تسجيل دوري.

ما حالات التسجيل التي يمكن لـ Registration Accept تحديثها؟
بعد أن يؤكد AMF إمكانية بقاء UE مسجلًا، يعيد نتيجة التسجيل المحدثة إلى UE عبر Registration Accept. وفق نتيجة الشبكة، قد تتضمن الرسالة معلمات مثل Allowed NSSAI وT3512 وTA List، وعند الحاجة 5G-GUTI جديدًا.
يكتسب T3512 أهمية خاصة في تحديث التسجيل الدوري. إذا قدم AMF قيمة جديدة، فيجب أن يستخدمها UE في الدورة الدورية التالية. وإذا لم تُرسل قيمة جديدة، فيمكن لـ UE الاستمرار في استخدام الإعداد المخزن. يسمح ذلك للشبكة بتعديل سلوك التسجيل الدوري بمرور الوقت بدل تثبيت الفاصل الزمني دائمًا داخل الجهاز.
تستمر TA List في Registration Accept في تعريف منطقة التسجيل الحالية لـ UE. وعلى الرغم من أن التحديث الدوري نفسه لا يُشغَّل بسبب الخروج من هذه المنطقة، فإن تفاعل تسجيل ناجحًا يظل يتيح للشبكة تزويد UE بأحدث معلمات إدارة التنقل.
إذا احتوت Registration Accept على 5G-GUTI جديد، فيحتاج UE إلى تأكيد الاستلام الناجح للهوية المؤقتة عبر Registration Complete. وإذا لم يخصص AMF 5G-GUTI جديدًا، فإن غياب Registration Complete لا يعني تلقائيًا وجود فشل. يجب تفسير مسار الإشارات وفق عناصر المعلومات في Registration Accept التي تحتاج فعليًا إلى تأكيد.
وهذا يوضح أيضًا أن تحديث التسجيل الدوري أكثر من مجرد آلية للحفاظ على النشاط. فهو يظل جزءًا من إطار 5GMM Registration، ويتيح للشبكة إعادة مزامنة معلمات التنقل المتعلقة بالتسجيل بدل الاكتفاء بالتحقق من قدرة UE على الاستجابة.
كيف يمكن التحقق من تحديث التسجيل الدوري في مسار الإشارات؟
عند استكشاف مشكلات تحديث التسجيل الدوري، لا تكون البداية الأكثر فاعلية هي البحث عن إشارات AUSF أو UDM. الأفضل هو تتبع السلسلة T3512 → حالة UE → Registration Request → سياق AMF → Registration Accept.
إذا لم يبدأ UE أي تحديث دوري بعد التسجيل، فتحقق أولًا مما إذا كانت Registration Accept تحتوي على قيمة T3512 صالحة. إذا كان T3512 معطلًا أو مضبوطًا على صفر، فلا ينبغي توقع تحديث دوري. وإذا كانت القيمة صالحة، فتأكد من أن UE دخل فعلًا حالة 5GMM-IDLE المناسبة ومن عدم حدوث أي تفاعل NAS قد يكون أوقف المؤقت أو أعاد تشغيله أو حدثه.
إذا أرسل UE رسالة Registration Request لكن AMF تعامل معها كتسجيل أولي، فتحقق من نوع تسجيل 5GS و5G-GUTI. إذا تعذر على AMF ربط 5G-GUTI بسياق UE موجود، فقد يدخل الإجراء في مسار أكثر تعقيدًا لاستعادة الهوية أو إعادة التسجيل.
إذا تم التعرف على Registration Request بصورة صحيحة ثم ظهر بعد ذلك إجراء مصادقة كامل، فهذا وحده لا يثبت وجود مشكلة. يجب فحص NAS Security Context الحالي ومعرفة ما إذا كانت الشبكة قررت إعادة تنفيذ المصادقة وفق سياستها الأمنية.
إضافة إلى T3512 في جانب UE، يستخدم AMF آلية مهمة لمراقبة إمكانية الوصول في جانب الشبكة، وهي Mobile Reachable Timer (مؤقت إمكانية الوصول المتنقل). بالنسبة إلى UE مسجل بصورة طبيعية، يكون هذا المؤقت في جانب الشبكة أطول من T3512، وعادة تكون العلاقة الافتراضية T3512 مضافًا إليه أربع دقائق. يبدأ AMF مؤقت Mobile Reachable Timer بعد تحرير اتصال إشارات NAS ويوقفه عندما يعيد UE إنشاء اتصال NAS.
تعمل الآليتان معًا:
T3512 في جانب UE: يحدد لـ UE متى يجب أن يعود لتحديث التسجيل
Mobile Reachable Timer في جانب AMF: يراقب ما إذا كان UE سيظهر مجددًا ضمن الفترة المتوقعة
إذا لم يتصل UE بالشبكة لفترة طويلة، فإن Mobile Reachable Timer وآلية إلغاء التسجيل الضمني اللاحقة تتيحان للشبكة الأساسية التعامل تدريجيًا مع UE لم يعد من الممكن تأكيد إمكانية الوصول إليه، بدل الاحتفاظ إلى أجل غير مسمى بسياق تسجيل قديم.
لذلك فإن الهدف الحقيقي من تحديث التسجيل الدوري في 5GC ليس «إعادة التسجيل كل بضع عشرات من الدقائق». بل يتيح لـ UE الذي يبقى خاملًا فترة طويلة ولـ AMF إعادة إنشاء فهم مشترك لحالة التسجيل بصورة دورية: UE ما يزال موجودًا، وعلاقة التسجيل الحالية ما تزال صالحة، ويمكن الاستمرار في استخدام معلمات التنقل ذات الصلة خلال الفترة التالية.

الأسئلة الشائعة
هل T3512 ثابت عند 54 دقيقة في كل شبكة 5G؟
لا. أربع وخمسون دقيقة هي القيمة الافتراضية التي حددها 3GPP، لكن AMF يمكنه تعيين قيمة أخرى وفق إعداد الشبكة وسلوك UE ومعلومات الاشتراك والسياسة. يجب أن يعتمد تحليل الإشارات واستكشاف الأعطال دائمًا على قيمة T3512 التي استلمها UE فعليًا بدل افتراض أنها 54 دقيقة دائمًا.
إذا كان لدى UE حركة بيانات طبيعية خلال فترة الـ54 دقيقة، فهل سيرسل تحديث تسجيل دوريًا عند الدقيقة 54 بالضبط؟
ليس بالضرورة. في التشغيل العادي لـ T3512، يؤثر الدخول إلى 5GMM-CONNECTED في المؤقت الدوري، وقد يعاد تشغيل المؤقت عندما يعود UE لاحقًا إلى IDLE. لذلك لا يمكن التنبؤ برسالة Registration Request التالية بمجرد إضافة 54 دقيقة إلى وقت إكمال التسجيل الأولي. كما يختلف سلوك التوقيت عندما يكون مؤقت التسجيل الدوري الصارم مفعّلًا.
هل يتطلب كل تحديث تسجيل دوري مشاركة AUSF وUDM وPCF؟
لا. إذا بقي AMF المُقدِّم للخدمة من دون تغيير، وكان سياق UE وسياق الأمان الحاليان صالحين، ولم تكن هناك حاجة إلى تحديث معلومات الاشتراك أو السياسة، فيمكن أن يبقى الإجراء قصيرًا جدًا. يعتمد استدعاء AUSF أو UDM أو PCF أو NRF على سياق UE وتنفيذ الشبكة في ذلك الوقت. ولا ينبغي اعتبارها وظائف شبكة إلزامية في كل تحديث تسجيل دوري.
هل ينطبق تحديث التسجيل الدوري على الوصول غير 3GPP مثل Wi-Fi؟
تنطبق آلية تحديث التسجيل الدوري المعتمدة على T3512 على UE مسجل في 5GS عبر وصول 3GPP. أما الوصول غير 3GPP، فيستخدم 5GS آليات أخرى مناسبة لإدارة التسجيل وإلغاء التسجيل، ولذلك لا ينبغي تطبيق سلوك T3512 المستخدم مع وصول NR مباشرة على Wi-Fi أو سيناريوهات الوصول غير 3GPP الأخرى.