带个Open你以为就是福利？说说OpenRAN的概念陷阱

Vortex

最近印度和日本的一些运营商部署OpenRAN后，国内不少资本似乎也是蠢蠢欲动，然而ORAN真的那么美好吗？

说美好的很显然都是对射频一窍不通的投机客，IT界的OpenXXX项目，通常特点都是开源，社区维护，和vendor free，这里面vendor free尤其重要，例如核心网NFV化，MME HSS PGW等网元可以以纯软件形式运行于任何厂家的带分支预测的通用处理器上面，同时开源也使得获取代码不受任何人限制，也不会被任何厂家用垄断来抬高宿主硬件的价格，这才叫Open。

至于为什么OpenRAN就是坑了？容我慢慢道来，首先可能你们看到了富士通NEC和airtel在采用一些ORAN硬件了，然而这些硬件本质上依然是高度厂商依赖性的，也就是vendor lock,表面上看着像是在搞Open,实际上本质是那些IT厂家借着open的幌子抢夺传统CT设备厂家的市场的，其设备可以说如果有详细拆解分析后跟传统CT厂家的设备区别并不会很大，而且性能可能还更差一点。

也许这些厂家会用SDR实现，然而目前facebook之前的ORAN概念用SDR实现已经证明依然是高度vendor lock，基本都是ettus 的USRP，这也是为什么euracom的OAI也是一直处于纸上谈兵的状态，究其根本也是因为一直在犯这种错，他家的NFV eNodeB基本也只能运行于USRP这种昂贵的硬件平台上，这就依然是vendor lock的问题。

如果用ASIC，那就跟HZEN等传统厂家的设备没有区别了，只是换供应商而已，而事实上，RAN侧的空口短期内依然是3GPP的最大堡垒，开源IT技术难以取代这块，即便是目前最开放的802.11(很多厂家的空口源码是可以获取的)也难以支撑目前3GPP系级别的用户量，射频前端对于功率和处理速率的极端要求(I/Q数据量基本都是Gbps级别)，注定需要用FPGA，否则使用同等的通用处理器就不是这价格了。

总而言之，从802.11系的厂家生态链来看，拥有更多的竞争对手，尽可能的标准化，利于ASIC大量生产，形成规模效应，才能最终降低RAN侧的成本，这之前指望什么鼓吹的ORAN是不现实的，开源open是个好东西，避免重复劳动，但是想短时间内替代必要劳动是不可能的，谨慎看待某些IT厂家鼓吹ORAN概念，目前也就OpenCN比较现实

没事来看看

威尼斯人官方网站技术你问我答 (积分兑奖)

说的很中肯，虽然个人不是很赞同

2xy

任何的垄断都不是好东西

Vortex

没事来看看 发表于 2020-5-7 14:32
说的很中肯，虽然个人不是很赞同

前辈有何高见，我也只是说下我所了解的

没事来看看

Vortex 发表于 2020-5-7 14:43
前辈有何高见，我也只是说下我所了解的

个人观点，在IT行业中曾经出现的小型机-PC服务器替换，肯定会在CT行业中重演。这种替换肯定是个漫长而且艰难的过程，核心网本来就是个IT属性很强的网元，所以最早完成NFV化是必然的；在众多网元中，RAN的解耦和重构肯定是最困难的，对于性能 时延 可靠性要求都很高。

海外的那些运营商，情况我不太了解，不好说。从目前来看，国内的O-RAN走的思路是比较务实的，现在小基站中做，这既能减少部署的难度，也不会太损害HZEN的利益，从OTIC的结果来看，是可以用的。而且就是在小站中，RRU部分还是由特殊的厂商来提供，解耦肯定是一步步来，能解的解，不能或者现阶段存在障碍的就先放放，一步到位肯定是不现实的。

但我相信通用处理器的进化速度，以及它的成本与产业链优势！

Vortex

没事来看看 发表于 2020-5-7 15:28
个人观点，在IT行业中曾经出现的小型机-PC服务器替换，肯定会在CT行业中重演。这种替换肯定是个漫长而且艰 ...

‘很同意，我也是类似意思，但是个人感觉短时间内，模拟那块想白盒化，非常困难，凡是当下吹这点的都不太靠谱，而且今年wifi6反而让空口开始封闭黑盒化起来了

马云的云

RAN侧如果不能一下子全部软件化，是不是可以从一部分开始，比如先从L2层往上的信令面开始？用户面和L2以下仍然高度标准化并用ASIC实现，L2往上信令面用通用CPU实现是否可以？

具体到设备，就是AAU、DU以ASIC实现，CU中的主控板以通用x86/Arm/Risc服务器实现，载频板用半通用的FPGA实现，短期内是否经济可行？

Vortex

马云的云 发表于 2020-5-7 15:39
RAN侧如果不能一下子全部软件化，是不是可以从一部分开始，比如先从L2层往上的信令面开始？用户面和L2以下仍 ...

