قد تكون جلسة PDU تعمل بصورة طبيعية منذ فترة: حصل UE بالفعل على عنوان IP، ومسار مستوى المستخدم N3 نشط، وحركة بيانات التطبيقات تمر كما هو متوقع. ثم تتغير ظروف الخدمة. قد يلزم خفض معدل البيانات المصرح به سابقًا، أو استخدام 5QI مختلف لتدفق QoS معين، أو تقرر الشبكة تقييد الحد الأقصى لمعدل الجلسة إلى 10 Mbps.
في هذه الحالة لا يحتاج 5GC إلى إنهاء جلسة PDU بالكامل ثم إنشائها من جديد. يمكن أن تبقى الجلسة الحالية نشطة مع تحديث قواعد QoS المتأثرة أو معلمات تدفق QoS أو سياسات التطبيق على مستوى المستخدم فقط. وهذا هو دور PDU Session Modification.
الفرق عن PDU Session Establishment واضح. فإجراء الإنشاء ينشئ جلسة لم تكن موجودة سابقًا، بينما يغيّر إجراء التعديل جلسة نشطة بالفعل. لذلك لم تعد الأسئلة الرئيسية تتعلق بكيفية اختيار SMF أو كيفية إنشاء UPF في البداية، بل بـما الذي أدى إلى التغيير، وكيف يحصل SMF على السياسة الجديدة، وما الذي يحتاج UE وgNB إلى تحديثه، وهل تُطبَّق سياسة QoS الجديدة فعليًا في UPF.
نطاق تعديل جلسة PDU
يتطلب PDU Session Modification شرطًا أساسيًا مهمًا: يجب أن تكون جلسة PDU المستهدفة موجودة بالفعل. ويكون UE وSMF وPCF وسياق RAN ذي الصلة مرتبطين بهذه الجلسة، كما يكون مستوى المستخدم في وضع التشغيل عادةً.
الهدف من إجراء التعديل هو تغيير المعلمات مع إبقاء الجلسة نشطة. وتُعد QoS من أكثر الأمثلة شيوعًا. فقد يحتاج تدفق QoS موجود إلى 5QI أو MBR أو MFBR مختلف أو إلى معلمة أخرى مصرح بها. وقد يتطلب تغيير السياسة أيضًا تحديث التحكم في المعدل المطبق بالفعل داخل UPF.
لا ينبغي فهم تعديل QoS على أنه مجرد تغيير حقل واحد في NAS. فقد يؤثر تحديث QoS واحد في ثلاثة أجزاء مختلفة من النظام:
جانب UE: يحتاج UE إلى استلام قاعدة QoS الجديدة أو معلمات تدفق QoS الجديدة؛
جانب RAN: قد يحتاج gNB إلى تعديل مورد PDU Session Resource المقابل أو موارد تدفق QoS؛
جانب UPF: إذا تغير تطبيق السياسة على مستوى المستخدم، فيجب تحديث قواعد PFCP ذات الصلة عبر N4.
لذلك من الأفضل النظر إلى PDU Session Modification باعتباره إعادة تهيئة أثناء التشغيل لجلسة نشطة. تظل هوية الجلسة دون تغيير، ويُطبَّق التعديل على PDU Session ID الحالي وتدفقات QoS المرتبطة به.
هناك أيضًا حد مهم يجب الانتباه إليه. يمكن لـPDU Session Modification تحديث تدفق QoS موجود، ويمكن في سيناريوهات الخدمة المناسبة استخدامه أيضًا لإنشاء تدفق QoS جديد داخل جلسة PDU نفسها. فعلى سبيل المثال، قد تتطلب سياسة تقودها التطبيقات لمكالمة VoNR تدفقًا إضافيًا بخصائص QoS محددة. لكن التركيز هنا هو على تعديل معلمات تدفق QoS موجود وليس إنشاء تدفق جديد.
أهم أسباب تشغيل تعديل الجلسة
أحد الفروق الرئيسية عن PDU Session Establishment هو أن UE ليس المصدر الوحيد الذي يمكنه بدء التعديل. فقد يعاد تكوين جلسة PDU نشطة بسبب طلب من UE، أو تغيير في سياسة الشبكة، أو تحديث بيانات الاشتراك، أو تغير ظروف الراديو.
يمكن تقسيم مصادر التفعيل الشائعة إلى خمس فئات:
بدء من UE: يرسل UE رسالة PDU Session Modification Request لطلب تغيير في QoS أو في معلمات أخرى مرتبطة بالجلسة؛
بدء من PCF: تتغير آلية التحكم في السياسة، مثل بلوغ حد استخدام معين فتخفض الشبكة المعدل المصرح به، أو عندما تتطلب سياسة تطبيق QoS مختلفة؛
بدء من UDM: تتغير بيانات اشتراك إدارة الجلسة، مثل تحديث فئة المشترك أو ملف QoS المشترك به؛
بدء من SMF: يقرر SMF إعادة تكوين الجلسة وفق السياسة المحلية أو إعدادات الشبكة أو حالة الجلسة الحالية؛
تفعيل مرتبط بـRAN: يبلّغ gNB عن ظروف الراديو أو الموارد، وبعد ذلك يحدد SMF ضرورة تعديل معلمات الجلسة.
تلتقي هذه الأسباب في النهاية عند SMF، لأنه يحتفظ بسياق التحكم في جلسة PDU ويحوّل متطلبات الخدمة أو السياسة الجديدة إلى معلمات يمكن تطبيقها في UE وRAN وUPF.
عند استكشاف مشكلات PDU Session Modification، لا ينبغي أن تكون الخطوة الأولى هي البدء من PDU Session Modification Command ومتابعة الرسائل اللاحقة فقط. من الأنسب تحديد أقدم حدث تحكم أدى إلى التغيير. إذا كان الحدث الأول هو UE Modification Request، فالإجراء بدأه UE. وإذا دفع PCF سياسة جديدة إلى SMF عبر Notification URI، فالتغيير مدفوع بالسياسة. وإذا ظهر تحديث لبيانات اشتراك UDM أولًا، فينبغي تتبع مسار تغيير الاشتراك.
تعديل جلسة PDU بمبادرة من UE
يسهل فهم الإجراء الذي يبدأه UE باعتباره حالة يحتاج فيها أحد التطبيقات إلى QoS مختلفة.
لنفترض أن UE يستخدم حاليًا PDU Session ID 5 وأن أحد تدفقات QoS لديه ما زال يعمل بالإعداد الأصلي. يضيف تطبيق متطلب خدمة جديدًا، ولذلك يطلب UE معلمات QoS مختلفة بإرسال PDU Session Modification Request.
تمر رسالة NAS أولًا عبر gNB إلى AMF. بعد ذلك يحدّث AMF الـSM Context القائم لدى SMF. وعلى الواجهة المعتمدة على الخدمات يستخدم AMF:
POST /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
يختلف ذلك عن Create SM Context. فالـSM Context موجود بالفعل، والشبكة تقوم الآن بتحديث سياق جلسة قائمة.
قد يتضمن طلب UE عناصر Requested QoS Rules وRequested QoS Flow Descriptions وPacket Filters المرتبطة بها. بعد استلام الطلب، يحتاج SMF إلى تحديد ما إذا كانت الشبكة تستطيع السماح بالتغيير المطلوب. وإذا كانت الجلسة تستخدم التحكم الديناميكي في السياسات، يرسل SMF طلب الخدمة أيضًا إلى PCF للحصول على التفويض.
على سبيل المثال، إذا طلب UE قيمة 5QI 8 لتدفق معين، فيمكن لـSMF استدعاء خدمة PCF SM Policy Control لتعديل Policy Association الحالية. يقيّم PCF سياسة المشترك وقواعد الخدمة وظروف الشبكة الحالية، ثم يعيد معلمات QoS المصرح بها فعليًا.
هناك نقطة مهمة: QoS التي يطلبها UE ليست بالضرورة QoS التي ستُطبَّق في النهاية. يعبّر UE عن متطلب الخدمة، بينما تخضع المعلمات النهائية لتفويض SMF وPCF.
بعد تحديد المعلمات المصرح بها، ينشئ SMF نوعين من المعلومات:
N1 SM: رسالة PDU Session Modification Command تحمل معلمات QoS الجديدة باتجاه UE؛
N2 SM: معلومات خاصة بإجراء PDU Session Resource Modify، توجه gNB إلى تعديل موارد تدفق QoS المقابل.
يرسل AMF معلومات N2 إلى gNB عبر NGAP، ويمرر إلى UE رسالة PDU Session Modification Command الموجودة في N1.
بعد أن يضبط gNB الموارد ذات الصلة، يعيد PDU Session Resource Modify Response. وعندما يقبل UE المعلمات الجديدة، يرسل عبر NAS رسالة PDU Session Modification Complete.
لا يستطيع SMF تأكيد انتقال معلمات الجلسة الجديدة من مرحلة تفويض السياسة إلى التطبيق الفعلي على جانب الوصول وUE إلا بعد استلام نتائج التنفيذ ذات الصلة.
تعديل QoS على جانب الشبكة بمبادرة من PCF
يتبع التعديل على جانب الشبكة منطقًا مختلفًا. لم يطلب UE QoS جديدة؛ بل يبدأ التغيير من طبقة التحكم في السياسة.
لنأخذ مثال حد الاستخدام. لدى المستخدم جلسة PDU نشطة بالفعل ويواصل نقل البيانات. يطلب PCF من الجلسة الإبلاغ عن معلومات الاستخدام أو مراقبتها. وعندما يصل الاستخدام المتراكم إلى حد مضبوط، يمكن للسياسة خفض الحد الأقصى لمعدل الجلسة أو التدفق المرتبط إلى 10 Mbps.
بعد ذلك يخطر PCF الـSMF عبر Notification URI المسجل عند إنشاء SM Policy Association. يحمل الإخطار SM Policy Decision الجديدة، مثل MBR المحدث وPolicy Control Trigger المقابل.
من منظور SMF، لا يمثل ذلك إنشاء جلسة جديدة، بل تعديل جلسة PDU ما زالت صالحة ونشطة.
إذا كان من الضروري تطبيق المعدل الجديد داخل UPF، يرسل SMF عبر N4 رسالة PFCP Session Modification Request. ويمكن تحديث QER ذي الصلة، مثل تغيير MBR إلى 10 Mbps. ولا يبدأ حد المعدل الجديد بالتطبيق على مستوى المستخدم إلا بعد قبول UPF للتعديل.
يجب عدم الخلط بين استخدامين مختلفين لكلمة “Modification”:
PDU Session Modification: الإجراء العام في 5GS لتعديل جلسة PDU نشطة؛
PFCP Session Modification: إجراء التحكم المحدد على N4 الذي يستخدمه SMF لتحديث قواعد مستوى المستخدم في UPF.
يعمل الإجراءان على طبقتين مختلفتين. قد يتضمن PDU Session Modification إجراء PFCP Session Modification، لكن وجود رسالة تعديل PFCP واحدة لا يعني اكتمال تعديل جلسة PDU بالكامل.
بعد أن يبدأ UPF بتطبيق QER الجديد، قد يظل SMF بحاجة إلى تحديث RAN وUE. تُرسل معلومات N1/N2 عبر AMF، ويتلقى gNB رسالة PDU Session Resource Modify Request، بينما يتلقى UE رسالة PDU Session Modification Command.
عندما ينتهي gNB من تحديث موارد الراديو ويقبل UE معلمات QoS الجديدة، يعيد الطرفان نتائج التنفيذ. بعد ذلك يستطيع SMF إبلاغ PCF بالنتيجة الناجحة حتى يعرف نظام السياسات أن قرار QoS قد تم تطبيقها فعليًا، وليس مجرد تخزينها كقرار سياسة.
التعديل المنسق عبر N1 وN2 وN4
من أكثر جوانب PDU Session Modification إرباكًا أن تغيير QoS نفسه قد يؤدي في الوقت ذاته إلى إجراءات تعديل في NAS وNGAP وPFCP.
يصبح المنطق أوضح عند فصل المسارات الثلاثة.
N1 يحدّث معلمات جلسة UE
يحمل N1 SM معلومات إدارة الجلسة بين UE وSMF. بعد أن تقرر الشبكة تعديل الجلسة، يرسل SMF إلى UE عبر AMF رسالة PDU Session Modification Command.
يحدّث UE معلمات جلسة PDU المحلية ويؤكد القبول برسالة PDU Session Modification Complete.
N2 يحدّث موارد RAN
عندما يلزم تغيير موارد الراديو المرتبطة بتدفق QoS، ينشئ SMF معلومات N2 SM المقابلة ويرسلها إلى gNB عبر AMF. يعدّل gNB موارد تدفق QoS المعنية باستخدام إجراء PDU Session Resource Modify ويعيد النتيجة، بما في ذلك قيم QFI التي تم تعديلها بنجاح عندما ينطبق ذلك.
N4 يحدّث قواعد التطبيق في UPF
إذا أثر التغيير في توجيه مستوى المستخدم أو تطبيق QoS، يحدّث SMF قواعد UPF المعنية عبر PFCP Session Modification.
قد يتطلب تغيير حد المعدل تحديث QER. وقد تؤثر تغييرات سياسة أخرى في PDR أو FAR أو قاعدة أخرى على مستوى المستخدم. يعتمد تحديد القواعد التي يتم تعديلها على الخدمة وسياسة التحكم؛ ولا يعني PDU Session Modification بالضرورة إعادة كتابة جميع قواعد PFCP.
يمكن تلخيص تغيير QoS كامل كما يلي:
السياسة / طلب UE
→ يعيد SMF حساب معلمات الجلسة
→ يحدّث N4 التطبيق في UPF
→ يحدّث N2 موارد gNB
→ يحدّث N1 معلمات UE
→ يؤكد كل طرف النتيجة
قد يختلف الترتيب الدقيق للرسائل بحسب سبب التفعيل والمعلمات التي يتم تغييرها. أثناء استكشاف الأعطال، ليس من المفيد الإصرار على أن كل سيناريو يجب أن يحتوي على تسلسل رسائل مطابق تمامًا. الأفضل هو التأكد من أن كل نقطة تنفيذ تحتاج إلى التغيير تستلم المعلمات الجديدة وتطبقها فعليًا.
اكتمال التعديل واستكشاف أعطال الإشارات
تتميز مشكلات PDU Session Modification بصفة تختلف عن فشل إنشاء الجلسة: قد تبقى جلسة PDU نشطة، وقد يستمر المستخدم في نقل البيانات، بينما لا تتوافق QoS الناتجة مع السياسة المقصودة.
على سبيل المثال، قد تتطلب السياسة خفض المعدل إلى 10 Mbps ويكون PCF قد أصدر قرار سياسة جديد بالفعل، بينما لا يزال اختبار معدل النقل الفعلي يعرض قيمة أعلى بكثير. استمرار جلسة PDU لا يثبت نجاح التعديل. يجب أن يحدد التحقيق النقطة التي توقفت عندها المعلمات الجديدة عن التطبيق.
يمكن استخدام نقاط التحقق التالية في تسلسل عملي لاستكشاف الأعطال:
تحديد سبب التفعيل: تحديد ما إذا كان الحدث الأول UE Modification Request أو PCF Notification أو تغيير بيانات UDM أو حدثًا على جانب SMF/RAN؛
التحقق من قرار SMF: التأكد من أن SMF قبل الطلب وأن PCF أعاد قرار السياسة المتوقع؛
التحقق من التطبيق على N4: إذا كان UPF مطالبًا بتطبيق QoS الجديدة، فيجب التأكد من نجاح PFCP Session Modification ومن تغير معلمات QER ذات الصلة فعليًا؛
التحقق من التنفيذ على N2: التأكد من أن gNB استلم PDU Session Resource Modify Request وأعاد تدفقات QoS التي تم تعديلها بنجاح؛
التحقق من التأكيد على N1: التأكد من أن UE استلم PDU Session Modification Command وأعاد PDU Session Modification Complete؛
التحقق من نتيجة الخدمة: التأكد من أن حركة البيانات الفعلية تتبع الآن المعدل أو QoS أو سياسة الخدمة المحدثة.
إذا كان PCF قد صرّح بالفعل بـ10 Mbps بينما لا يزال QER في UPF يحتوي على MBR القديم، فينبغي أن يركز التحقيق على المسار من SMF إلى N4. وإذا كان UPF يطبق المعدل الجديد بالفعل بينما لا يزال QoS Flow في gNB يستخدم المعلمات القديمة، فيجب فحص إجراء N2 Resource Modify بمزيد من التفصيل. وإذا كان جانب الشبكة قد أكمل جميع التغييرات المطلوبة لكن UE لا يعيد Modification Complete، فينبغي فحص جانب NAS لمعرفة ما إذا كانت قواعد QoS الجديدة قد تم قبولها.
قد يسبب اسم إحدى الرسائل التباسًا أيضًا. تستخدم بعض مخططات الإجراءات عبارة “PDU Session Modification Command Ack” لوصف خطوة تأكيد UE. لكن في إشارات 5GSM NAS، الرسالة الفعلية التي يرسلها UE بعد قبول PDU Session Modification Command هي PDU Session Modification Complete. لذلك ينبغي أن يعتمد تحليل الحزم على NAS Message Type الفعلي.
هذا الأسلوب الطبقي في استكشاف الأعطال أكثر فعالية بكثير من بدء التحقيق من جديد عند Registration Request. جلسة PDU موجودة بالفعل. المشكلة هي أن جلسة نشطة لم يتم تحديثها بصورة متسقة وفق السياسة الجديدة. لذلك يجب أن يظل نطاق البحث مركزًا على SM Context الحالي والسياسة وQoS Flow وآلية التطبيق على مستوى المستخدم.
الأسئلة الشائعة
هل يعيد PDU Session Modification تعيين عنوان IP الخاص بـUE؟
يؤدي تعديل QoS العادي إلى تحديث جلسة PDU قائمة وتدفقات QoS الخاصة بها بدلًا من إعادة بناء الجلسة بالكامل. يعتمد تغير سمات الجلسة الأخرى على السيناريو المحدد، لكن تعديلًا يقتصر على معلمات مثل 5QI أو MBR لا ينبغي اعتباره إجراء PDU Session Establishment جديدًا.
هل يبدأ UE دائمًا PDU Session Modification؟
لا. يستطيع UE طلب التعديل عبر PDU Session Modification Request، لكن تغيير سياسة PCF أو تحديث بيانات اشتراك UDM أو قرار محلي من SMF أو حدث مرتبط بـRAN يمكن أن يبدأ أيضًا تعديلًا من جانب الشبكة. وعادةً ينسق SMF التحديثات المطلوبة بين UE وRAN وUPF.
ما الفرق بين PDU Session Modification وPFCP Session Modification؟
PDU Session Modification هو الإجراء العام في 5GS لتعديل جلسة نشطة وقد يشمل UE وRAN وSMF وPCF ومستوى المستخدم. أما PFCP Session Modification فيحدث تحديدًا عبر واجهة N4 بين SMF وUPF ويغير قواعد فعلية على مستوى المستخدم داخل UPF. ويمكن أن يكون الثاني جزءًا من الأول، لكنهما ليسا الإجراء نفسه.
إذا تم تحديث QER بالفعل، فلماذا لا يزال gNB وUE بحاجة إلى التعديل؟
يتحكم QER في تطبيق QoS داخل UPF، لكن QoS Flow لا يتم تعريفه في UPF وحده. فقد يحتاج UE إلى QoS Rule جديدة أو وصف جديد للتدفق، وقد يحتاج RAN إلى ضبط موارد الراديو المقابلة. لذلك تتطلب بعض تعديلات QoS الحفاظ على الاتساق بين N1 وN2 وN4. ولا يعني تحديث UPF وحده أن إجراء PDU Session Modification الكامل قد انتهى.
هل يستطيع PDU Session Modification إضافة QoS Flow جديد؟
نعم. يمكن لـPDU Session Modification تحديث معلمات QoS Flow قائم، ويمكن في السيناريوهات المناسبة استخدامه أيضًا لإنشاء QoS Flow جديد داخل جلسة PDU نفسها. على سبيل المثال، قد تتطلب خدمة VoNR تقودها التطبيقات تدفق QoS إضافيًا بقيمة 5QI محددة. ويختلف سياق الخدمة في هذا السيناريو عن مجرد تحديث تدفق قائم، لذلك من الأفضل تحليله بصورة منفصلة.
