楊振東（中國聯(lián)通廣東分公司，廣東廣州 510627）

1 概述

5G 時代，各行業(yè)數(shù)字化轉(zhuǎn)型速度加快，數(shù)字經(jīng)濟推動云網(wǎng)一體加速發(fā)展，云網(wǎng)融合訴求增強。5G時代是萬物互聯(lián)、萬智互聯(lián)的智能時代，通信連接產(chǎn)業(yè)的價值由聯(lián)網(wǎng)升級到聯(lián)云。云網(wǎng)融合是新型信息基礎(chǔ)設(shè)施的核心，云服務(wù)由底層服務(wù)走向主導(dǎo)服務(wù)，云的重要性越發(fā)突出，未來5年所有的內(nèi)容、應(yīng)用、服務(wù)、數(shù)據(jù)、客戶都要上云。政府部門、事業(yè)單位、企業(yè)上云進程加速，企業(yè)新建的基礎(chǔ)設(shè)施將逐步部署在云上，預(yù)計到2025 年將達到85%的比例。隨著企業(yè)生產(chǎn)系統(tǒng)上云的普及，云網(wǎng)融合成為“剛需”。企業(yè)規(guī)模越大，上云的系統(tǒng)越關(guān)鍵，對云網(wǎng)融合的要求越高，多云（公有云、私有云、專屬云、混合云）部署成為普遍需求。

在云網(wǎng)協(xié)同、云網(wǎng)融合、云網(wǎng)一體的需求下，需要有與之相匹配的云網(wǎng)運營支撐系統(tǒng)架構(gòu)進行支撐。開放網(wǎng)絡(luò)自動化平臺（Open Network Automation Platform，ONAP）是Linux基金會旗下兩大開源MANO 工作組Open-O 和ECOMP 合并后成立的一個組織，ONAP致力于打造全球最大的NFV/SDN 網(wǎng)絡(luò)協(xié)同與編排器開源社區(qū)，面向物聯(lián)網(wǎng)、5G、企業(yè)和家庭寬帶等場景，打造網(wǎng)絡(luò)全生命周期管理平臺，使運營商業(yè)務(wù)開發(fā)更靈活、業(yè)務(wù)上線更快捷、網(wǎng)絡(luò)運維更高效。ONAP 提出設(shè)計態(tài)和運行態(tài)兩態(tài)分離的理念以及模型驅(qū)動的理念，為電信運營商業(yè)務(wù)編排設(shè)計和上線部署提供了基本框架。ONAP 已成為業(yè)界對于云網(wǎng)編排協(xié)同的主流標準，全球各主流運營商如中國移動、中國電信、AT&T、沃達豐、法國電信等均參照或借鑒此架構(gòu)和理念進行OSS運營支撐系統(tǒng)的規(guī)劃建設(shè)和運營。

2 需求分析

ONAP 架構(gòu)設(shè)計全面，各種功能組件比較豐富和完備，其中設(shè)計態(tài)組件包括對象設(shè)計與創(chuàng)建、策略創(chuàng)建、業(yè)務(wù)流程設(shè)計和其他周邊組件，運行態(tài)組件包括業(yè)務(wù)編排、控制器適配、數(shù)據(jù)采集/分析、全局資源庫、策略框架和其他周邊組件。在實際部署過程中，由于不同通信運營商的業(yè)務(wù)應(yīng)用場景、OSS 系統(tǒng)架構(gòu)現(xiàn)狀及演進策略以及資源稟賦有所不同，ONAP 架構(gòu)與現(xiàn)有實際業(yè)務(wù)應(yīng)用場景并不完全吻合，與現(xiàn)有OSS 系統(tǒng)存在較大差異，各運營商的演進策略也有快慢之分，不適宜直接全盤照搬部署。而且，現(xiàn)有ONAP 方案在編排架構(gòu)上沒有分層編排和分步實施的考慮，對云網(wǎng)業(yè)務(wù)自動化的編排協(xié)同架構(gòu)演進缺乏可落地的指導(dǎo)技術(shù)方案。如果一次性構(gòu)建業(yè)務(wù)和能力編排，存在如下問題。

a）現(xiàn)有的業(yè)務(wù)/應(yīng)用較為簡單，業(yè)務(wù)靈活編排組合或業(yè)務(wù)之間嵌套的需求不多，基于ONAP 的業(yè)務(wù)編排能力暫時無須使用。

