Эта статья является продолжением темы начатой статьей "Введение в O-RAN".
Узлы O-RAN
На рис. 1 показан общий вид узлов, определенных альянсом O-RAN. Синие элементы определены 3GPP и адаптированы спецификациями O-RAN (добавляется «O-»), а оранжевые - это элементы, определенные O-RAN. (интерфейсы между элементами явно не показаны на этом рисунке - они представлены подробнее далее)
К отдельным элементам относятся следующие:
O-Cloud: платформа облачных вычислений, включающая узлы физической инфраструктуры для размещения функций O-RAN; вспомогательные программные компоненты (например, система упроавления, мониторинг виртуальных машин, среда выполнения контейнеров и т.п.), функции управления и оркестрации.
O-RU (удаленный блок O-RAN): логический узел, на котором размещается уровень низкого физического уровня (например, FFT / IFFT, PRACH) и RF на основе LLS (разделение нижнего уровня);
O-DU (распределенный блок O-RAN): логический узел, на котором размещены уровни RLC (управление радиоканалом) / MAC (управление доступом к среде) / высокий PHY на основе LLS;
O-CU-CP (O-CU-Control Plane - плоскость управления центральным блоком O-RAN): логический узел, на котором размещены RRC (управление радиоресурсами) и CP (плоскость управления) PDCP (протокол конвергенции пакетных данных);
O-CU-UP (O-CU-User Plane - пользовательская плоскость): логический узел, на котором размещены SDAP (протокол адаптации служебных данных) и UP (пользовательский уровень) часть PDCP;
Near-RT RIC (интеллектуальный контроллер RAN в режиме близкого к реальному времени или nRT RIC): логический узел, обеспечивающий управление / оптимизацию элементов и ресурсов RAN в режиме почти реального времени посредством детального сбора данных и действий по E2. Контроллер nRT RIC может включать рабочий процесс AI / ML.
Non-RT RIC (Интеллектуальный контроллер RAN «не в реальном времени» или NRT RIC): логический узел, обеспечивающий управление без Real Time, а также оптимизацию элементов и ресурсов RAN, контроль процессов AI / ML и управление приложениями / функциями на основе политик в nRT RIC;
xApp : приложение, предназначенное для работы на nRT RIC, состоящее из одного или нескольких микросервисов. xApp не зависит от nRT RIC и может предоставляться третьей стороной.
SMO (Service and Management Orchestration): система, поддерживающая оркестрацию компонентов O-RAN, которая включает NRT RIC.
Различные блоки, как правило, могут быть предоставлены отдельными поставщиками, что позволяет создать экосистему игроков, разрабатывающих только CU или DU, или только xApps или RIC и т.д. В этом заключается преимущество концепции O-RAN.
Архитектура O-RAN
Давайте теперь посмотрим на общую архитектуру O-RAN (рис. 2), где объекты, представленные на рис. 1, соединены интерфейсами в соответствии со спецификацией O-RAN Alliance [11].
Как и раньше, «синие» объекты определяются 3GPP (оба включают функциональные возможности, предоставляемые синими полями, а также интерфейсы, такие как F1 и E1), в то время как «оранжевые» элементы и интерфейсы определяются O-RAN Alliance. Прежде всего остановимся на «оранжевых» интерфейсах:
Интерфейс A1: между NRT RIC и nRT RIC, через который NRT RIC предоставляет nRT RIC контроль политиками, дополнительной информацией и обновлениями модели машинного обучения.
Интерфейс E2: фактически доступ в O-RU, O-DU, O-CU. С его помощью мы можем контролировать, что происходит в этой подсистеме, используя сообщения мониторинга, приостановки, переопределения, управления и выполнения действий, исходящих от xApps / nRT RIC, и получать сбор данных и обратную связь от этих объектов.
Интерфейсы O1 и Open-Fronthaul M-plane: обычный интерфейс FCAPS (Fault, Configuration, Accounting, Performance, Security) с конфигурацией, реконфигурацией, регистрацией, безопасностью, производительностью, обменом деталями мониторинга с отдельными узлами, такими как O-CU-UP, O-CU-CP, O-DU, O-RU, а также nRT RIC.
Интерфейс O2: служит для управления ресурсами платформы и рабочей нагрузкой (например, масштабированием ресурсов и FCAPS).
На рисунке также показаны три контура управления, а именно первый контур управления, работающий в режиме реального времени, где выполняются действия в масштабе времени ниже 10 мс, например, планировщик находится в O-DU и не является предметом спецификации O-RAN Alliance. Затем у нас есть контур управления в режиме, близком к реальному времени, с синхронизацией от 10 мс до 1 с, в котором работают такие функции, как управление трафиком, управление мобильностью и управление помехами. Наконец, самый внешний контур управления касается операций не в реальном времени продолжительностью более 1 секунды, с функциями оркестровки и оптимизации, а также с включением моделей машинного обучения.
Варианты реализации O-RAN
На рис. 3 и 4 показаны различные варианты реализации архитектуры O-RAN на основе [11]. Обратите внимание, что узел E2 - это логический узел, завершающий интерфейс E2, для NR это O-CU-CP, O-CU-UP, O-DU или любая комбинация, разрешенная O-RAN Alliance.
В левой части рис. 3 показана полностью дезагрегированная архитектура (идентичная рис. 2), где nRT RIC имеет соединения E2 с каждым отдельным O-CU и O-DU, которые затем становятся отдельными узлами E2. Такие узлы можно агрегировать по-разному. Один примерный вариант показан в правой части рисунка 3, где O-CU и O-DU объединены вместе и они вместе обрабатываются и вызываются как один узел E2, к которому существует только одно соединение E2 (и одиночное соединение O1).
Следующий набор параметров на рис. 4 показывает другой способ комбинирования различных функциональных элементов. Левая часть этого рисунка представляет объединение nRT RIC вместе с O-CU, что означает, что интерфейс E2 для управления O-CU является внутренним, и от этого объединенного узла есть обычный интерфейс E2 только к O-DU. Наконец, правая сторона рис. 4 представляет вариант, в котором все узлы (кроме SMO) объединены вместе, таким образом, интерфейс E2 является полностью внутренним, имеется только одно соединение O1 и всегда присутствует интерфейс A1.
Резюме
В этом посте обсуждаются узлы и интерфейсы, определенные O-RAN Alliance. Предоставленные варианты реализации визуализируют одно из преимуществ O-RAN, а именно гибкость реализации с открытой архитектурой O-RAN. Эти варианты, с одной стороны, обеспечивают гибкость в реализации и различных конфигурациях поставщиков, но цена, которую приходится платить за это разнообразие, заключается в том, что нужен способ идентификации внутренних узлов, которые вы хотите контролировать, т.е. для этого требуются интерфейс E2 и интерфейс O1. чтобы иметь возможность фиксировать все эти различные параметры и инкапсулировать элементы управления, например, только для O-DU.
Обратите внимание, что O-RAN Alliance совсем недавно выпустила новый набор спецификаций вместе со значительными обновлениями существующих [12].
Аббревиатуры
5GC 5G Core Network
5QI 5G QoS Indicator
AMF Access and Mobility Function
API Application Programming Interface
CA Cell Association
CN Core Network
CP Control Plane
CU Central Unit
D/A Digital to analog
DU Distributed Unit
FCAPS Fault, Configuration, Accounting, Performance, Security
FH Fronthaul
gNB next-generation NodeB
I/F Interface
LLS Lower-Layer Split
MAC Medium Access Control
MANO Management and Orchestration
MBB Mobile Broadband
Mgmt Management
ML Machine Learning
NG-RAN Next Generation RAN
nRT near Real Time
O-CU-CP O-RAN Central Unit Control Plane
O-CU-UP O-RAN Central Unit User Plane
O-DU O-RAN Distributed Unit
O-eNB O-RAN evolved NodeB
ONF Open Networking Foundation
O-RAN Open RAN
O-RU O-RAN Radio Unit
OSC O-RAN Software Community
PDCP Packet Data Convergence Protocol
PHY Physical Layer
PM Performance Measurements
QoS Quality of Service
R/W Read/Write
RA Resource Allocation
RAN Radio Access Network
RFE Radio Front-End
RIC RAN Intelligent Controller
RLC Radio Link Control
RRC Radio Resource Control
RRM Radio Resource Management
RT Real-Time
RU Remote/Radio-Unit
SDAP Service Data Adaptation Protocol
SD-RAN Software Defined RAN
SM Spectrum Management
SMO Service Management and Orchestration
S-NSSAI Single - Network Slice Selection Assistance ID
SON Self-Organizing Networks
TS Traffic Steering
UE User Equipment
UPF User Plane Function
xApp Application to be placed at nRT RIC
Линки на источники
[1] O-RAN ALLIANCE (o-ran.org)
[2] 3GPP
[3] Open Networking Foundation
[4] SD-RAN – Open Networking Foundation
[5] Telecom Infra Project | Global Community Connectivity collaboration
[6] OpenRAN – Telecom Infra Project
[7] Home – Open RAN Policy Coalition
[8] O-RAN Software Community
[9] O-RAN Virtual Exhibition
[10] Open RAN Small Cell Forum
[11] O-RAN.WG1.O RAN Architecture Description v03.00, “O-RAN Architecture Description”, November 2020
[12] O-RAN ALLIANCE Introduces Minimum Viable Plan Towards Commercial O-RAN Solutions and 28 New O-RAN Specifications Released Since November 2020
GritsanY
Архитектура сотовой сети — это всегда что-то отличающееся от других систем. Как-то у вас мозги определённым образом склеены
keydet
В основном, все из-за эволюционного развития на протяжении очень длительного времени, еще со времен circuit switched networking, когда не пакеты рассылали, а коммутировали каналы. К примеру, только в ядре сети 5G перешли на полностью https взаимодействие, без всяких DIAMETER/RADIUS/ОКС-7. Если отслеживать архитектурную эволюцию по 3GPP спекам, то в целом все проясняется. Также, параллельно шла архитектурная эволюция от RISC до х86, от монолитов, до контейнерных микросервисов, со всеми сопутствующими плюшками, типа виртуализации, разделения на control/data plane и прочими вкусностями. Зачастую, чтобы ускорить процесс приложения не переписывались с нуля, а переносились в виртуальную среду, как "RISC плата с определенной допотопной функцией"=>"Виртуалка с определенной допотопной функцией" (так называемый, Lift and Shift).
Сейчас телеком вендоры обьединились и разрабатывают совместный фреймворк по стандартизации телеком сферы, под названием Frameworx. Он покрывает модель телеком-процессов eTOM, модель телеком-объектов SID и карту маппинга всего этого добра на телекомовские приложения TAM. Если интересно, как сейчас устроены мозги телеком архитекторов и в каком направлении развивается архитектура отрасли, то начните с вот этого: https://ru.m.wikipedia.org/wiki/Frameworx
vvpoloskin
Мне кажется, что такое разнообразие интерфейсов и сетевых элементов идёт в первую очередь от коммерционализации: технология строилась изначально из предпосылки, что за связь надо платить, и ключевую роль во всей системе играет биллинг.
Ни сети SDH/PDH, ни WiFi, ни WiMAX, ни КТВ, ни DWDM, ни Ethernet, ни IP не обладают таким разнообразием сетевых элементов. Почему? А потому что автоматизированный расчёт оплаты за услугу к ним приделан сбоку, как дополнение, изначально они проектировались без этого. Зато если задаться целью и разрисовать инфраструктуру фиксированного ШПД, особенно с учетом разных сред передачи на «последней миле» в виде ADSL и xPON, выделив под каждый функционал отдельный сетевой элемент и обозвав интерфейсы отбельными обозначениями, станет очень похоже на 3gpp (по крайней мере в части передачи данных). Отличие будет только в отсутствии роуминга.