OCUDU 26.10 — открытый релиз, который легко понять неправильно. Его главные функции звучат как готовый ответ сразу на несколько сложных задач телекоммуникаций: спутниковая связь, MIMO более высокого порядка, управление лучами, позиционирование, открытый fronthaul и усиленная безопасность. Одновременно проект переходит от первой публичной версии к предсказуемому графику выпусков в апреле и октябре под управлением Linux Foundation.

Телекоммуникационная лаборатория с радиооборудованием 5G и тестовой спутниковой линией, иллюстрирующая работу над совместимостью Open RAN

Это делает релиз важным. Но он не превращается от этого в подключаемую замену коммерческой сети радиодоступа. OCUDU 26.10 разумнее рассматривать как серьёзную публичную реализацию стека 5G CU/DU, в которой достаточно новых возможностей для экспериментов телекоммуникационных исследователей, создателей частных сетей и разработчиков оборудования. Это не доказательство того, что сложные проблемы совместимости Open RAN исчезли.

Поэтому полезный вопрос уже не сводится к тому, готов ли OCUDU к промышленной эксплуатации. Важно понять, какие части релиза технически подготовленная команда может проверить уже сейчас, какие аппаратные средства и допущения по синхронизации лежат под ними и какие функции всё ещё требуют независимой сквозной валидации.

Что изменилось в OCUDU 26.10

В официальных примечаниях к релизу перечислен широкий набор дополнений. Самое заметное — поддержка Release 17 для сетей, не связанных с наземной инфраструктурой, то есть NTN. В тот же релиз вошли базовая поддержка O-RAN Split 7.2b в реализации Open Fronthaul, поддержка антенн 8T8R, управление лучами Release 15 и 16 для FR1 и FR2, позиционирование по углу, опорные сигналы позиционирования в нисходящем канале, двухэтапный случайный доступ, предварительное планирование восходящей линии, сконфигурированные гранты, объединение TTI, повторение PUCCH и поддержка DTLS.

В анонсе Linux Foundation эти изменения собраны вокруг трёх практических тем: больше вариантов развёртывания, лучшая производительность радио и меньшая задержка, а также дополнительные функции позиционирования и безопасности. Это справедливое резюме, однако подробные примечания важнее краткого анонса: в них видна степень зрелости каждой функции.

В нескольких пунктах прямо сказано, что речь идёт о базовой поддержке либо что функция ещё не тестировалась с O-RU. Это не мелкий комментарий внизу страницы. В распределённой сети радиодоступа функция может собираться, проходить модульные тесты и всё равно ломаться при встрече с конкретным радиоблоком, источником синхронизации, профилем сжатия, транспортной сетью или системой управления. Если в примечаниях сказано, что функция не проверена сквозным образом, это указание оценщику, с чего начинать, а не обещание законченной работы.

OCUDU называет себя полноценным открытым проектом 5G gNB, охватывающим плоскость управления центрального блока, пользовательскую плоскость центрального блока и распределённый блок. В официальной документации указано, что проект рассчитан на коммерческое развёртывание и исследования, работает на универсальном оборудовании x86 и ARM, следует спецификациям 3GPP и O-RAN и распространяется по лицензии BSD 3-Clause. Репозиторий размещён на GitHub как зеркало, а разработка ведётся в репозитории проекта на GitLab.

Это устройство проекта существенно. OCUDU — не просто демонстратор протоколов. Его ценность находится на границе стандартов, систем реального времени, радиочастотного оборудования и средств развёртывания. Чем больше этой границы открыто в публичном коде, тем полезнее проект для тех, кому нужно исследовать, изменять или проверять сеть радиодоступа, а не пользоваться ею как закрытым устройством.

Почему Release 17 NTN привлекает основное внимание

Неназемные сети расширяют процедуры 5G на соединения со спутниками и другими воздушными платформами. Радиоканал больше не является коротким и относительно стабильным наземным путём между телефоном и ближайшей базовой станцией. В конструкцию системы входят задержка распространения, временные параметры, эффект Доплера, движение спутника, геометрия покрытия и расположение шлюзов. Программное обеспечение должно учитывать эти условия и при этом не обращаться со спутниковой ячейкой так, будто это обычная городская макроячейка.

Ранее OCUDU уже описывал поддержку GEO NTN. Веха 26.10 расширяет заявленную область проекта до NTN Release 17, а руководства описывают режим NTN с эфемеридами SIB19 и поддержкой синхронизации для сценариев GEO и LEO. Поэтому руководство по NTN полезнее для потенциального тестировщика, чем один заголовок: оно показывает, что проект рассчитывает на испытательную среду с подходящим пользовательским оборудованием и тщательно контролируемыми радиусловиями.

