通信人家园

标题: 带个Open你以为就是福利？说说OpenRAN的概念陷阱  [查看完整版帖子] [打印本页]
时间:  2020-5-7 14:24
作者: Vortex     标题: 带个Open你以为就是福利？说说OpenRAN的概念陷阱

最近印度和日本的一些运营商部署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比较现实

时间:  2020-5-7 14:32
作者: 没事来看看

说的很中肯，虽然个人不是很赞同
时间:  2020-5-7 14:35
作者: 2xy

任何的垄断都不是好东西
时间:  2020-5-7 14:43
作者: Vortex

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

前辈有何高见，我也只是说下我所了解的
时间:  2020-5-7 15:28
作者: 没事来看看

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

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

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

但我相信通用处理器的进化速度，以及它的成本与产业链优势！
时间:  2020-5-7 15:36
作者: Vortex

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

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

本帖最后由 马云的云 于 2020-5-7 15:54 编辑

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

具体到设备，就是AAU、DU以ASIC实现，CU中的主控板以通用x86/Arm/Risc服务器实现，载频板用半通用的FPGA实现，短期内是否经济可行？
时间:  2020-5-7 15:41
作者: Vortex

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

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

本帖最后由 马云的云 于 2020-5-7 15:58 编辑

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

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

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

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

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

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

ORAN现在好火啊。希望参与的公司不是帮别人打工，替别人数钱。
时间:  2020-5-7 15:57
作者: 马云的云

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

而且也没打算用CPU处理I/Q信号，那是网络加速卡干的事儿，就像GPU一样。
时间:  2020-5-7 15:58
作者: Vortex

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

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

你说的就是eNodeB云化，目前的趋势就是CRAN和RRH，注意是Head,直接CPRI类似的东西拉远，BBU云化后硬件利用率接近100%
时间:  2020-5-7 16:00
作者: 马云的云

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

现在就是BBU内部亟待进一步打破解耦了，主要是主控板--载频板的解耦。
时间:  2020-5-7 16:00
作者: Vortex

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

那就又会陷入vendor lock啊，那还搞什么NFV
时间:  2020-5-7 16:01
作者: Vortex

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

CRAN那个分层有好几层IF4/5好像比较现实，反正越接近I/Q传输量越高，也就现在光模块便宜了才支撑得起现在这种目标
时间:  2020-5-7 16:03
作者: 马云的云

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

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

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

任何vendor lock都是不可避免的，只是lock范围越小越好，这样升级/替换的代价就越小。
时间:  2020-5-7 16:03
作者: Vortex

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

那要看做什么了,不过最近的基本都是炒作想虎口夺食的
时间:  2020-5-7 16:04
作者: Vortex

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

不过话说GPU能不能用来处理I/Q信号，这值得研究
时间:  2020-5-7 16:07
作者: 马云的云

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

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

主控板可以采用通用CPU架构，载频板采用通用FPGA或专用ASIC加速卡的架构，主控板是软硬件解耦，载频板可以继续黑盒（ASIC实现）也可以软硬件解耦（FPGA实现）。
时间:  2020-5-7 16:12
作者: Vortex

本帖最后由 Vortex 于 2020-5-7 16:13 编辑
马云的云 发表于 2020-5-7 16:07
我说的和传统的C-RAN不是一码事。我说的侧重点是主控板和载频板解耦，且这俩部分可以异厂家配合。

主控 ...

你还在分主控板载频板就说明你没彻底理解NFV，eNodeB在NFV/CRAN里面只会是一个软件了，然后通过ethernet直接和RRH通过IF4/5等前传协议去联系，中间所有经过的东西都是IT常用的通用白牌硬件，整个系统里只剩RrH里面有一部分需要高集成度处理IQ数据的ASIC主控和没法通用化的RF模拟器件
时间:  2020-5-7 16:16
作者: Vortex

马云的云 发表于 2020-5-7 16:00
CPRI基本实现了RRU和BBU的解耦，尽管现在异厂家RRU+BBU的场景还不多见，但理论上是可以搭配的。

现在就是 ...

