لم تعد نواة 5G مصممة فقط للاتصالات بين الأشخاص. فالمركبات المتصلة والمصانع الذكية والمجمعات الذكية والرعاية الصحية عن بُعد والطائرات المسيّرة وغيرها من تطبيقات القطاعات الرأسية تحتاج بشكل متزايد إلى التأثير ديناميكياً في موارد الشبكة وفق حالة الخدمة أو الحصول من المشغّل على معلومات مصرح بها عن حالة الشبكة. ولو تطلب كل احتياج جديد من المشغّل تعديل إعدادات AMF وSMF وPCF وUDM ووظائف الشبكة الأخرى يدوياً، لأصبح نشر 5G على نطاق واسع في القطاعات الرأسية شديد الصعوبة.

هنا يأتي دور NEF، أي Network Exposure Function. فهو يقع بين 5GC ووظائف التطبيقات AFs، ويحوّل قدرات النواة الداخلية إلى واجهات معيارية يمكن للتطبيقات الخارجية استخدامها. وفي الوقت نفسه يتولى التحكم الأمني وترجمة المعلومات وتمرير المعلمات. وبالنسبة لتطبيقات الجهات الخارجية، يعمل NEF كبوابة محكومة إلى منظومة قدرات نواة 5G لدى المشغّل، وليس كبوابة API أساسية فحسب.

لماذا يحتاج 5GC إلى NEF

كان نموذج أعمال 4G موجهاً إلى حد كبير نحو B2C: توفر الشبكة الاتصال، ويستخدم المشتركون الإنترنت المحمول للوصول إلى التطبيقات المختلفة. ومع 5G توسع النموذج نحو B2B2X. وأصبح على الشبكة دعم المستخدمين الأفراد إلى جانب تفاعل أعمق وأكثر أتمتة مع المنصات المستخدمة في التصنيع والنقل والمجمعات والرعاية الصحية وغيرها من القطاعات الرأسية.

وهنا يبرز سؤال مهم: كيف يمكن لتطبيقات القطاعات استخدام قدرات شبكة المشغّل بطريقة آمنة وموحدة في الوقت نفسه؟

لنفترض أن شركة صناعية تريد منح أجهزة الإنتاج في منطقة محددة QoS أكثر قابلية للتنبؤ، أو تريد توجيه حركة تطبيق نحو شبكة بيانات محلية أقرب إلى المصنع. من دون آلية موحدة لإتاحة القدرات، قد تضطر منصة التطبيق إلى الاتصال مباشرة بعدة وظائف في النواة وتنفيذ إعدادات مختلفة بحسب المورّد. وهذا يزيد تعقيد التكامل ويكشف المزيد من واجهات النواة الداخلية.

ينشئ NEF حداً مشتركاً بين تطبيقات القطاعات و5GC. فلا يحتاج AF الخارجي إلى فهم كل التفاصيل الداخلية لـ AMF وSMF وPCF وUDM وUPF، بل يكفي أن يرسل طلب خدمة متوافقاً مع المعايير عبر NEF. بعد ذلك يتفاعل NEF مع وظائف الشبكة المناسبة في 5GC ويعيد النتيجة إلى جانب التطبيق.

يحوّل هذا النهج بعض المتطلبات التي كانت ستعتمد على التنسيق اليدوي والإعدادات الثابتة إلى استدعاءات خدمة معيارية، ما يسمح للمشغّلين بإتاحة قدرات الشبكة للشركاء بصورة أكثر أتمتة.

موضع NEF داخل 5GC

يُنشر NEF بين وظائف شبكة 5GC ووظائف التطبيقات AFs. والـ AF كيان وظيفي في طبقة التطبيق مسؤول عن منطق الأعمال. وقد يكون تطبيقاً موثوقاً يملكه المشغّل أو يديره، أو منصة تطبيق تابعة لجهة خارجية تقع خارج نطاق الثقة الخاص بالمشغّل. ولا يمكن منح تطبيق خارجي وصولاً غير مقيّد إلى وظائف النواة الداخلية، لذلك تتم التفاعلات المحكومة عبر NEF.

من منظور الواجهات، يصل NEF فعلياً بين بيئتين مختلفتين. في الاتجاه الشمالي يخدم AFs مثل منصات الفيديو ومنصات المركبات المتصلة وأنظمة التحكم الصناعي. وفي الاتجاه الجنوبي يتصل بوظائف 5GC الداخلية ويتواصل مع كيانات مثل SMF وPCF وUDM وفق الخدمة المطلوبة.