主要是通用处理器实时生成I/Q信号太困难，实际上你说的L1解耦，CPRI早就实现类似的东西了

马云的云

把BBU黑盒子给打开、对BBU内各单板之间的接口进行标准化，是目前急迫的需求。

这样各单板可以单独升级，例如在mMTC的低功耗大连接场景，跟目前的移动宽带场景差别很大，mMTC的RRC是eMBB的RRC数量的100～1000倍，数据量是eMBB的1/100～1/1000，导致这种场景下，对以处理RRC为主的主控板性能要求极高，反而对处理用户面的载频板性能要求较低，在这种场景下，很可能PRB的大部分要分配给控制信道，小部分分配给共享数据信道，甚至不需要共享数据信道，直接在控制信道内随路传输少量数据即可。

由于mMTC场景和eMBB场景并不能严格区分，一个基站可能这会儿以eMBB场景为主，可能发生某个突发事件后（比如发生火灾或地震）触发了大量MTC传感器激活并立即传输数据，造成那会儿该基站以mMTC场景为主。这种情况下如何配置单板资源？如何确定主控板和载频板的比例？不好确定。

唯有让主控板云化，资源大范围共享，这样某个局部RRC爆发后，可以在云端实时给这个基站多分配一些虚拟主控板。等不需要的时候再把这些虚拟主控板撤回，反正通用CPU通用服务器还能干别的事儿。

马云的云

Vortex 发表于 2020-5-7 15:41
主要是通用处理器实时生成I/Q信号太困难，实际上你说的L1解耦，CPRI早就实现类似的东西了

现在不是又搞出一个eCPRI嘛，数据量骤降到CPRI的1/16，如果解耦层级再提高一点的话，数据量还能降的更多，且实时性要求更低。

BossDianel

ORAN现在好火啊。希望参与的公司不是帮别人打工，替别人数钱。

马云的云

Vortex 发表于 2020-5-7 15:41
主要是通用处理器实时生成I/Q信号太困难，实际上你说的L1解耦，CPRI早就实现类似的东西了

而且也没打算用CPU处理I/Q信号，那是网络加速卡干的事儿，就像GPU一样。

Vortex

马云的云 发表于 2020-5-7 15:52
把BBU黑盒子给打开、对BBU内各单板之间的接口进行标准化，是目前急迫的需求。

这样各单板可以单独升级， ...

你说的就是eNodeB云化，目前的趋势就是CRAN和RRH，注意是Head,直接CPRI类似的东西拉远，BBU云化后硬件利用率接近100%

马云的云

CPRI基本实现了RRU和BBU的解耦，尽管现在异厂家RRU+BBU的场景还不多见，但理论上是可以搭配的。

现在就是BBU内部亟待进一步打破解耦了，主要是主控板--载频板的解耦。

Vortex

马云的云 发表于 2020-5-7 15:57
而且也没打算用CPU处理I/Q信号，那是网络加速卡干的事儿，就像GPU一样。

那就又会陷入vendor lock啊，那还搞什么NFV

Vortex

马云的云 发表于 2020-5-7 15:56
现在不是又搞出一个eCPRI嘛，数据量骤降到CPRI的1/16，如果解耦层级再提高一点的话，数据量还能降的更多， ...

CRAN那个分层有好几层IF4/5好像比较现实，反正越接近I/Q传输量越高，也就现在光模块便宜了才支撑得起现在这种目标

马云的云

Vortex 发表于 2020-5-7 16:00
那就又会陷入vendor lock啊，那还搞什么NFV

拆的越细，被lock的面积就越小，比如电脑，我嫌显卡性能不好，我可以单独升级个显卡，主板不用换。

如果是主板集成显卡，那就无法单独换显卡，只能整个电脑报废换个新的了，这显然没有前者划算。

任何vendor lock都是不可避免的，只是lock范围越小越好，这样升级/替换的代价就越小。

Vortex

BossDianel 发表于 2020-5-7 15:56
ORAN现在好火啊。希望参与的公司不是帮别人打工，替别人数钱。

那要看做什么了,不过最近的基本都是炒作想虎口夺食的

Vortex

马云的云 发表于 2020-5-7 15:57
而且也没打算用CPU处理I/Q信号，那是网络加速卡干的事儿，就像GPU一样。

不过话说GPU能不能用来处理I/Q信号，这值得研究

马云的云

Vortex 发表于 2020-5-7 15:58
你说的就是eNodeB云化，目前的趋势就是CRAN和RRH，注意是Head,直接CPRI类似的东西拉远，BBU云化后硬件利用 ...

我说的和传统的C-RAN不是一码事。我说的侧重点是主控板和载频板解耦，且这俩部分可以异厂家配合。

主控板可以采用通用CPU架构，载频板采用通用FPGA或专用ASIC加速卡的架构，主控板是软硬件解耦，载频板可以继续黑盒（ASIC实现）也可以软硬件解耦（FPGA实现）。