b）ONAP 組織成立于2017 年，其相關(guān)架構(gòu)、技術(shù)和組件還在發(fā)展完善中，對ONAP 的理念理解和使用經(jīng)驗不足，相關(guān)的應(yīng)用案例、應(yīng)用場景還不夠豐富，需要逐步積累。

c）ONAP 組件較多，實現(xiàn)了OSS域所有模塊功能，代碼量較大。一次性、一步到位構(gòu)建全套/全棧業(yè)務(wù)和能力編排協(xié)同平臺投資較大，但無法全部發(fā)揮作用，浪費投資。

d）新的ONAP 架構(gòu)對開發(fā)和運維人員需求較大，團隊職能還未整合，人員的能力無法在短時間內(nèi)滿足新架構(gòu)運營的要求。

e）部分運營商現(xiàn)有的業(yè)務(wù)編排能力還未遷移到云網(wǎng)協(xié)同器承載或參照ONAP 架構(gòu)部署，對業(yè)務(wù)/應(yīng)用層面編排協(xié)同的需求還未凸顯。

5G 時代，經(jīng)濟社會數(shù)字化轉(zhuǎn)型進程加快，云網(wǎng)能力協(xié)同、云網(wǎng)業(yè)務(wù)融合、云網(wǎng)一體化運營對云網(wǎng)運營支撐架構(gòu)的資源/能力編排協(xié)同層的演進需求，相對于業(yè)務(wù)/應(yīng)用編排協(xié)同層的演進需求，更為突出和迫切。需要找到一條切實可行的路徑和方法，滿足以上需求。

3 面向云網(wǎng)一體的運營支撐系統(tǒng)架構(gòu)演進方法

3.1 面向云網(wǎng)一體的運營支撐系統(tǒng)目標架構(gòu)

通信運營商為滿足云網(wǎng)一體運營需求，支撐云網(wǎng)產(chǎn)品電商化服務(wù)體驗，優(yōu)化云網(wǎng)一體運營支撐架構(gòu)實現(xiàn)分層解耦，研發(fā)和部署云網(wǎng)協(xié)同器，實現(xiàn)云網(wǎng)能力快速持續(xù)輸出，支撐差異化云網(wǎng)創(chuàng)新產(chǎn)品快速部署。通過重構(gòu)云網(wǎng)一體化運營支撐系統(tǒng)架構(gòu)，貫通B 域和O 域，實現(xiàn)云網(wǎng)協(xié)同能力開放。云網(wǎng)運營支撐體系分層解耦，將業(yè)務(wù)應(yīng)用層、云網(wǎng)協(xié)同層、云網(wǎng)控制層/網(wǎng)管平臺分層解耦，分層解耦的云網(wǎng)協(xié)同運營支撐系統(tǒng)架構(gòu)包含如下模塊。

a）業(yè)務(wù)受理平臺。負責(zé)業(yè)務(wù)統(tǒng)一受理、客戶資源管理、計費賬務(wù)等。

b）調(diào)度系統(tǒng)或服務(wù)開通系統(tǒng)。云網(wǎng)融合產(chǎn)品訂單BO 貫通入口，負責(zé)業(yè)務(wù)開通流程調(diào)度，包括云網(wǎng)資源核實分配、云網(wǎng)資源激活去活、裝機運維派單等環(huán)節(jié)。

c）資源管理系統(tǒng)。負責(zé)云網(wǎng)資源數(shù)據(jù)、用戶數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)統(tǒng)一管理、資源在線核配等。