تطور NEF من SCEF المستخدم في 4G، لكن نطاقه أصبح أوسع بكثير. فقد ارتبط SCEF أساساً بحالات استخدام IoT محددة، بينما يدعم NEF في 5GC نطاقاً أوسع بكثير من التطبيقات المتمحورة حول الإنسان والآلة، وأصبح جزءاً مهماً من إطار إتاحة القدرات القائم على الخدمات.

بحكم تصميمه، يقوم NEF بأكثر بكثير من مجرد تمرير الرسائل. وتشمل مسؤولياته الأساسية إتاحة قدرات الشبكة وأحداثها، وتزويد شبكة 3GPP بالمعلومات القادمة من التطبيقات الخارجية بصورة آمنة، وترجمة المعلومات بين الصيغ الخارجية والداخلية، واستقبال البيانات من وظائف الشبكة الأخرى لتخزينها أو إعادة إتاحتها لاحقاً عند الحاجة.

يمكن تخزين بعض المعلومات التي يستقبلها NEF في UDR، ولذلك لا يلزم أن تبقى مرتبطة بمثيل NEF واحد. كما يمكن لـ NEF دعم وظائف PFD، بما يوفر أساساً لاكتشاف التطبيقات ومعالجة السياسات بدقة أعلى.

كيف تُتاح خمس قدرات رئيسية

تأتي قيمة NEF في النهاية من الخدمات التي يستطيع إتاحتها. وفي عمليات نشر 5GC الفعلية يمكن تجميع قدراته الرئيسية في خمسة مجالات: إتاحة QoS، والاشتراك في أحداث الشبكة، وتوجيه حركة البيانات، وتزويد المعلمات، وإدارة PFD. وتمثل هذه الوظائف بعض أكثر متطلبات التفاعل شيوعاً بين تطبيقات القطاعات وشبكات المشغّلين.

إتاحة قدرات QoS

تتيح قدرات QoS لتطبيق شريك أن يطلب جودة خدمة محددة لتدفق خدمة بعينه. فعلى سبيل المثال قد يكون تطبيق فيديو يعمل بالفعل عبر جلسة PDU قائمة. وإذا اختار المستخدم خدمة فيديو بجودة أعلى، يمكن للـ AF استخدام NEF لطلب QoS محسّنة لتدفق حركة البيانات هذا.

بعد استلام الطلب، ينسق NEF مع وظائف النواة مثل PCF. ثم يطبق PCF منطق السياسات ويتعاون مع SMF وموارد الشبكة الأخرى لإنشاء معالجة QoS المناسبة لتدفق الخدمة.

النقطة الأساسية ليست مجرد منح الجهاز عرض نطاق أكبر. فالهدف هو تمكين التطبيق من التعبير عن متطلبات الخدمة عبر واجهة معيارية، مع إبقاء قرارات السياسة وتنفيذ موارد الشبكة تحت سيطرة 5GC.

التنقل والاشتراك في أحداث الشبكة

يمكن لـ AF تابع لجهة خارجية أيضاً استخدام NEF للاشتراك في أحداث الشبكة المرتبطة بـ UE، مثل فقدان الاتصال، واستعادة قابلية الوصول، والموقع الحالي أو آخر موقع معروف، وحالة التجوال، وأسباب فشل الاتصال، وحالة تسليم بيانات الوصلة الهابطة.

تكتشف وظائف مختلفة في النواة هذه الأحداث. فيمكن لـ AMF اكتشاف قابلية وصول UE وفقدان الاتصال وبعض أعطال الاتصال. ويمكن لـ UDM توفير معلومات مثل حالة التجوال أو بعض تغييرات ارتباط الهوية، بينما يستطيع SMF الإبلاغ عن الحالات المتعلقة بتسليم بيانات الوصلة الهابطة.

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

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

توجيه حركة البيانات

يمكن لـ NEF أيضاً استقبال طلبات Traffic Influence من AF وتوجيه حركة UE أو خدمة محددة نحو Local DN، أي Local Data Network. ويتم تعريف Local DN بواسطة DNAI، ويرتبط عادة بالحوسبة الطرفية أو بالخدمات المنشورة إقليمياً.

في مصنع مؤتمت مثلاً، قد يُنشر خادم للتحكم الصناعي في شبكة محلية قريبة من موقع الإنتاج. ويمكن لمنصة التطبيق أن تطلب عبر NEF من 5GC تعديل مسار مستوى المستخدم بحيث تُوجّه حركة الأجهزة المعنية نحو Local DN المناسب.

لا يتحكم NEF في UPF مباشرة. بل يرسل المتطلب إلى عملية التحكم في السياسات، ثم يتولى PCF وSMF معالجة السياسة وإعداد مستوى المستخدم. ووفق الحالة يمكن لـ SMF إعادة اختيار UPF أو إضافة UPFs أو استبدالها أو إزالتها من المسار القائم لإتمام عملية توجيه الحركة.

