إلى أي مشترك ينتمي هذا الـUE؟
هل يُسمح له بالوصول إلى الشبكة الحالية؟
هل يوجد سياق تنقل سابق لا يزال من الممكن إعادة استخدامه؟
ما شرائح الشبكة وإمكانات الوصول التي يشترك فيها الـUE، وأي AMF يجب أن يتولى خدمته؟
عند تشغيل جهاز 5G، يجب على الشبكة الأساسية الإجابة عن هذه الأسئلة قبل إنشاء خدمات بيانات المستخدم. وتُعالج هذه المسائل خلال التسجيل الأولي لـ5G. ومن منظور تتبع الإشارات، فإن الإجراء يتجاوز بكثير مجرد «Registration Request يتبعه نجاح التسجيل». فمنذ إرسال الـUE لرسالة Registration Request وحتى إرجاع Registration Complete في النهاية، قد تنفذ الشبكة معالجة الهوية، واسترجاع سياق AMF السابق، ومصادقة 5G-AKA، وإنشاء أمن NAS، والتسجيل لدى UDM، واسترجاع بيانات الاشتراك، ومعالجة سياسة الوصول.
من الأخطاء الشائعة عند دراسة هذا الإجراء محاولة حفظ كل رسالة بالترتيب. والمنهج الأكثر عملية هو فهم المشكلة التي يحلها AMF في كل مرحلة. ويمكن تلخيص مسار الإشارات الكامل على النحو التالي: تحديد الـUE الذي يطلب الوصول، وإنشاء هوية موثوقة، واستكمال سياق المشترك المطلوب، ثم إتمام التسجيل بعد ذلك فقط.
التسجيل الأولي يثبت حق الـUE في الوصول إلى الشبكة
التسجيل في 5GS ليس إجراءً واحدًا فقط. وبحسب سبب التشغيل، قد ينفذ الـUE إجراءات Initial Registration أو Mobility Registration Update أو Periodic Registration Update أو Emergency Registration. ويحدد الـUE الإجراء المناسب من خلال حقل 5GS registration type في رسالة Registration Request.
يحدث Initial Registration عادة عند تشغيل الـUE ودخوله إلى 5GS. ولأغراض التعلم، غالبًا ما يُقارن بإجراء Attach في LTE/EPC، لكن لا ينبغي اعتبار الإجراءين متطابقين. ففي البنية القائمة على الخدمات لـ5G Core، تتوزع إدارة التنقل والمصادقة وبيانات الاشتراك والتحكم في السياسات بين وظائف شبكة مثل AMF وAUSF وUDM وPCF. لذلك قد يتضمن إجراء تسجيل واحد عدة تفاعلات قائمة على الخدمات بين وظائف الشبكة.
والأهم من ذلك أن Initial Registration ينشئ أساسًا حالة إدارة الوصول والتنقل وليس جلسة بيانات للمستخدم. إذ يجب على الشبكة تحديد الـUE، وإنشاء سياق التنقل، وتحديد NSSAI المسموح بها وقيود المناطق السارية، وإنشاء علاقة الأمان المطلوبة للإشارات اللاحقة. وبعد استكمال هذه الشروط فقط يصبح لدى الـUE الأساس اللازم لطلب PDU Session.
لذلك فإن استلام Registration Accept لا يعني تلقائيًا أن المشترك أصبح قادرًا على الوصول إلى الإنترنت. فالتسجيل وإنشاء PDU Session مرحلتان منفصلتان في 5G Core.
Registration Request يُدخل الـUE في إجراء التسجيل داخل 5G Core
يبدأ إجراء التسجيل في الشبكة الأساسية برسالة NAS Registration Request. يرسل الـUE أولًا رسالة NAS عبر الواجهة الراديوية إلى gNB، ثم ينقل gNB الـNAS-PDU إلى AMF داخل NGAP Initial UE Message. وبالنسبة لمهندس الشبكة الأساسية، تمثل هذه الرسالة نقطة الدخول إلى إجراء التسجيل بأكمله.
إضافة إلى حمل Registration Request، تزود Initial UE Message الـAMF بمعلومات موقع الوصول مثل NR-CGI وTAI. وقد تتضمن رسالة NAS نفسها معلمات مثل 5GS registration type و5GS mobile identity وUE Security Capability وRequested NSSAI.
هذه المعلمات ليست مجرد قائمة بقدرات الـUE. بل يستخدمها AMF لتحديد كيفية متابعة التسجيل. يوضح Registration Type ما إذا كان الـUE ينفذ Initial Registration أو نوعًا آخر من تحديث التسجيل. وتحدد mobile identity ما إذا كان من الممكن ربط سياق مشترك موجود بالـUE. أما Requested NSSAI فتحدد شرائح الشبكة التي يطلبها الـUE، بينما توفر UE Security Capability مدخلات لاختيار خوارزميات أمن NAS لاحقًا.
هناك نقطة يسهل إساءة فهمها: تنفيذ الـUE لإجراء Initial Registration لا يعني بالضرورة أنه لا يملك أي معلومات 5G سابقة. فإذا كان الـUE لا يزال يحتفظ بـ5G-GUTI تم تخصيصه سابقًا، يمكنه تضمين هذه الهوية في Initial Registration Request جديد. وتؤثر قدرة الشبكة على إعادة استخدام المعلومات المرتبطة بهذه الهوية مباشرة في الخطوات التالية.
AMF الجديد يحل هوية الـUE وسياقه السابق
لنفترض أن UE كان مسجلًا سابقًا في 5GS في غوانغتشو، ثم أُوقف تشغيله وانتقل إلى بكين، وبعد ذلك شُغّل مجددًا عبر gNB في بكين. أصبح الـUE الآن تحت خدمة AMF جديد، لكنه قد يظل محتفظًا بـ5G-GUTI الذي خصصه له سابقًا AMF في غوانغتشو.
يمكن لـGUAMI الموجود داخل 5G-GUTI أن يوفر معلومات تساعد على تحديد AMF السابق. وإذا رأى AMF الجديد أن وظيفة الشبكة القديمة ربما لا تزال تحتفظ بسياق مفيد للـUE، فيمكنه طلب UE Context Transfer عبر الاتصال بين وحدات AMF واسترجاع معلومات مثل SUPI وGPSI وPEI وأجزاء من سياق إدارة التنقل.
وهذا يوضح نقطة مهمة: كلمة «Initial» تصف نوع إجراء التسجيل الحالي، ولا تعني أن المشترك يدخل شبكة 5G للمرة الأولى. فقد يظل الـUE محتفظًا بهوية 5G مخصصة سابقًا، وقد يتمكن AMF الجديد من إعادة استخدام سياق من AMF القديم.
لا يلزم التفاعل مع AMF القديم في كل إجراء Initial Registration. فإذا كان AMF الجديد يملك بالفعل معلومات الهوية التي يحتاجها، أو لم يكن هناك سياق UE سابق متاح، فقد يختلف مسار الإشارات. وإذا كان AMF لا يزال بحاجة إلى SUCI الخاص بالـUE، فيمكنه إرسال Identity Request، ويرد الـUE بالهوية المطلوبة في Identity Response.
وبالتالي، فإن عدم وجود Identity Request أو UE Context Transfer في تتبع الحزم لا يدل وحده على فشل التسجيل. والسؤال الأول الذي ينبغي طرحه هو: ما معلومات الهوية والسياق التي يمتلكها AMF بالفعل؟
5G-AKA يحول الهوية المعلنة إلى مشترك موثوق
معرفة الهوية التي يدّعيها الـUE لا تكفي لكي تثق به الشبكة. لذلك ينتقل الإجراء إلى إحدى أهم مراحل الأمان: المصادقة.
يجب على AMF تحديد AUSF قادر على مصادقة المشترك. وفي 5G Core القائم على الخدمات، يتضمن ذلك عادة اكتشاف وظائف الشبكة عبر NRF. وبناءً على الخدمة المطلوبة والمعلومات المتعلقة بالمشترك، يحدد AMF مثيل AUSF مناسبًا ويرسل طلب مصادقة.
بعد ذلك يعمل AUSF مع وظائف المصادقة المرتبطة بـUDM في الشبكة المنزلية. وعند استخدام SUCI، تستطيع الشبكة المنزلية استعادة SUPI المقابل وإعداد بيانات المصادقة اللازمة لـ5G-AKA. ثم يرسل AMF معلمات مثل RAND وAUTN إلى الـUE ضمن NAS Authentication Request. ويجري الـUE حساب المصادقة باستخدام بيانات الاعتماد المخزنة في USIM ويرسل Authentication Response يتضمن RES*.
لا تعتمد المصادقة على مقارنة واحدة تنفذها وظيفة شبكة واحدة. فجانب شبكة الخدمة وجانب الشبكة المنزلية يجريان عمليات التحقق الخاصة بكل منهما. يشتق AMF قيمة HRES* من الاستجابة الواردة من الـUE ويقارنها بـHXRES*. ويتحقق AUSF من RES* المُعادة مقابل XRES* المتوقعة. ولا تقبل الشبكة هوية المشترك باعتبارها مصادَقًا عليها إلا بعد نجاح عمليات التحقق المطلوبة.
بعد المصادقة، تنشئ الشبكة عادة NAS Security Context أو تحدثه. واستنادًا إلى معلومات مثل UE Security Capability، يختار AMF خوارزميات مناسبة لحماية السلامة والتشفير، ويستخدم إجراء Security Mode حتى يمكن حماية إشارات NAS الحساسة اللاحقة.
من منظور هندسي، تشكل هذه المرحلة حدًا أمنيًا واضحًا: قبل المصادقة تعالج الشبكة جهازًا يطلب الوصول؛ وبعد نجاح المصادقة وإنشاء أمن NAS يصبح لدى AMF سياق موثوق ومحمي للـUE على مستوى التحكم.
بيانات الاشتراك والسياسة تستكمل سياق الـUE
تجيب المصادقة الناجحة عن سؤال ما إذا كانت هوية المشترك حقيقية، لكن AMF لا يزال بحاجة إلى معرفة ما يُسمح لهذا المشترك بفعله فعليًا في الشبكة. وتحول المرحلة التالية الهوية التي تمت مصادقتها إلى سياق قابل للاستخدام للوصول والتنقل.
يختار AMF وحدة UDM المناسبة ويسجل نفسه باعتباره AMF الذي يخدم حاليًا SUPI عبر وصول 3GPP. وهذا التسجيل مهم لأن UDM يحتاج إلى معرفة أي AMF يجب أن يتلقى لاحقًا الإشعارات المتعلقة بالتنقل أو أحداث إلغاء التسجيل أو تغييرات بيانات الاشتراك لذلك المشترك.
ثم يسترجع AMF بيانات Access and Mobility Subscription Data. ووفقًا لملف المشترك، قد تتضمن Subscribed NSSAI وUE-AMBR ومعلمات التسجيل الدوري وقيود RAT وقيود المناطق. وهكذا تؤكد المصادقة أن الهوية صحيحة، بينما تجيب بيانات الاشتراك عن سؤال مختلف: ما الذي يُسمح لهذا المشترك الصحيح بفعله في الشبكة الحالية؟
قد يسترجع AMF أيضًا بيانات اشتراك ستُستخدم لاحقًا لاختيار SMF، بما في ذلك معلومات مرتبطة بـS-NSSAI وDNNs وDNN افتراضي. وهذا يسبب التباسًا عند قراءة تتبعات الإشارات: إذا ظهرت SMF Selection Subscription Data بالفعل أثناء التسجيل، فهل أصبح SMF جزءًا من الإجراء؟
ليس بالضرورة. ففي هذه المرحلة لا يحصل AMF إلا على معلومات قد تكون مطلوبة لاختيار SMF في المستقبل. ولا يتطلب Initial Registration إنشاء PDU Session في الوقت نفسه، ولذلك يستطيع AMF استرجاع بيانات الاشتراك هذه دون إنشاء SM Context أو إشراك إجراء نشط لإدارة الجلسات مع SMF.
أما بالنسبة لسياسة الوصول، فقد يختار AMF أيضًا PCF وينشئ AM Policy Association. ويمكن للسياسة التي يعيدها PCF أن تؤثر في مسائل مثل قيود الوصول إلى مناطق محددة. وعند هذه النقطة، يكون سياق الـUE الذي يحتفظ به AMF قد تطور من هوية أساسية إلى مجموعة من معلومات الهوية والأمان والاشتراك وشرائح الشبكة والموقع والسياسة.
Registration Accept يطبق نتيجة التسجيل على الـUE وgNB
تتم معظم المعالجة السابقة داخل الشبكة الأساسية، لكن النتيجة النهائية يجب أن تصل إلى شبكة الوصول والـUE. وعندما تتحقق الشروط المطلوبة، يرسل AMF رسالة Initial Context Setup Request إلى gNB، حاملة المعلومات اللازمة لإنشاء سياق الـUE، ويوصل NAS Registration Accept باتجاه الـUE.
يمكن أن تتضمن Registration Accept معلومات مثل 5G-GUTI جديد، وAllowed NSSAI، ومؤقت التسجيل الدوري T3512، وقائمة مناطق التتبع السارية. وتحدد هذه المعلمات كيفية بقاء الـUE مسجلًا في 5GS، وأي شرائح شبكة يمكنه استخدامها حاليًا، ومتى سيحتاج لاحقًا إلى تنفيذ Periodic Registration Update.
في الوقت نفسه، ينشئ gNB سياق الـUE المقابل من خلال إجراء Initial Context Setup. وبعد إكمال المعالجة، يعيد gNB رسالة Initial Context Setup Response. ثم يؤكد الـUE نتيجة التسجيل بإرسال NAS Registration Complete إلى AMF.
لذلك فإن Registration Accept وRegistration Complete أكثر من مجرد إشعاري نجاح. فهما يطبقان نتيجة التسجيل التي أُنشئت داخل الشبكة الأساسية على كل من الـUE وRAN، ويجعلان الشبكة وgNB والجهاز في حالة تسجيل 5GS متسقة.
التسجيل وإنشاء PDU Session مساران منفصلان للإشارات
هذا التمييز ضروري عند تحليل تسلسل الإشارات الكامل. فعند اكتمال 5GS Initial Registration، يعرف AMF من هو المشترك، وأين يوجد الـUE، وما مناطق الوصول وشرائح الشبكة المسموح بها، وما سياق الأمان والتنقل الساري. ولا تنشئ أي من هذه الخطوات تلقائيًا مسار بيانات على مستوى المستخدم.
للوصول إلى الإنترنت أو شبكة بيانات مؤسسة، لا يزال على الـUE تنفيذ PDU Session Establishment. وفي هذه المرحلة يتولى SMF مسؤولية إدارة الجلسات، ويختار UPF أو يتحكم به، ويهيئ عبر N4 قواعد مستوى المستخدم مثل PDR وFAR وQER وURR. كما تُجهز موارد N3 بين gNB وUPF ضمن عملية إنشاء الجلسة.
في استكشاف الأعطال التشغيلي، ينشأ عن هذا الفصل نوعان مختلفان تمامًا من الأعطال:
فشل التسجيل: التركيز على هوية الـUE والمصادقة وأمن NAS وبيانات اشتراك UDM وNSSAI وقيود المناطق ومعالجة السياسات في AMF.
نجاح التسجيل مع عدم عمل خدمة البيانات: نقل التحقيق إلى PDU Session Establishment وSMF وUPF وإشارات N3/N4 وتمرير مستوى المستخدم، بدلًا من تكرار فحص Registration Request وRegistration Accept.
يساعد إبقاء هذا الحد واضحًا على تقصير وقت استكشاف أعطال 5GC بشكل كبير. فظهور مؤشر 5G على الجهاز يدل فقط على أن الوصول الراديوي والتسجيل وصلا إلى حالة معينة. أما وجود اتصال بيانات فعلي فيظل معتمدًا على إجراءات إدارة الجلسات ومستوى المستخدم.
اقرأ التتبع كتغير في الحالة لا كقائمة رسائل
تكون مخططات الإشارات القياسية شاملة عمدًا لأنها يجب أن تغطي مشغلين مختلفين وسيناريوهات التجوال وأنواع الوصول ووظائف الشبكة الاختيارية. لكن تتبع شبكة فعلية لن يحتوي بالضرورة على كل خطوة في الإجراء المرجعي. فقد لا يحدث تفاعل مع AMF القديم، وقد لا تكون هناك حاجة إلى Identity Request، وقد لا يُستخدم EIR، كما أن إجراء وصول NR عادي لن يتضمن وظائف شبكة تنطبق فقط على أنواع وصول أخرى.
الطريقة الأكثر فائدة لاستكشاف Initial Registration هي تتبع كيفية تغير حالة الـUE:
Registration Request يصل إلى AMF
→ تحديد هوية الـUE وسياقه السابق
→ استكمال المصادقة وإنشاء أمن NAS
→ استرجاع بيانات الاشتراك من UDM
→ الحصول على سياسة الوصول السارية من PCF
→ AMF يستكمل سياق التسجيل
→ تسليم Registration Accept
→ الـUE يعيد Registration Complete
إذا وصل Registration Request إلى AMF ولكن المصادقة لم تبدأ، فيجب أولًا فحص معالجة الهوية واختيار وظائف الشبكة. وإذا نجحت المصادقة لكن Registration Accept لم يُعد، فاستمر في فحص بيانات UDM وNSSAI وقيود الوصول ومعالجة السياسات. وإذا كانت Registration Accept قد اكتملت بالفعل وكانت المشكلة أن بيانات المستخدم لا تعمل، فيجب نقل التحقيق بسرعة إلى مسار إشارات PDU Session.
لذلك فإن فهم 5G Initial Registration لا يعتمد أساسًا على حفظ عشرات الرسائل، بل على تتبع كيفية اكتمال سياق الـUE داخل AMF تدريجيًا: بدءًا من استقبال طلب الوصول، ثم معرفة هوية المشترك، وإثبات أن هذه الهوية موثوقة، وصولًا إلى تحديد الشروط التي يُسمح بموجبها لذلك المشترك بالبقاء مسجلًا في 5GS.
الأسئلة الشائعة
ما وظيفة T3512 في Registration Accept؟
يتحكم T3512 في سلوك تحديث التسجيل الدوري للـUE بعد التسجيل. فالـUE لا يبقى مسجلًا إلى أجل غير مسمى من دون تفاعل دوري لإدارة التنقل. ويمكن للشبكة استخدام هذا المؤقت لتحديد موعد تنفيذ الـUE لإجراء Periodic Registration Update.
لماذا يغيب EIR عن بعض تتبعات تسجيل 5G التجارية؟
التحقق من هوية الجهاز وظيفة اختيارية. ويعتمد نشر EIR والظروف التي تُفعّل فيها عملية فحص هوية الجهاز على بنية المشغل وسياساته التشغيلية. لذلك فإن غياب إشارات EIR في إجراء Initial Registration طبيعي من الجوانب الأخرى لا يُعد دليلًا كافيًا على وجود عطل.
لماذا يغيب N3IWF عادة عن تسجيل 5G NR القياسي؟
يُستخدم N3IWF أساسًا للوصول غير الموثوق من نوع non-3GPP، مثل بعض سيناريوهات وصول Wi-Fi إلى 5G Core. وعندما يتصل الـUE مباشرة عبر gNB باستخدام وصول 3GPP NR القياسي، توفر NG-RAN مسار الوصول، ولذلك لا يكون N3IWF عادة جزءًا من إشارات التسجيل.
لماذا قد يظهر اكتشاف وظائف الشبكة عبر NRF بعدد مرات مختلف في تتبعات الموردين المختلفين؟
قد تختلف تطبيقات 5G Core الفعلية بسبب التخزين المؤقت لعمليات اكتشاف وظائف الشبكة، والإعداد الثابت، ونماذج نشر SCP، وسلوك توجيه الخدمات الخاص بكل مورد. لذلك لا يلزم أن يظهر تبادل كامل لاكتشاف وظائف الشبكة عبر NRF قبل كل عملية خدمة. وعند تحليل التتبع، ينبغي ربط مثيل NF المحدد بطلب الخدمة اللاحق بدلًا من الحكم على الإجراء من خلال عدد رسائل NRF فقط.