d）云網(wǎng)協(xié)同器。南向?qū)釉凭W(wǎng)控制層/網(wǎng)管平臺實現(xiàn)跨專業(yè)、跨廠家、跨域（網(wǎng)絡(luò)域、業(yè)務(wù)域）的云網(wǎng)配置激活、數(shù)據(jù)查詢等指令適配下發(fā)；北向面向BO 域應(yīng)用業(yè)務(wù)平臺輸出云網(wǎng)編排協(xié)同能力和云網(wǎng)狀態(tài)感知能力。在本文描述的架構(gòu)中，云網(wǎng)協(xié)同器南向?qū)覥PE控制器、IP/光網(wǎng)絡(luò)控制器、5G切片管理平臺、云管平臺，北向?qū)诱{(diào)度或服務(wù)開通系統(tǒng)，實現(xiàn)對省內(nèi)多云、多網(wǎng)的能力統(tǒng)一封裝，向上層業(yè)務(wù)應(yīng)用平臺開放云網(wǎng)能力。

e）通信網(wǎng)絡(luò)和云資源控制層/網(wǎng)管平臺。包括網(wǎng)資源（光網(wǎng)、IP 網(wǎng)、無線網(wǎng)、核心網(wǎng)、寬帶網(wǎng)、城域網(wǎng)等通信網(wǎng)絡(luò)資源）和云資源（行業(yè)云、公有云、邊緣云等云資源）等云網(wǎng)原子能力解耦封裝。

f）云網(wǎng)資源層。云網(wǎng)基礎(chǔ)資源池，包括通信網(wǎng)絡(luò)轉(zhuǎn)發(fā)面和云資源池。

引入云網(wǎng)協(xié)同器帶來如下益處。

a）云網(wǎng)運營支撐系統(tǒng)架構(gòu)分層解耦。上層業(yè)務(wù)應(yīng)用平臺專注于業(yè)務(wù)流程處理，產(chǎn)品、業(yè)務(wù)層面的內(nèi)容展示，以及與客戶交互界面的友好便捷；云網(wǎng)協(xié)同器專注于云網(wǎng)底層能力的封裝和協(xié)同，專注于云網(wǎng)業(yè)務(wù)的實現(xiàn)邏輯和處理復(fù)雜繁瑣的技術(shù)實現(xiàn)細節(jié)。

b）人員的定位解耦。業(yè)務(wù)應(yīng)用平臺人員專注產(chǎn)品、業(yè)務(wù)的展現(xiàn)邏輯和業(yè)務(wù)流程；云網(wǎng)協(xié)同器人員專注云網(wǎng)底層CT+IT 能力實現(xiàn)，實現(xiàn)不同團隊人員的專業(yè)化。

c）前臺與中臺解耦。輕量快捷敏捷的前端業(yè)務(wù)應(yīng)用平臺與厚重復(fù)雜的云網(wǎng)能力中臺解耦，前端業(yè)務(wù)平臺敏捷高效響應(yīng)市場需求，云網(wǎng)能力中臺實現(xiàn)云網(wǎng)能力沉淀積累。

d）云網(wǎng)協(xié)同層與云網(wǎng)設(shè)備控制層分離和解耦。云網(wǎng)協(xié)同器可以根據(jù)運營商的業(yè)務(wù)、產(chǎn)品發(fā)展需要，快速進行個性化、差異化能力的開發(fā)和迭代，降低對底層設(shè)備廠家協(xié)同控制器的依賴，提升運營商自主創(chuàng)新能力和新產(chǎn)品新業(yè)務(wù)上線速度。

3.2 面向云網(wǎng)一體的運營支撐系統(tǒng)架構(gòu)演進方法

基于以上系統(tǒng)架構(gòu)，本文提出一種分層解耦、分步部署的基于ONAP/TMF 架構(gòu)理念的云網(wǎng)協(xié)同運營支撐架構(gòu)演進方法，在云網(wǎng)運營支撐系統(tǒng)架構(gòu)的設(shè)計和部署上將云網(wǎng)資源/能力編排協(xié)同層與云網(wǎng)業(yè)務(wù)/應(yīng)用編排協(xié)同層分離解耦，先將云網(wǎng)資源/能力編排協(xié)同層參考ONAP/TMF 架構(gòu)理念進行部署，再根據(jù)需要將云網(wǎng)業(yè)務(wù)/應(yīng)用編排協(xié)同層遷移到ONAP/TMF架構(gòu)。

運營商受技術(shù)水平和使用經(jīng)驗不足、已有業(yè)務(wù)編排的復(fù)雜度不高、投資規(guī)模、人員組織架構(gòu)分屬不同團隊以及現(xiàn)有運營支撐系統(tǒng)架構(gòu)與目標架構(gòu)不完全匹配等因素影響，在ONAP/TMF 編排架構(gòu)部署無法一步到位的情況下，可以通過分層解耦、分步部署的方法，通過云網(wǎng)協(xié)同器拉通底層云網(wǎng)能力，通過TOSCA的拓撲建模和工作流程引擎技術(shù)的使用，將所有云和網(wǎng)絡(luò)的資源對象進行抽象和建模，構(gòu)建統(tǒng)一的邏輯網(wǎng)絡(luò)和云資源層，向上層業(yè)務(wù)層開放云網(wǎng)能力，業(yè)務(wù)層感知到的只是云網(wǎng)能力集合和標準化接口參數(shù)，云網(wǎng)協(xié)同器對業(yè)務(wù)層屏蔽云網(wǎng)資源層的異構(gòu)接口差異。將云網(wǎng)協(xié)同器作為云網(wǎng)資源/能力編排協(xié)同層的功能承載平臺并按照ONAP 架構(gòu)進行部署，既支撐了新的業(yè)務(wù)需求并向業(yè)界先進主流編排架構(gòu)遷移，又保障了對現(xiàn)有業(yè)務(wù)流程的繼承和支撐，以及業(yè)務(wù)和服務(wù)的延續(xù)性。

3.2.1 TMF分層模型架構(gòu)說明

根據(jù)電信管理論壇（Telecommunication Management Forum，TMF）的標準，電信業(yè)務(wù)PSR 模型分層劃分為產(chǎn)品（Product）、面向客戶的服務(wù)（Customer Facing Service，CFS）、面向資源的服務(wù)（Resource Facing Service，RFS）和資源（Resource，RES）。運營商可以通過云網(wǎng)協(xié)同器先行實現(xiàn)RFS 和RES 層面的編排協(xié)同，然后根據(jù)需要在云網(wǎng)協(xié)同器增加CFS層面的編排協(xié)同能力，或者由上層業(yè)務(wù)平臺實現(xiàn)CFS 層面的編排協(xié)同。具體說明如下。

P：Product，產(chǎn)品是面向客戶提供最小可銷售單元的功能和操作能力，產(chǎn)品涉及的網(wǎng)絡(luò)屬性和網(wǎng)絡(luò)服務(wù)通過服務(wù)層獲取。

S：Service，服務(wù)分為2層，包含CFS和RFS。

CFS：面向客戶的服務(wù)，指的是客戶可感知的端到端網(wǎng)絡(luò)通信能力，由面向云網(wǎng)資源的服務(wù)組裝而成，包括點到點、點到網(wǎng)等能力。CFS 由一個或多個RFS組合而成，CFS 與CFS 之間可存在嵌套關(guān)系。CFS 一般是跨網(wǎng)絡(luò)域或跨業(yè)務(wù)域的。

RFS：面向資源的服務(wù)，指的是各通信網(wǎng)絡(luò)、云資源提供的云網(wǎng)能力，由云網(wǎng)資源提供的原子能力組裝而成，也可直接出租給客戶，包括5GC、PON、城域網(wǎng)、骨干網(wǎng)、省內(nèi)/本地傳輸網(wǎng)、云資源池IaaS/PaaS 等提供的業(yè)務(wù)服務(wù)。RFS由一個或多個RES提供的原子能力組裝而成，RFS一般是某個網(wǎng)絡(luò)域或業(yè)務(wù)域內(nèi)的。

R 或RES：Resource，資源是網(wǎng)絡(luò)中涉及的物理資源（網(wǎng)絡(luò)設(shè)備、線路等）、邏輯資源（IP、端口、鏈路、VLAN、碼號等）、網(wǎng)元（UPF、UDM、PCF 等）、虛擬資源（虛擬機、容器等）、業(yè)務(wù)平臺等的總稱。

電信業(yè)務(wù)的產(chǎn)品層、服務(wù)層和資源層的分層模型架構(gòu)如圖1所示。

圖1 TMF PSR分層架構(gòu)

3.2.2 基于ONAP和TMF架構(gòu)的演進方法

基于ONAP/TMF 的編排架構(gòu)，云網(wǎng)協(xié)同器分為設(shè)計態(tài)和運行態(tài)2 個獨立的工作區(qū)。在設(shè)計態(tài)工作區(qū)，部署云網(wǎng)資源（RES）對象、云網(wǎng)能力（RFS）對象、業(yè)務(wù)流程、API 接口、服務(wù)策略的編排設(shè)計模塊，包括面向RFS、RES的對象設(shè)計、編排協(xié)同流程設(shè)計、API接口設(shè)計和服務(wù)策略設(shè)計，生成基于TOSCA 模型和工作流模板的編排包（即CSAR文件）。

將編排包文件加載到運行態(tài)工作區(qū)，通過編排包就緒模塊進行編排包校驗和測試驗證，再通過服務(wù)接收和實例化，逆向逐層解析（即把1個RFS 對象分解為若干個RES 對象并實例化），最后將分解后的面向南向各個域控制器的API接口指令按照設(shè)計態(tài)工作區(qū)設(shè)定的工作流順序下發(fā)給各個域控制器執(zhí)行。云網(wǎng)協(xié)同器功能模塊圖如圖2所示。

圖2 云網(wǎng)協(xié)同器功能模塊

在此基礎(chǔ)上，在各方面條件成熟的時候可進行下一步部署，包含但不限于如下情況。

a）運營商的業(yè)務(wù)/應(yīng)用進一步豐富，2B/2C/2H 業(yè)務(wù)進一步融合，業(yè)務(wù)靈活編排組合或各業(yè)務(wù)之間嵌套的需求進一步凸顯。

b）ONAP相關(guān)架構(gòu)、技術(shù)和組件進一步完善，使用經(jīng)驗更加豐富，相關(guān)應(yīng)用案例和應(yīng)用場景進一步豐富。

c）人員支撐和整合更有保障，人員具備可進行CFS/RFS/RES 全棧的設(shè)計、編排、開發(fā)、測試和運維的能力。

d）原有業(yè)務(wù)已完成遷移到云網(wǎng)協(xié)同器進行處理。

在以上條件滿足時，可考慮將業(yè)務(wù)/應(yīng)用編排流程（即CFS）基于新的ONAP架構(gòu)部署實施，包括2種可選的實施方式。

方式1：在現(xiàn)有的云網(wǎng)協(xié)同器平臺架構(gòu)內(nèi)增加部署獨立的CFS設(shè)計、編排、測試模塊，并與現(xiàn)有的RFS、RES 設(shè)計、編排、測試流程整合，具體設(shè)計內(nèi)容包括如下2種情況。

a）基于云網(wǎng)協(xié)同器已有的和新增的RFS 對象進行編排組合，形成CFS。如圖3 所示，在設(shè)計態(tài)將RFS1/RFS2/RFS3 進行編排設(shè)計，構(gòu)建生成CFS1 編排包，然后將編排包加載到運行態(tài)，當(dāng)在運行態(tài)進行CFS1 編排包調(diào)用時，將CFS1 解析為RFS1/RFS2/RFS3，并執(zhí)行后續(xù)解析和實例化操作。

圖3 基礎(chǔ)的CFS設(shè)計和編排

b）基于a）已有的CFS/RFS 對象進行編排組合或嵌套，形成新的內(nèi)容更為豐富、較為復(fù)雜的CFS。如圖4 所示，在設(shè)計態(tài)將RFS4/RFS5/CFS1 進行編排設(shè)計，構(gòu)建生成CFS2 編排包，然后將編排包加載到運行態(tài)。當(dāng)在運行態(tài)進行CFS2 編排包調(diào)用時，將CFS2 解析為RFS4/RFS5/CFS1，然后再進一步將CFS1 解析為RFS1/RFS2/RFS3，并執(zhí)行后續(xù)解析和實例化操作。

圖4 復(fù)雜的CFS設(shè)計和編排

升級后的云網(wǎng)編排協(xié)同器將成為一個功能完備的、全棧的業(yè)務(wù)和能力編排協(xié)同器，即具備CFS/RFS/RES的設(shè)計、編排運行能力，其北向?qū)蝇F(xiàn)有的業(yè)務(wù)受理平臺（比如訂單平臺），承載業(yè)務(wù)開通指令；東西向?qū)淤Y源管理系統(tǒng)，負責(zé)業(yè)務(wù)開通相關(guān)資源的申請；南向?qū)痈鱾€域控制器，負責(zé)對底層網(wǎng)元、平臺的數(shù)據(jù)配置。云網(wǎng)協(xié)同器升級后，待已有業(yè)務(wù)完全割接到云網(wǎng)協(xié)同器后，可將現(xiàn)網(wǎng)的調(diào)度、服務(wù)開通系統(tǒng)逐步退出服務(wù)。升級后的云網(wǎng)編排協(xié)同器功能模塊圖如圖5所示。

