متى يتم تشغيل إعادة تخصيص AMF؟

لا يمثل Initial Registration مع إعادة تخصيص AMF المسار الافتراضي لكل عملية تسجيل في 5GC. فشروط التشغيل محددة: يجب أن تكون Network Slicing مطبقة، وأن يكون AMF الذي يستقبل Registration Request أولًا غير قادر على خدمة شريحة الشبكة التي يحتاجها UE في النهاية.

في سيناريو التسجيل العادي، يكون Initial AMF الذي اختاره gNB داعمًا بالفعل لـS-NSSAI المطلوب. ولذلك يمكن أن تظل معالجة الهوية والمصادقة واسترجاع بيانات الاشتراك وRegistration Accept على AMF نفسه طوال الإجراء.

تصبح إعادة التخصيص ضرورية فقط عندما توضح المعلومات التي تم الحصول عليها لاحقًا أن AMF الحالي لا يتوافق مع الشريحة المسموح لـUE باستخدامها أو التي يفترض أن يستخدمها افتراضيًا. ويمكن تلخيص المنطق كما يلي:

تصل Registration Request إلى Initial AMF
           → ينفذ Initial AMF معالجة التسجيل المطلوبة
           → يتم الحصول على معلومات اشتراك UE والشرائح بصورة كاملة
           → يحدد Initial AMF أنه لا يستطيع خدمة S-NSSAI المستهدف
           → يتم استدعاء NSSF لتحديد نطاق الخدمة المناسب
           → يتم نقل التسجيل إلى Target AMF

يجب تجنب سوء فهم شائع: ظهور اثنين من AMF في تتبع التسجيل نفسه لا يعني تلقائيًا أن AMF الأصلي تعطل أو أن موازنة حمل داخل AMF Pool قد حدثت. ففي هذا الإجراء يكون سبب التشغيل الحقيقي هو عدم التطابق بين قدرة AMF الحالي على خدمة الشرائح وشريحة الشبكة التي يحتاجها UE في النهاية.

لماذا قد يختار gNB في البداية AMF غير مناسب؟

عند دراسة إعادة تخصيص AMF للمرة الأولى، من السهل افتراض أن gNB ارتكب خطأ. فإذا كانت AMF مختلفة تخدم شرائح مختلفة، فلماذا لا يرسل RAN الجهاز UE مباشرة إلى AMF الصحيح منذ البداية؟

السبب الرئيسي هو أن gNB قد لا يمتلك معلومات كافية عند تنفيذ الاختيار الأولي لـAMF. لنفترض أن مركبة متصلة تعمل للمرة الأولى باستخدام 5G USIM مشترك في شريحتي شبكة:

• شريحة eMBB ‏(S-NSSAI1): تستخدم للترفيه والمعلومات داخل المركبة وخدمات البيانات العامة؛

• شريحة V2X ‏(S-NSSAI3): تستخدم لاتصالات المركبة مع محيطها (V2X) والخدمات المرتبطة بالقيادة الآلية.

لنفترض أن Default S-NSSAI للمشترك هو شريحة V2X، لكن UE يدخل 5GS للمرة الأولى ولا يملك 5G-GUTI صالحًا ولا يضمّن Requested NSSAI في Registration Request. في هذه المرحلة لا توجد لدى gNB قاعدة مباشرة لمعرفة أن UE ينبغي أن يخدمه في النهاية AMF المرتبط بشريحة V2X.

في الظروف العادية يستطيع gNB استخدام معلومات مثل GUAMI وS-NSSAI المطلوب من UE وإعداد AMF المحلي عند اختيار AMF. أما في هذا السيناريو، فكل من GUAMI وRequested NSSAI غير متاح، ولذلك لا يستطيع gNB إلا اختيار Initial AMF باستخدام المعلومات المتاحة حاليًا وسياسة الاختيار الافتراضية المحلية.

إذا اختار gNB في البداية AMF1 الذي يخدم شريحة eMBB، فسيتم نقل Registration Request إلى AMF1 داخل NGAP Initial UE Message.

عدم توافق هذا AMF مع متطلب الشريحة النهائي لـUE لا يعني بالضرورة وجود خطأ في إعداد gNB. والتفسير الأدق هو: عند إجراء أول اختيار لـAMF لا تكون لدى RAN بعد معلومات كافية لتحديد AMF الخاص بالشريحة النهائية لـUE.

كيف يكتشف Initial AMF عدم تطابق الشريحة؟