好像现在异厂家的RRU BBU并不兼容吧？虽说有个CPRI协议，但是据说都互不兼容
时间:  2020-5-7 16:17
作者: 没事来看看

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

现有的架构下，大部分公司也是给别人打工啊，比如给华为做配套的，还指望能赚多少钱
时间:  2020-5-7 16:17
作者: 马云的云

Vortex 发表于 2020-5-7 16:12
你还在分主控板载频板就说明你没彻底理解NFV，eNodeB在NFV/CRAN里面只会是一个软件了，然后通过ethernet直 ...

那是终极目标，但当下eNB马上实现全面虚拟化还不太现实，而且容易引起传统设备商的反对，对他们利益伤害太大。

我说的是中间步骤，就是先把处理信令面的部分给拆出来，用户面部分因为算法固定、数据量大、实时性要求高，用FPGA或ASIC实现具有能耗优势，这部分也是传统设备商的强项，这部分钱继续让他们赚着，不然一下子给人断粮也不合适。
时间:  2020-5-7 16:20
作者: 马云的云

Vortex 发表于 2020-5-7 16:16
好像现在异厂家的RRU BBU并不兼容吧？虽说有个CPRI协议，但是据说都互不兼容

既然协议都有了，咋不能彻底拆开，协议不明晰的就细化协议，多种实现的就继续给统一成标准化实现。

现在只是没有强势运营商主导RRU和BBU拆分罢了，不然谁不兼容标准，就不买谁的设备，看谁硬气。
时间:  2020-5-7 16:22
作者: Vortex

马云的云 发表于 2020-5-7 16:20
既然协议都有了，咋不能彻底拆开，协议不明晰的就细化协议，多种实现的就继续给统一成标准化实现。

现 ...

我感觉运营商并不是很在乎rru基本当送的
时间:  2020-5-7 16:23
作者: 马云的云

Vortex 发表于 2020-5-7 16:04
不过话说GPU能不能用来处理I/Q信号，这值得研究

GPU本质上还是一种专用于图形算法的ASIC，如果处理I/Q信号的算法不同，那针对处理I/Q信号的算法专门设计一款加速芯片也不是多难的事儿，就像现在机器学习已经有专用芯片，比用GPU效率更高是一个道理。
时间:  2020-5-7 16:24
作者: yinfang00150537

无论是ORAN，还是Open RAN，运营商都不会太Care，最关注的问题，还是如何降低CapEx。互联互通带来的OpEx成本会被同城同厂家的方式。
时间:  2020-5-7 16:28
作者: 马云的云

Vortex 发表于 2020-5-7 16:22
我感觉运营商并不是很在乎rru基本当送的

羊毛出在羊身上，就算是送的，成本已经算在BBU里面了。

而且RRU也不便宜，一个基站3个扇区就得要3个RRU，如果一个基站2个频段用不同的RRU的话就得6个RRU，一个RRU哪怕只要1万块钱，那也是6万块啊。
时间:  2020-5-7 16:33
作者: 考拉不是骆驼

一堆技术名词，看着有点头疼，先马下来慢慢看；
时间:  2020-5-7 16:34
作者: 马云的云

yinfang00150537 发表于 2020-5-7 16:24
无论是ORAN，还是Open RAN，运营商都不会太Care，最关注的问题，还是如何降低CapEx。互联互通带来的OpEx成本 ...

如何降低CAPEX？只能是拆细、引入多供应商。供应商越多、竞争越激烈，自然越便宜。

而且拆的越细，升级替换的时候，可以局部替换，不必整个替换，也可以节约成本。

例如4G升5G，主要是频谱带宽增加、天线增加，而用户数没怎么增加。这就意味着，信令面所需要的算力，5G相比4G并没有显著增加，只是增加了用户面的算力。

那么4G升5G，为什么不能继续使用处理信令面为主的原先4G基站主控板呢？因为没有解耦，无法继续使用原有资源（也可能是能升级但设备商想多卖钱不给你升级）。
时间:  2020-5-7 16:36
作者: Vortex

马云的云 发表于 2020-5-7 16:23
GPU本质上还是一种专用于图形算法的ASIC，如果处理I/Q信号的算法不同，那针对处理I/Q信号的算法专门设计一 ...

