التحدي الحقيقي في نشر عدة مثيلات من PCF لا يكمن في وجود هذه المثيلات بحد ذاته. المشكلة هي أن جهاز UE نفسه قد يُوجَّه بسهولة إلى مثيلات PCF مختلفة أثناء إجراءات خدمة مختلفة. فعند إنشاء جلسة PDU، قد يكون SMF قد أنشأ بالفعل ارتباطاً سياسياً مع أحد مثيلات PCF. لاحقاً، عند تشغيل خدمة صوت IMS وبدء AF طلب سياسة جديد، قد يؤدي موازنة الحمل إلى إرسال الطلب إلى PCF آخر. وعند حدوث ذلك ينقطع سياق السياسة بين المرحلتين، ما قد يؤدي إلى عدم اتساق تدفقات QoS الخاصة بـ VoNR وقواعد PCC وسياسات الجلسة.

تم تصميم BSF، أي Binding Support Function، خصيصاً لمعالجة هذا النوع من المشكلات حيث يجب أن تصل طلبات المستخدم نفسه عبر واجهات مختلفة إلى PCF نفسه. لا تقوم BSF بإنشاء قواعد PCC ولا تستبدل PCF في اتخاذ قرارات السياسة. وتتمثل مسؤوليتها الأساسية في الحفاظ على علاقة الربط بين جلسة UE وPCF المرتبط بها، بحيث يستطيع مستهلك الخدمة تحديد PCF الذي شارك بالفعل في التحكم بسياسة ذلك المستخدم عند وصول طلبات لاحقة.

لماذا قد تختار شبكات متعددة PCF مثيل PCF غير الصحيح

لفهم قيمة BSF، من المفيد الرجوع إلى مشكلة مشابهة كانت موجودة بالفعل في 4G. ففي بنية EPC يتواصل PGW مع PCRF عبر واجهة Gx، بينما يرسل P-CSCF في نطاق IMS طلبات تفويض السياسة عبر واجهة Rx. وعند نشر عدة مثيلات PCRF، يجب أن تنتهي مسارات إشارات Gx وRx عند مثيل PCRF نفسه. وإلا فلن تتمكن طلبات خدمات IMS اللاحقة من وراثة سياق السياسة الذي أُنشئ سابقاً في الجلسة.

في شبكات 4G، يتمثل الحل الشائع في استخدام DRA لتوجيه Diameter وربط الجلسات. لنأخذ مثالاً نموذجياً: عندما ينشئ PGW اتصال PDN من أجل IMS APN، يتم توجيه طلب Gx عبر DRA1 إلى PCRF1. ويسجل DRA1 العلاقة بين IMSI وعنوان IP الخاص بـ UE وPCRF1. وإذا أُرسلت لاحقاً رسالة Rx من P-CSCF إلى DRA2 بسبب موازنة الحمل ثم قام DRA2 بتمرير الطلب إلى PCRF2، فلن يكون لدى PCRF2 أي معرفة بسياق الجلسة الذي أُنشئ مسبقاً على جانب PGW.

الأثر أخطر بكثير من مجرد اختيار خادم غير صحيح. فـ PCRF2 لا يملك حالة قواعد PCC القائمة، ولذلك لا يمكن ربط طلبات سياسة الوسائط الجديدة المستلمة عبر Rx بصورة صحيحة بالسياسات التي تم إنشاؤها مسبقاً عبر Gx. وفي شبكات 4G يمكن معالجة المشكلة من خلال مزامنة معلومات الربط آنياً بين عدة مثيلات DRA، إلا أن هذه التطبيقات غالباً ما تكون خاصة بالمورّد، ما يزيد تعقيد النشر متعدد المورّدين والتشغيل طويل الأجل بشكل كبير.

في 5GC تبقى الحاجة إلى اتساق السياسات كما هي رغم تغيّر وظائف الشبكة والواجهات. يتواصل SMF مع PCF عبر N7، بينما يطلب AF تفويض السياسة عبر N5. وفي مسار سياسة VoNR كامل، يقدم AF أولاً متطلبات تدفق التطبيق وQoS، ثم ينشئ PCF قواعد PCC المقابلة، وبعد ذلك يطبق SMF وUPF تلك القواعد. وإذا وصلت طلبات مختلفة للمستخدم نفسه إلى مثيلات PCF مختلفة، فقد تنقطع استمرارية السياسة من جديد.