Здесь релиз становится интересным не только для энтузиастов спутниковой связи. Открытая реализация даёт исследователям возможность проследить, как допущения NTN проходят через конфигурацию, широковещательную информацию, синхронизацию и логику мобильности. Это позволяет проводить эксперименты, которые трудно выполнить с оборудованием поставщика, где детали реализации закрыты. Команда, работающая над устойчивой связью, удалёнными промышленными объектами, морскими каналами или гибридными наземно-спутниковыми сетями, также может использовать открытый CU/DU как точку сравнения архитектур.

Но открытый код не отменяет физических ограничений. Разработчик может проверить часть программного обеспечения с помощью симуляции или виртуального радиоканала, однако реалистичная оценка требует UE, радиочастотного тракта или эмулятора, подходящей синхронизации, ядра 5G и транспортного пути, воспроизводящего нужные условия. В документации проекта для некоторых учебных сценариев NTN указано оборудование Amarisoft. Это напоминает: даже самая интересная демонстрация может по-прежнему зависеть от специализированных или проприетарных компонентов вокруг открытого программного обеспечения.

Есть и другое ограничение. Поддержка стандартной функции не означает поддержку каждой спутниковой орбиты, схемы использования спектра, категории терминала или модели мобильности, которую охватывает стандарт. NTN Release 17 — большая техническая область. Ответственная трактовка OCUDU 26.10 такова: проект предоставляет публичную поверхность реализации для работы с NTN, но не решил спутниковый 5G как продуктовую категорию.

Что меняют 8T8R и управление лучами

Работа над 8T8R менее заметна для широкого читателя, но может быть важнее для наземных радиоэкспериментов. Конфигурация 8T8R использует восемь передающих и восемь принимающих антенных трактов. Большее число антенных портов может дать дополнительный контроль над прекодированием и диаграммами направленности, однако результат зависит от радиоблока, калибровки, условий канала, кодовых книг, вычислительной мощности и фактического числа используемых пространственных уровней. Восемь портов автоматически не означают восемь независимых потоков данных.

Публичный merge request проекта описывает реализацию так: она допускает восемь портов, но на описанном этапе ограничивает максимальное число уровней на кодовое слово четырьмя. Там же отдельно упоминаются конфигурация CSI, нисходящее прекодирование, настройка PDSCH, размер буферов HARQ и обработка полезной нагрузки PUCCH. Эти детали важны: функция, связанная с числом антенн, не является одним переключателем. Она затрагивает допущения планировщика, обратную связь, буферы, управляющую сигнализацию и радиоинтерфейс.

В OCUDU 26.10 также появились базовая отчётность и обратная связь CSI с кодовой книгой Type-II, а также управление лучами Release 15 и 16 для FR1 и FR2. Управление лучами — это процедуры обнаружения, измерения, выбора и поддержания подходящих лучей. В реальной системе сюда входят управляющая сигнализация, опорные сигналы, измерения, мобильность и взаимодействие между распределённым блоком и радиоблоком. Поддержка процедуры в коде необходима, но её практическая ценность определяется тем, работает ли вся цепочка при изменении радиоканала.

По этой причине веху проекта стоит читать вместе с примечаниями к релизу. Веха v26.10 описывает работу более инженерно: Cat-B 7.2 Open Fronthaul, Type-II CSI, 8T8R, управление лучами, позиционирование по углу, опорные сигналы позиционирования в нисходящей линии, двухэтапный случайный доступ, планирование восходящей линии, сконфигурированные гранты, объединение TTI, повторение PUCCH, DTLS и NTN Release 17. Там видна история задач и merge request, а не только список функций, представленный как готовая поверхность продукта.

Для лаборатории это веская причина попробовать релиз. Код и история задач помогают понять, какая подсистема отвечает за сбой. Для оператора это одновременно напоминание о необходимости явно описать план интеграции. Правильная проверка — не просто выяснить, поднимается ли ячейка. Нужно проверить, дают ли выбранные RU, схема тактирования, полоса канала, нумерология, набор возможностей UE и профиль трафика стабильное поведение под нагрузкой.

Split 7.2b полезен именно потому, что ещё не стал скучной рутиной