圖5 升級后的云網(wǎng)協(xié)同器功能模塊

需說明的是，新增加的CFS 層與現(xiàn)有RFS/RES 層完全融合，在設(shè)計態(tài)工作區(qū)將對象設(shè)計、業(yè)務(wù)流程設(shè)計、策略設(shè)計、API 設(shè)計和編排包構(gòu)建模塊完全整合在一起，在運行態(tài)工作區(qū)將編排包就緒、服務(wù)接收、實例分解、業(yè)務(wù)流程執(zhí)行和策略執(zhí)行模塊完全整合在一起。先在設(shè)計態(tài)基于RES→RFS→CFS 的順序進行建模并結(jié)合工作流技術(shù)構(gòu)建編排包，然后將設(shè)計態(tài)工作區(qū)構(gòu)建的編排包加載到運行態(tài)工作區(qū)，通過編排包就緒模塊進行編排包校驗和測試，接著通過服務(wù)接收和實例化，按照設(shè)計的工作流流程，逐層逆向解析（即先把1 個CFS 對象分解為若干個RFS 對象，再把每個RFS 對象分解為若干個RES 對象，并進行實例化），最后將分解后的面向南向各個域控制器的API接口指令按照設(shè)計的工作流流程下發(fā)給各個域控制器執(zhí)行。

