---
service: "Publicasta"
schema_version: "1.0"
article_id: 840
title: "OCUDU 26.10 يجلب شبكات 5G عبر الأقمار الصناعية واختبار توافق أكثر صرامة إلى شبكات RAN المفتوحة"
language: "ar"
default_language: "en"
canonical_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ar"
json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ar"
api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/ocudu_26_10_open_source_ran_satellite_5g?lang=ar"
channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar"
channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles"
search_url: "https://publicasta.com/api/public/v1/search"
documentation_url: "https://publicasta.com/api-docs#reading-publicasta"
openapi_url: "https://publicasta.com/api-docs/openapi.json"
published_at: "2026-10-09T06:42:16+00:00"
updated_at: "2026-10-09T06:42:16+00:00"
translations:
  - language: "ar"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ar"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ar"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ar"
  - language: "de"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=de"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=de"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=de"
  - language: "en"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=en"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=en"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=en"
  - language: "es"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=es"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=es"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=es"
  - language: "fr"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=fr"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=fr"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=fr"
  - language: "pl"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=pl"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=pl"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=pl"
  - language: "ru"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=ru"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=ru"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=ru"
  - language: "zh"
    html_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g?lang=zh"
    markdown_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.md?lang=zh"
    json_url: "https://publicasta.com/open_source_radar/ocudu_26_10_open_source_ran_satellite_5g.json?lang=zh"
---

# OCUDU 26.10 يجلب شبكات 5G عبر الأقمار الصناعية واختبار توافق أكثر صرامة إلى شبكات RAN المفتوحة

> إصدار OCUDU 26.10 يضيف دعم NTN في الإصدار 17، وهوائيات 8T8R، وتحديد الموقع، وتحسينات أمنية، وتنفيذاً أولياً لـ Split 7.2b. لكنه يظل منصة اختبار جادة، لا شبكة تجارية جاهزة للتشغيل.