关键GPU是现成的啊，而且也能做特定数学运算
时间:  2020-5-7 16:37
作者: Vortex

yinfang00150537 发表于 2020-5-7 16:24
无论是ORAN，还是Open RAN，运营商都不会太Care，最关注的问题，还是如何降低CapEx。互联互通带来的OpEx成本 ...

我是在说未来，照你这种思维Android就不该出现，那你继续用塞班呗
时间:  2020-5-7 16:39
作者: Vortex

yinfang00150537 发表于 2020-5-7 16:24
无论是ORAN，还是Open RAN，运营商都不会太Care，最关注的问题，还是如何降低CapEx。互联互通带来的OpEx成本 ...

到时候成熟了，设备不到以前1/10价格你们还不是要叫真香
时间:  2020-5-7 16:40
作者: Vortex

本帖最后由 Vortex 于 2020-5-7 16:41 编辑
马云的云 发表于 2020-5-7 16:20
既然协议都有了，咋不能彻底拆开，协议不明晰的就细化协议，多种实现的就继续给统一成标准化实现。

现 ...

但是既然RRU独立出来了，那为何干脆不直接用ethernet向RRU里注数据？真成了，那才叫扁平化
时间:  2020-5-7 16:41
作者: 马云的云

Vortex 发表于 2020-5-7 16:36
关键GPU是现成的啊，而且也能做特定数学运算

这种加速卡很好开发的，都不说国外，国内IC设计公司分分钟给你设计出十来种芯片，我以前公司做的网络防火墙里面的加密解密算法都用了个专用的ASIC芯片加速加解密运算，比GPU能效高多了，还有BTC矿机也都是专用芯片，不用GPU，专用芯片能耗低，加速快，成本也便宜，如果用GPU，由于算法不同，GPU内很多晶体管用不上，不就浪费了嘛。
时间:  2020-5-7 16:43
作者: Vortex

本帖最后由 Vortex 于 2020-5-7 16:45 编辑
马云的云 发表于 2020-5-7 16:41
这种加速卡很好开发的，都不说国外，国内IC设计公司分分钟给你设计出十来种芯片，我以前公司做的网络防火 ...

但是PC上的GPU是COTS啊，COTS是NFV的一大要素，我觉得浪费并不是问题，关键是便宜，GPU这种现在ARM/x86来源都都很丰富的极难被垄断，而且本身GPU就是给并行用的，符合I/Q信号处理大带宽并行处理的特征
时间:  2020-5-7 16:47
作者: 没事来看看

从O-RAN Open-RAN的产业发展角度来看，3GPP的那套玩意现在已经成了绊脚石了。
时间:  2020-5-7 16:47
作者: 马云的云

Vortex 发表于 2020-5-7 16:40
但是既然RRU独立出来了，那为何干脆不直接用ethernet向RRU里注数据？真成了，那才叫扁平化

eCPRI就是基于Ethernet承载的，CPRI对实时性太高，Ethernet不支持。

关键不是CPRI的承载协议，那个用不用Ethernet都无所谓，只要大家统一就行，就像PTN不也是运营商给搞出来一套统一的协议嘛。
时间:  2020-5-7 16:48
作者: xuqz

竞争手段
时间:  2020-5-7 16:49
作者: Vortex

马云的云 发表于 2020-5-7 16:47
eCPRI就是基于Ethernet承载的，CPRI对实时性太高，Ethernet不支持。

关键不是CPRI的承载协议，那个用不 ...

eurecom反正在他的OAI推的是ethernet承载，为啥？ethernet基本是现在随手最容易接触到的成本最低的COTS传输硬件
时间:  2020-5-7 16:50
作者: Vortex

没事来看看 发表于 2020-5-7 16:47
从O-RAN Open-RAN的产业发展角度来看，3GPP的那套玩意现在已经成了绊脚石了。

拉锯战，设备商想搞封闭，运营商想开放，就我看，运营商只能选NFV的路，否则以后被套的死死
时间:  2020-5-7 16:50
作者: 马云的云

