سؤال وجواب تقني: كيف تتحكم قاعدة BAR على الواجهة N4 في تخزين حزم الوصلة الهابطة والإشعار بوصول البيانات عندما يكون جهاز المستخدم UE في حالة CM-IDLE؟
عندما يدخل جهاز المستخدم UE في حالة CM-IDLE، فإن جلسة PDU الخاصة به لا تختفي. ومع ذلك، فإن مسار مستوى المستخدم N3 الذي كان يُستخدم سابقًا لتوجيه حركة الوصلة الهابطة قد لا يعود نشطًا. إذا وصلت بيانات جديدة من شبكة خارجية في هذه اللحظة، فلا يزال بإمكان الحزم الوصول إلى UPF، لكن لا يمكن توجيهها فورًا إلى gNB عبر N3 كما يحدث في حالة CM-CONNECTED. لذلك يحتاج UPF إلى تحديد ما إذا كان يجب تخزين الحزم، وعدد الحزم التي يمكن الاحتفاظ بها، ومدة بقائها مخزنة، ومتى يجب إخطار مستوى التحكم بوصول بيانات الوصلة الهابطة.
ضمن إطار قواعد PFCP على الواجهة N4، توفر قاعدة BAR (قاعدة إجراء التخزين المؤقت) القواعد الخاصة بسلوك التخزين هذا. ومع ذلك، فإن BAR لا تقرر بشكل مستقل ما إذا كان يجب أن يحدث التخزين. يتم تفعيل إجراء التخزين بواسطة إجراء التطبيق Apply Action في قاعدة FAR، بينما تحدد BAR كيفية تنفيذ هذا التخزين. هذا التمييز أساسي لفهم العلاقة بين FAR و BAR.
قاعدة BAR تحدد كيفية قيام UPF بتخزين الحزم
عندما يستقبل UPF حزمة، فإنه يستخدم أولاً PDR لتحديد نوع الحركة ثم يتبع FAR المشار إليه بواسطة PDR لتحديد الإجراء التالي. إذا كانت FAR تتطلب توجيهًا عاديًا، يقوم UPF بتوجيه الحزمة وفقًا لمعاملات التوجيه Forwarding Parameters. إذا كان إجراء التطبيق Apply Action في FAR يحتوي على BUFF، فلن يتم إرسال الحزمة فورًا نحو واجهة الوجهة، بل تدخل في عملية التخزين المؤقت.
هنا تصبح BAR ذات صلة. يمكن لـ FAR الإشارة إلى BAR التي تخبر UPF بكيفية تخزين الحزم المتأثرة. يمكن تلخيص العلاقة كما يلي:
PDR تحدد الحزمة ← FAR تختار BUFF/NOCP ← BAR تحدد سلوك التخزين المؤقت.
من المفاهيم الخاطئة الشائعة التعامل مع BUFF و BAR وكأنهما الشيء نفسه. ليسا كذلك. BUFF يجيب على السؤال: "هل يجب تخزين هذه الحزمة الآن؟" بينما BAR يجيب على السؤال: "بمجرد اختيار التخزين، ما هي الشروط التي يجب أن يتم فيها تخزين الحزمة؟" النظر فقط إلى BUFF في FAR دون التحقق من BAR المرتبطة أو إعدادات التخزين المحلية في UPF يعطي صورة جزئية فقط عن سلوك مستوى المستخدم.
كما يرتبط NOCP عادةً بهذا السيناريو. عندما يقوم UPF بتخزين حزم الوصلة الهابطة، يمكن أن يتطلب NOCP من UPF إخطار مستوى التحكم بوصول بيانات الوصلة الهابطة حتى يتمكن SMF من بدء إجراءات مستوى التحكم التالية. لذلك يتم التخزين والإخطار كمهمتين منسقتين: مستوى المستخدم يحتفظ بالحزم مؤقتًا بينما يتم الإبلاغ عن الحدث لمستوى التحكم.
السيناريو الأكثر شيوعًا لقاعدة BAR يحدث بعد دخول UE في حالة CM-IDLE
من الأسهل فهم دور BAR عندما ينتقل UE من CM-CONNECTED إلى CM-IDLE. لنفترض أن UE قد أكمل بالفعل التسجيل وإنشاء جلسة PDU. أثناء اتصاله، يكون مسار مستوى المستخدم N3 متاحًا ويمكن لـ UPF توجيه حزم الوصلة الهابطة مباشرة نحو gNB.
بعد فترة من عدم النشاط، قد يقوم جانب الوصول بتحرير الاتصال ويدخل UE في حالة CM-IDLE. تبقى جلسة PDU قائمة، لكن مسار توجيه مستوى المستخدم N3 الذي كان نشطًا سابقًا لم يعد متاحًا فورًا. الخوادم الخارجية ليست بالضرورة على علم بهذا التغيير في الحالة، لذلك قد تستمر حزم IP الجديدة للوصلة الهابطة في الوصول إلى UPF عبر N6.
هذا يخلق المشكلة الأساسية: لقد استقبل UPF البيانات، لكن لا يوجد حاليًا مسار N3 قابل للاستخدام يمكن من خلاله تسليمها إلى UE.
في هذه المرحلة، يقوم SMF بتحديث قواعد مستوى المستخدم عبر N4 بحيث تتغير FAR المعنية من التوجيه الفوري إلى سلوك التخزين المؤقت. في الحالة النموذجية، يتم تفعيل BUFF و NOCP في إجراء التطبيق Apply Action، بينما لم يعد FORW مستخدمًا كإجراء الوصلة الهابطة الحالي. عند وصول حزم ووصلة هابطة جديدة، يحتفظ بها UPF وفقًا لسياسة التخزين المطبقة ويبلغ SMF بوصول بيانات الوصلة الهابطة.
بعد استلام الإشعار، يمكن لـ SMF التنسيق مع AMF لبدء الإجراءات اللازمة لجعل UE قابلاً للوصول مرة أخرى، بما في ذلك النداء Paging عند الاقتضاء. بمجرد عودة UE إلى حالة يمكن فيها نقل حركة مستوى المستخدم واستعادة مسار N3، يقوم SMF بتحديث قواعد UPF مرة أخرى بحيث يتغير التعامل مع الوصلة الهابطة من التخزين إلى التوجيه. عندها يمكن للحزم المخزنة متابعة التوجيه نحو UE.
لذلك فإن BAR ليست مجرد قاعدة ثابتة لتخصيص الذاكرة. غرضها الحقيقي هو مساعدة مستوى المستخدم على تجاوز الفترة المؤقتة التي وصلت فيها حزم الوصلة الهابطة بالفعل ولكن التوجيه الفوري غير ممكن بعد.
معاملات BAR الرئيسية تحدد حدود التخزين المؤقت
لا يمكن أن يستمر التخزين المؤقت إلى أجل غير مسمى. إذا سُمح لـ UPF بالاحتفاظ بكمية غير محدودة من بيانات الوصلة الهابطة لجهاز UE غير قابل للوصول، فقد تُستهلك ذاكرة مستوى المستخدم بلا داعٍ. لذلك توفر BAR حدودًا لسلوك التخزين. اعتمادًا على إجراء PFCP وقدرات UPF، يمكن أن تشمل هذه المعاملات معرف BAR، وحدود عدد الحزم، ومدة التخزين، ومعاملات تأخير الإشعار.
معرف BAR (BAR ID)
يحدد معرف BAR قاعدة التخزين بشكل فريد داخل جلسة PFCP ويسمح لـ FAR المعنية بالإشارة إلى BAR الصحيحة. أثناء استكشاف الأخطاء وإصلاحها، رؤية إنشاء BAR وحده لا يثبت أن القاعدة تؤثر على الحركة قيد التحليل. يجب أيضًا فحص FAR المقابلة للتأكد من معرف BAR الذي تشير إليه فعليًا.
عدد الحزم المقترح للتخزين (Suggested Buffering Packets Count)
يشير عدد الحزم المقترح للتخزين إلى عدد الحزم التي يُنصح UPF بتخزينها للحركة المعنية. بمجرد تجاوز الحد المقترح، قد يتم التخلص من الحزم الإضافية. يتحكم هذا المعامل في حدود سعة التخزين بدلاً من مدة التخزين.
يعتمد ظهوره أيضًا على دعم ميزات UPF. إذا لم يكن الحقل مرئيًا في تتبع PFCP، فهذا وحده لا يثبت أن التحكم في التخزين مفقود. يجب أن يأخذ التحليل أيضًا في الاعتبار ما إذا كان UPF يدعم القدرة المعنية وما إذا كانت معاملات التخزين المحلية مستخدمة بدلاً من ذلك.
مدة تخزين الوصلة الهابطة (DL Buffering Duration)
تحدد مدة تخزين الوصلة الهابطة الفترة التي قد تستمر خلالها حزم الوصلة الهابطة في البقاء مخزنة في UPF بموجب الإجراء المطبق. تعكس مبدأ تصميم مهم: التخزين المؤقت مقصود كآلية مؤقتة أثناء استعادة تسليم مستوى المستخدم، وليس كتخزين دائم للحزم.
إذا ظل UE غير قابل للوصول لفترة طويلة، تحتاج عملية التخزين إلى شرط إنهاء محدد؛ وإلا فقد تظل موارد مستوى المستخدم مشغولة إلى أجل غير مسمى.
تأخير إشعار بيانات الوصلة الهابطة (Downlink Data Notification Delay)
في الإجراءات ومجموعات القدرات المدعومة، يمكن أن يتحكم تأخير إشعار بيانات الوصلة الهابطة في مدة انتظار UPF بعد استلام أول حزمة ووصلة هابطة قبل إخطار مستوى التحكم. يؤثر هذا المعامل على متى يتم إرسال الإشعار، بدلاً من ما إذا كان يجب تخزين الحزمة.
لذلك يجب تفسير سلوكه في سياق إجراء PFCP المحدد وتنفيذ الشبكة وقدرات UPF بدلاً من الاستدلال عليه من اسم المعامل وحده.
لماذا تكون معاملات BAR الكاملة مفقودة أحيانًا من تتبعات PFCP؟
هذه واحدة من أسهل النقاط التي يمكن إساءة تفسيرها عند تحليل BAR. عدد الحزم المطلوب تخزينها ومدة التخزين ومعاملات التخزين الأخرى لا يجب دائمًا توفيرها ديناميكيًا عبر N4. يمكن للمشغلين أو بائعي المعدات أيضًا تكوين سياسات التخزين محليًا في UPF.
مع هذا التنفيذ، قد يحتاج SMF فقط إلى تغيير إجراء FAR ديناميكيًا. على سبيل المثال، بعد دخول UE في حالة CM-IDLE، يمكن لـ SMF استخدام تعديل جلسة PFCP لتحديث FAR المعنية إلى BUFF/NOCP. بمجرد أن يرى UPF إجراء التخزين، يمكنه تطبيق حدود عدد الحزم والمدة المكونة محليًا.
لذلك فإن الملاحظة التالية في التتبع ليست غير طبيعية تلقائيًا:
تطلب FAR إجراء BUFF، لكن رسائل PFCP لا تحتوي على معاملات BAR الكاملة التي يتوقعها المهندس.
يجب التحقق من سؤالين إضافيين على الأقل: ما إذا كان UPF يستخدم قيم تخزين مكونة محليًا، وما إذا كان UPF يدعم التوفير الديناميكي لمعاملات BAR المعنية. خلاف ذلك، قد يُخطئ في اعتبار اختلاف التنفيذ قاعدة مفقودة من SMF.
يمكن أن يكون للتكوين المحلي أيضًا مزايا عملية. يمكن أن يقلل من بعض إشارات N4 ويستوعب اختلافات القدرات بين تطبيقات UPF. المقايضة هي أن جزءًا من سلوك التخزين لم يعد مرئيًا بالكامل في تتبع PFCP واحد، لذا قد يتطلب استكشاف الأخطاء متعدد البائعين تحليل الإشارات وفحص التكوين المحلي لـ UPF.
كيف يجب فهم تدفق PFCP عند وصول بيانات الوصلة الهابطة في حالة CM-IDLE؟
من الأسهل فهم BAR عندما يتم إرجاعها إلى الإجراء الكامل بدلاً من تحليلها كعنصر معلومات معزول.
أثناء وجود UE في حالة CM-CONNECTED، يكون مسار N3 متاحًا ويقوم UPF بتوجيه حزم الوصلة الهابطة وفقًا لـ FAR العادية. بعد فترة من عدم النشاط، يتم تحرير اتصال جانب الوصول. بمجرد أن يعلم SMF أن حالة اتصال مستوى المستخدم قد تغيرت، يستخدم تعديل جلسة PFCP لتحديث قواعد UPF المعنية.
النقطة المهمة هي أن جلسة PDU لم يتم حذفها. بدلاً من ذلك، مسار مستوى المستخدم الحالي للوصلة الهابطة غير متاح مؤقتًا للتسليم الفوري. لذلك يمكن أن تنتقل FAR المعنية إلى سلوك التخزين من خلال تفعيل BUFF وإجراء إخطار مستوى التحكم المطلوب، بينما توفر BAR أو تكوين UPF المحلي شروط التخزين التفصيلية.
عندما يرسل خادم إنترنت أو تطبيق بيانات ووصلة هابطة جديدة لاحقًا، تصل الحزم أولاً إلى UPF. يستخدم UPF قاعدة PDR لتحديد الحركة ثم يطبق FAR المرتبطة. نظرًا لأن الإجراء الحالي لم يعد FORW، يتم تخزين الحزم. في الوقت نفسه، يبلغ UPF عن وصول بيانات الوصلة الهابطة إلى SMF من خلال آلية إبلاغ PFCP.
ثم ينسق SMF مع إجراءات جانب AMF حتى يصبح UE قابلاً للوصول مرة أخرى ويمكن إعادة إنشاء مسار مستوى المستخدم. بمجرد توفر توجيه N3 مرة أخرى، يتم تحديث FAR على N4 مرة أخرى للتوجيه العادي ويمكن لـ UPF مواصلة تسليم حركة الوصلة الهابطة إلى UE.
يمكن تلخيص المنطق العام كما يلي:
يدخل UE في CM-IDLE ← يصبح N3 غير متاح مؤقتًا ← يقوم SMF بتحديث FAR/BAR ← تصل بيانات الوصلة الهابطة إلى UPF ← يخزن UPF ويبلغ عنها ← يستعيد مستوى التحكم قابلية الوصول لـ UE ← يتم استعادة N3 ← تعود FAR إلى التوجيه.
لذلك تتحكم BAR في سلوك مستوى المستخدم خلال الفترة التي وصلت فيها البيانات بالفعل، لكن مسار التسليم لم يعد بعد.
يجب أن يتبع استكشاف أخطاء BAR أربع خطوات: الإجراء، والتخزين، والإشعار، والاستعادة
نادرًا ما تظهر المشكلات المتعلقة بـ BAR كـ "خطأ BAR" صريح. في أغلب الأحيان، يكون العرض هو أن أول حركة ووصلة هابطة بعد دخول UE في حالة خمول تتصرف بشكل غير طبيعي. قد يعمل التطبيق بشكل طبيعي أثناء النشاط، لكن بعد فترة من عدم النشاط تصل الرسالة التالية بتأخير ملحوظ. في حالة أخرى، قد يتم نداء UE بنجاح وإعادة توصيله، ومع ذلك تكون أولى حزم الوصلة الهابطة قد فُقدت بالفعل.
يمكن تحليل هذه المشكلات في أربع مراحل.
الخطوة 1: تأكد من أن FAR دخلت فعليًا في وضع التخزين المؤقت
ابدأ بـ FAR المشار إليها بواسطة PDR الوصلة الهابطة المعنية وتأكد من حدوث تعديل جلسة PFCP المتوقع بعد دخول UE في CM-IDLE. تحقق مما إذا كان إجراء التطبيق Apply Action قد تغير من سلوك FORW العادي إلى إجراءات BUFF والإشعار المتوقعة للسيناريو.
إذا كانت FAR لا تزال تحاول توجيه الحزم نحو مسار مستوى مستخدم لم يعد قابلاً للاستخدام، فالمشكلة ليست في المقام الأول مشكلة BAR.
الخطوة 2: حدد قواعد التخزين التي يطبقها UPF
تحقق من معرف BAR المشار إليه بواسطة FAR ثم افحص معاملات إنشاء BAR أو تحديث BAR المقابلة. إذا كان تتبع PFCP لا يحتوي على معاملات التخزين الكاملة، فتابع بفحص تكوين التخزين المحلي لـ UPF والقدرات المدعومة.
إذا كان حد عدد الحزم صغيرًا جدًا، فقد يتم التخلص من بعض حزم الوصلة الهابطة الأولى قبل أن يصبح UE قابلاً للوصول مرة أخرى. إذا اختلف سلوك التخزين الملحوظ بشكل كبير عن التوقعات، فيجب أيضًا التحقق من ارتباط BAR نفسه.
الخطوة 3: تأكد من أن UPF أبلغ عن وصول بيانات الوصلة الهابطة
تخزين الحزم وحده لا يعيد الاتصال مع UE. إذا لم يكن مستوى التحكم على علم بوصول بيانات ووصلة هابطة جديدة، فلن يبدأ إجراء النداء Paging أو استعادة مستوى المستخدم اللاحق. لذلك يجب فحص التتبع بحثًا عن تقرير جلسة PFCP المناسب والمعالجة الصحيحة بواسطة SMF.
إذا كانت الحزم مخزنة بالفعل في UPF ولكن لا يتبع ذلك أي إجراء لمستوى التحكم، فيجب أن ينتقل استكشاف الأخطاء من معاملات BAR نحو مسار الإبلاغ من UPF إلى SMF وإجراءات SMF اللاحقة.
الخطوة 4: تأكد من استئناف التوجيه بعد استعادة مستوى المستخدم
بعد أن يصبح UE قابلاً للوصول مرة أخرى، تحقق من أن SMF يقوم بتحديث قواعد N4 بشكل صحيح بحيث تتغير FAR الوصلة الهابطة من التخزين إلى التوجيه العادي ويتم استعادة معاملات توجيه N3 المطلوبة.
إذا نجح النداء Paging وعاد UE، لكن FAR بقيت في وضع BUFF، فقد يدخل النظام في حالة يكون فيها UE قابلاً للوصول بينما تستمر الحزم في البقاء في UPF. لذلك يجب أن يستمر استكشاف أخطاء BAR حتى يتم استعادة مسار توجيه مستوى المستخدم بالكامل.
القيمة الجوهرية لقاعدة BAR
ضمن إطار قواعد PFCP، لا تشارك BAR في كل حزمة موجهة بشكل عادي بنفس الطريقة التي تشارك بها PDR و FAR. تظهر أهميتها بشكل أوضح في حالة محددة ولكنها حرجة: الجلسة ما تزال موجودة، لكن مسار مستوى المستخدم الحالي لا يمكنه تسليم بيانات الوصلة الهابطة الجديدة فورًا.
تغير FAR إجراء معالجة الحزم من FORW إلى BUFF، وتحدد BAR حدود التخزين، ويحتفظ UPF بالحزم مؤقتًا ويبلغ عن وصولها، وتنسق وظائف مستوى التحكم مثل SMF و AMF استعادة قابلية الوصول لـ UE. معًا، تعمل هذه الآليات على تجاوز الانتقال من عدم توفر التسليم المؤقت إلى مسار مستوى مستخدم نشط.
لذلك لا ينبغي فهم BAR فقط على أنها "قاعدة إجراء التخزين = قاعدة لتخزين الحزم." التفسير الأكثر فائدة هو: تخبر BAR الـ UPF بكيفية إدارة حزم الوصلة الهابطة التي وصلت بالفعل بينما يكون مسار تسليم مستوى المستخدم غير متاح مؤقتًا. بمجرد النظر إلى BAR مع CM-IDLE و FAR BUFF/NOCP وتقرير جلسة PFCP وإجراءات النداء Paging واستعادة مستوى المستخدم اللاحقة، يصبح دورها على الواجهة N4 أكثر وضوحًا.
الأسئلة الشائعة
ما الفرق بين BAR و BUFF في FAR؟
BUFF هو إجراء تطبيق Apply Action في FAR يشير إلى أنه يجب تخزين الحزم المطابقة بدلاً من توجيهها فورًا. تحدد BAR كيفية تنفيذ هذا التخزين، مثل حدود عدد الحزم أو مدة التخزين أو الشروط الأخرى المطبقة. بعبارات بسيطة، تقرر FAR أن التخزين مطلوب، بينما تحدد BAR كيفية تنفيذ التخزين.
هل يمكن أن تعمل BAR بشكل مستقل عن FAR؟
لا ينبغي التعامل مع BAR كقاعدة مطابقة حزم مستقلة. يتم مطابقة الحزمة أولاً بواسطة PDR، التي تشير إلى FAR المعنية. عندما تتطلب FAR التخزين وتشير إلى BAR المطبقة، يتم استخدام معاملات BAR للتحكم في كيفية تخزين تلك الحزم.
لماذا لا يتم التخلص من حزم الوصلة الهابطة ببساطة عندما يدخل UE في CM-IDLE؟
لا يعني CM-IDLE أن جلسة PDU قد حُذفت. قد تستمر التطبيقات الخارجية في إرسال البيانات بينما يكون مسار تسليم مستوى المستخدم غير متاح مؤقتًا فقط. يسمح التخزين قصير المدى بالاحتفاظ بجزء من حركة الوصلة الهابطة هذه بينما يستعيد مستوى التحكم قابلية الوصول لـ UE، مما يساعد على تقليل انقطاع استمرارية التطبيق.
هل يعني غياب عدد الحزم المقترح للتخزين أن BAR مكونة بشكل خاطئ؟
ليس بالضرورة. يعتمد ظهور هذا المعامل على إجراء PFCP وقدرة UPF والتنفيذ. قد تكون حدود عدد الحزم وسلوك التخزين الآخر مكونة أيضًا محليًا في UPF، لذا يجب فحص دعم القدرات وارتباط BAR وتكوين التخزين على جانب الجهاز.
لماذا لا يزال UE لا يستقبل البيانات على الرغم من أن UPF قد خزن حزم الوصلة الهابطة؟
التخزين هو جزء واحد فقط من الإجراء. يجب أيضًا على UPF الإبلاغ عن وصول بيانات الوصلة الهابطة إلى SMF، ويجب على مستوى التحكم بدء الإجراءات اللازمة لاستعادة قابلية الوصول لـ UE، ويجب على SMF تحديث FAR ومعاملات توجيه N3 بمجرد توفر مسار مستوى المستخدم مرة أخرى. الفشل في أي من هذه المراحل يمكن أن يترك الحزم مخزنة أو يؤدي في النهاية إلى التخلص منها.