تقوم BSF عملياً بتوحيد قدرة الربط التي كانت تعتمد سابقاً على آليات مزامنة مملوكة. فهي تحافظ على العلاقة بين جلسة UE الحالية وPCF المسؤول عنها، بما يساعد على ضمان إعادة توجيه طلبات السياسة اللاحقة إلى مثيل PCF الذي شارك بالفعل في الجلسة.

ما المعلومات التي تربطها BSF؟

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

قد يتضمن سجل ربط نموذجي عنوان IP الخاص بـ UE وSUPI وDNN وS-NSSAI وعنوان PCF المرتبط. وفي عمليات النشر التي تحتاج إلى التكامل مع واجهات Diameter التقليدية، قد يتضمن السجل أيضاً اسم مضيف Diameter أو FQDN الخاص بـ PCF.

لا يتم جمع هذه الحقول لمجرد استكمال المعلومات. فلكل حقل دور محدد في تصفية الربط الصحيح وتحديده:

• UE IP: يوفر طريقة مباشرة للعثور على الربط بالاعتماد على عنوان مستوى المستخدم الحالي، وهو من أكثر معلمات الاستعلام شيوعاً.

• SUPI: يحدد المشترك على مستوى هوية المستخدم ويساعد على ضمان ارتباط السجل بجهاز UE الصحيح.

• DNN: يميز بين شبكات البيانات المختلفة التي يستخدمها UE نفسه، مثل IMS وخدمات الإنترنت العادية.

• S-NSSAI: يحدد بصورة أدق شريحة الشبكة المرتبطة بالجلسة في نشر 5G يعتمد تقطيع الشبكة.

• عنوان PCF: يوفر معلومات العنونة الفعلية التي يحتاجها مستهلك الخدمة للوصول إلى PCF المختار.

• اسم مضيف Diameter/FQDN: يوفر مرجع ربط لتوجيه Diameter التقليدي في عمليات النشر التي تتعايش فيها SBI وDiameter.

لهذا السبب، لا ينبغي اختزال ربط BSF إلى مطابقة بسيطة واحد إلى واحد بين عنوان UE وعنوان PCF. فقد يمتلك UE واحد عدة جلسات PDU وقد يصل إلى DNNs أو شرائح شبكة مختلفة. وإذا كانت شروط الاستعلام واسعة أكثر من اللازم، فقد لا يتوافق PCF الذي تمت إعادته مع سياق الخدمة الحالي.

في النشر الفعلي، يجب أن تتوافق دقة الربط مع دقة التحكم بالسياسة. وهذا مهم بصورة خاصة لخدمات IMS حيث تكون استمرارية السياسة أمراً حرجاً. وإذا كان لدى UE عدة شرائح أو عدة سياقات لشبكات البيانات، فلا ينبغي حذف DNN وS-NSSAI من معايير الربط.

كيف ينبغي استخدام Nbsf_Management؟

تقدم BSF خدمة Nbsf_Management عبر SBI. ولا تعتمد هذه الخدمة على مجموعة كبيرة من واجهات API غير المرتبطة، بل توفر أربع عمليات أساسية تغطي دورة الحياة الكاملة لسجل الربط: التسجيل، والاكتشاف، والتحديث، وإلغاء التسجيل. وفي النشر العملي، تقابل هذه العمليات مباشرة إنشاء ربط PCF واستخدامه وصيانته وإزالته.

Register: إنشاء الربط أولاً

بعد اختيار PCF وبدء مشاركته في التحكم بسياسة UE، يجب عليه تسجيل الربط لدى BSF. ويكون الطلب النموذجي كما يلي:

POST .../pcfBindings

يمكن أن يتضمن جسم الطلب حقولاً رئيسية مثل عنوان IP الخاص بـ UE وSUPI وDNN وS-NSSAI وعنوان PCF وFQDN المقابل. وبعد أن تنشئ BSF سجل الربط بنجاح، تعيد:

201 Created

يُعد التوقيت من أكثر أخطاء التنفيذ شيوعاً في هذه المرحلة. يجب تسجيل الربط قبل بدء أي استعلام لاحق من جهة الخدمة. وإلا، فعندما يصل طلب من جهة AF أو طلب متوافق مع Diameter إلى الشبكة، قد لا تكون BSF قد أنشأت بعد ربط PCF المقابل، ما يؤدي إلى فشل البحث.

Discovery: استرجاع PCF القائم من سياق الجلسة

تظهر القيمة العملية لـ BSF بوضوح أكبر في عملية Discovery. يرسل مستهلك الخدمة استعلاماً باستخدام معلومات UE المتاحة في ذلك الوقت:

GET .../pcfBindings?query_parameters

يمكن أن تشمل معلمات الاستعلام عنوان IP الخاص بـ UE وSUPI أو GPSI وDNN وS-NSSAI ومعرفات أخرى ذات صلة. وإذا تم العثور على ربط مطابق، تعيد BSF:

200 OK

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

Update وDeregister: الحفاظ على دورة حياة الربط

إذا تغيرت معلومات الربط، يمكن تحديث سجل قائم باستخدام PATCH:

PATCH .../pcfBindings/{bindingId}

يعيد التحديث الناجح 200 OK. وعند تحرير الجلسة، أو توقف PCF عن خدمة UE، أو فقدان الربط صلاحيته، يجب حذف السجل باستخدام:

DELETE .../pcfBindings/{bindingId}

يعيد الحذف الناجح عادة 204 No Content. وفي عمليات النشر الفعلية، يجب عدم تجاهل خطوة إلغاء التسجيل. فإذا بقيت سجلات ربط قديمة في BSF مدة طويلة، فقد ينشئ المشترك نفسه جلسة جديدة لاحقاً ويطابق عن طريق الخطأ PCF قديماً. وغالباً ما تكون هذه المشكلة أصعب في التشخيص من مجرد غياب سجل الربط.

كيفية استكشاف مشكلات ربط N7 وRx

عبر مسار الإشارات الكامل، يمكن تقسيم سير عمل BSF إلى ثلاث مراحل: تسجيل الربط أولاً، ثم الاستعلام عنه، وأخيراً إعادة توجيه إشارات السياسة اللاحقة إلى PCF الأصلي. وعندما يكون هذا التسلسل واضحاً، يصبح استكشاف مشكلات سياسة VoNR أكثر كفاءة بكثير من جمع كميات كبيرة من الإشارات دون اتجاه محدد.

المرحلة الأولى: إنشاء جلسة PDU وتسجيل PCF

بعد دخول مثيل BSF الخدمة، يسجل أولاً قدراته ومعلومات العنونة لدى NRF. بعد ذلك ينشئ UE جلسة PDU من أجل IMS DNN، ويطلب SMF التحكم بالسياسة من PCF. وبعد اختيار PCF، يستدعي Nbsf_Management_Register لتخزين الربط بين UE وPCF داخل BSF.

في هذه المرحلة قد تحتوي BSF على سجلات ربط مشابهة لما يلي:

UE IP1 + DNN1 + S-NSSAI1 + SUPIxx → PCF1
UE IP2 + DNN2 + S-NSSAI2 + SUPIyy → PCF2

المرحلة الثانية: مكالمة VoNR تشغل استعلاماً عن السياسة

عندما يبدأ UE مكالمة VoNR، يطلق نطاق IMS طلباً جديداً لتفويض السياسة. وفي بنية 5GC القياسية، يتبادل AF وPCF معلومات السياسة عبر واجهة N5. وفي بعض عمليات النشر التي تستمر باستخدام إشارات IMS التقليدية عبر Diameter، قد يظل P-CSCF يستخدم إجراء Rx/AAR.

السؤال الأساسي في هذه المرحلة واضح: أي PCF يجب أن يستقبل طلب السياسة؟

