В таблице «Протоколы и функции цифрового модуля», на мой взгляд, функции лучше разделить не на «Layer 3» и «Layer 1 high + Layer 2», а хотя бы на «L3/L2» (SDAP/RRC/PDCP, RLC/MAC) и на «High PHY».
В L3/L2 осуществляется пакетная обработка, для которой хорошо подходит CPU, а High PHY функции оптимально выгрузить на акселератор, желательно все (режим акселерации Inline), совместив с eCPRI/NIC и с синхронизацией (GNSS/PTP/SyncE), как это делается, например, в акселераторе, разработанном совместно Dell-ом и Marvell-ом.
Можно ещё разделить L3 (SDAP/RRC, PDCP) и L2 (RLC, MAC), так как они в Open RAN, обычно, реализуются раздельно: в CU и в DU соответственно. Такое разделение также полезно потому, что отельные функции User Plane части CU (CU-UP) могут выгружаться из CPU, например, в P4-коммутатор (может быть реализован на FPGA), как это делается в ONF SD-RAN, а Control Plane функции CU (CU-CP) могут выгружаться в xApps приложения nRT-RIC контроллера.
Честно говоря, в XRAN до O-RAN меня интересовал только FrontHaul и то, что XRAN занимался ещё и RIC-ом, я не знал.
В O-RAN есть два RIC-а: nRT-RIC и NRT-RIC. Вы какой из них имеете ввиду?
NRT-RIC, по-моему, сейчас безальтернативно — ONAP.
А у nRT-RIC, как писал выше, есть два варианта: u-ONOS (micro ONOS) от ONF или RIC от LFN O-RAN SC (контрибуторы AT&T и Nokia).
При слове Стендфорт у меня всплывает в памяти только SDN и OpenFlow c Nick-ом McKeown и Scott-ом Shenker, которые сейчас считаются отцами-основателями SDN.
Насчёт наибольшей зрелости OAI согласен. Не знаю только, как насчёт RAN части, но EPC часть используется в Magma проекте (инициатор Facebook), коммерчески поддерживаемом Mirantis-ом. Интересно, что Magma сотрудничает с COMAC (Converged Multi-Access and Core) и OMEC (Open Mobile Evolved Core) проектами ONF. Если вам известны близкие к коммерческим реализации OAI RAN, было бы очень интересно о них узнать.
Интересно!
В 3GPP жуткая тьма спецификаций и все какие-то «зашифрованные», в том смысле, что в них (на мой взгляд) много косвенных формулировок, и чтобы докопаться до сути приходится много копать в других документах. Так как я не специализируюсь только на мобильной связи, то из тех спецификаций, которые мне удалось просмотреть, нигде не попадалось разделение CU на CP и UP. Буду признателен, если подскажите, в каком TS это написано.
SBI — Service Based Inerface. Вообще-то, я имел ввиду термин SBA (Service-Based Architecture) — IT-подобная архитектура пакетного ядра 5G (5GC). SBI является частью SBA.
RAN functional split — это то, что в статье называется «CU/DU functional split» в соответствии с 3GPP. Основных сплитов, определённых в 3GPP, всего 8, и потенциально любой из них может использоваться для CU/DU (Central Unit, Distributed Unit) разделения, но стандартизирован сплит 2 (F1 интерфейс).
К CD/DU компонентам в соответствие с O-RAN добавляется RU (Remote или Radio Unit), т.е. к стандартному высокоуровневому сплиту (HLS) между CU и DU (интерфейс F1) добавляется низкоуровневый сплит (LLS) между DU и RU. Есть несколько вариантов использования LLS. Для простоты можно сказать, что F1 — это сплит 2, а O-RAN Open FronHaul (OFH) — это сплит 7-2x (вариация сплита 7). А например, Small Cell Forum (SCF) использует сплит 6.
Разделение User Plane (UP) и Control Plane (CP) — это то, что в статье называется «Control/user plane separation». В 4G это было архитектурным обновлением в виде CUPS (Control/User Plane Separation), а в 5G это было заложено изначально для пакетного ядра (5GC) путём отделения UP-компонента UPF от CP-компонента SMF. В части RAN такое разделение в O-RAN сделано для CU (Central Unit) компонента на CP-CP и CP-UP.
Следует добавить, что в O-RAN кроме UP и CP используется разделение MP (Managenment Plane) – функции MP выносятся в NRT-RIC. Функциональное разделение на UP, CP и MP в сетях фиксированной связи используется более 20 лет, только там вместо UP используется термин DP (Data Plane).
Спасибо за развёрнутый ответ!
Стараясь не перегружать и не растягивать тест, я не стал перечислять и другие open-source проекты, наиболее продвинутым и наиболее используемым (насколько я могу судить по публикациям) из которых, как вы правильно заметили, является OAI или OSA (OAI Software Alliance), включающего UE, RAN и EPC части, каждую из которых можно использовать отдельно. К сожалению, пока open-source проектов в части пакетного ядра (EPC/5GC) существенно больше, чем в части RAN (LTE/NR). Например, здесь (https://arxiv.org/pdf/2005.10027.pdf) в части RAN кроме OAI упоминается только srsLTE и Radisys.
Но, насколько я могу судить, OAI пока не полностью соответствует архитектуре O-RAN альянса, создание которого в начале 2018 г., пожалуй, можно считать рождением полноценного Open RAN, которому предшествовали XRAN, C-RAN, Open vRAN и TIP OpenRAN (до объединения OpenRAN и OpenRAN 5G NR групп в окт. 2020 г.).
Насколько я знаю, в OAI нет вертикального разделения на UP, CP и MP, предусмотренного в O-RAN за счёт выноса CP в nRT-RIC (near Real-Time RAN Intelligent Controller) и MP в NRT-RIC (Non-Real-Time RIC). В данном случае, nRT-RIC и NRT-RIC являются аналогами SDN контроллера в CP (Control Plane) и в MP (Management Plane) части соответственно. Это отдельная интересная тема. Так, Ericsson выступает против nRT-RIC и участвует только в NRT-RIC части O-RAN. Но наиболее разрушительным (disruptive) потенциалом Open RAN для бизнеса традиционных RAN-вендоров, наряду с Open FrontHaul (OFH), на мой взгляд, всё-таки обладает nRT-RIC.
Сейчас есть два open-source проекта nRT-RIC: в составе LFN (Linux Foundation Networking) O-RAN SC (OSC) проекта, курируемого O-RAN альянсом, контрибуторами которого (в части nRT-RIC) являются AT&T и Nokia, и ONF SD-RAN на базе SDN-контроллера ONOS, код которого (в части SDN) уже является довольно зрелым и используется некоторыми отдельными операторами.
Также, вы как сотрудник Intel знаете, что ONF SD-RAN в части CU-UP (Central Unit User Plane) намерен использовать P4 white-box коммутаторы, чипы для которых (Tofino/Tofino2) теперь производит Intel с приобретением BareFoot Network. Т.е., и P4 тоже является частью Open RAN. Конечно, P4 не сможет реализовать всех CU-UP функций, но для решения простых и массовых задач он подойдёт.
Позволю не согласиться с узостью темы. Да, для сегодняшних традиционных вендоров и подавляющего большинства операторов, исключая лидеров (AT&T, Rakuten, Vodafone и пр.), сейчас это экзотика. Но, еа мой взгляд, важно понимать, что реально происходит и почему это происходит. Можно много философствовать, но 5G стал революционным шагом трансформации мобильной связи, окончательно определив переход на цифровые технологии: SBI, RAN functional split, архитектурное разделение User Plane (UP) и Control Plane (CP) в RAN/5GC. Конечно, ещё можно строить 5G сети по старинке, но новые возможности открытости, дезагрегации и виртуализации, создающие условия для внедрения SDN, NFV и Cloud-Native технологий в RAN и в 5GC, нативно заложены в 5G.
Если говорить про широту/узость темы Open RAN, то, если рассмотреть общие тенденции трансформации ИКТ, по меньшей мере, за последние 8 лет, то можно заметить, что RAN стал последним технологическим доменом (вслед за пакетным транспортом, оптическим транспортом и DWDM), в котором стали реализовываться принципы открытости и SDN/NFV/Cloud-Native, а именно горизонтальная дезагрегация (разделение на RU, DU, CU), вертикальная дезагрегация (разделение на UP, CP и MP), виртуализация. Эти технологии не привязаны только к 5G и могут быть реализованы во всех беспроводных сетях (2G, 3G, 4G, WiFi). Более того, обновления версий/релизов RAN могут быть практически непрерывными и постоянными (CI/CD), что может отменить прежний подход разделения поколений связи, т.е. 5G может по сути оказаться последним G. Хотя маркетологам нравится создавать шумиху вокруг очередного G. Другими словами, на общей платформе (MEC/DC) средствами Open RAN будут одновременно реализовываться разные RAT для разных сценариев использования.
Отдельная большая тема: как относятся (сопротивляются) к Open RAN традиционные вендоры, «держащие за горло» операторов (а не наоборот), как в Open RAN жизненно заинтересованы целые государства (те же упомянутые в статье США) для обеспечения безопасности своих цифровых экономик, какие варианты Open RAN окажутся наиболее востребованными, каков темп перехода на Open RAN (перевес в пользу Open RAN, полный переход на Open RAN), какую роль в Open RAN играют open-source и white-box (O-RAN SC, TIP OpenRAN/Evenstar, ONF SD-RAN). Надеюсь, эти темы Александр поднимет в своих дальнейших статьях.
В таблице «Протоколы и функции цифрового модуля», на мой взгляд, функции лучше разделить не на «Layer 3» и «Layer 1 high + Layer 2», а хотя бы на «L3/L2» (SDAP/RRC/PDCP, RLC/MAC) и на «High PHY».
https://itechinfo.ru/content/%D1%81%D0%B5%D1%82%D1%8C-%D1%80%D0%B0%D0%B4%D0%B8%D0%BE%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B0-5g-%D1%87%D0%B0%D1%81%D1%82%D1%8C-1
В L3/L2 осуществляется пакетная обработка, для которой хорошо подходит CPU, а High PHY функции оптимально выгрузить на акселератор, желательно все (режим акселерации Inline), совместив с eCPRI/NIC и с синхронизацией (GNSS/PTP/SyncE), как это делается, например, в акселераторе, разработанном совместно Dell-ом и Marvell-ом.
Можно ещё разделить L3 (SDAP/RRC, PDCP) и L2 (RLC, MAC), так как они в Open RAN, обычно, реализуются раздельно: в CU и в DU соответственно. Такое разделение также полезно потому, что отельные функции User Plane части CU (CU-UP) могут выгружаться из CPU, например, в P4-коммутатор (может быть реализован на FPGA), как это делается в ONF SD-RAN, а Control Plane функции CU (CU-CP) могут выгружаться в xApps приложения nRT-RIC контроллера.
В O-RAN есть два RIC-а: nRT-RIC и NRT-RIC. Вы какой из них имеете ввиду?
NRT-RIC, по-моему, сейчас безальтернативно — ONAP.
А у nRT-RIC, как писал выше, есть два варианта: u-ONOS (micro ONOS) от ONF или RIC от LFN O-RAN SC (контрибуторы AT&T и Nokia).
При слове Стендфорт у меня всплывает в памяти только SDN и OpenFlow c Nick-ом McKeown и Scott-ом Shenker, которые сейчас считаются отцами-основателями SDN.
В 3GPP жуткая тьма спецификаций и все какие-то «зашифрованные», в том смысле, что в них (на мой взгляд) много косвенных формулировок, и чтобы докопаться до сути приходится много копать в других документах. Так как я не специализируюсь только на мобильной связи, то из тех спецификаций, которые мне удалось просмотреть, нигде не попадалось разделение CU на CP и UP. Буду признателен, если подскажите, в каком TS это написано.
Если вы не против, напишу лично.
RAN functional split — это то, что в статье называется «CU/DU functional split» в соответствии с 3GPP. Основных сплитов, определённых в 3GPP, всего 8, и потенциально любой из них может использоваться для CU/DU (Central Unit, Distributed Unit) разделения, но стандартизирован сплит 2 (F1 интерфейс).
К CD/DU компонентам в соответствие с O-RAN добавляется RU (Remote или Radio Unit), т.е. к стандартному высокоуровневому сплиту (HLS) между CU и DU (интерфейс F1) добавляется низкоуровневый сплит (LLS) между DU и RU. Есть несколько вариантов использования LLS. Для простоты можно сказать, что F1 — это сплит 2, а O-RAN Open FronHaul (OFH) — это сплит 7-2x (вариация сплита 7). А например, Small Cell Forum (SCF) использует сплит 6.
Разделение User Plane (UP) и Control Plane (CP) — это то, что в статье называется «Control/user plane separation». В 4G это было архитектурным обновлением в виде CUPS (Control/User Plane Separation), а в 5G это было заложено изначально для пакетного ядра (5GC) путём отделения UP-компонента UPF от CP-компонента SMF. В части RAN такое разделение в O-RAN сделано для CU (Central Unit) компонента на CP-CP и CP-UP.
Следует добавить, что в O-RAN кроме UP и CP используется разделение MP (Managenment Plane) – функции MP выносятся в NRT-RIC. Функциональное разделение на UP, CP и MP в сетях фиксированной связи используется более 20 лет, только там вместо UP используется термин DP (Data Plane).
Стараясь не перегружать и не растягивать тест, я не стал перечислять и другие open-source проекты, наиболее продвинутым и наиболее используемым (насколько я могу судить по публикациям) из которых, как вы правильно заметили, является OAI или OSA (OAI Software Alliance), включающего UE, RAN и EPC части, каждую из которых можно использовать отдельно. К сожалению, пока open-source проектов в части пакетного ядра (EPC/5GC) существенно больше, чем в части RAN (LTE/NR). Например, здесь (https://arxiv.org/pdf/2005.10027.pdf) в части RAN кроме OAI упоминается только srsLTE и Radisys.
Но, насколько я могу судить, OAI пока не полностью соответствует архитектуре O-RAN альянса, создание которого в начале 2018 г., пожалуй, можно считать рождением полноценного Open RAN, которому предшествовали XRAN, C-RAN, Open vRAN и TIP OpenRAN (до объединения OpenRAN и OpenRAN 5G NR групп в окт. 2020 г.).
Насколько я знаю, в OAI нет вертикального разделения на UP, CP и MP, предусмотренного в O-RAN за счёт выноса CP в nRT-RIC (near Real-Time RAN Intelligent Controller) и MP в NRT-RIC (Non-Real-Time RIC). В данном случае, nRT-RIC и NRT-RIC являются аналогами SDN контроллера в CP (Control Plane) и в MP (Management Plane) части соответственно. Это отдельная интересная тема. Так, Ericsson выступает против nRT-RIC и участвует только в NRT-RIC части O-RAN. Но наиболее разрушительным (disruptive) потенциалом Open RAN для бизнеса традиционных RAN-вендоров, наряду с Open FrontHaul (OFH), на мой взгляд, всё-таки обладает nRT-RIC.
Сейчас есть два open-source проекта nRT-RIC: в составе LFN (Linux Foundation Networking) O-RAN SC (OSC) проекта, курируемого O-RAN альянсом, контрибуторами которого (в части nRT-RIC) являются AT&T и Nokia, и ONF SD-RAN на базе SDN-контроллера ONOS, код которого (в части SDN) уже является довольно зрелым и используется некоторыми отдельными операторами.
Также, вы как сотрудник Intel знаете, что ONF SD-RAN в части CU-UP (Central Unit User Plane) намерен использовать P4 white-box коммутаторы, чипы для которых (Tofino/Tofino2) теперь производит Intel с приобретением BareFoot Network. Т.е., и P4 тоже является частью Open RAN. Конечно, P4 не сможет реализовать всех CU-UP функций, но для решения простых и массовых задач он подойдёт.
Если говорить про широту/узость темы Open RAN, то, если рассмотреть общие тенденции трансформации ИКТ, по меньшей мере, за последние 8 лет, то можно заметить, что RAN стал последним технологическим доменом (вслед за пакетным транспортом, оптическим транспортом и DWDM), в котором стали реализовываться принципы открытости и SDN/NFV/Cloud-Native, а именно горизонтальная дезагрегация (разделение на RU, DU, CU), вертикальная дезагрегация (разделение на UP, CP и MP), виртуализация. Эти технологии не привязаны только к 5G и могут быть реализованы во всех беспроводных сетях (2G, 3G, 4G, WiFi). Более того, обновления версий/релизов RAN могут быть практически непрерывными и постоянными (CI/CD), что может отменить прежний подход разделения поколений связи, т.е. 5G может по сути оказаться последним G. Хотя маркетологам нравится создавать шумиху вокруг очередного G. Другими словами, на общей платформе (MEC/DC) средствами Open RAN будут одновременно реализовываться разные RAT для разных сценариев использования.
Отдельная большая тема: как относятся (сопротивляются) к Open RAN традиционные вендоры, «держащие за горло» операторов (а не наоборот), как в Open RAN жизненно заинтересованы целые государства (те же упомянутые в статье США) для обеспечения безопасности своих цифровых экономик, какие варианты Open RAN окажутся наиболее востребованными, каков темп перехода на Open RAN (перевес в пользу Open RAN, полный переход на Open RAN), какую роль в Open RAN играют open-source и white-box (O-RAN SC, TIP OpenRAN/Evenstar, ONF SD-RAN). Надеюсь, эти темы Александр поднимет в своих дальнейших статьях.