Vortex 发表于 2020-5-7 16:43
但是PC上的GPU是COTS啊，COTS是NFV的一大要素，我觉得浪费并不是问题，关键是便宜，GPU这种现在ARM/x86来 ...

GPU不够COTS，FPGA才是真正的COTS，通过烧ROM可以更新FPGA的加速算法，这个比以ASIC实现的GPU更通用。
时间:  2020-5-7 16:52
作者: 马云的云

没事来看看 发表于 2020-5-7 16:47
从O-RAN Open-RAN的产业发展角度来看，3GPP的那套玩意现在已经成了绊脚石了。

就是，3GPP里整天吵来吵去，还不如事实标准。
时间:  2020-5-7 16:53
作者: Vortex

本帖最后由 Vortex 于 2020-5-7 16:54 编辑
马云的云 发表于 2020-5-7 16:50
GPU不够COTS，FPGA才是真正的COTS，通过烧ROM可以更新FPGA的加速算法，这个比以ASIC实现的GPU更通用。

这么说吧，2C能买到的为唯一衡量标准，FPGA也不是普通C能买到的
时间:  2020-5-7 16:54
作者: 马云的云

3GPP里80%的Feature基本上没有超过20%的运营商买单，都变成垃圾了，原因何在？
时间:  2020-5-7 16:55
作者: Vortex

马云的云 发表于 2020-5-7 16:54
3GPP里80%的Feature基本上没有超过20%的运营商买单，都变成垃圾了，原因何在？

每年那么多提案，变成现网功能的有多少？在乎那个并没有用
时间:  2020-5-7 16:57
作者: 马云的云

Vortex 发表于 2020-5-7 16:53
这么说吧，2C能买到的为唯一衡量标准，FPGA也不是普通C能买到的

2C能买到，阿里云上一堆FPGA服务器，还有一个FPGA ROM商店，你可以直接挑别人写好的ROM烧进去，如果没有符合你需求的ROM，你也可以自己写一个烧进去。

16年我在阿里云上训练神经网络的时候还是用GPU服务器，现在都不用GPU了，已经有专门的AI服务器了。其实GPU在服务器上用途不大，毕竟服务器没法用来打游戏。
时间:  2020-5-7 16:59
作者: Vortex

马云的云 发表于 2020-5-7 16:57
2C能买到，阿里云上一堆FPGA服务器，还有一个FPGA ROM商店，你可以直接挑别人写好的ROM烧进去，如果没有符 ...

但是还是没GPU来源丰富，现在是个电脑都有Intel的GPU，这还是最基本的
时间:  2020-5-7 17:00
作者: 云中云

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2020-5-7 17:01
作者: Vortex

马云的云 发表于 2020-5-7 16:57
2C能买到，阿里云上一堆FPGA服务器，还有一个FPGA ROM商店，你可以直接挑别人写好的ROM烧进去，如果没有符 ...

FPGA我所知道的Xlinx，Altera，Lattice基本都在豪门下吧？那价格，并没有2C的GPU便宜
时间:  2020-5-7 17:03
作者: Vortex

云中云 发表于 2020-5-7 17:00
NSA不是已经降低Capex了吗，不然全SA，那才是理想的5G

上SA大概率核心网就是NFV了，想再靠什么应用绑定不现实
时间:  2020-5-7 17:03
作者: 马云的云

Vortex 发表于 2020-5-7 16:59
但是还是没GPU来源丰富，现在是个电脑都有Intel的GPU，这还是最基本的

Intel的GPU也能用？不支持CUDA库是不行的，基本上都是用英伟达的，大部分算法库依赖CUDA。
时间:  2020-5-7 17:06
作者: 马云的云

Vortex 发表于 2020-5-7 17:01
FPGA我所知道的Xlinx，Altera，Lattice基本都在豪门下吧？那价格，并没有2C的GPU便宜

看跟谁比，英伟达的GPU可不便宜，AMD的稍微便宜一点但性能也次一些，其它的都没法用。
时间:  2020-5-7 17:07
作者: Vortex

马云的云 发表于 2020-5-7 16:41
这种加速卡很好开发的，都不说国外，国内IC设计公司分分钟给你设计出十来种芯片，我以前公司做的网络防火 ...