В обсуждениях Open RAN совместимость часто означает обещание, что распределённый блок одного поставщика сможет работать с радиоблоком другого. Открытый fronthaul занимает центральное место в этом обещании. При функциональном разделении 7.2x часть обработки физического уровня распределяется между O-DU и O-RU, а радиосэмплы и управляющая информация передаются по сети fronthaul. Это может расширить экосистему поставщиков, но одновременно превращает синхронизацию, пакетную передачу, сжатие, согласование профилей и поддержание времени в эксплуатационные задачи.

Альянс O-RAN публикует спецификации интерфейсов и функций, призванных поддержать открытую, интеллектуальную и совместимую сеть радиодоступа. Различие между спецификацией и работающей многопоставщицкой интеграцией принципиально. Спецификация определяет контракт. Реализациям всё равно нужно согласовать профили, необязательные функции, поведение управления, синхронизацию, пределы производительности и объём тестирования.

OCUDU 26.10 добавляет базовую поддержку Split 7.2b. В официальных примечаниях прямо указано, что она ещё не тестировалась с O-RU. Именно это предложение должно определять оценку функции. Для разработчиков, которым нужно изучить или расширить интерфейс, она ценна. Но оно не даёт оснований считать, что любой радиоблок 7.2b подключится успешно.

Различие между 7.2a и 7.2b имеет и практические последствия. Размещение таких функций, как прекодирование, влияет на то, что должны знать O-DU и O-RU, какой объём информации проходит по fronthaul и как радиоблок участвует в формировании луча. В общедоступных технических материалах по 7.2x категории A и B часто различаются именно по месту прекодирования. Переход от конфигурации 7.2a к 7.2b должен означать больше, чем изменение файла конфигурации. Нужно проверить поддерживаемые профили, сжатие, сообщения плоскости управления, синхронизацию и поведение радиоблока.

Существующая документация проекта указывает в том же направлении. В актуальных публичных материалах OCUDU Split 7.2a связан с собственной библиотекой Open Fronthaul, тогда как в примечаниях к 26.10 7.2b описан как базовое дополнение. Поэтому 26.10 полезен как тест совместимости экосистемы, но оценивать его следует на конкретном оборудовании и по воспроизводимому плану.

Разумный первый эксперимент использует один известный O-RU, фиксированные диапазон и полосу, документированную схему часов и синхронизации, а также повторяемый тест трафика. Нужно захватывать пакеты fronthaul и управляющие сообщения. Стоит записывать загрузку CPU, потери пакетов, ошибки синхронизации, стабильность регистрации и пропускную способность. Если результат отрицательный, цель — найти нарушенный контракт, а не объявить всю архитектуру рабочей или сломанной.

Позиционирование — вторая история, скрытая в релизе

OCUDU 26.10 добавляет позиционирование по углу и генерацию опорных сигналов позиционирования в нисходящем канале. Эти возможности указывают на радиосеть, которая способна предоставлять больше, чем соединение. Радиоизмерения могут использоваться для оценки местоположения, промышленного трекинга, мониторинга активов, экстренных служб и приложений, учитывающих состояние сети. В частной сети позиционирование может оказаться полезным даже при недоступной или ненадёжной спутниковой навигации.

В примечаниях к релизу снова используется осторожная формулировка: функции позиционирования названы базовой поддержкой и ещё не проверены сквозным образом с O-RU. Для позиционирования это особенно важно, потому что результат зависит от геометрии антенн, калибровки, синхронизации, многолучёвости, качества измерений и алгоритмов, которые превращают радионаблюдения в оценку координат.

Опорный сигнал может существовать в стеке и при этом не давать полезного местоположения на складе, в городском каньоне или промышленном цехе. Поэтому оценщику стоит разделить три вопроса. Может ли сеть настроить и передать нужные сигналы? Могут ли UE и радиоблок согласованно измерять их? Даёт ли целая система точность и доступность, подходящие для конкретного применения? OCUDU 26.10, судя по описанию, отвечает на первый вопрос и открывает работу над вторым и третьим.

Это уже имеет значение. Открытые реализации позволяют исследователям изучать пути синхронизации и измерений, сравнивать алгоритмы и строить повторяемые испытательные стенды. Они также облегчают поиск границы между протокольной ошибкой, проблемой калибровки радио и предположением на уровне приложения. Закрытые системы могут выдавать более отполированный результат, но диагностика в них сложнее.

Работа над безопасностью — не пункт в контрольном списке

