來自市場研究公司Omdia的最新報告稱，開放網(wǎng)絡自動化平臺（ONAP）項目已經(jīng)進入第三年。AT&T仍然致力于ONAP的發(fā)展，但許多運營商和供應商對于ONAP與其他標準活動之間的重疊感到困惑，如ETSI網(wǎng)絡功能虛擬化（NFV）和MEF生命周期服務編排（LSO）。Omdia服務提供商運營與IT首席分析師James Crawshaw認為，ONAP的作用是作為多個標準的參考實現(xiàn)，彌合通用規(guī)范和實際代碼之間的差距，從而提高互操作性。

ONAP第六版已經(jīng)發(fā)布，但仍存一些懷疑

Linux Foundation Networking （LFN）最近發(fā)布了ONAP的第六版。ONAP最初于2017年2月推出，包含服務設(shè)計（建模資源、制定策略和應用程序），服務部署（通過編排實現(xiàn)的自動化實例化）和服務操作（例如恢復和擴展）。ONAP可以被視為NFV和電信云時代“徹底的”下一代OSS。

ONAP的架構(gòu)是模塊化的，因此運營商可以選擇僅實現(xiàn)其中一個功能（比如活動庫存和可用庫存），而不是整個系統(tǒng)。ONAP社區(qū)還為寬帶服務、VoLTE和vCPE等受歡迎的用例定義了更容易理解的“藍圖”。

ONAP項目受到了貝爾加拿大、Orange和沃達豐等運營商的熱烈歡迎，并繼續(xù)得到了原始種子代碼提供商AT&T和中國移動的支持。但是，傳統(tǒng)的電信設(shè)備和OSS供應商社區(qū)往往更加謹慎。此外，許多通信服務提供商（CSP）的CTO對其他類似目標的項目更加感興趣，例如MEF的LSO，TM Forum的開放數(shù)字架構(gòu)（Open Digital Architecture），以及ESTI主持的開源項目——Open Source MANO（該項目得到了西班牙電信研發(fā)部門的熱情支持）。

三星取代華為成為僅次于AT&T的第二大貢獻者

根據(jù)ONAP的Bitergia Dashboard（onap.biterg.io）的數(shù)據(jù)，截至2020年6月的一年中，提交的代碼數(shù)量約為24600個，較去年下降了約29％，較前一年下降了15％。這似乎仍然是一個健康的數(shù)字；對于社區(qū)項目來說，不太有利的是AT&T在新代碼提交方面持續(xù)占據(jù)主導地位（截至2020年6月的這一年中，AT&T的貢獻率為44%，上一年為36%）。

值得關(guān)注的是，華為不再是第二大貢獻者（截至2018年6月的一年中華為的貢獻率為18%，2019年為10%）。取而代之的是，三星在最近一年中以占據(jù)9%的代碼提交量躍居第二位，而在前幾年則一直默默無聞。緊隨三星之后的是愛立信（6%）、中國移動（6%）和諾基亞（5%）。從提交的代碼數(shù)量來看，中興通訊、Amdocs和IBM等此前的前五大貢獻者最近不那么活躍了。

關(guān)于如何最好地使用ONAP意見不一

LFN終端用戶咨詢小組的一篇報告非常有趣，它討論了ONAP的不同“使用”方式。該報告的貢獻者來自于AT&T、中國移動、Orange、STC、阿根廷電信、TIM和沃達豐。一項調(diào)查詢問了CSP如何計劃使用ONAP。這個問題只有11個肯定回答，另外3個不確定，還有一個近期沒有使用ONAP的計劃。因此，為了獲得更大的樣本，Omdia在LinkedIn調(diào)查中提出了一個類似的問題。Omdia調(diào)查獲得了41票回應，分配情況如下：

A（39％）：內(nèi)部構(gòu)建一個完整的ONAP系統(tǒng)；

B（17％）：外包ONAP系統(tǒng)的建設(shè)；

C（15％）：使用專業(yè)支持的ONAP發(fā)行版；

D（29％）：將ONAP視為參考實現(xiàn)。

受訪者中包括一家新成立的亞洲移動運營商的CTO，一家歐洲Tier 1運營商的技術(shù)創(chuàng)新負責人，一家Tier 1跨國運營商的首席IT系統(tǒng)架構(gòu)師，以及一家全球Tier 1運營商的集團網(wǎng)絡戰(zhàn)略主管。

令人驚訝的是，Omdia的調(diào)查發(fā)現(xiàn)，與LFN的調(diào)查相比，對“內(nèi)部構(gòu)建”方法的支持更多（39% vs. 27%），選擇外包方法的較少（17% vs. 36%），對發(fā)行版的支持更多一些（15% vs. 9%），對參考實現(xiàn)方法的支持幾乎相同（29% vs. 27%）。

ONAP的關(guān)鍵價值可能是作為一個參考實現(xiàn)

盡管有這個調(diào)查結(jié)果，但Omdia認為，由于缺乏資源，除了AT&T、貝爾加拿大和Orange外，很少有運營商會自己構(gòu)建一個完整的ONAP系統(tǒng)。任何會這樣做的企業(yè)可能都是在小范圍內(nèi)進行，例如，對單個國家在特定領(lǐng)域的單一業(yè)務線（例如Open RAN）進行部署。Omida猜測，很多公司會因為成本問題而將ONAP外包給供應商（例如Amdocs或Nokia），或者系統(tǒng)集成商（比如埃森哲或Tech Mahindra）。

乍一看，支持發(fā)行版的選項似乎不可行。明顯的的候選者紅帽和Canonical都不提供ONAP發(fā)行版。Aarna Networks提供，但這是一家擁有不到10名員工的公司。然而，LFN告訴Omdia，埃森哲和IBM都計劃提供通用的ONAP發(fā)行版，而其他供應商計劃提供“特定于客戶”的發(fā)行版（這在一定程度上破壞了開源發(fā)行版的整體理念）。

這就留下了將ONAP作為參考實現(xiàn)的選項。其理念是， 諸如3GPP、ETSI、MEF和TM Forum這樣的標準組織只提供關(guān)于它們的標準和接口應該如何工作的指導方針，實現(xiàn)則由每個供應商自行決定。

每個供應商都可以聲稱符合標準，但提供的解決方案不能與其競爭對手完全互操作，從而增加了客戶粘性。ONAP社區(qū)現(xiàn)在提供了有關(guān)如何執(zhí)行操作（例如ETSI標準中一般描述的VNF加載）的實際代碼。

CSP現(xiàn)在要求候選供應商遵守ONAP規(guī)范，并確保其互操作性。ONAP社區(qū)是運營商繞開供應商在傳統(tǒng)標準制定過程中設(shè)置的互操作性障礙的一種工具。如果成功，它將有助于行業(yè)簡化運營，從而可以將資源投資于服務創(chuàng)新，而非IT管道。

責任編輯：gt