開放網(wǎng)絡(luò)自動化平臺（ONAP）在本月將會發(fā)布代碼的首個版本Amsterdam，該項目是Linux基金會下的開源項目，前身是AT&T主導(dǎo)的ECOMP平臺和中國移動主導(dǎo)的Open-O平臺，今年2月份宣布兩大項目合并成為ONAP，是運營商試圖克服新軟件和虛擬化技術(shù)帶來的互操作性挑戰(zhàn)的開源計劃之一。

盡管ONAP致力于為服務(wù)提供商解決互操作性的挑戰(zhàn)以及虛擬化面臨的問題，但并不是所有的運營商都看好ONAP項目。該項目面臨歐洲電信標(biāo)準協(xié)會（ETSI）支持的開源MANO（OSM）的競爭，AT&T和中國移動等運營商是ONAP項目背后的推動力量，OSM背后也有西班牙電信等運營商在支持，兩大開源項目可以說勢均力敵。

與OSM已經(jīng)發(fā)布了兩個版本不同，ONAP目前第一個版本才初具雛形，首個版本Amsterdam也要到11月16日才能發(fā)布，且業(yè)界共識是Amsterdam不能在生產(chǎn)網(wǎng)絡(luò)中加以應(yīng)用。據(jù)知情人士透露，ONAP在第三或者第四個版本發(fā)布之前缺乏在生產(chǎn)網(wǎng)絡(luò)中使用所需的穩(wěn)定性，他不建議運營商部署第一個版本。

Amsterdam版本將著重支持三種網(wǎng)絡(luò)功能或服務(wù)：虛擬防火墻（vFW），虛擬客戶端設(shè)備（vCPE），在虛擬演進分組核心（vEPC）上運行的LTE語音服務(wù)。

德國電信不是ONAP的成員，DT的副首席技術(shù)官Arash Ashouriha在今年10月的SDN NFV大會上表示：“通信領(lǐng)域中多個服務(wù)提供商已經(jīng)開始向ONAP靠攏，但仍然有很長的路要走，因為整個行業(yè)不是ONAP一家獨大，且首個版本的可用性也是一個問題。”

在開源軟件領(lǐng)域這是很正常的現(xiàn)象，開源項目的成熟周期通常相對較長，需要不斷對開源項目進行改進，作為一個全面的服務(wù)管理平臺，ONAP可能是電信運營商最雄心勃勃的開源項目。

盡管業(yè)界對ONAP的成熟度有所懷疑，但貝爾加拿大仍然投身于ONAP，且是積極為部署Amsterdam版本的主要服務(wù)提供商，該公司發(fā)言人表示：“作為ONAP的會員之一，我們期待與合作伙伴展開合作，在今年底部署ONAP首個版本，也希望能夠在明年春天整合ONAP的運營管理。”

運營管理能夠支持ONAP平臺及其組成部分的部署、管理和運營商，該功能將會在ONAP第二個版本Beijing中面世，Beijing版本預(yù)計將在明年5月24日發(fā)布。

雖然ONAP已經(jīng)獲得了全球多個運營商的支持（涵蓋用戶超過全球移動用戶的50%），但是業(yè)界對ONAP的質(zhì)疑卻越來越高。總體而言，一個擁有幾百萬行代碼的軟件工具對于使用它來運營的運營人員來說難度非常大。Heavy Reading市場研究集團高級分析師James Crawshaw認為，ONAP的復(fù)雜性與開源開放的原則是對立的。

ONAP目前包含1000多萬行代碼，涵蓋了多個廠商的超過30個不同的軟件項目，其復(fù)雜性的成因是AT＆T的ECOMP和中國移動、中國電信的OPEN-O項目的代碼合并，雖然大多數(shù)代碼都是現(xiàn)成的，但是想要ONAP從一開始就很順利運行很明顯是不切實際的。

某位一級運營商的高管解釋為什么不加入ONAP時表示，在維護軟件所需的功能方面，幾百萬行代碼的工作將是一個很大的問題。其他運營商認為ONAP將會由一些非常大的用戶來控制，他們通過ONAP來推進自己的軟件化的進程。Heavy Reading的Crawshaw在談及ONAP的成員時表示，盡管ONAP目前已經(jīng)有AT&T、中國移動、華為、中興等在內(nèi)的50多個成員，但是他表示除了中國移動有影響力之外，其他運營商并沒有參與這個計劃，表明這并不是一個真正的開源計劃。

某一級運營商高管表示，只有AT&T和中國移動正在向ONAP提供開發(fā)者，Orange和Vodafone等其他大型電信公司沒有為該項目提供開發(fā)人員。