عندما تصل Registration Request إلى Initial AMF، لا يقوم AMF بالاستعلام من NSSF مباشرة. ففي هذه المرحلة لا يزال يفتقر إلى معلومات كافية عن المشترك لتحديد ما إذا كان هو AMF الخدمة النهائي الصحيح.

يتبع AMF أولًا منطق Initial Registration العادي وينفذ الإجراءات المطلوبة، بما في ذلك معالجة هوية UE واختيار AUSF ومصادقة 5G-AKA وإجراءات أمان NAS ذات الصلة.

من النتائج الأساسية لهذه المرحلة أن AMF يؤكد هوية UE ويحصل على SUPI. ومع توفر SUPI يمكن لـInitial AMF تحديد UDM المناسب واسترجاع Access and Mobility Subscription Data الخاصة بـUE.

في هذه المرحلة تكون لدى الشبكة معلومات أكثر بكثير مما كان لديها عند وصول Registration Request أول مرة. وقد تتضمن بيانات الاشتراك التي يعيدها UDM قيمتي Subscribed NSSAI وDefault S-NSSAI للمشترك.

وبالاستمرار في مثال المركبة المتصلة، ينتمي Initial AMF إلى نطاق خدمة eMBB، لكن بيانات الاشتراك توضح أن UE مشترك في كل من eMBB وV2X، وأن Default S-NSSAI يشير إلى V2X، أي S-NSSAI3.

يستطيع Initial AMF الآن الوصول إلى استنتاج لم يكن gNB قادرًا على الوصول إليه سابقًا: رغم أنه استطاع استقبال Initial Registration وبدء معالجته، فإنه ليس AMF المناسب لتقديم خدمة مستمرة لشريحة V2X الافتراضية الخاصة بـUE. ويصبح هذا التحديد نقطة تشغيل إعادة تخصيص AMF.

مرحلة gNB: تتوفر معلومات وصول محدودة فقط
           → مرحلة Initial AMF: يتم تأكيد هوية UE
           → مرحلة UDM: يتم الحصول على معلومات NSSAI الفعلية الخاصة بالاشتراك
           → يتبين أن AMF الحالي غير متوافق مع الشريحة المستهدفة

لذلك فإن إعادة تخصيص AMF ليست تغييرًا عشوائيًا للقرار في منتصف التسجيل. فهي تحدث لأن الشبكة الأساسية تستطيع اتخاذ قرار أدق بشأن AMF الخدمة بعد اكتمال هوية المشترك ومعلومات الشريحة.

كيف يحدد NSSF AMF الخدمة الجديد؟

بمجرد أن يحدد Initial AMF أنه لا يستطيع خدمة الشريحة المستهدفة، فإنه لا يختار AMF آخر بنفسه بشكل مباشر. بل يستدعي Network Slice Selection Function أو NSSF.

يستخدم Initial AMF خدمة Nnssf_NSSelection لطلب Network Slice Selection. ويمكن أن تتضمن المدخلات S-NSSAI المشترك به UE ومعلومات عن AMF الحالي وTAI الحالي لـUE. والهدف هو تحديد الشرائح المصرح بها في منطقة التسجيل الحالية ومجموعة AMF التي ينبغي أن تقدم الخدمة.

قد تتضمن Authorized Network Slice Information التي يعيدها NSSF ما يلي:

• Allowed NSSAI: شرائح الشبكة المصرح لـUE باستخدامها في الظروف الحالية؛

• Configured NSSAI: إعدادات الشرائح التي يمكن توفيرها لـUE عند الحاجة؛

• Target AMF Set: مجموعة AMF القادرة على خدمة شريحة الشبكة المعنية؛

• Rejected NSSAI: الشرائح التي لا يمكن قبولها في TA الحالي أو ضمن الشروط المرتبطة به.

من المهم التمييز بين Target AMF Set وTarget AMF. فالمسؤولية الأولى لـNSSF هي تحديد مجموعة AMF المناسبة، أي تضييق نطاق المرشحين وفق شروط الشريحة والموقع، بدلًا من إعادة عنوان AMF واحد محدد مباشرة.

بعد الحصول على Target AMF Set، يستطيع Initial AMF استخدام معلومات مثيلات NF المسجلة في NRF لاسترجاع عناوين AMF داخل المجموعة وقدراتها وأوزانها وحالتها التشغيلية. ثم يمكنه تحديد Target AMF المحدد الذي ينبغي أن يتولى Registration.

يمكن تلخيص العلاقة كما يلي:

UDM: يوفر معلومات اشتراك UE في الشرائح
           → Initial AMF: يحدد أن قدرته على الخدمة لا تتطابق مع المتطلب
           → NSSF: يحدد الشرائح المصرح بها وTarget AMF Set
           → NRF: يوفر معلومات مثيلات AMF المتاحة داخل المجموعة
           → Initial AMF: يختار Target AMF

لا يتمثل دور NSSF في هذا الإجراء في موازنة الحمل التقليدية. بل يربط متطلب الشريحة بنطاق خدمة AMF قادر على دعم هذا المتطلب.

كيف يتم نقل Registration Request إلى Target AMF؟

بعد تحديد Target AMF لا يحتاج UE إلى إرسال Registration Request جديدة بالكامل. كل ما تحتاجه الشبكة هو نقل إجراء التسجيل الجاري مع السياق المطلوب حتى يتمكن AMF الجديد من مواصلة المعالجة.

تتوفر آليتان للنقل: نقل غير مباشر عبر gNB، أو نقل مباشر بين Initial AMF وTarget AMF.

النقل غير المباشر عبر gNB

في النقل غير المباشر يرسل Initial AMF رسالة NGAP Reroute NAS Request إلى gNB. وتحمل الرسالة معلومات مرتبطة بـInitial UE Message الأصلي، إضافة إلى Target AMF Set ID، وتطلب من NG-RAN إعادة توجيه رسالة NAS Registration الحالية.

بعد ذلك يرسل gNB رسالة Initial UE Message جديدة إلى Target AMF تتضمن NAS-PDU الخاص بـRegistration Request الأصلية. ويمكن تمثيل مسار مستوى التحكم كما يلي:

UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF

لا يحتاج UE إلى تنفيذ وصول RRC من جديد. فـNG-RAN يعيد ببساطة توجيه رسالة Registration NAS الحالية إلى AMF المناسب.

النقل المباشر بين AMF

في النقل المباشر لا يعيد Initial AMF الرسالة عبر gNB، بل ينقل رسالة N1 وRegistration Context مباشرة إلى Target AMF عبر الواجهة المعتمدة على الخدمات في 5GC.

يستدعي Initial AMF الوظيفة Namf_Communication_N1MessageNotify ويرسل Registration Request كاملة مع Registration Context Container إلى Target AMF.

لا تقتصر المعلومات المنقولة على رسالة NAS واحدة. فقد يتضمن Registration Context أيضًا UE Context وAccess Type ومعلومات gNB وUser Location وAllowed NSSAI وConfigured NSSAI وRejected NSSAI وغيرها من المعلومات اللازمة لمواصلة معالجة التسجيل.

UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF

تختلف مسارات الإشارات، لكن الهدف واحد: أن يحصل Target AMF على رسالة NAS والسياق اللازمين لمواصلة Registration من دون إعادة تشغيل إجراء Initial Registration بالكامل من البداية.

بعد تولي العملية، يكمل Target AMF ما تبقى من معالجة التسجيل ويرسل Registration Accept إلى UE. وتعكس الاستجابة نتائج اختيار الشريحة وإعادة تخصيص AMF، وقد تتضمن Allowed NSSAI وConfigured NSSAI وRejected NSSAI وقيمة 5G-GUTI جديدة.

من منظور UE، النتيجة المهمة هي نجاح التسجيل وأن توفر الشبكة الشرائح المتاحة في المنطقة الحالية إلى جانب سياق التنقل الجديد في 5GS. ويبقى التغيير الداخلي في Serving AMF شفافًا إلى حد كبير بالنسبة لـUE.

كيف يمكن التحقق من إعادة تخصيص AMF في تتبع الإشارات؟

قد يسهل الخلط بين Initial Registration المصحوب بإعادة تخصيص AMF وبين توجيه تسجيل غير طبيعي أو فشل أول اختيار لـAMF. والطريقة الأكثر فاعلية لاستكشاف الأخطاء ليست مقارنة أرقام الرسائل واحدة تلو الأخرى، بل تتبع مسارين رئيسيين: تحديد الشريحة ونقل السياق.

يجب أن يسمح تسلسل الإشارات الطبيعي للمهندس بالإجابة عن الأسئلة التالية:

لماذا وصلت Registration Request أولًا إلى هذا Initial AMF؟
           → من أين حصل Initial AMF على Subscribed / Default NSSAI الخاص بـUE؟
           → ما الذي دفع AMF إلى تحديد أنه لا يستطيع مواصلة خدمة UE؟
           → ما Target AMF Set الذي أعاده NSSF؟
           → ما Target AMF المحدد الذي تم اختياره في النهاية؟
           → ما المسار المستخدم لنقل Registration Context؟