لا ينبغي للجهة الطالبة أن تختار PCF آخر اعتماداً فقط على منطق موازنة الحمل المعتاد. بدلاً من ذلك، تستعلم أولاً من BSF باستخدام معلومات مثل عنوان UE وDNN وS-NSSAI. تطابق BSF سجل الربط القائم وتعيد مثيل PCF المسؤول بالفعل عن جلسة UE.

المرحلة الثالثة: إعادة توجيه الإشارات اللاحقة إلى PCF الأصلي

بعد تحديد PCF الصحيح، يتم توجيه طلبات السياسة اللاحقة إلى PCF نفسه. وبذلك يبقى سياق السياسة الذي أُنشئ أثناء إقامة جلسة PDU والطلبات الجديدة التي تظهر أثناء مرحلة وسائط VoNR على مثيل التحكم بالسياسة ذاته. عندها يستطيع PCF إنشاء قواعد PCC وصيانتها استناداً إلى سياق الجلسة الكامل.

إذا أمكن بدء مكالمة VoNR لكن كان سلوك سياسة QoS غير طبيعي، أو كانت قواعد وسائط IMS غير متسقة، أو واجه بعض المشتركين فقط أعطالاً متقطعة، فيجب فحص مسار ربط BSF قبل إرجاع المشكلة مباشرة إلى شبكة النفاذ الراديوي.

يمكن تقسيم تسلسل عملي لاستكشاف الأخطاء إلى أربع خطوات. أولاً، التأكد من تنفيذ عملية BSF Register فعلياً بعد إنشاء جلسة PDU. ثانياً، التحقق من صحة عنوان IP الخاص بـ UE وSUPI وDNN وS-NSSAI المخزنة في BSF. ثالثاً، التحقق من أن شروط الاستعلام المستخدمة في طلب Discovery اللاحق تستطيع مطابقة الربط الأصلي بصورة فريدة. رابعاً، التأكد من أن عنوان PCF أو معرف Diameter المعاد يطابق تماماً PCF الذي شارك أصلاً في التحكم بالسياسة عبر N7.

يجب أيضاً مراعاة بنية النشر. ففي بعض الشبكات قد يتم نشر BSF وSMF معاً في الموقع نفسه. عندئذ قد تختلف نقاط التقاط الحزم ومسارات الاستدعاء الداخلية عن نشر BSF مستقل. ومع ذلك يبقى المبدأ الأساسي كما هو: يجب على الشبكة الحفاظ على ربط مستقر بين جلسة UE وPCF المسؤول عنها.

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

هل تقوم BSF وNRF كلتاهما باختيار وظائف الشبكة؟

لا. لكل منهما دور مختلف. تساعد NRF وظائف الشبكة على اكتشاف مثيلات NF المتاحة وقدراتها، ولذلك تعمل بشكل أقرب إلى سجل للخدمات. أما BSF فتخزن ربطاً تم إنشاؤه مسبقاً بين جلسة UE محددة وPCF. ببساطة، تجيب NRF عن سؤال «ما مثيلات PCF المتاحة؟»، بينما تجيب BSF عن سؤال «أي PCF مسؤول بالفعل عن جلسة UE هذه؟».

هل يمكن أن يكون لدى UE ربط PCF واحد فقط؟

ليس بالضرورة. فالربط لا يُحدد بهوية UE وحدها، بل قد يعتمد أيضاً على DNN وS-NSSAI وسياق جلسة PDU المحدد. وإذا وصل UE نفسه إلى شبكات بيانات أو شرائح شبكة مختلفة، فقد يلزم الحفاظ على الروابط المقابلة بصورة منفصلة.

هل يمكن نشر BSF وSMF في مثيل وظيفة شبكة واحد؟

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

ما الذي يجب فحصه أولاً عند فشل استعلام BSF؟

ابدأ بثلاث نقاط: هل تم إنشاء سجل الربط بنجاح، وهل تتطابق معلمات الاستعلام مع القيم المستخدمة أثناء التسجيل، وهل انتهت صلاحية الربط أو تم حذفه مبكراً. وإذا أعادت BSF سجلاً، فتحقق أيضاً من أن عنوان PCF أو FQDN أو معرف Diameter المعاد يشير إلى مثيل PCF المتوقع.