你可以看看17年OAI就有人研究过这问题了，GPU加速https://www.openairinterface.org ... ith_GPU_Offload.pdf
时间:  2020-5-7 17:08
作者: 云中云

提示: 作者被禁止或删除 内容自动屏蔽
时间:  2020-5-7 17:08
作者: Vortex

马云的云 发表于 2020-5-7 17:06
看跟谁比，英伟达的GPU可不便宜，AMD的稍微便宜一点但性能也次一些，其它的都没法用。

那也比FPGA便宜，2C的东西跟2B的价格根本不是一个档次
时间:  2020-5-7 17:08
作者: 马云的云

本帖最后由 马云的云 于 2020-5-7 17:09 编辑
Vortex 发表于 2020-5-7 17:03
上SA大概率核心网就是NFV了，想再靠什么应用绑定不现实

CT届折腾这么多年，连一个最基本的RAN层QoS都做不到，连一个全球通用户数据流量优先级高于神州行用户都做不到。

如果是IT厂家搞网络，这种能增收的VIP功能早几十年就做出来了，要不说运营商都是活该呢。

也不知道上了5G，全球通用户和神州行用户能划成不同的RAN切片不。
时间:  2020-5-7 17:09
作者: Vortex

马云的云 发表于 2020-5-7 17:06
看跟谁比，英伟达的GPU可不便宜，AMD的稍微便宜一点但性能也次一些，其它的都没法用。

看看TW的人做的
  1. www.openairinterface.org/docs/workshop/3_OAI_Workshop_20170427/Session1_C-RAN/Yuan-Te_Liao_-_Soft_PHY_with_GPU_Offload.pdf
复制代码
时间:  2020-5-7 17:10
作者: Vortex

马云的云 发表于 2020-5-7 17:08
CT届折腾这么多年，连一个最基本的RAN层QoS都做不到，连一个全球通用户数据流量优先级高于神州行用户都做 ...

你以为CT的人很有本事？大部分还不是拼芯片方案而已
时间:  2020-5-7 17:12
作者: 马云的云

本帖最后由 马云的云 于 2020-5-7 17:12 编辑
云中云 发表于 2020-5-7 17:08
国内这种AI服务器都是ASIC，发展下去有点入误区了，长期还是FPGA和GPU有前途。总之，这个方向都有问题的， ...

有啥误区的，这些ASIC也是PCI-E槽位插卡的，也能单独升级，等淘汰了，把卡拔下来插新的就是了，主板又不用动。

ASIC比GPU便宜，可能买5个ASIC加速卡比买一个GPU卡都还便宜，干嘛非跟GPU死磕。
时间:  2020-5-7 17:13
作者: Vortex

马云的云 发表于 2020-5-7 17:12
有啥误区的，这些ASIC也是PCI-E槽位插卡的，也能单独升级，等淘汰了，把卡拔下来插新的就是了，主板又不用 ...

就是为了避免vendor lock
时间:  2020-5-7 17:14
作者: Vortex

马云的云 发表于 2020-5-7 17:12
有啥误区的，这些ASIC也是PCI-E槽位插卡的，也能单独升级，等淘汰了，把卡拔下来插新的就是了，主板又不用 ...

NFV网络转发用通用处理器本身性能就很差，但是还是得硬着头皮搞，因为不搞就等着被宰
时间:  2020-5-7 17:14
作者: 马云的云

Vortex 发表于 2020-5-7 17:08
那也比FPGA便宜，2C的东西跟2B的价格根本不是一个档次

并没有，英伟达用于服务器的GPU卡比用于打游戏的GPU卡便宜，所以英伟达经常强调，严禁把用于服务器的GPU卡装到游戏工作站上面去。
时间:  2020-5-7 17:15
作者: Vortex

马云的云 发表于 2020-5-7 17:14
并没有，英伟达用于服务器的GPU卡比用于打游戏的GPU卡便宜，所以英伟达经常强调，严禁把用于服务器的GPU卡 ...

但是你管不到运营商啊
时间:  2020-5-7 17:18
作者: 马云的云

Vortex 发表于 2020-5-7 17:10
你以为CT的人很有本事？大部分还不是拼芯片方案而已

