Как устроена архитектура ПО базовой станции Huawei

Представьте, что в одной коробке высотой 2U нужно одновременно запустить четыре поколения мобильной связи — 2G, 3G, 4G и 5G, — да так, чтобы они делили между собой процессор, транспорт, радио и антенну, и не роняли друг друга при огромной нагрузке, поддерживали зоопарк из разных плат и плюсом поколений этих плат. Примерно это и есть базовая станция Huawei серии 3900/5900.

Снаружи это модульный «конструктор» из шасси и плат. Внутри — многоуровневая программная платформа на ARM-процессоре, которая абстрагирует железо и раздаёт его «сервисам» разных стандартов связи.

Проблематика, с которой сталкиваются и решают разработчики:

1. Операционная система может изменятся (VxWorks → Linux).

2. Версия и API ядра Linux изменяются.

3. Архитектура процессора может изменятся (ARM → RISC‑V).

4. Большая вариативность типов baseband плат.

5. Большая вариативность типов сервисных плат.

6. Большая вариативность типов радиоблоков и их архитектуры (TDD/FDD/количество RX/TX).

7. Разные поколения плат построены на разных процессорах, FPGA, ASICах, DSP и несут разную периферию.

8. Рост числа стандартов связи 2G → 3G → 4G → 5G и все на одной коробке.

9. Рост числа фич.

10. Смена поколения шасси BBU3900 → BBU5900.

Ниже — обзор архитектуры: как платформа отделена от приложений, на какой ОС всё работает, как собирается кластер из плат, как устроено управление, логирование и обновление ПО. И как решают выше названные проблемы на уровне архитектуры.  

Небольшой дисклеймер

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

1. Открытую техническую документацию Huawei на серию 3900 & 5900 (Technical Description, Configuration Principles, Component Description).

2. Реверс‑инжиниринг образов прошивок плат.

Так что могут в статье могут иметься некоторые неточности, но дизассемблер редко ошибается,а художник так видит.

 

 

Немного о железо: BBU, платы и радио

Чтобы говорить про ПО, сначала посмотрим на железо — архитектура софта ложится прямо на него.

Базовая станция физически состоит из трёх вещей:

BBU (Baseband Unit) это шасси – «мозг» цифровой обработки. В серии это BBU3900, BBU3910 и новый BBU5900. Внутри шасси — слоты, в которые вставляются платы.

RF-модули — радиочасть, бывают двух видов: RRU (выносной радиоблок) или AAU (активная антенная система для 5G Massive MIMO).

Шкафы, питание, обвязка — нам сейчас не очень интересное.

Внутри BBU живут платы нескольких типов, и именно их разделение задаёт архитектуру ПО, для примера возьмем самую простую конфигурацию:

 

Ключевая деталь: главная плата UMPT совмещает управление и транспорт (буква T — Transmission), а тяжёлая математика радиоканала вынесена на отдельные платы UBBP. Между BBU и радиочастью всё общается по оптике CPRI — поддержаны топологии «звезда», «цепочка», «кольцо» и «двойная звезда».

Откуда взялась UMPT: LMPT, WMPT, GTMU → UMPT

Буква U в «UMPT» — это Universal, и появилась она не просто так. В первом поколении BBU3900 главная плата была «помодовой»: под каждый стандарт своя — GTMU для GSM, WMPT для UMTS, LMPT для LTE. Каждая несла control-plane, O&M и транспорт только своего стандарта. Хочешь на площадке 2G+3G+4G — ставь три разные главные платы, каждую со своим ПО и каналом управления.

Потом Huawei сделала UMPT — Universal MPT: одну плату, которая умеет хостить GSM, UMTS, LTE и NR, динамически деля между ними ресурсы контроллера. Именно UMPT сделала возможным co-MPT (несколько стандартов на одной плате) и всю виртуализацию ресурсов, о которой пойдёт речь дальше. Семейство росло: UMPTa → UMPTb → UMPTe → UMPTg. Почему росло? —  увеличивали производительность.   

Переезд с «помодовых плат» — это не только про железо, но и про ОС. Платы первого поколения работали на более старых процессорах под VxWorks; UMPT переехала на многоядерный HiSilicon, а на новых чипах — под Linux. Поэтому код, написанный ещё в эпоху «помодовых» плат под VxWorks, продолжает работать на UMPT под Linux — через слой совместимости. В современной версии ПО «помодовых» плат уже почти не осталось: в каталоге плат — GTMU и семейство UMPT.

Физика и логика: BTS Node и «сервисы»

Самая важная абстракция во всей платформе — разделение на физический и логический уровни.

Физический уровень — это «железная» базовая станция, BTS Node: инфраструктура и прикладная платформа.

Логический уровень — это сервисы (Services), которые на этой платформе разворачиваются: GBTS Service (GSM), NodeB Service (UMTS), eNodeB Service (LTE) и gNodeB Service (5G NR).

Иными словами, «базовая станция GSM» и «базовая станция 5G» — это не разные коробки, а разные программные сервисы на одной и той же платформе. Станция становится тем, что на неё установили.

Связываются эти два мира через два чётко описанных интерфейса (и это уже чистая архитектура ПО, а не маркетинг):

Интерфейс «платформа — сервис» — через него платформа управляет жизненным циклом сервиса: развёртывание, апгрейд версии, старт/рестарт, мониторинг состояния. По сути API «оркестратора» над прикладными RAT‑стеками.

Интерфейс «узел — RAT» — через него сервис запрашивает у платформы общие ресурсы: транспортные линки, TX/RX‑каналы радио, процессорное время, несущие ресурсы.

Именно поэтому платформа «скрывает различия ПО и железа от сервисов за счёт абстрагированных ресурсов». Это буквально слой виртуализации ресурсов внутри базовой станции.

Шесть подсистем, из которых собрана станция

Логически станция разбита на шесть подсистем — каждая это отдельный домен ПО со своими драйверами и интерфейсом наружу:

1. CTL (Control) — Управляющая подсистема. Управляет ресурсами станции, даёт management-интерфейс в сторону центра эксплуатации, control-интерфейс в сторону сети и интерфейс согласования общих устройств в многомодовой станции.

2. Транспортная подсистема. Перекладывает данные между транспортной сетью и станцией, даёт физические порты и user-plane интерфейс.

3. Обработка основной полосы. Считает uplink/downlink, физический уровень. Живёт на платах UBBP.

4. Радиочастотная подсистема. Приём/передача радиосигнала, порты к антенне. Соединяются с baseband по CPRI.

5. Тактирование. Синхронизирует часы станции с внешними источниками (GNSS, сеть). Для мобильной связи синхронизация критична, особенно в TDD и 5G.

6. MPE (Power & Environment) — Питание и мониторинг. Питание, температура, мониторинг внешних аварий и датчиков.

Разные стандарты могут делить одну подсистему (например, один клок на всех) или использовать независимые экземпляры — это и есть гибкость, ради которой всё затевалось.

Co-MPT против Separate-MPT: как уживаются 2G/3G/4G/5G

Когда на одной станции нужно запустить несколько стандартов (multi-RAT), есть два способа это сделать.

Separate-MPT: каждому стандарту — свой «компьютер»

В separate-MPT режиме сервис каждого стандарта живёт на отдельном узле со своей управляющей платой и управляется по отдельному каналу O&M. Стандарты всё равно могут делить железо — шкаф, BBU, транспорт, клок, RF-модули, антенну, — но на уровне ПО это независимые платформы. Чтобы они не передрались за общие ресурсы, узлы договариваются между собой через отдельный интерфейс согласования: чем меньше ресурсов общие — тем меньше взаимозависимость.

Co-MPT: всё на одной управляющей плате

