ONAP第六版已经发布,关键价值可能是作为一个参考实现

来自市场研究公司Omdia的最新报告称，开放网络自动化平台（ONAP）项目已经进入第三年。AT&T仍然致力于ONAP的发展，但许多运营商和供应商对于ONAP与其他标准活动之间的重叠感到困惑，如ETSI网络功能虚拟化（NFV）和MEF生命周期服务编排（LSO）。Omdia服务提供商运营与IT首席分析师James Crawshaw认为，ONAP的作用是作为多个标准的参考实现，弥合通用规范和实际代码之间的差距，从而提高互操作性。

ONAP第六版已经发布，但仍存一些怀疑

Linux Foundation Networking （LFN）最近发布了ONAP的第六版。ONAP最初于2017年2月推出，包含服务设计（建模资源、制定策略和应用程序），服务部署（通过编排实现的自动化实例化）和服务操作（例如恢复和扩展）。ONAP可以被视为NFV和电信云时代“彻底的”下一代OSS。

ONAP的架构是模块化的，因此运营商可以选择仅实现其中一个功能（比如活动库存和可用库存），而不是整个系统。ONAP社区还为宽带服务、VoLTE和vCPE等受欢迎的用例定义了更容易理解的“蓝图”。

ONAP项目受到了贝尔加拿大、Orange和沃达丰等运营商的热烈欢迎，并继续得到了原始种子代码提供商AT&T和中国移动的支持。但是，传统的电信设备和OSS供应商社区往往更加谨慎。此外，许多通信服务提供商（CSP）的CTO对其他类似目标的项目更加感兴趣，例如MEF的LSO，TM Forum的开放数字架构（Open Digital Architecture），以及ESTI主持的开源项目——Open Source MANO（该项目得到了西班牙电信研发部门的热情支持）。

三星取代华为成为仅次于AT&T的第二大贡献者

根据ONAP的Bitergia Dashboard（onap.biterg.io）的数据，截至2020年6月的一年中，提交的代码数量约为24600个，较去年下降了约29％，较前一年下降了15％。这似乎仍然是一个健康的数字；对于社区项目来说，不太有利的是AT&T在新代码提交方面持续占据主导地位（截至2020年6月的这一年中，AT&T的贡献率为44%，上一年为36%）。

值得关注的是，华为不再是第二大贡献者（截至2018年6月的一年中华为的贡献率为18%，2019年为10%）。取而代之的是，三星在最近一年中以占据9%的代码提交量跃居第二位，而在前几年则一直默默无闻。紧随三星之后的是爱立信（6%）、中国移动（6%）和诺基亚（5%）。从提交的代码数量来看，中兴通讯、Amdocs和IBM等此前的前五大贡献者最近不那么活跃了。

关于如何最好地使用ONAP意见不一

LFN终端用户咨询小组的一篇报告非常有趣，它讨论了ONAP的不同“使用”方式。该报告的贡献者来自于AT&T、中国移动、Orange、STC、阿根廷电信、TIM和沃达丰。一项调查询问了CSP如何计划使用ONAP。这个问题只有11个肯定回答，另外3个不确定，还有一个近期没有使用ONAP的计划。因此，为了获得更大的样本，Omdia在LinkedIn调查中提出了一个类似的问题。Omdia调查获得了41票回应，分配情况如下：

A（39％）：内部构建一个完整的ONAP系统；

B（17％）：外包ONAP系统的建设；

C（15％）：使用专业支持的ONAP发行版；

D（29％）：将ONAP视为参考实现。

受访者中包括一家新成立的亚洲移动运营商的CTO，一家欧洲Tier 1运营商的技术创新负责人，一家Tier 1跨国运营商的首席IT系统架构师，以及一家全球Tier 1运营商的集团网络战略主管。

令人惊讶的是，Omdia的调查发现，与LFN的调查相比，对“内部构建”方法的支持更多（39% vs. 27%），选择外包方法的较少（17% vs. 36%），对发行版的支持更多一些（15% vs. 9%），对参考实现方法的支持几乎相同（29% vs. 27%）。

ONAP的关键价值可能是作为一个参考实现

尽管有这个调查结果，但Omdia认为，由于缺乏资源，除了AT&T、贝尔加拿大和Orange外，很少有运营商会自己构建一个完整的ONAP系统。任何会这样做的企业可能都是在小范围内进行，例如，对单个国家在特定领域的单一业务线（例如Open RAN）进行部署。Omida猜测，很多公司会因为成本问题而将ONAP外包给供应商（例如Amdocs或Nokia），或者系统集成商（比如埃森哲或Tech Mahindra）。

乍一看，支持发行版的选项似乎不可行。明显的的候选者红帽和Canonical都不提供ONAP发行版。Aarna Networks提供，但这是一家拥有不到10名员工的公司。然而，LFN告诉Omdia，埃森哲和IBM都计划提供通用的ONAP发行版，而其他供应商计划提供“特定于客户”的发行版（这在一定程度上破坏了开源发行版的整体理念）。

这就留下了将ONAP作为参考实现的选项。其理念是， 诸如3GPP、ETSI、MEF和TM Forum这样的标准组织只提供关于它们的标准和接口应该如何工作的指导方针，实现则由每个供应商自行决定。

每个供应商都可以声称符合标准，但提供的解决方案不能与其竞争对手完全互操作，从而增加了客户粘性。ONAP社区现在提供了有关如何执行操作（例如ETSI标准中一般描述的VNF加载）的实际代码。

CSP现在要求候选供应商遵守ONAP规范，并确保其互操作性。ONAP社区是运营商绕开供应商在传统标准制定过程中设置的互操作性障碍的一种工具。如果成功，它将有助于行业简化运营，从而可以将资源投资于服务创新，而非IT管道。

责任编辑：gt