我觉得H/Z/E/N搞一个uU口的QoS出来不难啊，而且架构也现成，可以根据不同的APN区分PDCP的优先级，全球通/动感地带/神州行别混用APN，搞三个APN给各自群体用就行了，NodeB在PDCP激活后设定不同APN的优先级队列，这很难吗？主要是没厂家搞，运营商自己也不提需求，似乎是受前些年「比特中立」思维给限制住了。实际上互联网厂家叫嚣比特中立坑运营商，结果自己搞一堆VIP、会员出来大肆搂钱，运营商就是傻。
时间:  2020-5-7 17:20
作者: 马云的云

Vortex 发表于 2020-5-7 16:49
eurecom反正在他的OAI推的是ethernet承载，为啥？ethernet基本是现在随手最容易接触到的成本最低的COTS传 ...

成本低当然是好事，能满足的话自然就用了。CPRI要求实时性，Ethernet确实做不到，eCPRI就可以了。
时间:  2020-5-7 17:21
作者: 马云的云

Vortex 发表于 2020-5-7 16:55
每年那么多提案，变成现网功能的有多少？在乎那个并没有用

这就意味着大量研发资源被浪费了，而研发成本，最终不还是全体运营商买单，甚至是全体用户买单。
时间:  2020-5-7 17:24
作者: 马云的云

Vortex 发表于 2020-5-7 17:13
就是为了避免vendor lock

足够便宜的话无所谓吧，不行就换呗。
时间:  2020-5-7 17:24
作者: 马云的云

Vortex 发表于 2020-5-7 17:14
NFV网络转发用通用处理器本身性能就很差，但是还是得硬着头皮搞，因为不搞就等着被宰

Intel的DPDK，算通用不？
时间:  2020-5-7 17:25
作者: Vortex

马云的云 发表于 2020-5-7 17:21
这就意味着大量研发资源被浪费了，而研发成本，最终不还是全体运营商买单，甚至是全体用户买单。

IEEE一样的，802.11更散
时间:  2020-5-7 17:26
作者: Vortex

马云的云 发表于 2020-5-7 17:18
我觉得H/Z/E/N搞一个uU口的QoS出来不难啊，而且架构也现成，可以根据不同的APN区分PDCP的优先级，全球通/ ...

还用得着这些？一个802.1q不就完事了，还是L3的东西
时间:  2020-5-7 17:28
作者: Vortex

本帖最后由 Vortex 于 2020-5-7 17:29 编辑
马云的云 发表于 2020-5-7 17:24
Intel的DPDK，算通用不？

当然算，Linux开源的东西，只不过Intel肯定有点私心想让只在x86上跑，不过有源码就好办
时间:  2020-5-7 17:30
作者: 马云的云

Vortex 发表于 2020-5-7 17:09
看看TW的人做的

DL/UL 16Mbps/7Mbps，这性能还是差的有点远啊。GPU干这事儿吧，还是不太合适，最基本的，数据处理完，GPU不能直接发到Ethernet上，还要存回RAM，再由网卡发到Ethernet上，这就限制了吞吐量。

英特尔的DPDK是有10G以太网卡接口的，处理完直接发到网络上，不再写回RAM。
时间:  2020-5-7 17:31
作者: 马云的云

Vortex 发表于 2020-5-7 17:26
还用得着这些？一个802.1q不就完事了，还是L3的东西

我说的是空口，其实到了光纤上面，反而没啥瓶颈。空口区分优先级十分必要。
时间:  2020-5-7 18:08
作者: Vortex

马云的云 发表于 2020-5-7 17:30
DL/UL 16Mbps/7Mbps，这性能还是差的有点远啊。GPU干这事儿吧，还是不太合适，最基本的，数据处理完，GPU ...

你看清楚，他测试的5mhz 16qam 理论也就25mbps
时间:  2020-5-7 18:09
作者: Vortex

马云的云 发表于 2020-5-7 17:31
我说的是空口，其实到了光纤上面，反而没啥瓶颈。空口区分优先级十分必要。