方式2：升級現(xiàn)有的調(diào)度、服務(wù)開通系統(tǒng)為業(yè)務(wù)編排平臺，以支持CFS 設(shè)計、編排、測試功能，或參考ONAP/TMF 架構(gòu)理念，另外獨立部署業(yè)務(wù)/應(yīng)用編排平臺，負責(zé)CFS 層面的設(shè)計、編排和測試，該平臺南向通過REST API與云網(wǎng)協(xié)同器對接，直接調(diào)用云網(wǎng)協(xié)同器的RFS/RES 編排能力，從而最終完成目標ONAP 架構(gòu)的部署。待已有業(yè)務(wù)完全割接到業(yè)務(wù)/應(yīng)用編排平臺后，可將現(xiàn)網(wǎng)的調(diào)度、服務(wù)開通系統(tǒng)逐步退出服務(wù)。業(yè)務(wù)編排平臺的具體設(shè)計內(nèi)容包括如下2種情況。

a）業(yè)務(wù)/應(yīng)用編排平臺的CFS 由若干個RFS 對象組成，業(yè)務(wù)/應(yīng)用編排平臺按照設(shè)定的業(yè)務(wù)流程將CFS拆解成RFS，然后直接調(diào)用云網(wǎng)協(xié)同器的RFS/RES 編排能力。