من السهل إساءة قراءة إصدار OCUDU 26.10. فالعناوين الرئيسية توحي بأنه يقدم إجابة مكتملة دفعة واحدة عن مشكلات اتصالات صعبة: الاتصال عبر الأقمار الصناعية، وMIMO الأعلى رتبة، وإدارة الحزم، وتحديد الموقع، والواجهة الأمامية المفتوحة، والأمن الأقوى. كما ينتقل المشروع من إصدار عام أولي إلى وتيرة متوقعة في أبريل وأكتوبر تحت حوكمة مؤسسة Linux Foundation.

 ![مختبر اتصالات يضم معدات راديوية لشبكات الجيل الخامس وتجهيزاً لاختبار وصلة عبر الأقمار الصناعية، يعبّر عن قابلية التشغيل البيني لشبكات Open RAN](https://publicasta.com/storage/projects/10/pages/840/2026/10/3f4611c8-f80d-4020-abfe-d61d78e98a2f.webp)

 هذا يجعل الإصدار مهماً، لكنه لا يجعله بديلاً فورياً قابلاً للتشغيل والتوصيل عن شبكة وصول لاسلكي تجارية. الأفضل فهم OCUDU 26.10 بوصفه تنفيذاً عاماً جاداً لمكدس 5G CU/DU، مع قدرات جديدة تكفي لتبرير تجارب يجريها باحثو الاتصالات وبناة الشبكات الخاصة ومطورو المعدات. ولا يقدم دليلاً على اختفاء الأجزاء الصعبة من قابلية التشغيل البيني في Open RAN.

 لذلك فإن السؤال المفيد أضيق من السؤال عما إذا كان OCUDU جاهزاً للإنتاج: ما الأجزاء التي يستطيع فريق مجهز تقنياً اختبارها الآن، وما افتراضات العتاد والتوقيت الكامنة وراءها، وما الميزات التي لا تزال تحتاج إلى تحقق مستقل من طرف إلى طرف؟

 ## ما الذي تغير في OCUDU 26.10

 تسرد [ملاحظات الإصدار الرسمية](https://docs.ocudu.org/releases/release_notes/) مجموعة واسعة من الإضافات. وأكثرها تأثيراً هو دعم الإصدار 17 للشبكات غير الأرضية، أو NTN. ويضيف الإصدار نفسه دعماً أساسياً لـ O-RAN Split 7.2b في تنفيذ Open Fronthaul، ودعماً لهوائيات 8T8R، وإدارة الحزم في الإصدارين 15 و16 ضمن FR1 وFR2، وتحديد الموقع القائم على الزاوية، وإشارات مرجعية لتحديد الموقع في الوصلة الهابطة، والنفاذ العشوائي ذي الخطوتين، والجدولة المسبقة في الوصلة الصاعدة، والمنح المهيأة، وتجميع TTI، وتكرار PUCCH، ودعم DTLS.

 وتجمع [إعلان Linux Foundation](https://www.linuxfoundation.org/press/ocudu-ecosystem-foundation-announces-ocudu-26.10-and-invites-developers-to-the-ocudu-ecosystem-developer-summit-october-20-22-near-washington-dc-to-learn-m-1791460743158) هذه التغييرات في ثلاثة محاور عملية: خيارات نشر أكثر، وأداء لاسلكي أفضل وزمن تأخير أقل، ووظائف إضافية لتحديد الموقع والأمن. هذا وصف منصف، لكن الملاحظات التفصيلية أهم من الملخص لأنها تكشف درجة نضج كل ميزة.

 تُوسم عدة بنود صراحة بأنها دعم أساسي أو بأنها لم تُختبر بعد مع O-RU. وهذه الصياغة ليست هامشاً. ففي شبكة RAN موزعة، يمكن لميزة أن تُبنى بنجاح، وتجتاز اختبارات الوحدة، ثم تفشل عند اتصالها بوحدة لاسلكية معينة أو مصدر توقيت أو ملف ضغط أو شبكة نقل أو تنفيذ للإدارة. وعندما تقول ملاحظة إصدار إن وظيفة ما لم تُختبر من طرف إلى طرف، فهي تحدد نقطة بداية للمقيّم، ولا تعد بأن العمل اكتمل.

 يصف OCUDU نفسه بأنه مشروع gNB مفتوح المصدر وكامل لشبكات 5G، يغطي مستوى التحكم في الوحدة المركزية، ومستوى المستخدم في الوحدة المركزية، والوحدة الموزعة. وتقول [الوثائق الرسمية](https://docs.ocudu.org/) إنه يستهدف النشر التجاري والبحث، ويعمل على عتاد x86 وARM عام الغرض، ويتبع مواصفات 3GPP وO-RAN، ومرخص بموجب رخصة BSD ثلاثية البنود. ويُستضاف المستودع على GitHub بوصفه نسخة مرآة، بينما تجري المساهمات في [مستودع المشروع على GitLab](https://gitlab.com/ocudu/ocudu).

 وتهم هذه البنية لأن OCUDU ليس مجرد عارض لبروتوكول. تكمن قيمته عند الحد الفاصل بين المعايير، والأنظمة ذات الزمن الحقيقي، وعتاد الترددات الراديوية، وأدوات النشر. وكلما كشف المشروع جزءاً أكبر من هذا الحد في كود عام، أصبح أكثر فائدة لمن يحتاج إلى فحص شبكة RAN أو تعديلها أو التحقق منها، بدلاً من استهلاكها كجهاز مغلق.

 ## لماذا يحظى NTN في الإصدار 17 بكل هذا الاهتمام

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

 كان OCUDU قد وثّق دعم NTN للأقمار في المدار GEO في مواد سابقة. وتوسع محطة 26.10 نطاق المشروع المعلن إلى NTN في الإصدار 17، كما تصف الدروس التعليمية وضع NTN باستخدام معلومات المدار الفلكي SIB19 ودعم التوقيت لسيناريوهات GEO وLEO. لذلك فإن [درس NTN](https://docs.ocudu.org/tutorials/) أكثر فائدة للمختبر المحتمل من العنوان وحده؛ فهو يشير إلى إعداد اختبار يتطلب معدات UE مناسبة وبيئة لاسلكية مضبوطة بعناية.

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

 لكن الكود المفتوح لا يلغي القيود الفيزيائية. يستطيع المطور اختبار جزء من البرمجيات بالمحاكاة أو عبر مسار لاسلكي افتراضي، إلا أن التقييم الواقعي يحتاج إلى UE، أو واجهة تردد لاسلكي أو مُحاكٍ، وتوقيت مناسب، ونواة 5G، ومسار نقل يعيد إنتاج الظروف المقصودة. وتذكر وثائق المشروع معدات Amarisoft لبعض دروس NTN. وهذا تذكير بأن العرض الأكثر إثارة قد يظل معتمداً على مكونات متخصصة أو مملوكة تحيط بالبرمجيات المفتوحة.

 وهناك حد آخر. فدعم ميزة معيارية لا يعني دعم كل مدار فضائي، أو ترتيب طيفي، أو فئة طرفية، أو نمط تنقل يغطيه ذلك المعيار. وNTN في الإصدار 17 مجال تقني واسع. والتفسير المسؤول لـ OCUDU 26.10 هو أنه يوفر سطح تنفيذ عام للعمل على NTN، لا أنه حل شبكات 5G الفضائية بوصفها فئة منتجات.

 ## ما الذي تغيره 8T8R وإدارة الحزم

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

 يوضح طلب الدمج العام الخاص بالميزة أن التنفيذ يسمح بثمانية منافذ، مع إبقاء الحد الأقصى لعدد الطبقات لكل كلمة ترميز عند أربع طبقات في المرحلة الموصوفة. كما يشير إلى إعداد CSI، والترميز المسبق في الوصلة الهابطة، وإعداد PDSCH، وحجم مخزن HARQ، ومعالجة حمولة PUCCH. وهذه التفاصيل مهمة لأنها توضح أن ميزة عدد الهوائيات ليست مفتاحاً واحداً؛ فهي تمس افتراضات المجدول، والتغذية الراجعة، والمخازن، وإشارات التحكم، والواجهة اللاسلكية.

 ويتضمن OCUDU 26.10 أيضاً دعماً أساسياً لتقارير وتغذية CSI باستخدام Type-II codebook، وإدارة الحزم في الإصدارين 15 و16 ضمن FR1 وFR2. وإدارة الحزم هي مجموعة الإجراءات المستخدمة لاكتشاف الحزم المناسبة وقياسها واختيارها والحفاظ عليها. وفي نظام حقيقي يشمل ذلك إشارات التحكم، والإشارات المرجعية، والقياسات، والتنقل، والتنسيق بين الوحدة الموزعة والوحدة اللاسلكية. ووجود مسار كود يدعم الإجراء ضروري، لكن فائدته تعتمد على عمل السلسلة الكاملة بصورة صحيحة مع تغير ظروف القناة.

 ولهذا السبب يستحق المعلم الزمني للمشروع القراءة إلى جانب ملاحظات الإصدار. ويسجل [المعلم v26.10](https://gitlab.com/ocudu/ocudu/-/milestones/2) أعمال الميزات بصيغة هندسية أكثر: Open Fronthaul من الفئة B، وType-II CSI، و8T8R، وإدارة الحزم، وتحديد الموقع القائم على الزاوية، وإشارات تحديد الموقع في الوصلة الهابطة، والنفاذ العشوائي ذي الخطوتين، والجدولة في الوصلة الصاعدة، والمنح المهيأة، وتجميع TTI، وتكرار PUCCH، وDTLS، وNTN في الإصدار 17. كما يوفر مساراً مرئياً للمشكلات وطلبات الدمج بدلاً من تقديم قائمة الميزات كسطح منتج مكتمل.

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

 ## إن Split 7.2b مفيد تحديداً لأنه لم يصبح مملاً بعد

 غالباً ما تستخدم نقاشات Open RAN قابلية التشغيل البيني اختصاراً لوعد مفاده أن وحدة موزعة من مورّد يمكنها العمل مع وحدة لاسلكية من مورّد آخر. وتعد واجهة النقل الأمامية المفتوحة مركزية لهذا الوعد. ففي التقسيم الوظيفي 7.2x تُفصل أجزاء من معالجة الطبقة الفيزيائية بين O-DU وO-RU، بينما تعبر عينات الراديو ومعلومات التحكم شبكة النقل الأمامية. ويمكن لذلك أن ينشئ منظومة مورّدين أوسع، لكنه يجعل التوقيت، ونقل الحزم، والضغط، والتزامن، وتوافق الملفات، مسائل تشغيلية.

 تنشر [O-RAN Alliance](https://www.o-ran.org/specifications) مواصفات للواجهات والوظائف التي تستهدف شبكات وصول لاسلكي مفتوحة وذكية وقابلة للتشغيل البيني. والتمييز بين المواصفة وبين دمج متعدد المورّدين يعمل فعلاً مهم. فالمواصفة تحدد العقد؛ لكن التنفيذات لا تزال بحاجة إلى الاتفاق على الملفات، والميزات الاختيارية، وسلوك الإدارة، والتزامن، وحدود الأداء، وتغطية الاختبارات.

 يضيف OCUDU 26.10 دعماً أساسياً لـ Split 7.2b. وتقول ملاحظات الإصدار الرسمية تحديداً إنه لم يُختبر بعد مع O-RU. وينبغي أن تحدد هذه الجملة وحدها طريقة تقييم الميزة. فهي ذات قيمة للمطورين الذين يحتاجون إلى فحص الواجهة أو توسيعها، لكنها ليست سبباً لافتراض أن أي وحدة راديو 7.2b ستتصل بنجاح.

 وللفرق بين 7.2a و7.2b آثار عملية أيضاً. فموضع وظائف مثل الترميز المسبق يؤثر في ما يجب أن تعرفه O-DU وO-RU، وفي كمية المعلومات التي تعبر النقل الأمامي، وفي طريقة مشاركة الوحدة اللاسلكية في تشكيل الحزم. وغالباً ما تفصل المواد التقنية العامة حول 7.2x بين الفئة A والفئة B وفق موضع الترميز المسبق. لذلك ينبغي لفريق ينتقل من إعداد 7.2a إلى 7.2b أن يتوقع أكثر من تعديل ملف إعداد؛ إذ عليه التحقق من الملفات المدعومة، والضغط، ورسائل مستوى التحكم، والتوقيت، وسلوك الوحدة اللاسلكية.

 وتشير وثائق المشروع الحالية إلى الاتجاه نفسه. فالمواد العامة لـ OCUDU تسرد Split 7.2a عبر مكتبة Open Fronthaul الداخلية، بينما تصف ملاحظات إصدار 26.10 إضافة 7.2b بوصفها دعماً أساسياً. ويجعل هذا الانتقال الإصدار 26.10 اختبار توافق مفيداً للمنظومة، لكنه يعني أيضاً وجوب تقييم الإصدار باستخدام عتاد مسمى وخطة اختبار قابلة لإعادة الإنتاج.

 يمكن أن تستخدم التجربة الأولى المعقولة وحدة O-RU معروفة، ونطاقاً وعرض نطاق ثابتين، وإعداداً موثقاً للساعة والتزامن، واختبار حركة يمكن تكراره بين البنيات. ينبغي التقاط حزم النقل الأمامي ورسائل التحكم، وتسجيل حمل CPU، وفقدان الحزم، وأخطاء التوقيت، واستقرار التسجيل، ومعدل النقل. وإذا كانت النتيجة فشلاً، فالهدف هو تحديد العقد الذي فشل، لا إعلان صلاحية البنية كلها أو انهيارها.

 ## تحديد الموقع قصة ثانية مخفية في الإصدار

 يضيف OCUDU 26.10 تحديد الموقع القائم على الزاوية وتوليد إشارات مرجعية لتحديد الموقع في الوصلة الهابطة. وتشير هذه القدرات إلى شبكة RAN تستطيع تقديم أكثر من الاتصال. فالقياسات الراديوية قد تدعم تقدير الموقع، والتتبع الصناعي، ومراقبة الأصول، وخدمات الطوارئ، والتطبيقات الواعية بالشبكة. وفي شبكة خاصة، قد يكون تحديد الموقع مفيداً حتى عندما يكون الملاحة عبر الأقمار الصناعية غير متاحة أو غير موثوقة.

 وتستخدم ملاحظات الإصدار لغة حذرة مرة أخرى: توصف ميزات تحديد الموقع بأنها دعم أساسي ولم تُختبر بعد من طرف إلى طرف مع O-RU. وهذه المؤهلة مهمة خصوصاً لتحديد الموقع، لأن المخرج يعتمد على هندسة الهوائيات، والمعايرة، والتزامن، وتعدد المسارات، وجودة القياس، والخوارزميات التي تحول الملاحظات الراديوية إلى تقدير للموقع.

 قد توجد إشارة مرجعية لتحديد الموقع داخل المكدس من دون أن تنتج موقعاً مفيداً في مستودع أو وادٍ عمراني أو قاعة صناعية. لذلك ينبغي للمقيّم فصل ثلاثة أسئلة: هل تستطيع الشبكة إعداد الإشارات المعنية وإرسالها؟ هل يستطيع UE والوحدة اللاسلكية قياسها باستمرار؟ وهل ينتج النظام الكامل مستوى دقة وتوافر مناسباً للتطبيق المقصود؟ يبدو أن OCUDU 26.10 يعالج السؤال الأول ويفتح العمل على السؤالين الثاني والثالث.

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

 ## العمل الأمني أكثر من بند في قائمة

 يتضمن الإصدار دعم DTLS للاتصالات الآمنة، وتحسينات في الأمن والمرونة، وتصريحات في الوثائق حول اختبار أمن O-RAN. كما يذكر إعلان Linux Foundation الاختبار المستمر بالتشويش، والمشاركة في OSS-Fuzz، والتحقق المستقل. وهذه إشارات إيجابية لأن مكدس الشبكة الذي يتعامل مع حركة التحكم، وحركة المستخدم، وواجهات الإدارة، يملك سطح هجوم واسعاً.

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

 ينبغي قراءة [وثائق الأمن والنشر](https://docs.ocudu.org/tutorials/) مع الكود وتقارير الاختبار قبل وضع البرمجيات على شبكة مكشوفة. ويجب أن يجرد التقييم الجاد كل واجهة: اتصالات الشبكة الأساسية، ومسارات F1 أو CU/DU الداخلية، واتصالات E1 بين مكونات CU، وواجهة O-RAN الأمامية، وواجهات الإدارة البرمجية، والمقاييس، وواجهات الحاويات، وأي مسارات أوامر عن بعد. ثم ينبغي اختبار المصادقة، وفشل الشهادات، والرسائل المشوهة، واستنزاف الموارد، وفصل الصلاحيات، والتسجيل.

 إن رخصة BSD-3-Clause المتساهلة جذابة للاستخدام التجاري والبحثي، لكن الترخيص ليس ضماناً تشغيلياً. ويشير المستودع إلى أن أجزاءً منه قد تنفذ مواصفات 3GPP وقد تكون لها متطلبات ترخيص إضافية. وعلى الشركة التي تخطط لشحن منتج إجراء مراجعتها القانونية الخاصة، وتتبع المكونات الخارجية، والحفاظ على إشعارات المشروع. كما عليها فحص الكود الدقيق وحالة اختبار الميزات التي تخطط لتوزيعها، بدلاً من التعامل مع ترخيص المشروع الأعلى مستوى كإجابة امتثال كاملة.

 ## من ينبغي له تجربة OCUDU 26.10

 الجمهور الأقوى هو فريق يستطيع بالفعل بناء بيئة اختبار 5G قائمة على Linux وتشغيلها. ويتطلب [دليل تثبيت OCUDU](https://docs.ocudu.org/user_manual/installation/) نظام تشغيل قائماً على Linux مع دعم نواة الزمن الحقيقي. ويستخدم البناء CMake وC++17، مع اعتماديات تشمل SCTP وyaml-cpp وmbedTLS ومكتبة FFT. ويسرد الدليل Ubuntu 22.04 أو أحدث، وFedora، وArch كمسارات تثبيت مدعومة، بينما يعتمد الأداء الفعلي في الزمن الحقيقي على المضيف، ووحدة CPU، وبطاقة الشبكة، وإعداد النواة، وإعداد الراديو.

 يمكن للباحثين العاملين على NTN أو إدارة الحزم أو تحديد الموقع أو النقل الأمامي المفتوح استخدام الإصدار قاعدة عامة للتجارب. وتستطيع فرق الشبكات الخاصة فحص كيفية ملاءمة مكدس CU/DU مع نواة 5G وO-RU ونظام الإدارة. ويمكن لمطوري العتاد استخدام الكود وتاريخ المشكلات للتحقق من افتراضات الواجهات. كما يستطيع الطلاب والمهندسون الذين يتعلمون بنية 5G الاستفادة، شرط أن يتعاملوا مع المشروع كنظام ينبغي فهمه، لا كملف ثنائي يُثبت ثم يُنسى.

 وتغطي دروس المشروع أكثر من عملية بناء بسيطة. فهي تشمل شبكة split 8 كاملة باستخدام srsUE وOpen5GS، واختبارات تنقل UE تجارية جاهزة، وإعداد NTN، ودمج Near-RT RIC، وDPDK، وتسريع العتاد، وصور الحاويات، والنشر على Kubernetes، وضبط الأداء. وهذا النطاق مفيد لأنه يربط البرمجيات بالمنظومة المحيطة. لكنه يكشف أيضاً تكلفة التقييم الواقعي: فبعض الدروس تتطلب USRP، أو بطاقة شبكة قادرة على DPDK، أو مسرّعاً، أو معدات توقيت، أو O-RU متوافقاً، أو UE تجارياً.

 ويكون OCUDU خياراً أضعف لفريق يريد منتج 5G خاصاً جاهزاً، مع دعم مورّد، وتركيبات عتاد معتمدة، ومستوى إدارة جاهز للتشغيل، وهدف أداء تعاقدي. قد يصبح جزءاً من منتج كهذا، لكن عبء الدمج والتحقق لا يختفي لأن المصدر مفتوح. بل إن القدرة على تغيير الكود تنشئ مسؤولية إضافية: الحفاظ على مجموعة الرقع، وتتبع تغييرات المنبع، وإعادة إنتاج البنيات، وتحديد نتائج الاختبار الكافية لمستوى مخاطر النشر.

 ## خطة تقييم عملية

 ابدأ باختيار سؤال واحد. فاختبار كل شيء في 26.10 مرة واحدة سينتج كمية كبيرة من الضجيج. وينبغي لمختبر يهتم بالوصلات الفضائية أن يبدأ بدرس NTN وسيناريو توقيت ومدار محدد. أما الفريق الذي يقيم قابلية التشغيل البيني مع وحدة راديو، فعليه البدء بوحدة O-RU واحدة وSplit 7.2b، لا بمجموعة أجهزة غير متحقق منها. وعلى باحث تحديد الموقع أن يتحقق أولاً من توليد الإشارة والقياس قبل أن يعد بدقة على مستوى التطبيق.

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

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

 وبالنسبة إلى Split 7.2b، التقط قياسات وظيفية وتشغيلية معاً. تأكد من اتفاق O-DU وO-RU على الملفات والضغط. افحص التزامن قبل تفسير معدل النقل. قِس معدلات الحزم، والزمن، والتذبذب، والفقد، والهامش المتبقي من CPU. كرر الاختبار بعد إعادة التشغيل وتحت إعاقة مضبوطة. فالواجهة التي تعمل مرة واحدة على منضدة نظيفة ليست بعدُ عملية نشر قابلة للتشغيل البيني.

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

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

 ## البدائل ونقاط المقارنة

 OCUDU ليس الطريق المفتوح المصدر الوحيد إلى تجربة 5G RAN. فلا يزال OpenAirInterface مشروعاً مرجعياً مهماً للباحثين والمشغلين الذين يستكشفون Open RAN وأنظمة 5G. ويوفر مشروع srsRAN مساراً آخر مفتوح المصدر لـ CU/DU ومكدس وصول لاسلكي، مع وثائق واسعة ومواد دمج للعتاد. وينبغي أن يتبع الاختيار مجموعة الميزات والعتاد التي يجري اختبارها، لا ترتيباً عاماً.

 وغالباً ما تكون المقارنة المفيدة محددة. أي مشروع يدعم النطاق والتقسيم المستهدفين؟ أي مشروع يملك إعداداً مختبراً مع وحدة O-RU المختارة؟ أي جدولة أو تنفيذ PHY أو دمج E2 يطابق التجربة؟ ما مدى نشاط قائمة المشكلات المعنية؟ هل يستطيع الفريق إعادة إنتاج البناء والحصول على مساعدة عندما يظهر فشل خاص بالعتاد؟ فمصفوفة الميزات أقل قيمة من مسار مختبر ومختبر فعلي عبر المعدات الموجودة في المختبر.

 وتميّز OCUDU محاولته الحالية وضع تنفيذ واسع لـ CU/DU، وحوكمة مفتوحة، وإصدار في أكتوبر، وقدرات أحدث مثل NTN و8T8R، في مشروع عام واحد. وهذا يجعله جديراً بالمراقبة حتى للفرق التي لا تتبناه. فقد توفر خيارات تنفيذه نقطة مقارنة للمكدسات الأخرى، كما قد يكشف عمل الدمج العام مواضع ترك المعايير فيها مساحة للتفسير.

 وليس البديل عن اختبار مكدس مفتوح دائماً منتجاً تجارياً. قد يكون مكوناً أصغر مضبوطاً. إذ يستطيع فريق التحقق من ملف Open Fronthaul، أو مسار إشارة لتحديد الموقع، أو تغيير في المجدول، من دون بناء شبكة بحجم شركة اتصالات. ويفيد OCUDU في هذا الدور لأن المصدر والوثائق وتاريخ المشكلات تسمح بإبقاء التجربة قريبة من التنفيذ.

 ## الدلالة الحقيقية للإصدار

 يهم OCUDU 26.10 لأنه ينقل كود Open RAN إلى مرحلة أكثر تطلباً. فقد أثبت الإصدار العام الأول أن المشروع قادر على نشر أساس واسع ومفتوح لـ CU/DU. أما إصدار أكتوبر فيسأل ما إذا كان ذلك الأساس يستطيع استيعاب توقيت الأقمار الصناعية، وتكوينات الهوائيات الأعلى رتبة، وإجراءات الحزم، وتحديد الموقع، واختبارات الأمن، وملفات النقل الأمامي الإضافية، من دون خسارة عملية تطوير شفافة.

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

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

 لذلك فإن OCUDU 26.10 جاهز للاختبار، وجاهز للتعليم في عدة مجالات. لكن ملاحظات الإصدار نفسها توضح أين لا يزال يحتاج إلى عمل إضافي قبل الوثوق به. وهذا المزيج، أي قدرة عامة كبيرة مع حدود ظاهرة، هو بالضبط ما ينبغي البحث عنه في إصدار بنية تحتية مفتوح المصدر.

 ## المصادر

 اعتمدت هذه المراجعة على ملاحظات إصدار OCUDU 26.10، وإعلان Linux Foundation، ومعلم المشروع v26.10، ووثائق OCUDU وأدلة التثبيت والدروس التعليمية، وطلب دمج دعم 8T8R، ومستودع المصدر، ومواصفات O-RAN، ودليل O-RAN 7.2 RU من مشروع srsRAN. وتبقى كل ميزة موصوفة بأنها دعم أساسي أو غير مختبرة من طرف إلى طرف بحاجة إلى تحقق مستقل قبل استخدامها في نشر إنتاجي.