В co-MPT режиме сервисы всех стандартов разворачиваются на одном узле и управляются как единое целое: одна плата UMPT, один канал управления, общий пул ресурсов. Исторически это эволюционировало от «GSM и LTE на разных платах» до полного фарша «2G+3G+4G+5G на одной управляющей плате».

За удобство приходится платить связанностью: любая операция над общими ресурсами (смена параметра, сброс, блокировка, апгрейд и откат ПО) затронет все стандарты, которые эти ресурсы делят. Классический trade-off: co-MPT — меньше железа и единое управление, separate-MPT — изоляция отказов. Та же дилемма, что «монолит против микросервисов», только в embedded-мире и с радиоволнами.

Что показывает архитектура прошивки: Linux, Hi1380 и DOPRA

Теперь посмотрим, на чём всё построено. Главная управляющая плата работает на ARM big-endian (BE8) — довольно редкий зверь в наше время; телеком исторически любит big-endian (сетевой порядок байт). И это не bare-metal и не «чистый» VxWorks, а полноценный встраиваемый Linux RT на многоядерном SoC собственной разработки Huawei — HiSilicon Hi1380.

Ключевые элементы стека:

DOPRA — проприетарная сервисная платформа Huawei (Distributed Object‑oriented Programmable Real‑time Architecture). Играет роль «операционной среды» поверх ОС: планирование, обмен сообщениями между модулями, управление состоянием. Вся прикладная логика станции построена как набор акторов, общающихся сообщениями, — архитектурно это ближе к Erlang/акторной модели, чем к привычному многопоточному C++. Хотя написана на C.

ROSA — абстракция реального времени: процессы‑акторы и обмен сообщениями между ними.

VISP — собственный IP‑стек вместо сетевого стека Linux; рядом сосуществует маршрутизирующая платформа Huawei (VRP). В системе уживается несколько реализаций сокетов сразу.

Транспортные драйверы — Ethernet, E1/TDM (легаси для 2G/3G), встроенный L2-коммутатор.

OpenHPI — управление «корзиной» плат (см. раздел про сельф‑менеджмент).

Зачем вообще свой IP-стек. В зависимостях плат виден не сетевой стек ядра Linux, а собственный TCP/IP Huawei — переносимый «Versatile IP Stack», живущий в пользовательском пространстве; один и тот же на главных и на бейсбенд-платах. Зачем не взять готовый ядерный:

•   Переносимость между ОС. Платформа родилась на VxWorks, затем переехала на Linux. Свой стек даёт один идентичный API к IP на обеих ОС и на всех платах — сеть не переписывают при каждой смене ядра.

• User-space + kernel bypass. Стек работает в пользовательском пространстве, в быстром тракте транспорта, минуя ядро — zero-copy и обработка на выделенных ядрах (та же идея, что в DPDK/VPP). Ядерный стек на каждый пакет требовал бы перехода user/kernel.

• Реальное время. Стек в Linux оптимизирован под пропускную способность, а не под ограниченный джиттер; свой стек интегрирован с реал-тайм-фреймворком платформы и даёт предсказуемый тайминг.

• Сборка под плату. Стек конфигурируемый: бейсбенду — минимум, транспортной плате — полный набор (SCTP для сигнализации, IPsec, мультикаст, VLAN, QoS и д.р).

• Наследие. Поверх API этого стека написан весь транспортный и прикладной код — сохранив стек, его не переписывают под сокеты Linux.

Короче: один переносимый userspace-стек реального времени, одинаковый на всех ОС и платах, плюс быстрый data-plane — ценой поддержки «ещё одного TCP/IP».

Загрузочный образ платы устроен как матрёшка: внешняя обёртка с контролем целостности по CRC32 → фирменный загрузчик → сжатое ядро Linux ARM → корневая файловая система squashfs → набор device tree под разные ревизии железа. Одна и та же прошивка грузится на несколько аппаратных вариантов, а загрузчик детектит плату и выбирает нужный device tree.

Загрузчик по шагам: от CRC32 до init

Загрузчик оказался на удивление лаконичным.

Обёртка с контролем целостности. Первый рубеж: в заголовке лежит CRC32 всего образа; испортишь прошивку — загрузчик это заметит ещё до старта.

Stage-1 — крошечный ARM-стаб. Всего несколько инструкций: прочитать системный регистр CPU, выключить MMU и кэши, перейти на следующую ступень. Задача — привести процессор в предсказуемое состояние и прыгнуть дальше.

Stage-2. Детектит плату, выбирает подходящий device tree (их в образе больше десятка), формирует командную строку ядра, печатает «goto linux» и передаёт управление сжатому ядру. Из device tree видно железо: SoC Hisilicon на базе ARM Cortex-A9, до четырёх ядер, стандартная периферия (контроллер прерываний, таймеры, watchdog и т.д), последовательная консоль.

Самое интересное — в параметрах ядра: один стандарт системы с процессорными ядрами. Linux сознательно прибивается к одному «мастер»-ядру, а остальные ядра отдаются под другое — baseband/реальное время. Это AMP (асимметричная многопроцессорность) в чистом виде: Linux не занимает весь чип, он сосед по кристаллу. Там же — установка «любой сбой ядра = паника = перезагрузка» (телеком не терпит подвисшего состояния) и заранее выделенная область под аварийный лог («чёрный ящик»).

Финал. Ядро поднимает рамдиск (в него разворачивается корневая ФС), и rootfs — это BusyBox: стартовый init и скрипты инициализации. Дальше стартуют DOPRA/ROSA и прикладные сервисы. Вся цепочка:

BootROM чипа → обёртка (CRC32) → stage-1 стаб (MMU/кэш off) → stage-2 (детект платы → device tree → “goto linux”) → ядро Linux на master-ядре (AMP) → рамдиск (squashfs) → BusyBox init → DOPRA/приложение

А где же VxWorks?

Резонный вопрос, потому что VxWorks буквально просвечивает сквозь прошивку. В коде полно классических VxWorks-примитивов и развилок «идти в VxWorks-ветку или в Linux/VISP-ветку». Казалось бы — вот он, работает рядом с Linux.

Но если присмотреться, VxWorks-ядра на этих платах нет: rootfs — чистейший Linux, ядро — обычный zImage, нигде нет ни баннера VxWorks, ни образа Wind River. Разгадка — в слое абстракции ОС (DOPRA/ROSA). Платформа Huawei исторически родилась на VxWorks (ещё на помодовых платах), а на новых чипах переехала на Linux, но прикладной код сохранил VxWorks-совместимый API, чтобы его не переписывать. Чип многоядерный, и AMP архитектурно допускает разные ОС на разных ядрах — но в этой прошивке второго, работающего VxWorks-ядра нет: присутствует только абстракция. Так что корректная формулировка — не «два ядра бок о бок», а «Linux плюс VxWorks-совместимый API как наследие».

Архитектура DOPRA: акторы, VOS и ROSA

Раз уж мы помянули DOPRA и ROSA как «ОС-абстракцию», стоит разобрать, что это за платформа. DOPRA (Distributed Object-oriented Programmable Real-time Architecture) — не ОС и не просто библиотека, а акторный фреймворк поверх ОС.

Фундамент — VOS (Vendor OS). Прикладной код обращается не к системным вызовам ОС напрямую, а к тонкому слою абстракции. Через него идёт всё: асинхронные сообщения, группированные таймеры, пулы памяти (преаллокация вместо malloc), задачи и тики, регистрация компонентов, контроль перегрузки CPU и межъядерный обмен для AMP. Именно VOS прячет реальную ОС: платформа одинаково работает на Linux и VxWorks, потому что знает только этот слой.

Ядро модели — акторы (PID), функции (FID), автоматы (FSM). Это не многопоточный код с общей памятью, а акторная модель, ближе к Erlang/микроядру:

• PID — у каждого компонента свой идентификатор; сообщения адресуются PID, а не потоку.

