Network Slicing في 5G وتوجيه NIS2: تأمين شرائح البنية التحتية الحيوية

مستشفى في شمال أوروبا ينشر شريحة 5G URLLC للجراحة عن بُعد. الشريحة مُهيّأة لتأخير أقل من 10 مللي ثانية مع موثوقية 99.999%. على نفس محطة gNB، شريحة eMBB للمستهلكين تتعامل مع بث الفيديو لآلاف المشتركين القريبين. مساء الجمعة، حفل موسيقي في الاستاد المجاور يُغرق شريحة eMBB. التأخير على شريحة الجراحة يقفز إلى 200 مللي ثانية. الجرّاح يُبلغ عن تأخّر. المريض مستقر، لكن الثقة في عزل الشريحة تتحطّم.

لم يكتشف أحد التداخل بين الشرائح حتى شعر به إنسان. لم يُطلق أي إنذار. لم يُتجاوز أي حدّ KPI في نظام OSS. العزل كان موجوداً في التهيئة. لم يكن موجوداً في الطيف الراديوي.

هذه هي المشكلة بالتحديد حيث يتصادم network slicing في 5G مع NIS2: كيف تُثبت أن شبكة افتراضية مخصصة لبنية تحتية حيوية معزولة فعلاً في الظروف الحقيقية؟

ما هو network slicing في 5G فعلياً

تقنية network slicing مُعرّفة في مواصفة 3GPP TS 23.501 (بنية النظام لنظام 5G). تسمح لبنية تحتية مادية واحدة 5G SA (Standalone) باستضافة عدة شبكات افتراضية معزولة منطقياً من طرف إلى طرف، كلٌّ منها مُصمّمة لفئة خدمة محددة.

كل شريحة تُعرّف بمعرّف S-NSSAI (Single Network Slice Selection Assistance Information)، يتكوّن من حقلين:

• SST (Slice/Service Type): قيمة من 8 بتات تُحدّد فئة الخدمة. القيم المعيارية تشمل SST=1 (eMBB)، SST=2 (URLLC)، SST=3 (mMTC). القيم المحددة من المشغّل تتراوح من 128 إلى 255.
• SD (Slice Differentiator): قيمة اختيارية من 24 بتاً تُميّز الشرائح التي تشترك في نفس SST. مثلاً، شريحتا URLLC لعميلين مؤسسيين مختلفين تشتركان في SST=2 لكن بقيم SD مختلفة.

عملية اختيار الشريحة تشمل AMF (Access and Mobility Management Function)، الذي يتلقّى S-NSSAI المطلوب من الطرفية أثناء التسجيل ويوجّهها إلى مثيل الشريحة المناسب. NSSF (Network Slice Selection Function) يُساعد AMF عندما لا يستطيع AMF الحالي توفير S-NSSAI المطلوبة.

على مستوى الشبكة الأساسية، يمكن لكل شريحة امتلاك مثيلات خاصة من SMF (Session Management Function) وUPF (User Plane Function) وقواعد سياسة عبر PCF (Policy Control Function). على مستوى RAN، يعتمد الـ slicing على مُجدول gNB لتخصيص الموارد الراديوية لكل شريحة وفق معاملات SLA المُهيّأة. هنا يتباعد النظري عن العملي.

NIS2 والتزامات البنية التحتية الحيوية

توجيه NIS2 (التوجيه 2022/2555 الصادر عن البرلمان الأوروبي والمجلس، المعتمد في ديسمبر 2022) حلّ محلّ توجيه NIS الأصلي ووسّع نطاق التزامات الأمن السيبراني وصرامتها في الاتحاد الأوروبي بشكل ملحوظ.

مشغّلو الاتصالات مصنّفون بوصفهم كيانات أساسية بموجب NIS2. هذا التصنيف يُفعّل التزامات ملزمة بموجب المادة 21:

• إجراءات أمنية قائمة على المخاطر تغطّي سلسلة التوريد، وإدارة الحوادث، واستمرارية الأعمال، وأمن الشبكة
• الإبلاغ عن الحوادث خلال 24 ساعة (إنذار مبكّر)، 72 ساعة (إخطار كامل)، وشهر واحد (تقرير نهائي) إلى فريق CSIRT المعيّن
• أمن سلسلة التوريد، بما في ذلك التحقق من مكونات وخدمات الأطراف الثالثة
• مسؤولية هيئة الإدارة: مجلس إدارة الكيانات الأساسية يتحمّل مسؤولية مباشرة عن إدارة المخاطر السيبرانية