b）業(yè)務(wù)/應(yīng)用編排平臺的CFS 由若干個較為簡單的CFS 和RFS 對象嵌套組成，在業(yè)務(wù)/應(yīng)用編排平臺按照設(shè)定的業(yè)務(wù)流程將復(fù)雜的CFS 拆解成RFS，然后直接調(diào)用云網(wǎng)協(xié)同器的RFS/RES編排能力。

升級后的業(yè)務(wù)編排平臺東西向?qū)淤Y源管理系統(tǒng)，負責(zé)云網(wǎng)資源的核實分配，升級后的業(yè)務(wù)層和能力層設(shè)計編排功能模塊如圖6所示。

圖6 升級后的業(yè)務(wù)層和能力層設(shè)計編排功能模塊

本文提出的云網(wǎng)協(xié)同運營支撐架構(gòu)分層解耦、分步部署的演進方法，具有現(xiàn)實可行、平滑升級、靈活擴展、經(jīng)濟節(jié)約等特點，可以為運營商的云網(wǎng)協(xié)同運營支撐系統(tǒng)架構(gòu)向ONAP/TMF 架構(gòu)轉(zhuǎn)型的分步部署實施提供清晰的路徑指引和參考。運營商可以根據(jù)業(yè)務(wù)需求、技術(shù)成熟度、平臺建設(shè)進度和人員支撐情況，自主掌控云網(wǎng)協(xié)同運營支撐系統(tǒng)架構(gòu)演進進度。

4 結(jié)束語

本文介紹了一種分層解耦、分步部署的云網(wǎng)協(xié)同運營支撐系統(tǒng)架構(gòu)演進方法，在云網(wǎng)運營支撐系統(tǒng)架構(gòu)的設(shè)計和部署上將云網(wǎng)資源/能力編排協(xié)同層與云網(wǎng)業(yè)務(wù)/應(yīng)用編排協(xié)同層分離解耦，先將云網(wǎng)資源/能力編排協(xié)同層參考ONAP/TMF 架構(gòu)理念進行部署，再根據(jù)需要將云網(wǎng)業(yè)務(wù)/應(yīng)用編排協(xié)同層遷移到ONAP/TMF 架構(gòu)。本文介紹的方法可以為運營商的云網(wǎng)協(xié)同運營支撐系統(tǒng)架構(gòu)向ONAP/TMF 架構(gòu)轉(zhuǎn)型的分步部署實施提供清晰的路徑指引和參考。