إذا كان Initial AMF قد حصل بالفعل على معلومات الاشتراك في الشرائح وحدد أنه لا يستطيع خدمة UE، لكن لم تتبع ذلك أي عملية اختيار عبر NSSF، فيجب أن يركز التحقيق على اكتشاف NSSF وطلب Nnssf_NSSelection وإعدادات الشرائح المرتبطة به.

إذا أعاد NSSF قيمة Target AMF Set ولكن تعذر تحديد Target AMF بعينه، فينبغي أن تشمل الفحوص التالية إعداد AMF Set وNF Profiles في NRF وحالة مثيلات AMF ومعلومات قدراتها.

إذا ظهرت رسالة NGAP Reroute NAS Request لكن Target AMF لم يستقبل Initial UE Message الجديدة، فيجب نقل تركيز استكشاف الأخطاء من اختيار الشريحة إلى إعادة توجيه NAS في gNB وإمكانية الوصول عبر N2 إلى Target AMF.

وإذا استُخدم النقل المباشر، فيجب البحث في التتبع عن Namf_Communication_N1MessageNotify وRegistration Context بدلًا من انتظار Reroute NAS Request التي لن تظهر في هذا المسار.

بالنظر إلى الإجراء كاملًا، تحل إعادة تخصيص AMF مشكلة محددة: تكون المعلومات المتاحة أثناء أول اختيار لـAMF غير مكتملة، ثم تصحح الشبكة الأساسية قرار Serving AMF بعد الحصول على هوية المشترك الكاملة ومعلومات الاشتراك في الشرائح.

عند دخول UE إلى الشبكة للمرة الأولى، قد لا يمتلك gNB سوى معلومات GUAMI محدودة أو معلومات Requested NSSAI أو إعداد AMF الافتراضي المحلي. وبعد المصادقة واسترجاع بيانات الاشتراك يستطيع 5GC أخيرًا تحديد الشرائح المصرح للمشترك باستخدامها. ثم يحول NSSF متطلب الشريحة إلى Target AMF Set، بينما يساعد NRF في تحديد مثيل AMF الفعلي القادر على مواصلة Registration.

لذلك فإن السؤال الأكثر فائدة عند تحليل تدفق الإشارات هذا ليس «لماذا تغير AMF في منتصف التسجيل؟»، بل: في أي مرحلة حصلت الشبكة أخيرًا على معلومات كافية لتحديد AMF الذي يجب أن يواصل خدمة UE؟

الأسئلة الشائعة

هل إعادة تخصيص AMF هي نفسها موازنة الحمل داخل AMF Pool؟

لا. تركز موازنة الحمل داخل AMF Pool عادة على السعة والأوزان وتوزيع التوافر العالي بين عدة مثيلات AMF. أما في هذا الإجراء فتحدث إعادة تخصيص AMF لأن Initial AMF لا يستطيع خدمة شريحة الشبكة التي يحتاجها UE في النهاية. وقد تؤدي الآليتان إلى Serving AMF مختلف، لكن شروط التشغيل ومنطق الإشارات مختلفان جذريًا.

هل يتطلب كل نشر لـNetwork Slicing اختيار NSSF وإعادة تخصيص AMF؟

لا. حتى عند تطبيق Network Slicing لا تكون إعادة تخصيص AMF ضرورية إذا كان AMF الذي اختاره gNB أولًا قادرًا بالفعل على خدمة الشريحة التي يحتاجها UE في النهاية. إعادة التخصيص فرع شرطي في عملية التسجيل وليست خطوة إلزامية في كل شبكة تستخدم slicing.

هل يستطيع UE اكتشاف تغير AMF مباشرة أثناء التسجيل؟

من منظور UE، الأهم هو نجاح Registration والقيم التي تعيدها الشبكة مثل Allowed NSSAI وConfigured NSSAI وRejected NSSAI و5G-GUTI. أما إعادة تخصيص AMF ونقل Registration Context فهما إجراءان داخليان للتحكم في 5GC ويظلان شفافين إلى حد كبير بالنسبة لـUE.

هل النقل غير المباشر أو المباشر هو الأكثر شيوعًا دائمًا؟

لا يمكن استخلاص حكم عام من تعريف الإجراء وحده. فالآلية المستخدمة تعتمد على بنية نشر 5GC وتنفيذ المورد وقدرات الاتصال المعتمد على الخدمات بين AMF وإعدادات RAN والشبكة الأساسية. ويجب أن يتبع استكشاف الأخطاء الفعلي مسار الإشارات الذي تتم ملاحظته في الشبكة العاملة.