بالنسبة للمشغّلين الذين ينشرون network slicing في 5G لقطاعات حيوية (الصحة، الطاقة، النقل، الأمن العام)، يعني NIS2 أن عزل الشريحة ليس ميزة أداء. إنه التزام أمني. إذا أمكن تدهور شريحة URLLC لمستشفى بسبب حركة المستهلكين، فقد أخفق المشغّل في تنفيذ إجراءات إدارة مخاطر كافية بموجب المادة 21.

التقاطع مع network slicing مباشر: إذا وعد مشغّل بشريحة URLLC معزولة لعميل بنية تحتية حيوية، فإن NIS2 يتطلب أن يكون العزل قابلاً للإثبات، لا مُفترضاً. ملف تهيئة يُظهر تعيين S-NSSAI ضروري. الدليل على أن العزل يصمد تحت الازدحام والتنقل وظروف التداخل هو ما سيبحث عنه مدققو NIS2.

أين يفشل عزل الشرائح عملياً

بنية 3GPP لـ network slicing مُعرّفة جيداً على مستوى الشبكة الأساسية. مثيلات مخصصة من SMF وUPF لكل شريحة توفّر فصلاً حقيقياً للبيانات فوق واجهة N3. المشكلة تقع على مستوى RAN، حيث الموارد الراديوية المادية مشتركة.

مشاركة الموارد الراديوية

محطة gNB تخدم عدة شرائح على نفس الطيف. مُجدول MAC مسؤول عن تخصيص PRBs (Physical Resource Blocks) للطرفيات وفق SLA شريحتها. لكن السعة الراديوية الإجمالية محدودة. عندما تستهلك شريحة eMBB نسبة 90% من PRBs المتاحة أثناء ذروة حركة المرور، قد لا تحصل شريحة URLLC على الحد الأدنى المضمون، حسب تنفيذ المُجدول وتهيئة RRM (Radio Resource Management) للمشغّل.

مواصفة 3GPP TS 28.541 تُعرّف نموذج إدارة الشبكات الفرعية للشرائح. المعاملات maxNumberOfUEs وresourceAllocationStrategy قابلة للتهيئة لكل شريحة. لكن التطبيق يعتمد على تنفيذ المُجدول من المُصنّع، ولا توجد منهجية اختبار معيارية للتحقق من الامتثال تحت الحمل.

ثغرات تطبيق QoS

كل جلسة PDU داخل شريحة مرتبطة بتدفقات QoS، مُعرّفة بـ QFI (QoS Flow Identifier). معرّف 5QI (5G QoS Identifier) يُطابق خصائص معيارية: ميزانية تأخير الحزمة، معدّل خطأ الحزمة، وأولوية الجدولة. حركة URLLC عادةً تستخدم 5QI=82 (GBR حرج التأخير، ميزانية 10 مللي ثانية) أو 5QI=83 (10 مللي ثانية، موثوقية أعلى).

عملياً، سلسلة تطبيق QoS تحتوي نقاط فشل متعددة: UPF قد يُعلّم الحزم بشكل صحيح، لكن مُجدول gNB قد لا يحترم الأولوية تحت الازدحام. RAN قد يحترم الأولوية لتدفق GBR لكن يسمح لتدفقات non-GBR من نفس الشريحة بالتنافس مع تدفقات GBR من شريحة أخرى.

تسرّب الإشارات بين الشرائح

رسائل RRC وNAS ليست بطبيعتها مدركة للشرائح في نقلها. طرفية مسجّلة على عدة شرائح تتلقى رسائل RRC Reconfiguration قد تُشير إلى موارد عبر الشرائح. إذا لم يفصل gNB بشكل صحيح تقارير القياس ومعاملات إعادة اختيار الخلية لكل شريحة، قد تُوجّه طرفية على شريحة URLLC إلى قياسات مُحسّنة لشريحة eMBB، مما يُدهور التأخير.

متطلبات كل نوع شريحة: ما تفرضه الأرقام

كل نوع شريحة له أهداف أداء مُحدّدة كمّياً تُعرّف ما إذا كانت الشريحة تعمل وفق المواصفات. هذه الأهداف مصدرها 3GPP TS 22.261 (متطلبات الخدمة لنظام 5G) وITU-R M.2410.

الفجوة بين هدف URLLC البالغ 1 مللي ثانية / 99.999% وهدف eMBB البالغ 4 مللي ثانية / 99.9% ليست هامشية. إنها رتبتان من الحجم فرقاً في الموثوقية. إثبات أن شريحة URLLC تحقق هدفها مع التعايش مع حركة eMBB على نفس gNB يتطلب قياسات تحت الازدحام، لا في ظروف الراحة فقط.

منهجية التحقق الميداني

التحقق من عزل الشرائح ميدانياً يتطلب التقاط وتحليل إشارات Layer 3 على مستوى الطرفية. المنهجية التالية توفّر الأدلة التي يتطلبها الامتثال لـ NIS2.

