في شبكة 5G، بعد أن يكمل UE عملية التسجيل، تحتاج الشبكة الأساسية إلى الاحتفاظ بصورة عامة عن موقعه حتى تتمكن من الوصول إليه عند إجراء النداء أو وصول خدمات واردة أو بيانات الوصلة الهابطة. لكن UE لا يبقى في مكان واحد؛ فقد ينتقل من Tracking Area إلى أخرى أو حتى يغادر منطقة خدمة AMF الحالي. ولو كان على UE تنفيذ تسجيل جديد بعد كل حركة، لأصبحت إشارات مستوى التحكم مفرطة. وإذا لم يحدّث موقعه مطلقًا، فقد تفقد الشبكة في النهاية القدرة على معرفة المكان الذي يمكن الوصول إليه فيه. Mobility Registration Update صُمم لتحقيق توازن بين دقة الموقع وكلفة الإشارات.
من الأسئلة الشائعة عند دراسة إشارات 5GC لأول مرة: إذا كان UE مسجلاً بالفعل، فلماذا يحتاج إلى إرسال Registration Request أخرى بعد الانتقال إلى منطقة جديدة؟ هل الانتقال إلى gNB آخر يؤدي دائمًا إلى تحديث؟ وهل الدخول إلى Tracking Area جديدة يعني دائمًا ضرورة تغيير AMF؟ تشير هذه الأسئلة إلى المبدأ نفسه: يظل UE في حالة 5GS Registered، لكن موقعه الحالي قد يكون خرج من Registration Area التي خصصتها الشبكة له سابقًا. لذلك يحتاج 5GC إلى تحديث موقع UE، وتحديد ما إذا كان Serving AMF سيبقى كما هو، وتعيين Registration Area المناسبة للمرحلة التالية من التنقل. هذه ليست عملية تسجيل جديدة عند التشغيل، كما أن UE لا يعيد التسجيل في كل مرة يغيّر فيها الخلية. إنها آلية للحفاظ على استمرارية سياق التنقل في 5GS.
مغادرة Registration Area هي شرط التشغيل الأساسي لتحديث التنقل
لا يقتصر التسجيل في 5GC على Initial Registration. فحقل 5GS registration type الموجود في Registration Request يميّز بين إجراءات مثل Initial Registration وMobility Registration Update وPeriodic Registration Update وEmergency Registration. وفي سيناريوهات التنقل، يُعد الفرق بين Tracking Area (TA) وRegistration Area من أكثر النقاط التي تسبب الالتباس.
تُعد TA إحدى المناطق الأساسية التي تستخدمها الشبكة لإدارة الموقع، بينما تمثل Registration Area مجموعة من مناطق TA يسمح AMF داخلها ببقاء UE مسجلاً. وقد تحتوي Registration Area على TA واحدة أو عدة مناطق TA. افترض أن AMF يخدم TA1 وTA2 وTA3 وTA4، لكنه يخصص TA1 وTA2 فقط لـUE معين كـRegistration Area الحالية استنادًا إلى نمط التنقل. عندما ينتقل UE من TA1 إلى TA2، فإنه يظل داخل المنطقة المسجلة ولا يحتاج إلى تنفيذ Mobility Registration Update لمجرد أن TA قد تغيرت.
يتغير الوضع عندما ينتقل UE إلى TA3 بينما لا تكون TA3 جزءًا من Registration Area المخزنة حاليًا. يكتشف UE أن TAI الحالي يقع خارج منطقته المسجلة، فيرسل NAS Registration Request جديدة ويضبط 5GS registration type على mobility registration updating. لذلك فإن تغيير الخلية لا يؤدي تلقائيًا إلى Mobility Registration Update، وحتى تغيير TA لا يؤدي إليه دائمًا. شرط التشغيل المعتاد هو الدخول إلى TA تقع خارج Registration Area الحالية لـUE.
هذا هو الغرض من مفهوم Registration Area. فهو يسمح لـUE بالتنقل ضمن نطاق محدد دون التفاعل مع 5GC في كل مرة يتجاوز فيها حدود TA، ما يساعد على تحقيق توازن بين دقة الموقع وحمل إشارات مستوى التحكم. ويمكن للشبكة تخصيص قائمة TA أكبر لـUE ذي نمط تنقل أوسع، أو تقليص Registration Area عندما تكون هناك حاجة إلى تتبع أكثر دقة للموقع. ولذلك تُعد Registration Area نفسها جزءًا من سياسة إدارة التنقل.
كيف تعيد Registration Request حالة التنقل الحالية إلى 5GC؟
أوضح فرق بين Mobility Registration Update وInitial Registration هو أن UE ليس مشتركًا مجهولاً تمامًا. فقد أكمل تسجيل 5GS بالفعل ويحتفظ عادةً بمعلومات مثل 5G-GUTI الذي خصصته الشبكة وRegistration Area وسياق NAS ذي الصلة. لذلك لا تُستخدم Registration Request الجديدة لإنشاء الهوية من الصفر، بل تقول للشبكة عمليًا: «أنا UE نفسه الذي تعرفه بالفعل، لكن موقع تنقلي قد تغير».
ينشئ UE أولاً وصول مستوى التحكم عبر gNB الجديد. ثم ينقل gNB رسالة NAS Registration Request إلى AMF داخل NGAP Initial UE Message. وبالإضافة إلى NAS-PDU، توفر Initial UE Message معلومات عن موقع الوصول مثل NR-CGI وTAI الحاليين. وفي Mobility Registration Update نموذجية، قد تحمل Registration Request عدة عناصر معلومات مهمة: يحدد 5GS registration type الإجراء على أنه mobility registration updating؛ ويساعد 5G-GUTI الشبكة على تحديد AMF أو GUAMI المرتبط بالتسجيل السابق لـUE؛ ويوفر Last Visited Registered TAI مرجعًا إلى الموقع المسجل سابقًا؛ وتوضح UE Security Capability خوارزميات NAS المدعومة للتشفير وحماية السلامة؛ وتعكس PDU Session Status جلسات PDU التي يعتقد UE أنها ما زالت نشطة؛ ويمكن لـRequested NSSAI توفير شرائح الشبكة المطلوبة من UE عند الحاجة.
لذلك، أثناء تحليل التتبع، لا ينبغي أن يكون السؤال الأول هو ما إذا كانت المصادقة ستحدث لاحقًا في الإجراء. بل يجب أولاً التحقق مما إذا كانت Registration Request نفسها تحدد بوضوح أن العملية هي Mobility Registration Update وليست Initial Registration. فإذا فُسر نوع التسجيل بشكل غير صحيح، فمن السهل تحليل بقية تدفق الإشارات من منظور خاطئ.
لماذا تتبع التحديثات داخل AMF نفسه والتحديثات بين AMF مسارات مختلفة؟
مغادرة Registration Area لا تعني بالضرورة مغادرة منطقة خدمة AMF الحالي. ويحدد هذا الفرق مباشرة مدى تعقيد بقية إجراء الإشارات، كما أنه أحد أول الفروع التي يجب تحديدها عند تحليل Mobility Registration Update.
يبقى Serving AMF كما هو
افترض أن AMF يخدم TA1 وTA2، بينما كانت الشبكة قد خصصت سابقًا TA1 فقط كـRegistration Area لـUE. عندما ينتقل UE من TA1 إلى TA2، تقع TA2 خارج Registration Area الحالية، ولذلك يلزم تنفيذ Mobility Registration Update. ومع ذلك، تظل TA2 داخل منطقة خدمة AMF نفسه.
في هذه الحالة، لا توجد عملية انتقال فعلية من Old AMF إلى New AMF. فـAMF الحالي يحتفظ بالفعل بسياق تنقل UE، ولا يحتاج إلا إلى معالجة الموقع الجديد وتحديث Registration Area وتجديد أي معلومات لازمة للسياسات أو السياق. تتغير Registration Area، لكن Serving AMF لا يتغير.
يتغير Serving AMF
يصبح الإجراء أكثر تعقيدًا عندما ينتقل UE من TA يخدمها AMF إلى TA يخدمها AMF آخر. فعلى سبيل المثال، قد يكون UE قد أكمل التسجيل تحت AMF1 وحصل على 5G-GUTI مرتبط بـAMF1. وبعد انتقاله عبر gNB جديد إلى منطقة خدمة AMF2، يحتاج New AMF إلى معرفة هوية UE، وأي AMF كان يخدمه سابقًا، وأي سياق يمكن إعادة استخدامه.
لذلك فإن Mobility Registration Update بين AMF ليست مجرد تحديث للموقع، بل تشمل أيضًا نقل سياق إدارة تنقل UE من Serving AMF السابق إلى الجديد.
كيف يعثر New AMF على Old AMF ويسترد سياق UE؟
في سيناريو التنقل بين AMF، فإن أول مسألة يجب على New AMF حلها بعد استلام Registration Request ليست ما إذا كان المشترك يستطيع إنشاء خدمة بيانات، بل تحديد أي AMF كان يدير UE سابقًا. ويلعب 5G-GUTI دورًا مهمًا هنا. تساعد المعلومات المرتبطة بـGUAMI والموجودة في الهوية المؤقتة الشبكة على تحديد AMF الذي كان يخدم UE سابقًا. وبعد ذلك يستطيع New AMF تحديد Old AMF وطلب UE Context الموجود عبر خدمة Namf_Communication.
المنطق المعتاد مباشر: يرسل UE Mobility Registration Update باستخدام 5G-GUTI السابق؛ ويستخرج New AMF الهوية المرتبطة بـAMF من 5G-GUTI؛ ثم يتم تحديد Old AMF؛ ويطلب New AMF الـUE Context؛ ويعيد Old AMF سياق التنقل القابل للنقل. ويمكن لهذه المعلومات أن تساعد New AMF على استعادة معلومات الهوية والتنقل مثل SUPI وGPSI وPEI وأجزاء من Access and Mobility Context، ما يسمح لـServing AMF الجديد بالاستمرار انطلاقًا من حالة UE موجودة بدلاً من التعامل مع الجهاز على أنه مجهول بالكامل.
الحصول على السياق من Old AMF لا يعني أنه يمكن دائمًا تخطي جميع إجراءات الأمان اللاحقة. فإذا كانت معلومات الهوية أو سياق الأمان المتاحان غير كافيين، فقد تطلب الشبكة SUCI الخاص بـUE مرة أخرى وتنفذ التحقق من الهوية أو مصادقة 5G-AKA وفقًا لظروف الأمان الحالية. ولذلك ينبغي تجنب افتراضين جامدين عند تحليل التتبع: لا تتطلب Mobility Registration Update دائمًا مصادقة جديدة كاملة، لكن توفر Old AMF Context لا يضمن أيضًا أن المصادقة لن تحدث مرة أخرى. ويعتمد ظهور Identity Request أو 5G-AKA كامل على UE Context المنقول وNAS Security Context وسياسة الشبكة.
كيف تُكمل UDM وNRF وPCF انتقال مسؤولية Serving AMF؟
استرداد UE Context من Old AMF لا يعني أن علاقة الخدمة قد انتقلت بالكامل. ففي 5GC، يتوزع موقع المستخدم وحالة الخدمة على عدة وظائف شبكية. وبوجه خاص، يجب أن تعرف UDM أي AMF أصبح مسؤولاً الآن عن خدمة UE.
يمكن لـNew AMF استخدام NRF لاكتشاف UDM يوفر الخدمات المطلوبة، ثم تسجيل 3GPP Access Registration الجديدة في UDM. وتكتسب هذه الخطوة أهمية خاصة في سيناريو بين AMF لأن سجل Serving AMF في UDM يجب أن ينتقل من Old AMF إلى New AMF. وبعد ذلك يمكن لـUDM تشغيل Deregistration Notification المناسبة باتجاه Old AMF لتحرير علاقة الخدمة السابقة.
يحتاج New AMF أيضًا إلى Access and Mobility Subscription Data الحالية، التي قد تتضمن GPSI وSubscribed NSSAI وUE-AMBR ومعلمات التسجيل الدوري وقيود RAT وقيود الوصول حسب المنطقة. وإذا تطلب التعامل اللاحق مع PDU Session اختيار SMF، فيمكن لـAMF أيضًا استرداد SMF Selection Subscription Data، بما في ذلك معلومات DNN وDefault DNN المرتبطة بـS-NSSAI ذي الصلة، والاشتراك في تغييرات بيانات الاشتراك المقابلة. ويكمل PCF هذه العملية من خلال توفير Access and Mobility Policy. ويمكن لـNew AMF اختيار PCF المناسب وإنشاء AM Policy Association للحصول على معلومات سياسة التنقل مثل قيود المناطق.
تحل هذه الخطوات مشكلات مختلفة. يخبر Old AMF Context الـNew AMF بالحالة السابقة لـUE. ويخبر UDM Registration الشبكة الأساسية بأي AMF يخدم UE الآن. وتوضح Subscription Data للـNew AMF ما المسموح للمشترك باستخدامه. وتوضح PCF Policy للـAMF قواعد التنقل والوصول المطبقة حاليًا. ولهذا لا ينبغي اختزال Mobility Registration Update في عبارة «يقوم AMF بتحديث TAI». ففي سيناريو بين AMF، تنقل العملية أيضًا مسؤولية إدارة التنقل من AMF إلى آخر.
كيف تحدد Registration Accept نطاق التنقل التالي لـUE؟
بعد اكتمال معالجة الهوية والسياق وبيانات الاشتراك والسياسات، يحتاج AMF إلى تطبيق حالة التسجيل الجديدة على كل من gNB وUE. وفي إجراء نموذجي، يمكن لـAMF استخدام NGAP Initial Context Setup Request لإنشاء أو تحديث السياق المتعلق بـUE في gNB مع تسليم NAS Registration Accept إلى UE.
أهم ما في Registration Accept ليس مجرد نجاح التسجيل. فالرسالة توفر أيضًا معلمات تحدد كيفية عمل UE خلال المرحلة التالية من التنقل. وقد يتم تخصيص 5G-GUTI جديد بعد الانتقال بين AMF ليعكس Serving AMF الجديد. ويحدد Allowed NSSAI شرائح الشبكة المسموح بها حاليًا لـUE. ويحدد T3512 التوقيت المرتبط بـPeriodic Registration Update مستقبلية. أما TA List، أو Registration Area، فتخبر UE بأي مناطق TA يمكنه التنقل بينها مع بقائه مسجلاً دون تشغيل Mobility Registration Update أخرى من النوع نفسه.
بعد أن يكمل gNB معالجة السياق ذات الصلة، يعيد Initial Context Setup Response، ثم يرسل UE رسالة Registration Complete. وهكذا تنتهي Mobility Registration Update الحالية. ومن منظور انتقال الحالة، يمكن تلخيص التدفق كالتالي: يغادر UE الـRegistration Area الحالية؛ وتحمل Registration Request هوية التنقل السابقة إلى 5GC؛ وتحدد الشبكة ما إذا كان Serving AMF يجب أن يتغير؛ ويُنقل UE Context من Old AMF عند الحاجة؛ ويكمل New AMF التسجيل في UDM ويحصل على معلومات الاشتراك والسياسة الضرورية؛ وتوفر Registration Accept الـ5G-GUTI الجديد وRegistration Area؛ وأخيرًا يعيد UE رسالة Registration Complete.
يمكن أن يتبع استكشاف الأعطال سلسلة الحالة نفسها. فإذا وصلت Registration Request إلى New AMF لكن تعذر العثور على Old AMF، فيجب التركيز على 5G-GUTI وGUAMI وعنونة AMF. وإذا تم استرداد Old AMF Context بنجاح لكن الإجراء توقف عند مرحلة UDM، فينبغي أن تشمل الفحوصات التالية اكتشاف UDM وAMF Registration واسترداد بيانات الاشتراك. وإذا اكتملت المعالجة الداخلية للشبكة الأساسية لكن Registration Accept لم تصل إلى UE، فيجب متابعة التحقيق في نتائج السياسات وقيود المناطق وإشارات NGAP الهابطة وإنشاء سياق RAN. والهدف من فهم 5GC Mobility Registration Update ليس حفظ عشرات رسائل HTTP/2 وNGAP، بل فهم كيف تجيب الشبكة عن ثلاثة أسئلة بعد تحرك UE مسجل: أين يوجد UE الآن، وأي AMF يجب أن يواصل إدارته، وأي Registration Area يجب أن تنطبق على فترة التنقل التالية؟
الأسئلة الشائعة
هل ينفذ UE عملية Mobility Registration Update في كل مرة يدخل فيها Tracking Area جديدة؟
ليس بالضرورة. السؤال الأساسي هو ما إذا كانت TA الجديدة ما تزال جزءًا من Registration Area الحالية لـUE. فإذا كان AMF قد خصص بالفعل TA1 وTA2 كـRegistration Area لـUE، فإن الانتقال من TA1 إلى TA2 لا يؤدي عادةً إلى هذا التحديث لمجرد تغير TA. أما الدخول إلى TA خارج Registration Area فهو شرط التشغيل المعتاد.
هل تؤدي Mobility Registration Update دائمًا إلى تغيير AMF؟
لا. قد يغادر UE الـRegistration Area الحالية بينما تظل TA الجديدة ضمن منطقة خدمة AMF نفسه. في هذه الحالة يبقى Serving AMF دون تغيير. ولا يلزم نقل السياق من Old AMF إلى New AMF إلا عندما ينتقل UE إلى منطقة تحتاج إلى خدمة AMF آخر.
هل يتكرر 5G-AKA مع كل Mobility Registration Update؟
لا ينبغي افتراض قاعدة ثابتة. يعتمد تكرار إجراءات الهوية أو 5G-AKA على UE Context المتاح وNAS Security Context وسياسة الشبكة. فإذا أمكن مواصلة استخدام سياق صالح، فقد لا تحتاج بعض إجراءات الأمان إلى التكرار بالكامل. وإذا كانت شروط الهوية أو الأمان غير كافية، فقد تنفذ الشبكة خطوات المصادقة اللازمة مرة أخرى.
ما الفرق بين 5GC Mobility Registration Update والتحديث عند انتقال UE من 4G إلى 5G؟
قد يستخدم كلا السيناريوهين نوع التسجيل Mobility Registration Update، لكن مصدر سياق التنقل يختلف. فالتنقل بالكامل داخل 5GS يتضمن عادةً سياق تنقل بين Old AMF وNew AMF. أما سيناريو التشغيل البيني في وضع الخمول من 4G إلى 5G فقد يتضمن أيضًا MME وN26 وتحويل السياق بين EPS و5GS. وعند تحليل تتبع الإشارات، يجب أولاً تحديد ما إذا كان UE يتحرك داخل 5GS أم يدخل 5GC من EPC.