• FID (Function ID) — функциональные юниты регистрируются по FID; старт системы = регистрация компонентов по FID.

• Сообщения — акторы общаются только асинхронными сообщениями, без прямых вызовов чужих функций; отсюда слабая связность и отказоустойчивость.

• Автоматы (FSM) — каждый актор обычно реализован как конечный автомат: сообщение = событие, двигающее состояние.

 

ROSA — рантайм, который всё это крутит. Хостит акторов и диспетчеризует сообщения; версионируется отдельно — то есть это самостоятельный переиспользуемый компонент.

Короче: DOPRA — акторный микроядерный фреймворк. Компоненты-PID с собственным состоянием (FSM) общаются сообщениями через слой абстракции ОС; он прячет ОС и мультиядро, рантайм диспетчеризует; состав декларативен, таймеры, лицензии и контроль перегрузки — встроенные сервисы. Прикладной код не знает ни про ОС, ни про то, на каком ядре/плате живёт сосед — отсюда переносимость VxWorks↔Linux и раседелённость по ядрам и платам.

Минимальную реализацию такой архитектуры на C можно посмотреть тут (навайбкодил). Почитать про акторы тут и тут.

Процессы станции

Посмотрим на реальный перечень задач работающей станции (вывод «All Task Infomation» в консоли, формат VxWorks-совместимого ядра: TID, имя задачи, статус, режим, точка входа, время работы, размеры стеков). 128 задач — это и есть тот самый набор процессов-акторов:

Огромный перечень

Имена говорят сами за себя: WebLMTTask — веб-интерфейс, openhpi — селф-менеджмент, RunLogTask — логи, tEthLinkChk/udpRecvTask/tTranIPSecAging — транспорт и IPSec, tGNSSTask0/tPtpDoProcTask/tSyncDoProcTask — синхронизация (GNSS/PTP), SerdesStateMonitor/tBBULinkTask — линки SerDes/BBU, smsMsgDeal/smsBChan_* — смс.

Виртуальные процессоры: как функции раскладываются по ядрам

Абстракция ресурсов в прошивке вполне материальна: платформа оперирует виртуальными процессорами (vCPU) и на старте «деплоит» их на ядра 4х ядерного Hi1380. Логический сервис не прибит гвоздями к конкретному ядру — он получает виртуальный процессор, а платформа решает, куда его физически положить.

Это и есть техническая реализация фразы «ресурсы можно делить или использовать независимо для каждого сервиса». В co-MPT станции GSM, UMTS, LTE и NR — это, грубо говоря, разные наборы vCPU-задач на общем пуле ядер, с общим планировщиком и общей шиной сообщений.

Внутри UBBP: ASIC, DSP, FPGA и CPU

Главную плату мы разобрали. Теперь самый жир, заглянем в соседнюю — ту, что делает собственно радиоканал. UBBP (Universal BaseBand Processing) устроена принципиально иначе, чем UMPT: это не «один SoC под Linux», а гетерогенная связка из трёх уровней, где каждый слой заточен под свой класс задач.

Про поколения платы. В пакете прошивки есть образы всех ревизий UBBP, и ниже я разбираю именно ту, что на фото, — UBBPg1a: управляющее ядро Kunpeng 529, вычислители HiSilicon SD6603 + SD6186, ПЛИС Pango, релиз SRAN16.1, есть 5G NR. Её второй вычислитель работает на собственном ядре HiSilicon «AVP», а первый — на CEVA. Ранняя ревизия UBBP отличается только кремнием: чип SD6182 с лицензионным ядром Xtensa, релиз SRAN11.1 и без NR; архитектура у них одна и та же.

Уровень 1 — управление (Linux). Управляющее ядро ARM под Linux, поднятое через U-Boot: на UBBPg1a это HiSilicon Kunpeng 529, на ранней ревизии — Cortex-A15. Linux сам ничего в радиоканале не считает — «деплоит» рабочий код на вычислительные ядра, а командами обменивается с главной платой по backplane.

Уровень 2 — Два DSP-ядра разных архитектур. На плате уживаются два разных ядра, и видно это по двум образам. Один образ — для CEVA DSP (и на UBBPg1a, и на ранней ревизии): софт-PHY — LDPC, FFT, L1/L2; математика считается в коде.Второй — для бейсбенд-чипа SD6186. На UBBPg1a работает на собственном ядре HiSilicon «AVP» (свой набор инструкций), в отличие от ранней ревизии с лицензионным Xtensa (SD6182). Релиз SRAN16.1, с поддержкой 5G NR.

Философия разная: CEVA считает PHY в софте, а код для AVP почти ничего не считает сам — он оркестрирует аппаратные ускорители: конфигурирует их, проверяет и гоняет данные.

Уровень 2.5 — аппаратные ускорители. «Железные» ASIC-блоки покрывают все стандарты, включая 5G NR: FFT/DFT, матричный блок/MIMO, оценка канала, подавление помех (IRC), кодирование и rate matching (LTE и NR), WCDMA-тракт (G-RAKE, деспрединг, демодуляция, регенерация), GSM (GMSK, A5 аппаратно), а также декомпрессия IQ, планировщик и контроль допуска. На SD6186 ядро AVP управляет, а считают блоки — hardware-offload вместо software-DSP.

Уровень 3 — ПЛИС: фронтхол-фабрика. ПЛИС на UBBP — не вычислитель физического уровня. На фото UBBPg1a стоит Pango PGL2100H (китайский вендор). Её роль — цифровой фронт-хол и коммутационная фабрика фронтхола: физический уровень CPRI/eCPRI (SerDes, эквалайзеры CTLE/DFE), IQ-кроссбар по контейнерам антенна-несущая (AxC), раздача кадровой синхры и применение весов цифрового бимформинга.

Китайский цифровой суверенитет. На старых платах (UMPT со Spartan-6) ПЛИС была Xilinx — американская. На UBBPg1a её место заняла Pango (КНР), управляющее ядро — собственный Kunpeng 529, бейсбенд — собственные ASIC SD6603 + SD6186. Причём и внутри ASIC: в ранней ревизии DSP-ядро было лицензионным Xtensa (Cadence), а в SD6186 его место заняло собственное ядро HiSilicon — AVP.

Аппаратные ускорители

Вычислительный ASIC UBBPg1a (SD6186) имеет около полусотни аппаратных блоков — больше, чем ранняя ревизия (~33). По стандартам (⁺ — новые относительно ранней ревизии):

Главные отличия от ранней ревизии: блоки оценки канала, декомпрессии IQ, планировщик и контроль допуска, и целый набор 5G NR. В ранней ревизии (SD6182) блоков NR не было.

DSP/PHY-функции: что именно считается

Кроме «железных» блоков, цифровую обработку делают и сами ядра — CEVA считает в софте, а ядро второго чипа управляет радиотрактом по CPRI:

Разделение труда: тяжёлую арифметику вынесли в аппаратные блоки и CEVA, а управляющее ядро занимается конфигурацией тракта, приёмом по антеннам-несущим, оценкой помеховой обстановки и таймингом кадра — «дирижирует», а не считает.

Кластер из плат UMPT: топология и роли

Немного рассмотрим кластеры (это не отказоустойчивый кластер, а скорее способ запустить несколько стандартов на разных платах. Но есть возможность собрать кластер в режиме холодного резерва), это важно, так как в софте есть их поддержка. Одной платы, да и одного шасси, хватает не всегда — когда стандартов много или нужна большая ёмкость, тогда платы UMPT объединяют в кластер. «Кластер» существует на нескольких масштабах: две главные платы в одной BBU, две BBU между собой, и даже два Linux-кластера внутри одного чипа. За топологию в прошивке отвечает отдельная подсистема — назовём её подсистемой топологии BBU. Пойдём от простого к сложному.