Релиз включает поддержку DTLS для защищённого обмена, улучшения безопасности и устойчивости, а документация содержит заявления о тестировании безопасности O-RAN. В анонсе Linux Foundation также упоминаются непрерывное фаззинг-тестирование, участие в OSS-Fuzz и независимая валидация. Это хорошие сигналы: сетевой стек, обслуживающий управляющий и пользовательский трафик, а также интерфейсы управления, имеет большую поверхность атаки.

Тем не менее поддержку безопасности следует рассматривать как вопрос процесса и архитектуры, а не как знак качества. DTLS может защищать канал связи, но не определяет, кому разрешено устанавливать этот канал, как выпускаются и меняются ключи, какие конечные точки считаются доверенными, что происходит при истечении сертификатов и как разделяются трафик управления, контроля и пользовательская плоскость. Фаззинг способен обнаружить классы ошибок в парсерах и конечных автоматах, но не доказывает правильность конфигурации развёрнутой системы.

Перед размещением ПО во внешней сети следует читать документацию по безопасности и развёртыванию вместе с исходным кодом и отчётами тестирования проекта. Серьёзная оценка должна включать инвентаризацию каждого интерфейса: соединения с ядром сети, F1 или внутренние пути CU/DU, соединения E1 между компонентами CU, fronthaul O-RAN, API управления, метрики, контейнерные интерфейсы и любые удалённые каналы команд. Затем нужно проверить аутентификацию, отказ сертификатов, некорректные сообщения, исчерпание ресурсов, разделение привилегий и журналирование.

Разрешительная лицензия BSD-3-Clause привлекательна для коммерческого и исследовательского использования, но лицензия не равна эксплуатационной гарантии. В репозитории отмечено, что отдельные части могут реализовывать спецификации 3GPP и иметь дополнительные лицензионные требования. Компания, планирующая выпускать продукт, должна провести собственную юридическую проверку, отслеживать сторонние компоненты и сохранять уведомления проекта. Кроме того, ей следует изучить точный код и статус тестирования функций, которые она собирается распространять, а не считать верхнеуровневую лицензию исчерпывающим ответом по соответствию требованиям.

Кому стоит попробовать OCUDU 26.10

Основная аудитория — команда, которая уже умеет собирать и эксплуатировать среду тестирования 5G на Linux. В руководстве по установке OCUDU требуется операционная система на базе Linux с поддержкой ядра реального времени. Сборка использует CMake и C++17; среди зависимостей указаны SCTP, yaml-cpp, mbedTLS и библиотека FFT. В руководстве Ubuntu 22.04 или более поздняя версия, Fedora и Arch перечислены как поддерживаемые варианты установки, однако фактическая производительность реального времени зависит от хоста, CPU, сетевой карты, конфигурации ядра и радиосхемы.

Исследователи, работающие с NTN, управлением лучами, позиционированием или открытым fronthaul, могут использовать релиз как публичную основу экспериментов. Команды частных сетей могут изучать взаимодействие стека CU/DU с ядром 5G, O-RU и системой управления. Разработчики оборудования — проверять предположения об интерфейсах по коду и истории задач. Студенты и инженеры, изучающие архитектуру 5G, тоже получат пользу, если будут воспринимать проект как систему для понимания, а не как бинарный файл, который достаточно установить один раз.

Учебные материалы проекта охватывают больше, чем простую сборку. В них есть полностью разделённая сеть 8 с srsUE и Open5GS, тесты handover с коммерческими UE, настройка NTN, интеграция Near-RT RIC, DPDK, аппаратное ускорение, контейнерные образы, развёртывание в Kubernetes и настройка производительности. Такой диапазон полезен, потому что показывает связь ПО с окружающей экосистемой. Он одновременно демонстрирует цену реалистичной оценки: для некоторых руководств нужны USRP, сетевая карта с поддержкой DPDK, ускоритель, оборудование синхронизации, совместимый O-RU или коммерческий UE.

OCUDU хуже подходит команде, которой нужен готовый частный продукт 5G с поддержкой поставщика, сертифицированными сочетаниями оборудования, настроенной плоскостью управления и контрактной целью по производительности. Проект может стать частью такого продукта, но интеграционная и проверочная нагрузка не исчезает из-за открытости исходного кода. Более того, возможность менять код создаёт дополнительную ответственность: поддерживать набор патчей, отслеживать изменения upstream, воспроизводить сборки и решать, какие результаты тестирования достаточны с учётом рисков конкретного развёртывания.

Практический план оценки

