作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客
本文网址：https://blog.csdn.net/HiWangWenBing/article/details/121534249
目录
O-RAN与3GPP
O-RAN并非是业务、性能标准，更多的是网络设备运营管理的接口标准。
因此，O-RAN并不对空口的性能、业务场景提出任意的要求和规范。
O-RAN关注的是网元的管理接口，因此O-RAN是一个管理标准。
O-RAN也是一个标准体系，包括硬件、软件、前传接口、RIC, 网管，而不是一个点。
因此， O-RAN标准以及遵循O-RAN标准的设备本身，并没有引入性能指标的下降或提升。
O-RAN系统性能指标主要取决于异厂家设备的配合，而不在于是否遵循O-RAN的标准。
O-RAN的诉求来自于运营商而不是设备
O-RAN的诉求其实来自于运营商，O-RAN是设备运营商的选择，而不是设备商。
因此在O-RAN的部署上，其实设备商没有主导权和技术引导权，设备商唯一要做的是，根据运营商的诉求，提供相应的产品。
O-RAN对运营商的商业价值与对应的技术实现
（1）运营管理的智能化 =》 产生了RIC网元和NMS中非实时智能控制
（2）支持设备的虚拟化与动态部署 =》 产生了VRAN, VRAN并非一定要O-RAN， VRAN各个网元尽快能在通用的服务器上运行，至于软件接口是否O-RAN并非VRAN的诉求。
（3）降低设备采购和运营成本：硬件的白盒化
硬件的白盒化，主要的诉求，就是低成本。附属效果是虚拟化的软件部署。
并非所有的运营商对O-RAN都有诉求
在众多运营商中，对O-RAN有诉求的运营商不是大多数，只有少数的运营商对O-RAN有诉求。
如美国的A&T, 中国移动，日本的乐天。
对O-RAN有诉求运营商，并非要求全栈支持O-RAN
O-RAN是一个涉及所有RAN网元的体系，对于某一个运营商的O-RAN的的支持，并非要全栈、全功能的支持VRAN, 而是会根据他们自身的网络部署特点来部署O-RAN.
有些运营商关注的是智能化，不关心O-RU的低成本化。
有些运营商关注的是虚拟化，而并不关注运营的智能化。
有些运营商关注的是O-RU的低成本化，而不关注智能化。
O-RAN/VRAN/经典BBU的部署特征
（1）经典BBU =》单一vendor + 专有硬件
（2）VRAN =》单一vendor + 通用硬件
（3）O-RAN =》多vendor + 通用硬件
RIC的网元价值：近实时诉求
RIC网元出现的价值在于网络的自优化，且为近实时的网络优化（<1s的响应速度）。
因此，如果运营商对近实时的网络自优化没有诉求，其实是不需要有RIC网元的。
大于1s的网络自优化由NMS完成。
小于10ms的网络自优化由RAN设备完成。
RIC的专利
RIC是3GPP之外出现的一个新网元，是O-RAN的原创网元。
因此，这块没有被3GPP完全开垦过，这里是催生创新和专利的新土地, 如节能与智能化控制。
RIC网元并非属于RAN的体系
RIC网元本身并非是无线接入网的一部分，而是边缘云设备，是Cloud的一部分。
因此，在公司的组织架构上，通常RIC也不是无线接入设备开发部门的一部分。
eCPRI的价值
CPRI为小区保留预定的前传接口的带宽，即使没有用户数据，也会占用CPRI的带宽。
eCPRI动态分配带宽，只有需要调度的用户数据时，才占用eCPRI的网络带宽 。
eCPRI能实现互通吗？
eCPRI本身并非是O-RAN的标准，而是5G的标准。
eCPRI协议本身并不能实现不同厂家设备之间的互联互通，如果没有O-RAN, eCPRI只能在同一厂家的RU和BBU之间互联互通。与CPRI协议类似。
eCPRI与O-RAN的关系
在前传接口，O-RAN借用了eCPRI的协议，并在其基础之上，C/P/S/M明确了相应的IoT的Profile，以确保不同厂家设备的互联互通。
FHGW的价值
主要实现eCPR 7-2到CPRI option8的转换。
如果是eCPRI到eCPRI, 则通过普通的以太网交换机就能够实现。
在实际应用部署中，FHGW基本用不到
关于一体化基站的O-RAN支持
一体化基站的前传接口已经被压缩到了基站内部，因此前传的netact接口并没有强制性的要求。
一体化基站通常是指DU与RU的一体化，不包括CU，该接口是F1接口，这个接口在O-RAN中称为7-3，O-RAN并没有强制要求。
eCPRI的CPlane并非是RRC L3信令
eCPRI中的CPlane并非是手机与基站之间的RRC L3信令，手机与基站的RRC信令，是通过eCPRI的UPlane承载的。
这里的CPlane是指L1-high与L1-low之间的空口无线帧的调度信息。
IoT profile指明了O-RU的硬件能力
O-RU与BBU的分离也意味着O-DU无法预先知道与之相连的O-RU的能力。O-RU需要上报能力。
而O-RU的种类繁多，且有大量的不同厂家的O-RU与不同厂家的O-DU互联互通。
因此，需要一种机制来抽象和定义不同种类的O-RU， 这就是IoT profile的意义。
有了IoT profile，通过profile id就可以适配一组O-RU的配置参数和能力特征.
只有IoT profile，无法完成O-RAN的前传接口
IoT profile只定义O-RU的能力分类以及对应的能力属性。
只有YangModel + IoT profile + 启动流程才能共同完成对O-RAN的支持。
YangModel定义了所有的管理接口规范，是大而全
IoT定义了特定的O-RU的能力类型与对应的特征参数，是小而专
特定的流程定义了时序.
O-RAN面临的新的挑战
（1）在混合组网时，端到端的方案无法向原先，由传统的设备商提供，对集成商提出了更高的要求、
（2）FHGW的低位比较尴尬，在大部分O-RAN的场合，可以有通用以太网交换机完成。
（3）端到端的性能保障是一个非常现实的问题，任何一家设备上都无法保证端到端的整体性能。
（4）O-RAN的功能定义远远少于原先各个设备厂家定义的私有功能，导致在实际部署时，哪些私有的增强功能无法平滑的迁移过去，比如单频网的定义，其他特有的增强功能等等。
（5）O-RAN在不同版本之间，不像3GPP一样，前向兼容和平滑过渡。
作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_CSDN博客
本文网址：https://blog.csdn.net/HiWangWenBing/article/details/121534249