في شبكة 5G Core تحتفظ AMF بمعلومات مباشرة عن تنقل UE، بما في ذلك منطقة التتبع الحالية وحالة قابلية الوصول وتغيرات التسجيل وحالة CM وتغيرات نوع الوصول. وعندما تحتاج وظائف شبكة مثل SMF أو NEF أو UDM إلى هذه المعلومات، فإن الاستعلام المتكرر من AMF لا يقدم سوى لقطة لحالة لحظية ولا يلتقط تغيرات الحالة بكفاءة. تعالج Namf_EventExposure هذه المشكلة بتحويل معلومات التنقل التي تديرها AMF إلى خدمات أحداث تستطيع وظائف الشبكة الأخرى الاشتراك فيها وتلقي إشعارات مستمرة عنها.
-
اسم الخدمة: Namf_EventExposure
النموذج الأساسي: اشتراك في الأحداث + إشعار بتغير الحالة
المستهلكون المعتادون: SMF، NEF، UDM
سياق الإصدار: استنادًا إلى التعريفات ذات الصلة في 3GPP Release 15.6
دور الخدمة وحدودها
Namf_EventExposure هي خدمة من AMF تتيح الأحداث المرتبطة بالتنقل لوظائف الشبكة الأخرى. وبما أن AMF مسؤولة عن إدارة الوصول والتنقل، فهي تحتفظ مباشرة بمعلومات مثل موقع UE وحالة التسجيل وحالة إدارة الاتصال. ولا تحتاج وظائف الشبكة الأخرى إلى إعادة إنشاء منطق تحديد الحالة نفسه. وبدلًا من ذلك يمكنها استخدام هذه الخدمة لتحديد الأحداث التي تهمها، بينما تحدد AMF وقت وقوعها وترسل الإشعارات عند استيفاء الشروط المهيأة.
يختلف الاشتراك في الأحداث جوهريًا عن استعلام الحالة التقليدي. فالاستعلام يجيب عن سؤال «ما الحالة الحالية؟»، بينما يجيب الاشتراك عن «متى تتغير الحالة؟». على سبيل المثال لا تحتاج SMF إلى الاستعلام باستمرار عما إذا كان UE قابلًا للوصول؛ فقد يكفي أن تتلقى إشعارًا عند انتقاله من حالة «قابل للوصول» إلى «غير قابل للوصول». وقد تهتم NEF فقط بدخول UE إلى منطقة محددة، بينما قد تهتم UDM بتغيرات التسجيل أو قابلية الوصول. لذلك توفر إتاحة الأحداث أسلوبًا غير متزامن قائمًا على الشروط لتبادل المعلومات فقط عند الحاجة.
لا تبث AMF جميع معلوماتها الداخلية دون تمييز. بل تُتاح الأحداث وفق علاقات اشتراك قائمة. ويحدد المستهلك وUE المستهدف ونوع الحدث وURI الخاص بالإشعار نطاق الاشتراك معًا. يقلل هذا النهج من الإشارات غير الضرورية ويتيح لكل وظيفة شبكة الاشتراك فقط في معلومات التنقل المرتبطة بمنطق خدمتها.
أنواع الأحداث والمعلمات الأساسية
يمكن لـ AMF إتاحة أحداث تغطي جوانب متعددة من تنقل UE وتسجيله واتصاله وقابلية الوصول إليه. وبدلًا من حفظ كل حدث على حدة، يسهل تجميعها في ثلاث فئات: أحداث الموقع والمنطقة، وأحداث التسجيل وحالة الوصول، وأحداث قابلية الوصول أو الاستثناءات.
أحداث الموقع والمنطقة
يُعد الإبلاغ عن موقع UE من أكثر أنواع الأحداث مباشرة. ويمكن للمستهلك الاشتراك في تغيرات موقع UE واحد أو مجموعة من UEs، مع تضمين معلومات مثل TAI ومعرّف الخلية في الإشعارات. أما تقارير AOI، أي «منطقة الاهتمام»، فتركز على علاقة UE بمنطقة محددة مسبقًا، مثل ما إذا كان قد دخل المنطقة أو غادرها أو كان في حالة غير معروفة.
تكون تقارير AOI مفيدة خصوصًا عندما لا يحتاج التطبيق إلى تحديثات دقيقة ومستمرة للموقع، بل يحتاج فقط إلى معرفة ما إذا كان UE داخل منطقة محددة. فإذا كان التطبيق يحتاج مثلًا فقط إلى تحديد دخول UE إلى منطقة تتكون من TA1 وTA2، فلا حاجة إلى إصدار إشعارات موقع متواصلة ما دام UE داخل تلك المنطقة. ولا يلزم التقرير إلا عند دخول المنطقة المهيأة أو مغادرتها.
حالات التسجيل والوصول والاتصال
يميز تقرير حالة التسجيل بين REGISTERED وDEREGISTERED، بينما يوضح تقرير إدارة الاتصال ما إذا كان UE في CM-IDLE أو CM-CONNECTED. ولهاتين الحالتين معنيان مختلفان بالنسبة لوظائف الشبكة التي تحتاج إلى تحديد إمكانية إنشاء اتصال في مستوى المستخدم أو اتصال إشارات بصورة فورية.
يمكن لـ AMF أيضًا إتاحة تغيرات نوع شبكة الوصول الخاصة بـ UE، مثل الانتقال بين وصول 3GPP وnon-3GPP، إلى جانب تغير المنطقة الزمنية الحالية لـ UE. ولا تحتاج هذه المعلمات عادة إلى الاستعلام عنها بتردد عالٍ، لكن تغيرها قد يؤثر في قرارات السياسات أو معالجة الخدمة، ولذلك فهي مناسبة لنموذج الاشتراك في الأحداث.
أحداث قابلية الوصول والاستثناءات
يوضح تقرير قابلية الوصول ما إذا كانت AMF ترى أن UE قابل للوصول عبر الشبكة. وتشمل النتائج المحتملة «قابل للوصول» و«غير قابل للوصول» وREGULATORY-ONLY. وتعني REGULATORY-ONLY أن UE قابل للوصول فقط للخدمات ذات الأولوية التنظيمية. ولا ينبغي الخلط بين قابلية الوصول وحالة الاتصال؛ فقد يظل UE في CM-IDLE قابلًا للوصول، رغم احتمال الحاجة إلى إجراء النداء قبل إعادة إنشاء الاتصال.
تصف أحداث الاستثناء فشل الاتصال أو فقدانه. وقد تتضمن تقارير فشل الاتصال قيم أسباب تحرير اتصال RAN أو NAS. ويمكن إنشاء تقرير عن فقد الاتصال عندما تحدد AMF، مثلًا بعد انتهاء مؤقت قابلية الوصول المتنقل، أن الاتصال مع UE قد فُقد، وبذلك يستطيع المشترك تلقي معرّف UE ذي الصلة.
إضافة إلى الأحداث المرتبطة بـ UE فردي أو مجموعة من UEs، يمكن لـ AMF إتاحة إحصاءات عن عدد UEs داخل منطقة معينة. وفي هذه الحالة يهتم المستهلك بإجمالي عدد UEs في المنطقة بدلًا من حالة مشترك بعينه. ويوضح ذلك أن إتاحة الأحداث لا تقتصر على الإشعارات لكل UE، بل يمكنها أيضًا توفير معلومات إحصائية مرتبطة بالتنقل.
الاشتراك والتحديث والإشعار
تنظم Namf_EventExposure تغيرات الحالة ضمن دورة حياة اشتراك كاملة. تنشئ وظيفة الشبكة المستهلكة اشتراكًا أولًا، وتحفظ AMF علاقة الاشتراك. وإذا احتاج المستهلك لاحقًا إلى تغيير شروط الحدث، يمكن تحديث الاشتراك. وعندما لا يعود الحدث مطلوبًا يمكن حذف الاشتراك. ثم ترسل AMF نتائج الحدث الفعلية إلى عنوان الإشعار المهيأ.
لإنشاء اشتراك يرسل المستهلك طلب POST لاشتراك جديد. وإذا نجح الطلب، تعيد AMF معلومات الاشتراك الذي تم إنشاؤه مع معرّف يمكن الرجوع إليه في العمليات اللاحقة. وإذا احتاج المستهلك إلى تعديل شروط الحدث، يمكنه استخدام PATCH على الاشتراك المعني بدلًا من حذفه وإعادة إنشائه. وعندما لا يعود الحدث مطلوبًا يرسل المستهلك DELETE لإزالة علاقة الاشتراك، وبعد ذلك تتوقف AMF عن إرسال الإشعارات لذلك الاشتراك.
Notify هي الخطوة الأساسية التي تنقل تغير الحالة الفعلي. وعندما يتحقق شرط الحدث المشترك فيه، ترسل AMF إشعار حدث عبر POST إلى eventNotificationUri المخزن مع الاشتراك. وبعد أن يعالج المستهلك الإشعار ويعيد استجابة، تكتمل معاملة الإشعار. ويمكن تلخيص التسلسل المعتاد كما يلي:
-
يحدد المستهلك UE والحدث اللذين يريد مراقبتهما؛
-
تنشئ AMF سياق الاشتراك وتحافظ عليه؛
-
تستمر AMF في تتبع حالة التنقل ذات الصلة؛
-
عند تحقق شرط الحدث ترسل AMF إشعارًا؛
-
يعالج المستهلك الحدث وينفذ منطق الخدمة المطلوب؛
-
يتم تحديث الاشتراك أو حذفه عندما تتغير متطلبات الخدمة.
يمكن تهيئة التقارير لتكون لمرة واحدة أو مستمرة. ويكون التقرير لمرة واحدة مناسبًا عندما يحتاج المستهلك فقط إلى النتيجة الحالية أو وقوع حدث واحد. أما في التقارير المستمرة فيظل الاشتراك فعالًا، وقد تؤدي تغيرات الحالة اللاحقة المطابقة للشروط المهيأة إلى إشعارات إضافية. ومن منظور هندسي ينبغي لذلك التعامل مع «الحدث الذي يتم الاشتراك فيه» و«عدد التقارير المطلوبة» باعتبارهما عاملين منفصلين في التهيئة.
منظور هندسي وخلاصة
من منظور بنية 5GC القائمة على الخدمات، تعالج Namf_EventExposure حدًا للمسؤوليات: أي وظيفة شبكة تكتشف الحالة وأي وظيفة تستهلكها. وبما أن AMF تمتلك أصلًا معلومات إدارة التنقل، فمن الأكثر كفاءة أن تتيحها عبر آلية أحداث معيارية بدلًا من أن تقوم SMF أو NEF أو UDM باستنتاج حالة UE نفسها مرارًا عبر إشارات إضافية.
ولهذا السبب أيضًا يناسب نموذج الاشتراك إتاحة الأحداث. فموقع UE والتسجيل وحالة الاتصال وقابلية الوصول كلها معلومات قائمة على الحالة. وتظل هذه القيم ثابتة معظم الوقت، لكن تغيرها قد يؤثر فورًا في سلوك وظيفة شبكة أخرى. وسيولد الاستعلام المستمر حجمًا كبيرًا من الإشارات بقيمة تشغيلية محدودة، بينما يسمح الاشتراك والإشعار بتدفق المعلومات فقط عند وقوع حدث فعلي.
عند تحليل إشارات Namf_EventExposure عمليًا، توجد أربعة عناصر مهمة بشكل خاص: أي NF أنشأت الاشتراك، وما الحدث المطلوب، وأي UE أو منطقة تتم مراقبتها، وإلى أين يُرسل الإشعار. ومن خلال تتبع معرّف الاشتراك مع eventNotificationUri يمكن عادة إعادة بناء التفاعل الكامل من إنشاء الاشتراك وتعديله حتى رسالة Notify النهائية.
أفضل طريقة لفهم Namf_EventExposure هي بناء نموذج بسيط: تحتفظ AMF بحالة التنقل، ويعلن المستهلك ما يهتم به، وينشئ الاشتراك العلاقة، وتنقل Notify النتيجة عند تغير الحالة. وبعد وضوح هذا النموذج يصبح تفسير أحداث محددة مثل الموقع وAOI والتسجيل وحالة الاتصال وقابلية الوصول أسهل بكثير.
الأسئلة الشائعة
ما الفرق الجوهري بين Namf_EventExposure والاستعلام المباشر من AMF؟
يسترجع الاستعلام المباشر الحالة في لحظة محددة. أما إتاحة الأحداث فتنشئ اهتمامًا مسبقًا وتتيح لـ AMF إشعار المستهلك عند تغير الحالة ذات الصلة. يناسب الأول الاستعلامات اللحظية، بينما يناسب الثاني المراقبة المستمرة للأحداث.
هل يمكن لمستهلك واحد الاشتراك في أحداث لعدة UEs؟
نعم. يعتمد نطاق الهدف المدعوم على نوع الحدث. فبعض الأحداث يمكن أن تنطبق على UE واحد أو مجموعة من UEs، بينما يمكن لإحصاءات مثل عدد UEs داخل منطقة محددة أن تشمل أي عدد من UEs.
هل تعني CM-IDLE أن UE غير قابل للوصول؟
لا. تصف حالة CM حالة إدارة الاتصال الخاصة بـ UE، بينما تصف قابلية الوصول ما إذا كانت الشبكة تستطيع الوصول إلى UE. وقد يظل UE في CM-IDLE قابلًا للوصول، رغم أن الاتصال يتطلب عادة إعادة إنشاء الوصلة أولًا.
لماذا يحتاج إشعار الحدث إلى URI منفصل للاستدعاء العكسي؟
لا يلزم أن يحدث إنشاء الاشتراك ووقوع الحدث في الوقت نفسه. يقدم المستهلك URI للإشعار عند إنشاء الاشتراك، مما يسمح لـ AMF بإرسال رسالة Notify لاحقًا عند تحقق شرط الحدث المهيأ دون إبقاء اتصال الطلب الأصلي مفتوحًا.