الخطوة 1: تحليل PDU Session Establishment

عند إنشاء الطرفية لجلسة PDU، تحتوي رسالة NAS (وهي PDU Session Establishment Accept المُعرّفة في 3GPP TS 24.501) على S-NSSAI المُعيّن من الشبكة. قد يختلف هذا عن S-NSSAI المطلوب من الطرفية إذا تجاوز NSSF الشبكة الاختيار.

التقط رسالة Registration Accept وتحقق من أن Allowed NSSAI يتطابق مع تهيئة الشريحة المتوقعة. ثم التقط PDU Session Establishment Accept وتحقق من S-NSSAI المُعيّن وقواعد QoS (بما في ذلك 5QI وARP وقيم GBR/MBR).

الخطوة 2: التحقق من تدفقات QoS تحت الحمل

مع جلسة PDU نشطة على الشريحة المستهدفة، أنشئ حركة مرور تُشبع شريحة eMBB على نفس الخلية. راقب شريحة URLLC لاكتشاف تدهور التأخير وزيادة التذبذب وفقدان الحزم. ستكشف إشارات L3 ما إذا كان gNB يُرسل رسائل RRC Reconfiguration تُعدّل معاملات جدولة طرفية URLLC استجابةً لازدحام eMBB.

الخطوة 3: التنقل مع استمرارية الشريحة

نفّذ عمليات تسليم (handover) داخل التردد وبين الترددات بينما الطرفية نشطة على شريحة محددة. تحقق من أن الخلية الهدف تحافظ على نفس تعيين S-NSSAI بعد التسليم. رسالة RRC Reconfiguration أثناء التسليم يجب أن تحمل معلومات الشريحة، وتعديل جلسة PDU اللاحق (إن وُجد) يجب أن يحافظ على معاملات QoS.

الخطوة 4: كشف التداخل بين الشرائح

استخدم إعداد dual-SIM أو متعدد الطرفيات لقياس الأداء في وقت واحد على شريحتين مختلفتين تخدمهما نفس الخلية. اربط ذرى التأخير على شريحة URLLC بانفجارات معدّل النقل على شريحة eMBB. التقاطات L3 المتزامنة زمنياً من كلتا الطرفيتين توفّر الدليل على صمود العزل أو عدمه.

الأداة الحاسمة لهذا المسار هي مفكّك شفرات بروتوكول L3 قادر على تحليل رسائل NAS وRRC في الوقت الفعلي، مباشرةً من شريحة الطرفية عبر بروتوكول DIAG من Qualcomm. هذا يوفّر رؤية للإشارات المتبادلة فعلياً بين الطرفية والشبكة، لا العرض المجرّد الذي تقدّمه أنظمة OSS للمُصنّعين.

لاختبارات شبكة 5G على نطاق واسع، تلتقط أدوات الاتصالات المعتمدة على الهاتف الذكي إشارات L3 ومؤشرات RF (مثل RSRP وRSRQ وSS-SINR لكل شعاع) في وقت واحد أثناء اختبارات القيادة، مما يتيح التحقق من الشرائح عبر مناطق تغطية واسعة دون أجهزة مسح مخصصة.

الخاتمة

يُحوّل network slicing في 5G بنيةً تحتية مادية مشتركة إلى شبكات افتراضية مخصصة للقطاعات الحيوية. البنية سليمة. المواصفات شاملة. لكن التهيئة ليست عزلاً، والتحقق المختبري ليس إثباتاً ميدانياً.

غيّر NIS2 مشهد الامتثال. المشغّلون الذين يخدمون كيانات أساسية بشبكات 5G مُقسّمة إلى شرائح يجب أن يُثبتوا الآن أن عزل الشرائح يصمد في الظروف الحقيقية: الازدحام، والتنقل، والتداخل، والتكامل متعدد المُصنّعين. التزامات إدارة المخاطر في المادة 21 تنطبق مباشرةً على آليات إدارة الموارد الراديوية وتطبيق QoS التي تُحدّد ما إذا كانت شريحة URLLC تُقدّم فعلاً تأخيراً بمقدار 1 مللي ثانية وموثوقية 99.999% عندما يكون ذلك مهماً.

الدليل يأتي من الميدان. رسائل PDU Session Establishment وتحليل RRC Reconfiguration والربط بين أداء الشرائح توفّر البيانات القابلة للتحقق التي يطلبها مدققو NIS2.

مع تكاثر عمليات نشر 5G SA واعتماد البنية التحتية الحيوية بشكل متزايد على الاتصال المُقسّم إلى شرائح، سؤال واحد يُحدّد موقف امتثال المشغّل: هل يمكنك إثبات أن شرائحك معزولة، أم أنك تفترض ذلك فقط؟