التزويد الآمن للمعلمات

يمكن لـ AF خارجي أيضاً استخدام NEF لتزويد 5GC بمعلمات معينة مرتبطة بالمستخدم. ولا يعني ذلك أن التطبيق يستطيع تعديل معلمات النواة بحرية، إذ يخضع نطاق المعلومات التي يمكن تزويدها لرقابة صارمة.

تشمل الأمثلة المعتادة Expected UE Behaviour وبعض Network Configuration Parameters. ويمكن لـ Expected UE Behaviour وصف خصائص التنقل المتوقعة للجهاز، بينما قد تتضمن معلمات إعداد الشبكة معلومات مثل أقصى زمن استجابة، أو التأخير المقبول لنقل بيانات الوصلة الهابطة، أو العدد الموصى به من حزم الوصلة الهابطة التي ينبغي تخزينها مؤقتاً عندما يكون UE غير قابل للوصول.

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

إدارة PFD

يمكن فهم PFD، أو Packet Flow Description، على أنه مجموعة من القواعد المستخدمة لاكتشاف التطبيقات. ويمكن لـ AF تابع لجهة خارجية إنشاء معلومات تعريف التطبيق عبر NEF. وقد تُخزن القواعد الناتجة في UDR، ثم يسترجعها SMF عبر NEF، وتُرسل بعد ذلك إلى UPF لاكتشاف التطبيق.

بالمقارنة مع تعريف حركة البيانات اعتماداً فقط على المنافذ أو العناوين الأساسية، يمكن لقواعد PFD وصف خصائص تطبيق أكثر تحديداً. فعلى سبيل المثال يمكن التعرف على خدمة فيديو من خلال نمط URL معين أو خصائص أخرى لحركة البيانات، ما يسمح للشبكة بربط الحركة بدقة أكبر بقواعد معالجة السياسات المناسبة.

القيمة التقنية الحقيقية لـ NEF

من منظور البنية، لا تتمثل أهم وظيفة لـ NEF في إضافة عقدة تمرير أخرى، بل في إنشاء طبقة قابلة للإدارة لإتاحة القدرات. ترى وظائف AF الخارجية واجهات موجهة للخدمات، بينما يستمر العمل الفعلي داخل 5GC بواسطة وظائف مثل التحكم في سياسات PCF وإدارة جلسات SMF وإدارة بيانات UDM ومعالجة مستوى المستخدم في UPF.

ولهذا لا ينبغي اعتبار NEF مجرد بوابة API عادية. إذ يجب أن يفهم العلاقة بين طلبات الأعمال الخارجية وقدرات نواة 3GPP، مع تولي التحكم الأمني وترجمة المعلومات وتنسيق العمليات بين الجانبين.

كما أن NEF لا يستبدل وظائف الشبكة الأخرى. فما زال تنفيذ QoS يعتمد على التحكم في السياسات وإعداد موارد الجلسة، وما زالت أحداث الشبكة تُكتشف بواسطة NF المناسبة، وما زالت مسارات مستوى المستخدم تُعدّل بواسطة وظائف مثل SMF، وتظل البيانات المرتبطة بالمستخدم محفوظة لدى UDM وUDR. ويتمثل دور NEF في إتاحة هذه القدرات الداخلية بطريقة محكومة وموحدة.

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

عملياً، يساعد NEF نواة 5G على التطور من شبكة تقدم الاتصال بصورة أساسية إلى منصة قادرة على إتاحة قدرات الشبكة مباشرة لتطبيقات القطاعات.

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

هل يجب نشر جميع وظائف AF خارج شبكة المشغّل؟

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

هل تُخزن بيانات الأعمال دائماً محلياً داخل NEF؟

لا. يمكن تخزين بعض المعلومات التي يستقبلها NEF في UDR واستخدامها لاحقاً بواسطة وظائف شبكة أخرى أو إجراءات لاحقة. لذلك لا يلزم أن يبقى تخزين البيانات مرتبطاً بمثيل NEF واحد.

هل Local DN هو نفسه UPF؟

لا. Local DN هو شبكة بيانات محلية تستضيف تطبيقات أو خدمات بيانات محددة، بينما UPF هو وظيفة شبكة لمستوى المستخدم في 5GC. ويمكن توجيه الحركة عبر مسار UPF مناسب للوصول إلى Local DN محدد، لكن لكل منهما دور مختلف.

هل ينشئ UPF قواعد PFD بنفسه؟

لا. يمكن أن يوفر AF قواعد PFD وأن تُدار عبر NEF. يسترجع SMF القواعد ذات الصلة ثم يرسلها إلى UPF لتحقيق اكتشاف أدق للتطبيقات في مستوى المستخدم.