Начните с одного вопроса. Проверка всех возможностей 26.10 одновременно даст впечатляющий объём шума. Лаборатории, интересующейся спутниковыми каналами, стоит начать с руководства по NTN и определённого сценария синхронизации и эфемерид. Команде, оценивающей совместимость с радиоблоком, лучше взять один O-RU и Split 7.2b, а не набор непроверенных устройств. Исследователю позиционирования сначала нужно подтвердить генерацию и измерение сигналов, а уже потом обещать точность на уровне приложения.

Зафиксируйте точную ревизию исходного кода и запишите компилятор, ядро, CPU, сетевую карту, FPGA или ускоритель, радиочастотный тракт, UE, ядро сети и конфигурацию. Сохраняйте логи сборки и конфигурационные файлы вместе с результатом. Открытые телекоммуникационные системы необычно чувствительны к деталям среды; результат, который нельзя воспроизвести, трудно интерпретировать, даже если исходный код доступен.

Затем разделите оценку на уровни. Сначала запустите программные тесты и статические проверки. Потом добейтесь стабильной регистрации и пользовательской сессии в самой простой поддерживаемой конфигурации. На третьем этапе добавьте выбранную функцию. После этого вводите нагрузку, мобильность, изменения синхронизации или второй компонент другого поставщика. Такой порядок помогает отличить проблему базовой системы от проблемы функции и от многопоставщицкой проблемы.

Для Split 7.2b собирайте и функциональные, и эксплуатационные измерения. Убедитесь, что O-DU и O-RU согласовали профили и сжатие. Проверьте синхронизацию до того, как начнёте трактовать пропускную способность. Измеряйте скорость пакетов, задержку, джиттер, потери и запас CPU. Повторите тест после перезапуска и при контролируемом ухудшении условий. Интерфейс, который один раз заработал на чистом стенде, ещё не является совместимым развёртыванием.

Для NTN проверяйте допущения по времени и мобильности отдельно от прикладного трафика. Сравнивайте ожидаемое и наблюдаемое поведение при изменении задержки и геометрии. Документируйте, что симулируется, что эмулируется, а что проходит через реальное радио или спутниковое оборудование. Это различие станет важным, когда кто-то позднее сошлётся на результат как на свидетельство готовности к эксплуатации.

Для безопасности создайте модель угроз до включения удалённого доступа. Используйте сегментацию сети, минимальные привилегии, защищённые учётные данные и подписанные либо проверенные артефакты, если они доступны. Считайте контейнерные образы, вспомогательные инструменты, конечные точки управления и системы мониторинга частью доверенной вычислительной базы. Изучайте отчёты безопасности и трекер задач проекта, но не передавайте upstream-разработчикам окончательную оценку риска.

Альтернативы и точки сравнения

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. Октябрьская версия ставит другой вопрос: сможет ли эта основа вместить спутниковую синхронизацию, более сложные антенные конфигурации, процедуры управления лучами, позиционирование, тестирование безопасности и дополнительные профили fronthaul, сохранив прозрачный процесс разработки.

Это более содержательная история, чем утверждение, будто открытый код уже заменил устоявшуюся телекоммуникационную инфраструктуру. Open RAN всё ещё должен заслужить доверие испытаниями совместимости, измерениями производительности, проверкой безопасности, эксплуатационными инструментами и долгосрочным сопровождением. Разрешительная лицензия помогает большему числу людей изучать и развивать ПО, но не предоставляет калибровку радио, разрешение на использование спектра, синхронизацию, договор поддержки или промышленную валидацию.

Разработчикам сейчас стоит выбрать одну функцию 26.10 и воспроизвести документированный путь проекта до внесения изменений. Исследователям релиз даёт более богатую основу для экспериментов с NTN, позиционированием и распределённой обработкой радиосигналов. Операторам и производителям оборудования следующим шагом нужна проверка совместимости на конкретном оборудовании с сохранёнными доказательствами, а не широкое решение о закупке.

Итак, OCUDU 26.10 уже готов для испытаний и в нескольких областях — для обучения. Собственные примечания к релизу ясно показывают, где ему пока нельзя доверять без дополнительной работы. Такое сочетание — существенные публичные возможности и видимые ограничения — именно это стоит искать в новом инфраструктурном релизе с открытым исходным кодом.

Источники

Основные утверждения и технический контекст в статье связаны с официальными материалами Linux Foundation, документацией OCUDU, вехой OCUDU v26.10, merge request по поддержке антенн 8T8R, зеркалом исходного кода, спецификациями O-RAN Alliance и руководством srsRAN по O-RAN 7.2 RU. Ссылки на эти материалы приведены непосредственно в соответствующих разделах; отдельный список источников намеренно не дублирует их.