Две платы UMPT в одной BBU

Самый компактный «кластер» — две главные платы UMPT в одном шасси. BBU может нести две управляющие платы, и каждая становится отдельным сетевым элементом (NE). Классический пример: одна плата = LTE, другая = 3G — вместе они образуют LNR separate-MPT NE.

Что важно:

Соединены через backplane. Обе платы в одной корзине, поэтому общаются по объединительной плате BBU (встроенный L2-коммутатор, адресация по слотам) — никаких внешних кабелей. Сама объединительная плата — это две фабрики: control-plane по Gigabit Ethernet, а высокоскоростные данные — по Serial RapidIO (4 SerDes-линий, DMA и doorbells). Привычного PCIe здесь нет — его место занимает RapidIO, классический коммутируемый межплатный fabric в телекоме. Doorbell здесь — лёгкое аппаратное уведомление: короткий пакет без данных с 16-битным кодом события, который на приёмной плате вызывает прерывание. Паттерн обычный: сами данные идут DMA-ом, а сигнал «готово» — doorbell-ом (аналог MSI в PCIe или IPI между платами).

Делят железо, но раздельны по софту. У каждого NE свой программный и аппаратный стек, но они совместно используют саму BBU, транспорт, клок, RF-модули и антенну.

Согласование общих ресурсов. Чтобы две платы не передрались за общий транспорт/клок/RF, их узлы договариваются через интерфейс согласования ресурсов. Параметры разделяемых ресурсов на обоих NE должны быть согласованы, и multi-node OMC-тул делает это автоматически.

Ограничения. Нельзя два NE одного стандарта в одном separate-MPT NE; если одна плата несёт LN co-MPT, вторая уже не может нести LTE- или NR-only NE (конфликт стандартов).

По сути это separate-MPT «в миниатюре»: два независимых мозга в одном шасси, делящие периферию и синхронизированные через backplane.

Меж-BBU кластер: root + leaf

Разберем один из вариантов, все рассматривать не будем, там много нюансов, за полными знаниями в документацию хуавей. Когда одного шасси мало, кластер расширяют на вторую BBU. Две полки соединяются UMPT↔UMPT через специальный порт CI (разъем под SFP). Роли жёстко заданы: root (master) и leaf (slave), причём root обязана быть той полкой, где развёрнут NR, а leaf требует плату UMPTb или новее; максимум — две BBU. Master-UMPT ведёт единую топологию плат всех slave-полок.

