來自市場研究公司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