这东西根本不关心性能，是有和无的区别，真有了，绝对会有软件公司做优化的
时间:  2020-5-7 20:25
作者: hbnygvmj1234

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

关键是你没有定义“通用处理器”。通用处理器是指“intel”？还是国内/国外电信商都能够生产的处理器？如果是intel，如果建国同志一纸令下断供，还是通用吗？
时间:  2020-5-7 20:42
作者: 等待

马云的云 发表于 2020-5-7 16:17
那是终极目标，但当下eNB马上实现全面虚拟化还不太现实，而且容易引起传统设备商的反对，对他们利益伤害太 ...

“用户面部分因为算法固定、数据量大、实时性要求高”，这最适合做ASIC了。可惜技术还是在不断发展中，不然ASIC化之后，谁都可以做设备商来赚这个钱，当然也就赚不到钱了。做芯片倒是可以发财。
时间:  2020-5-8 08:45
作者: yinfang00150537

Vortex 发表于 2020-5-7 16:39
到时候成熟了，设备不到以前1/10价格你们还不是要叫真香

关键的问题是，现在的价格降到了多少？
Open RAN的CapEx看两个方面：BBU的虚拟化、RRU的白盒化。
1. 基于x86的云化BBU已经证明了功耗和成本比传统BBU更便宜、功耗更低了吗？
2. 白盒RRU我相信肯定比传统设备商的RRU要便宜不少，但对于宏站而言，性能指标能够满足吗？说不定人家一个宏站能顶两三个白盒呢。从另一个角度来说，传统BBU应对白盒RRU，难道就没有应对措施么，也可以用自己的芯片搭出跟白盒价格相当的专用RRU呢。
所以，ORAN还是Open RAN，关键开始从两个角度上如何满足运营商对CapEx和OpEx降低的追求，第一个追求极致成本，第二个追求极致体验。
时间:  2020-5-8 09:05
作者: Vortex

hbnygvmj1234 发表于 2020-5-7 20:25
关键是你没有定义“通用处理器”。通用处理器是指“intel”？还是国内/国外电信商都能够生产的处理器？如 ...

我可没说就是x86,国产还有龙芯等项目
时间:  2020-5-8 09:06
作者: Vortex

yinfang00150537 发表于 2020-5-8 08:45
关键的问题是，现在的价格降到了多少？
Open RAN的CapEx看两个方面：BBU的虚拟化、RRU的白盒化。
1. 基 ...

反正永远都是价格，买办的本质，造不如买，想想也是被宰活该
时间:  2020-5-8 10:38
作者: hbnygvmj1234

Vortex 发表于 2020-5-8 09:06
反正永远都是价格，买办的本质，造不如买，想想也是被宰活该

买办通常是对外吧，通信至少是国内稍占上风，而且相对于七国八制时已经极大的挤出利润了。

如果有资金有人才，为啥不往操作系统、芯片制造和存储器件等等努力？
时间:  2020-5-8 10:56
作者: soloman1001

最终呢，也就是Capex与Opex相互转换而已。
时间:  2020-5-8 12:23
作者: Vortex

hbnygvmj1234 发表于 2020-5-8 10:38
买办通常是对外吧，通信至少是国内稍占上风，而且相对于七国八制时已经极大的挤出利润了。

如果有资金 ...

照你这意思TDSCDMA就是错的
时间:  2020-5-10 23:38
作者: xsohydra

mark一下，这个帖子好多技术讨论
时间:  2020-5-14 08:47
作者: qkb_75@163.com

OpenCN 是什么？
时间:  2020-6-28 19:02
作者: hillsboro

ott公司当然想虎口夺食啊
时间:  2021-1-25 06:05
作者: ath

等待 发表于 2020-5-7 20:42
“用户面部分因为算法固定、数据量大、实时性要求高”，这最适合做ASIC了。可惜技术还是在不断发展中，不 ...

用户面的计算只有一部分是固定的，那个一般用加速器，大部分功能还是用的DSP之类的软件方式实现。当然，DSP可以算一种特殊的ASIC。
时间:  2021-5-14 14:57
作者: hotheart

mark一下，本帖好多干货



通信人家园 (https://www.txrjy.com/) Powered by C114