Что нужно физически. Два соединения: control-plane между UMPT (оптика при расстоянии > 5 м — комплект из двух SFP и оптический патчкорд и baseband-данные через HEI-порты на UBBP (у новых UBBP — порты 40 Гбит/с). Клок раздаёт плата USCU. На панели UMPT за control-plane отвечает выделенный порт CI (SFP): «used for connecting to another BBU or a USU»; при бóльших конфигурациях BBU связывают через коммутатор USU или плату UCIU (интерфейс SCPRI, 2.5/4.9 Гбит/с).

Ограничения:

максимум две BBU — ровно root + leaf

root = BBU с NR, leaf = UMPTb+;

нельзя соединять при конфликте стандартов (пример: BBU1 с LNR co‑MPT + BBU2 с LTE‑only — нельзя, LTE дублируется).

Единая модель объектов. На обоих масштабах подсистема топологии строит одно дерево узлов, каждый — с адресом (стойка → субрэк → слот), типом и статусами (авария / админ-состояние / рабочее / standby / доступность). В это же дерево попадают CPRI-цепочки RRU с хопами — топологии «звезда / цепочка / кольцо».

Как кластер живёт в рантайме:

Discovery. Каждая плата рапортует свой адрес и тип; master собирает полное дерево, включая slave‑шасси и цепочки RRU.

Контрольные линки. Поднимаются и проверяются control‑plane линки плата‑плата и шасси‑шасси, поверх работает BFD для быстрого обнаружения обрыва.

· Единый O&M. Один master‑UMPT отдаёт в NMS единую картину (станция видится одним узлом), раздаёт конфигурацию всем платам и полкам, агрегирует аварии.

Синхронизация. Root — источник времени; по IEEE 1588v2 PTP плюс SyncE частота и время расходятся на leaf и дальше на RRU.

Ресурсы. В co‑MPT master динамически раздаёт vCPU, baseband и транспорт между стандартами; в separate‑MPT платы согласуют общие ресурсы через интерфейс согласования.

Главная понять, когда вообще нужны две главные платы: co-MPT — все четыре стандарта на одной плате, хватает одной платы и одной BBU; separate-MPT — стандарты на разных платах, нужны две главные платы (либо в одной полке, либо в двух BBU). То есть кластер — это способ собрать мультимод из раздельных плат/полок (частый кейс — legacy-эволюция: GU в старой BBU + L*N в BBU5900), когда свести всё на одну co-MPT-плату не вариант.

Заглянем глубже: два кластера на чипе, память и монтирование

Если копнуть прошивку дальше, выясняется, что «кластер» есть даже внутри одного чипа — и это закрывает сразу несколько вопросов.

Мастер выбирается на четырёх уровнях:

Тип платы. На старте загрузчик определяет, что за плата (мастер и слейв грузят разные бинарники), и выбирает нужный device tree. Не определил — перезагрузка.

CPU‑кластер на чипе (это и есть AMP). Hi1380 поделён на два Linux‑кластера. Роль (кластер A или B) читается из специального интерфейса ядра плюс параметра загрузки. Cluster A — основной, cluster B выполняет отдельный набор стартовых скриптов. Кластеры делят общую память и общаются через внутричиповые механизмы: аппаратный мейлбокс (сигналы и короткие сообщения с прерыванием), менеджер буферов (передача данных по общим пулам без копирования) и когерентный порт ACP (доступ к общей памяти без ручного сброса кэшей).

Главная плата в полке. Система знает, какая плата главная — по назначенному слоту.

Root в меж‑BBU кластере. Root BBU = та, где NR; leaf = UMPTb+.

Память мапится статически. Linux не владеет всей DDR — каждый кластер/ОС получает заранее нарезанные окна. Из device tree видно, что Linux‑кластеру отданы конкретные регионы DDR (несколько окон от единиц до сотен мегабайт плюс большой гигабайтный регион), а промежутки — память второго кластера, DSP/baseband и буферы данных. Плюс фиксированные области под рамдиск и под «чёрный ящик». Это каноничный AMP: каждая ОС владеет своим куском DDR плюс общие окна для IPC.

Точки монтирования:

• Виртуальные ФС (стандартный Linux): псевдо-ФС на RAM-диске для временных данных — всё волатильное, пропадает при ребуте.

• Постоянный флеш: NOR/NAND через MTD с фирменной флеш-ФС (на базе YAFFS), разбитый на разделы: конфигурация и бинарники, логи, рабочая и резервная зоны ПО, boot-уровень. Исторически разделы именуются в стиле VxWorks (через двоеточие) — наследие платформы.

• Образ платы: при старте монтируется петлёй per-board файловый образ, откуда запускаются board-специфичные скрипты.

• USB и сеть: USB для обновления, NFS-клиент и сервер(для обмена файлами в кластере).

Обновление ПО в кластере. Что бы поднять кластер ПО должно быть одной версии. Мастер проверяет версии, если они не сходятся, то обновляет: новый образ пишется в резервную A/B-зону флеша; манифесты совместимости проверяют версии всех плат и шасси; master активирует образ и поднимает вторичные ядра/кластеры новой версией; slave-шасси получают софт по control-линкам, а RRU — по TFTP через CPRI; при сбое активации — откат на старую зону. Один master дирижирует обновлением всего кластера, а две зоны и матрица совместимости не дают получить «кирпич» или рассинхрон версий.

Два кластера на чипе: кто за что отвечает

Разбиение чипа на два кластера (какие ядра, какие окна DDR) делает загрузчик и device tree. Отдельный драйвер ядра выполняет только две узкие функции:

Идентичность кластера. Читает номер кластера из SoC, проверяет, что это 0 или 1, и публикует его ядру и юзерспейсу через специальный интерфейс. По нему стартовые скрипты ветвятся: cluster A идёт одним путём, cluster B — другим.

Арбитраж общей консоли. Оба кластера делят один физический UART. Драйвер разруливает, чей он сейчас, через регистр‑переключатель и прерывание, перенаправляет печать ядра и сигналит соседу межпроцессорным прерыванием («забирай консоль»).

Сам обмен данными между кластерами и DSP-ядрами делает многоядерная подсистема обмена: аппаратный блок управления буферами, пулы в разделяемой памяти (zero-copy) и Ethernet-подобный интерфейс поверх shared-памяти (виртуальные MAC на каждое ядро). Это и есть канал, по которому cluster A ↔ cluster B ↔ DSP гоняют пакеты через общий DDR.

Транспорт, управление и селф-менеджмент

Вещи, которые делают эту коробку именно телеком-оборудованием операторского класса, а не просто ARM-компьютером с радио.

Транспорт. Набор транспортных драйверов организован в отдельных .so либах. платы UMPT: Ethernet/IP (современный backhaul), E1/TDM (легаси для 2G/3G), встроенный L2-коммутатор. Поверх — собственный IP-стек VISP вместо сетевого стека Linux; рядом сосуществует маршрутизирующая платформа(VRP) Huawei.

Управление (O&M). Управляющая подсистема отдаёт management-плоскость в сторону NMS/OSS: либо единым каналом (co-MPT), либо несколькими независимыми (separate-MPT). Локально инженер цепляется через веб-интерфейс (см. ниже).

Селф-менеджмент. Построен на OpenHPI, открытая реализация стандарта HPI (Hardware Platform Interface) от SA Forum — консорциума carrier-grade систем .Он превращает «корзину с платами» в управляемую программную модель:

Домен → ресурсы → RDR. Полка BBU — домен; каждая вставленная плата — ресурс; возможности ресурса описаны записями RDR (датчики, контролы, инвентарь).

Сенсоры (температура, напряжения, обороты вентиляторов), контролы (светодиоды), инвентарь FRU (серийники, парт-номера из EEPROM), hot-swap (конечный автомат горячей замены) и сторожевые таймеры.

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

Вывод: Huawei не изобретала свой велосипед для управления шасси, а взяла открытый телеком-стандарт. BBU управляет собой ровно как серверная blade-корзина carrier-grade класса.

Веб-интерфейс и OAM: чем и как управляют станцией

Управляющих плоскостей две: локальный веб сервер и система управления сетью оператора(NMS).

WebLMT — веб-сервер в базовой станции

Локально станция управляется через WebLMT (Web Local Maintenance Terminal) — да, у базовой станции есть свой веб-интерфейс:

· На главной плате поднимается встроенный HTTP‑сервер (HTTP/1.1), поверх — HTTPS/TLS (TLSv1.0–1.2) с серверным сертификатом и зашифрованным ключом.

• Отдаётся обычный SPA: HTML плюс gzip‑упакованные JS и XML.

• Общение с бэкендом — через REST‑подобный API (login/logout, выполнение команд).

• Логин — challenge‑response (HMAC + клиентское шифрование), так что пароль в открытом виде по сети не передается; таймаут сессии, парольные политики, принудительная смена пароля, блокировка учётки.

Веб‑движок подгружает плагин на каждый стандарт — интерфейс подстраивается под развёрнутые RAT.

Файловые операции вынесены в отдельный Java Web Start‑клиент. Я не любитель явы, не одобряю.

И ещё про «локально»: инженеру необязательно подключать Ethernet кабель. В прошивке есть драйвер USB-WiFi (чип Ralink/MediaTek) в режиме точки доступа — в USB-порт платы можно воткнуть WiFi-свисток, и станция поднимет локальную беспроводную точку, чтобы подключиться к WebLMT/MML по воздуху.

MML — единый язык команд

И локально, и с системы управления станция управляется на MML (Man-Machine Language) — текстовых командах вида «глагол объект: параметры»: просмотр, изменить, установить, добавить, активировать, показать. WebLMT просто оборачивает тот же MML в REST-вызов.

Лично мне веб управление не понравилось. Нужно: зайти на веб, ввести капчу с картинки, выбрать нужное меню в веб интерфейсе. Отнимает много времени, особенно капча с картинки, которую не всегда с первого раза угадаешь. После cisco/juniper/linux cli – кажется, что это не удобно. Поэтому я написал свой клиент, который поднимает OAM канал на сертификатах и дает вводить команды привычным способом. Так же умеет слать бинарные команды, так что можно написать свою NMS, или интегрировать в стороннюю.

Северный интерфейс (Northbound interfaces)

С операторским NMS станция общается по OM‑каналу (IPv4 и IPv6). Поверх канала:

• SOAP как кодек управляющих сообщений; Два формата передачи команд — бинарный и текстовые MML. Набор команд хранится в xml, плюс отдельная либа.so которая их обрабатывает.

• Массовая передача файлов (ПО, конфигурация, логи) — через выгрузку на внешний FTP‑сервер

• Аварии уходят на NMS уведомлениями.

 Telnet, SNMP, или привычного SSH — нет, управление строится на связке MML + SOAP.

Протоколы — как плагины

Стек протоколов управления и транспорта сделан как загружаемые модули: нужен протокол — грузится .so:  (802.1ag CFM, 802.3ah link-OAM, 802.1X, CMPv2, IP-протоколы, трассировщики). Тот же плагинный подход, что и у прикладных библиотек платформы.

Безопасность: PKI, доступ и защита станции

Безопасности в прошивке уделено много внимания — это несколько уровней, видно что инженеры хуавей старались:

Полноценная PKI. Вокруг управления выстроена полноценная инфраструктура открытых ключей:

• операторский корневой УЦ и серверные/компонентные сертификаты;

• CMPv2 — автоматический выпуск и обновление сертификатов самой станции из PKI оператора;

• 802.1X — станция аутентифицируется в транспортной сети, прежде чем в неё пустят;

• LDAP — централизованная аутентификация учёток инженеров;

• CMS/PKCS#7 для защищённых сообщений.

Плюс сам вход: HTTPS-портал с challenge-response логином (пароль в открытом виде по сети не уходит), таймаут сессии и блокировка учётки.

Пароли — хешами, дефолты в XML. Пароли не лежат в обычном системном файле паролей в рутфс — учётки хранятся в персистентном конфиге на NOR-флеш (там же, где корень доверия), и только в виде хешей (SHA-512): открытого пароля на плате нет. Заводские (дефолтные) пароли поставляются отдельно — в XML-конфиге — и подлежат обязательной смене при первом входе (парольные политики, блокировка учётки).

Защита от сканирования портов. Встроенный пакетный фильтр: ACL-правила плюс списки доверенных узлов и пиров (security-host/peer/template) и бело/чёрные списки. Трафик с неизвестных адресов и на незадействованные порты отбрасывается — сканер портов не видит открытых сервисов. Детектор обнаружения сканирования отравляет атакующего в бан (походит на  fail2ban, но реализация собственная)

Контроль запущенных процессов. Есть белый список процессов: стартовать разрешено только «своим» бинарям из списка — посторонний или подменённый процесс не запустится. Вместе с контролем целостности образов (контрольные суммы/подпись на загрузке) это закрывает подмену кода.

ARM TrustZone — аппаратный корень доверия. Самый нижний уровень защиты — не в Linux, а под ним. SoC аппаратно разделён на два «мира»: Normal World (Linux и приложения) и Secure World — изолированная доверенная среда исполнения (TEE) на базе OP-TEE. У Secure World своя защищённая память, куда Normal World физически не залезет, а переключение миров — через механизм безопасного вызова (SMC). В TEE — самое чувствительное: проверка подписи при secure boot, защищённое хранилище ключей и блокировка отладки.

JTAG закрыт на уровне eFuse и не разведен на стандартный разъем.  Даже при компрометации Linux ключи и проверка целостности остаются за аппаратной границей.

UART отключен на ввод/вывод.

Если собрать вместе: HTTPS-портал с REST-API и challenge-response логином, северный SOAP к системе управления, файловые серверы, плагинный стек протоколов, автоматический PKI-энролмент, хеши паролей на защищённой NOR, пакетный фильтр от сканирования, белый список процессов и — в самом низу — аппаратный TrustZone/TEE (OP-TEE) как корень доверия. Маленький, но взрослый enterprise-бэкенд — причём с «безопасностью по умолчанию».

Логирование и отладка: чёрный ящик, логи и трейс

Логирование — это не «один лог-файл», а несколько независимых подсистем:

BlackBox / «чёрный ящик». Перед крахом или сбросом система сохраняет «последнее слово» в зарезервированную область RAM, которая переживает перезагрузку. Нюансы, делающие это бортовым самописцем: отдельный lastword на каждый виртуальный процессор, защита контрольным полем, своё «последнее слово» даже у FPGA; после ребута содержимое сбрасывается в файл. В связке с установкой «любой сбой ядра → паника → ресет» получается: станция падает, но успевает записать состояние.

Файловые логи с ротацией и сжатием. Несколько потоков, кольцевые и сжатые: платформенный лог (модули регистрируются в нём), рабочий лог рантайма, и трейс шагов загрузки.

Распределённый сбор. Каждый драйвер и модуль умеет отдавать свою диагностику, а коллектор собирает это в единый дамп. То есть логирование не централизованное «сверху», а федеративное: каждый компонент сам рапортует о себе.

Operation / Security (аудит). Отдельный журнал: кто вошёл и что делал. Записи структурированы (login/logout, оператор), с разделением ручного логина и авто-логина по ключу.

Trace — онлайн-трейс сигнализации. Принципиально другой поток: не файлы «что было», а живой стрим «что происходит прямо сейчас». Трейс-модули монтируются на лету (свои на каждый стандарт), а сам трейс привязывается к конкретному объекту — сигнальной ассоциации, линку, соте, абоненту. Результат стримится вживую в WebLMT инженеру.

Точечное включение логов. У каждого модуля свой набор: включить/выключить отладочную печать глобально или по одному объекту, выставить уровень, показать/сбросить счётчики. Это критично: на боевой станции включение полной отладка — это к падению сервиса, поэтому детализацию включают точечно.

Хранение — на флеше (отдельный раздел под логи, ротация и сжатие), таймстемпы от NTP/SNTP; наружу логи уходят по FTP/SFTP на NMS или скачиваются через веб-интерфейс. Если смотреть глазами «серверного» разработчика — это ровно современная модель наблюдаемости: логи, трейсы, crash-dump, аудит и метрики-счётчики, только вместо ELK и Jaeger — флеш-раздел и SFTP на NMS.

Как читают логи инженеры

Для удобства анализа логов/CDR/перфоманса/траблшутинга/анализа KPI есть отдельный софт под Windows с названием Fault Management Application (FMA). Инженер выгружает логи с БС на FTP, и далее просматривает их в FMA.  выглядит вот так:

Как устроено обновление ПО

Доставка ПО — трёхуровневая матрёшка.

Верхний уровень: релизный пакет SRAN

Весь релизный —пакет SRAN, собран из независимо версионируемых кусков:

Release SRAN  V100R016C10SPC130
├─ packcfg.xml / vercfg.xml / ratadapt.xml / VERMATCH.XML   ← манифесты (namespace ROSA/SoftwareManagement)
│   · .sgn (RSA) · .cms (PKCS#7 + цепочка) · .crl / SWSCRL.crl
├─ COMM/   comm.csp     V500R010C10SPC130   ← общая платформа
├─ eGBTS/  rat_g.csp    V100R022C10SPC130   ← GSM (2G)
├─ NodeB/  rat_u.csp    V200R022C10SPC130   ← UMTS (3G)
├─ eNodeB/ rat_l.csp    V100R016C10SPC130   ← LTE (4G)
├─ gNodeB/ gNodeB.csp   V100R003C10SPC130   ← 5G NR (type=10)
├─ GBTS/   Download.zip                     ← legacy GSM (старый .zip)
└─ RFA/    RFA.csp      V100R016C10SPC130   ← радио (type=8)
     каждый product-каталог: <pkg>.csp + .sgn + VERMATCH.XML/.SGN + Precfg.ini

Что здесь важно архитектурно:

·         Станция — это композиция версий, а не монолит. Общая платформа в одной ветке, каждый стандарт — в своей; SRAN их склеивает. Манифест версий перечисляет всё с путями и типами, плюс список поддерживаемых моделей станций.

·         Матрица совместимости версий. Отдельный манифест задаёт приоритет стандартов и правила, с какими версиями соседних стандартов данная версия уживается. Именно это не даёт собрать мультимод из несовместимых кусков.

·         Адаптация. Отдельный манифест маппит функции на типы приложений — какую app-адаптацию платформе грузить.

·         Подпись — на каждом уровне. Отдельные RSA-подписи, контейнеры PKCS#7 с цепочкой сертификатов и списки отзыва. Ровно та PKI/целостность, что мы видели в управлении.

 

Почему у пакета прошивки две подписи? Потому что Вася Пупкин работающий в хуваей выложил в паблик утилиту для подписывания файлов с приватными ключами. По той же причине, теперь две схемы обновления ПО через USB. И вся та безопасность, о которой говорили ранее помножилась на ноль. Не делайте как Вася.

Что реально лежит в пакете прошивки

Каждый product-пакет — это манифестный архив (дескрипторная таблица: имя файла + смещение + размер, достаётся без сканирования маркеров). Внутри — образы конкретных плат (вложенные контейнеры → squashfs → исполняемые модули), конфиги и подписи.

Пакет главной управляющей платы показывает, из чего вообще состоит «прошивка»: ОС (загрузчик + Linux + rootfs + device tree), прикладные squashfs-образы, платформа и фреймворк отдельными модулями, IP-стек и транспортные драйверы, конфигурация процессов в XML (тот самый актор-рантайм описан декларативно, а не зашит в код), прошивка FPGA и CPLD, device tree, лицензионные item’ы.

А для радиомодулей(RRU/AAU) состав совсем «SDRный»: загрузчик, образ SoC, DSP-образы, FPGA-битстрим, файлы цифрового предыскажения усилителя (DPD), калибровки радиотракта, доверенная среда исполнения (ARM TrustZone). То есть одна «прошивка базовой станции» — это на самом деле десятки прошивок для десятков разных процессоров, DSP и ПЛИС, собранные в один подписанный контейнер.

Флеш-память: NOR и NAND — и почему их разделили

У платы два разных типа флеш-памяти, и это осознанное архитектурное разделение. Видно даже по загрузке: ядро поднимает драйверы обоих — NOR (через интерфейс CFI) и NAND (с ECC), плюс слой MTD и разборщик разделов.

На NOR — то, что должно быть маленьким, надёжным и всегда доступным: загрузчик и переменные окружения; пароли / учётные данные; сертификаты и ключи (PKI — корень доверия); критичные мелкие конфиги (идентификатор платы, указатели на калибровку). NOR байт-адресуема и поддерживает XIP (процессор читает и исполняет прямо из неё при reset), без бэд-блоков, очень надёжна; пишется редко — выравнивание износа не нужно, можно аппаратно защитить от записи. Загрузчик на NOR обновляется вручную — не через онлайн-апгрейд: прошивать его «на лету» — верный «кирпич». Поэтому его трогают редко, отдельной ручной процедурой.

На NAND — весь объём: ОС (ядро Linux + rootfs в squashfs); две зоны ПО A/B (с откатом); прикладные образы (приложение, DSP, FPGA); логи (чёрный ящик) и большие конфиг-БД. NAND дёшева и ёмка — сотни мегабайт помещаются; зато есть бэд-блоки, поэтому нужны ECC, выравнивание износа и флеш-ФС, которые прячут изнашивание. Эта память часто перезаписывается (логи, A/B), и штатное обновление идёт сюда — в резервную зону, с откатом.

Как прошивка вообще попадает на плату. На заводе ПО заливают на NOR программатором (на стенде, а не «через станцию»), и на микросхемe клеят наклейку с версией — чтобы на складе и при монтаже было видно, что внутри, не включая оборудование. А дальше — «на носителе минимум, остальное по сети»: в NOR лежит, по сути, только загрузчик, а основную прошивку (ОС, приложение, образы) загрузчик вытягивает по IP и раскладывает в NAND. Тот же приём, что у радиомодулей (грузятся по сети). Поэтому NOR практически не меняется за всю жизнь платы (отсюда и ручное обновление загрузчика), а весь «живой» объём — на NAND. Логика работы одинакова.

Почему разделено:

• Надёжность загрузки и корень доверия. То, что обязано загрузиться всегда (загрузчик), и секреты/ключи — на надёжной NOR без бэд-блоков, которую процессор читает напрямую при reset. Корень доверия изолирован от часто-перезаписываемого объёма.

• Ёмкость против цены. Секреты и загрузчик крошечные → маленькая (но дорогая за бит) NOR; ОС + ПО + логи — сотни мегабайт → дешёвая ёмкая NAND.

• Паттерн записи и безопасность. NOR пишется редко (без выравнивания износа), NAND часто (ECC + флеш-ФС). И это защита: NAND можно перепрошить целиком, а NOR-корень доверия это переживёт и проверит подпись нового образа перед запуском — та же PKI.

Обновление, подпись и «две зоны» с откатом

Отдельного разговора заслуживает то, как обновление накатывается. Возьмём обновление с USB-флешки (Тут надо сказать, что обновление с флешки – это аварийная процедура, пакет обновления подписывает сертификатами тех. поддержка и присылает под каждую BBU). Штатный механизм обновления через O&M или веб-LMT.

Есть два формата пакета обновления на флешке:

• Новый, манифестный. В корне лежит DeployCfg.xml — единый манифест: какие платы (по серийнику ESN/MPTSN, где ANY — wildcard), в каком режиме (ServiceMode = буквы G/U/L для 2G/3G/4G) и какие файлы ставить (Software, ColdPatch, HotPatch, CfgDataFile, License…). Один файл на флешке описывает мультиплатформенную, мультистандартную установку.

• Старый, каталоговый. Если DeployCfg.xml нет — откат на фиксированные папки по типу продукта: /usb:/NodeB, /usb:/eNodeB, /usb:/BTS3900 GSM, /usb:/TDNodeB.

Либа отвечающая за обновление  берёт тот каталог, который физически присутствует (и ругается, если их сразу два). Пайплайн: детект USB → монтирование файловой системы → разбор манифеста → precheck по каждому типу приложения (загрузить пакет обновления, проверить версию, проверить подпись и «криптозащищённость») → и только потом установка. Любой сбой подписи, версии или контрольных сумм останавливает процесс — обновление не начинается, а не ломается на середине.

 

Многоступенчатый контроль целостности и подлинности:

• дескриптор безопасности с HMAC и шифрованием;

• отдельная ЭЦП на конфиг пакета;

• заголовочная цифровая подпись пакета (RSA/CMS, со списками отзыва);

• CRC16 в метаданных и CRC32 на загрузочных образах;

• сверка версий: смешанные версии или неподдержанный тип платы отбраковываются до установки.

Две зоны и откат. Классическая A/B-схема: новый образ пишется в резервную зону, и только при успешной активации станция переключается на неё; при неудаче — остаётся жить старая. Плюс «горячие» патчи (без перезагрузки) и «холодные» (с рестартом). Именно так гигантскую коробку на вышке обновляют удалённо, не посылая инженера.

Алгоритм детектирования сбоя активации простой: если три раза загрузка не прошла успешно — загрузчик накатывает прошивку из резервной зоны.

Кстати, фоновую механику обновления Huawei описывает в своей документации (Commissioning Guide): станция сама детектит USB, читает ПО и конфиг из фиксированных каталогов, сверяет версии и обновляется только при расхождении, а при совпадении — пропускает. Весь процесс оператор видит по миганию RUN-светодиода: быстрое мигание (0.125 с) — идёт загрузка/активация (~12 + ~3–4 минуты), медленное (1 с) — штатная работа.

 

Как грузится RRU: загрузчик, диагностическая ОС, софт — по CPRI

Радиоблок устроен как «тонкий» клиент: в собственной флешке у него лежат загрузчик и компактная резидентная ОС с диагностикой, а весь рабочий софт приезжает с BBU по оптике. Эта резидентная ОС поднимается и без связи с BBU и отвечает за первичный подъём и самотест железа, мониторинг и аварии, сбор диагностики и захват аварийного дампа, восстановление. Постоянного рабочего приложения радиоблок у себя не держит — его забирает с BBU.

Рабочий софт лежит на BBU и содержит полный набор: ядро Linux (для современных радиоблоков), главное приложение, DSP-образ, FPGA-битстрим, DPD, калибровки.

Протокол — TFTP. На BBU для радио стороны поднят TFTP-сервер.

Процесс:

1. Питание → стартует загрузчик из флеша RRU
2. Загрузчик поднимает оптический CPRI‑линк к BBU, согласует line rate
3. По in‑band C&M‑каналу CPRI RRU получает связность (L2/IP) с BBU
4. Загрузчик по TFTP качает с BBU набор: ядро, приложение, DSP, FPGA, DPD, калибровки
5. Образы разворачиваются в RAM → RRU грузит Linux и запускает радио
6. Софт тянется заново при КАЖДОЙ загрузке → версия RRU всегда = версии BBU

Раз радиоблок каждый раз берёт софт с BBU, его версия автоматически синхронна с головной платой. Отдельного апгрейда RRU не существует: заменил модуль на вышке — он сам провизионится. Весь интеллект и управление версиями — на BBU, в RRU — загрузчик, резидентная ОС с диагностикой железа.

Старые RRU: ещё живой VxWorks

Новые радиоблоки работают на Linux. А вот если взять что постарше — например, RRU3232, — там под капотом VxWorks. И это показывает, что радио-сторона прошла ту же миграцию, что и главная плата.

Образ запрятан в несколько слоёв сжатия и обёрток, а размотав его, VxWorks видно в упор: сообщения инициализации ядра, его системные задачи, классические API, отладочный агент Wind River. Старт образа — с ARM-инструкции перехода (reset-вектор), то есть VxWorks на ARM. Модули грузятся как отдельные объектные файлы — самая характерная подпись VxWorks (Linux так не делает; у него были бы модули ядра). И никакого Linux-ядра в пакете нет, в отличие от новых радиоблоков.

Поверх VxWorks работает тот же DOPRA — фирменная платформа Huawei, только в VxWorks-флейворе. Состав пакета вполне «SDRный»: битстрим ПЛИС, цифровое предыскажение и его коэффициенты, коэффициенты фильтров и частотные шаблоны, списки регистров. В логике — управление усилителем мощности (HPA), адаптация DPD, CPRI. И двойной BOOTROM (Active/Standby) — та же A/B-идея, что на главной плате.

Вывод: и UMPT плата, и радио прошли один путь — VxWorks → Linux. На управлении это помодовые платы (VxWorks) → UMPT (Linux), на радио — старые RRU (VxWorks) → новые RRU (Linux). А DOPRA как слой абстракции пережил оба перехода, поэтому VxWorks-наследие и просвечивает даже там, где уже давно Linux. При этом старое железо до сих пор совместимо с новым.

RF API: как BBU управляет радиоблоком

Транспорт — HDLC поверх CPRI. Команды едут по управляющему каналу CPRI (C&M), кадрированному HDLC, поверх тех же SerDes, по которым идёт IQ: с адресацией узлов и согласованием скорости канала.

Диспетчер — шина сообщений + обработчики модулей. На стороне радиоблока команда принимается внутренней шиной сообщений и роутится в обработчик своей подсистемы (на каждую — свой).

HAL радио. Сами команды живут в слое аппаратной абстракции радио (ROC — «Radio-On-Chip»). Это не зависящая от поставщика прослойка: один набор команд транслируется в регистры конкретного трансивера. Видны бэкенды под разные RFIC — Analog Devices и AFE75xx-класс.

Категории команд и подкоманды. Имя строится как «подсистема → элемент → запись/чтение» (почти всё — запись, пара — чтение):

Обычная последовательность запуска радио: клок и питание → синтезатор → синхронизация конвертеров → усиление и АРУ → профиль применения → калибровка → подтверждение готовности. Отсюда и связка «RF-команды ↔ синхронизация ↔ калибровка».

А если eCPRI? Транспорт меняется, API — нет. В eCPRI фронтхол пакетный (поверх Ethernet). И самое интересное — как едет управление (C&M): по прошивке AAU видно, что оно кладётся в eCPRI-сообщение типа «Vendor Specific» — вендорскую «ячейку» стандарта, и несёт те же управляющие сообщения, что и в CPRI (там — в HDLC-кадре, здесь — в кадре Vendor Specific по Ethernet). Сам набор RF-команд не меняется — меняется «конверт». O-RAN M-plane тут ни при чём: ни NETCONF, ни YANG в прошивке нет — это проприетарный Huawei-eCPRI (BBU и AAU оба Huawei). Диспетчер, HAL радио и работа с трансивером идентичны. Что eCPRI добавляет: синхронизация по PTP (IEEE 1588) + SyncE (в Ethernet нет встроенного клока), задержку меряют явно, IQ обычно сжимается. Фронтхол-ПЛИС поддерживает оба режима.

Калибровка и метрология RF-тракта

Раз зашла речь про RF, отдельно стоит калибровка — в прошивке это не пара функций, а целая подсистема. Она делает так, что «заданная» мощность равна реально излучённой.

Это управляемый процесс, а не разовая заводская операция. Калибровкой рулит не файл-сценарий, а командный RF-API: BBU шлёт команды в RRU в две фазы — до и после конфигурации несущих. Приёмный тракт калибруется поэлементно (все тракты либо feedback-тракт DPD). При сбое тракт помечается «некалиброванным».

Что калибруется:

• TX-мощность — «скомандовано → реально излучено» по каналам/трактам (плюс пороги предупреждений/аварий);

• RX-тракты — усиление по приёмным путям, включая feedback-тракт DPD;

• Канальная / фазовая когерентность — выравнивание амплитуды и фазы всех антенных трактов, основа MIMO и бимформинга;

• Задержки — компенсация задержек по CPRI-волокну, чтобы антенны были выровнены по времени;

• RTWP / шумовой порог — опорный уровень приёма, чтобы измерения шума/помех были абсолютными;

• Частота / клок — подстройка опорного генератора (автоподстройка частоты через ЦАП, VCXO/VCTCXO);

• Температурная компенсация — дрейф мощности/частоты от температуры + защита по перегреву;

• CFR / DPD — линеаризация усилителя; фильтры и ALD / RET — электрический наклон антенны по AISG.

Процесс распределённый: BBU ↔ RRU по CPRI. BBU инициирует, RRU измеряет свой RF-фронт-энд и рапортует обратно; результаты сливаются и раздаются по стандартам. Фазовое выравнивание завязано на подсистему синхронизации — калибровка, тайминг и бимформинг в одной связке.

Хранение. Калибровочные коэффициенты привязаны к конкретной железке (копируются/очищаются при замене юнита), с бэкап-копией и статусом «калиброван/нет». Это ровно те «критичные мелкие данные», что живут на надёжной стороне флеша (рядом с корнем доверия) — потерять калибровку значит, что станция начнёт «врать» по мощности и частоте.

Связь с метрологией прямая: калибровочные таблицы лежат в основе RF-тест-режима, поэтому расхождение «внешний тестер (вроде CMU200) vs внутреннее измерение станции» — это и есть прямая оценка состояния калибровки.

Как мы это проверяли: запуск прошивки в QEMU

Чтобы не верить дизассемблеру на слово, образ главной платы я реально загрузил — в эмуляторе. Написана минимальная машина QEMU, моделирующая железо по настоящим device tree из прошивки: Cortex-A9 с A9 MPCore (контроллер прерываний, таймеры), память, UART-консоль и контроллер Ethernet HiSilicon GMAC, так что сетевые интерфейсы поднимаются и гоняют реальный трафик.

Оно грузится: декомпрессор → Linux 4.4.197 → загрузка модулей (включая драйверы флеша NOR/NAND) → стартовые скрипты → детект платы → интерактивный шелл на консоли. Главного приложения в эмуляции нет, я запустил его не до конца, слишком большой объем по эмуляции реального железа, хотя до какой‑то стадии грузится, но дальше продолжать играть с этим я не стал, нужен был сам факт возможности запуска в эмуляторе. Наблюдения из живой системы:

• uname → Linux 4.4.197 armv7b — то самое ARM big‑endian;

• консольный ввод работает;

• в логе видны драйверы флеша (NOR через CFI, NAND с ECC) — подтверждает раздел про NOR/NAND.

.

Выводы

Сложные системы требуют сложную архитектуру. Архитектура базовой станции Huawei 3900/5900 — это красивый пример того, как общие принципы «большого» software-инжиниринга перенесены в embedded-телеком:

• Разделение платформы и приложений. BTS Node — платформа, RAT-стеки (2G/3G/4G/5G) — приложения-сервисы поверх неё, со строго описанными интерфейсами. По сути — PaaS внутри одной коробки.

• Виртуализация ресурсов. Виртуальные процессоры, абстрагированные ресурсы, общий пул ядер — чтобы один и тот же кусок железа гибко раздавался разным стандартам связи.

• Актороориентированный рантайм. DOPRA + ROSA и обмен сообщениями между процессами-задачами — вместо монолита множество изолированных акторов.

• Честный trade-off. Co-MPT (всё на одной плате, минимум железа, но сильная связанность) против separate-MPT (изоляция отказов ценой дублирования) — та же дискуссия, что монолит против микросервисов.

• Обычный фундамент под необычной задачей. Под капотом — встраиваемый Linux на ARM big-endian, zImage и squashfs, OpenHPI, собственный IP-стек, RapidIO-backplane. Ничего магического; магия — в том, как это собрано вместе, чтобы четыре поколения связи ужились в одном корпусе и не мешали друг другу.

• Зрелый жизненный цикл ПО. Манифестные пакеты с дескрипторной таблицей, многослойный контроль целостности (CRC + RSA/CMS-подписи), две зоны прошивки с откатом и горячие/холодные патчи — всё, что нужно, чтобы безопасно обновлять оборудование, до которого нет физического доступа.

Для тех кто дочитал до конца – маленький анонс

В следующей статье расскажу, как запустить 4G на BBU3900 и Open5GS.

Перечень сокращений