1. 概述
隨著電信運營商、有線運營商、雲服務提供商以及他們的方案提供商對通用自動化平臺需求的增加，ONAP項目應時而生，並致力於在充分利用現有投資的前提下，提供差異化的、按需定製的、有競爭力的網絡服務。
在ONAP誕生之前，通信運營商為了提供新的業務，在從安裝新的數據中心設備到（某些情況下）升級客戶現場設備等一系列工作中，需要執行大量的人工調整工作。這種人工模式的規模和成本均對運營商提出了重大的挑戰。許多運營商都在尋求利用SDN和NFV技術，提高業務創新速度，簡化設備的互操作性和集成難度，降低整體的資產投入和運營成本。另外，目前碎片化的管理場景也使得端到端級別的業務質量難以得到監控和保障。截止當前ONAP已準備發布第三個版本，這些挑戰在現網依然存在。
ONAP通過為物理和虛擬網絡設備提供全局的和大規模（多站點和多VIM）的自動化功能來解決這些挑戰。它通過支持可以快速定義資源的TOSCA數據模型，提供一套通用的、開放的、可互操作的北向REST接口，以及支持YANG和TOSCA數據模型來提高業務敏捷性。ONAP的模塊化和分層特性有助於提高互操作性並簡化集成過程，它能夠與多個VIM、VNFM、SDN控制器甚至傳統網絡設備的集成來支持多VNF的環境。ONAP對VNF的整體要求發布將助力符合ONAP標準的VNF的商業部署。這樣既可以幫助網絡和雲業務運營商優化他們的物理和虛擬基礎設施，以降低成本、提高性能；同時，ONAP採用標準模型，降低了異構設備的集成和部署成本，同時最大限度地減少了管理的碎片化。
在ONAP平臺上，終端用戶/組織和他們的網絡/雲業務提供商可以在一個動態、閉環過程中進行協作，實例化網絡設備和業務，並對操作類事件進行實時響應。為了設計、實施、規劃、計費和保障這些動態業務，主要有三方面的要求：
一個健壯的設計框架，可以在各方面對業務進行規範，包括：對組成業務的各類資源和關係進行建模，制定指導業務行為的策略規則，制定業務彈性管理所需的應用、分析和閉環事件。一個流程/策略驅動的編排和控制框架（業務編排器和控制器），在必要時提供自動的業務實例化，並能夠彈性管理業務需求。一個分析框架，可以根據指定的設計、分析和策略，密切監控整個業務生命周期中的行為，實現控制框架所要求的響應，從而可以對從設備自愈到根據需求變化對資源進行擴縮容調整等各種情況進行處理。為此，ONAP將特定業務和技術細節從通用信息模型、核心編排平臺和通用管理引擎（用於發現、配置和保障等）中分離出來。此外，它將DevOps/NetOps方法的效率和模式與運營商引入新業務和技術所需求的正式模型和過程相結合。它利用包括Kubernetes在內的雲原生技術來管理和快速部署ONAP平臺及相關組件。傳統的OSS/管理軟體平臺架構會對業務和技術進行硬編碼，在整合變化時需要很長的軟體開發和集成周期，ONAP與之形成鮮明的對比。
ONAP平臺根據以下基本原則，支持產品/業務的獨立的設計、創建和生命周期管理：
在不需要平臺軟體新版本和影響現有業務的情況下，可以發布新業務，並對新技術動態進行全生命周期編排（包括設計、配置和運營）和業務API部署；電信級的可擴展性，包括橫向擴展（線性擴容）和分發，以支持大量的業務和大規模網絡；元數據驅動和策略驅動的架構，以確保使用和發布功能的靈活性和自動化；架構足夠靈活，可採用最好的組件；通用功能只需要一次開發，多次復用；核心功能支持多種不同的業務和基礎設施；隨著需求增長或收縮，架構應支持彈性擴展。2. ONAP架構
ONAP平臺提供了構建特定行為所需的通用功能（例如：數據採集、閉環控制、元數據流程創建、策略/流程分發等）。
當創建一項業務或運營能力時，需要在ONAP設計框架界面上設計業務/運營特定的業務定義、數據採集、分析方法和策略（包括糾正/補救措施的流程）。
圖1展示的是ONAP架構和基於微服務的平臺組件的概要設計視圖。
下文的圖2提供了ONAP架構的簡化功能視圖，突出部分關鍵組件的作用：
設計態環境用於往ONAP上線業務和資源，並基於它們設計新業務。對外API組件為ONAP平臺的北向接口提供了互操作性，同時Multi-VIM/CLOUD模塊支持ONAP系統負荷在雲間的互操作。OOM提供了Kubernetes託管雲環境下雲原生安裝和部署的能力ONAP的通用服務可以管理更加複雜和優化的拓撲。MUSIC允許ONAP擴展到多站點環境，以支持全局規模的基礎架構需求。OOF提供一種聲明性的、策略驅動的方法用於創建和優化應用，如歸屬/位置、變更管理調度優化等。信息模型和框架實用程序持續演進，以協同眾多標準化組織的拓撲、工作流和策略模型，包括ETSI NFV MANO、TM Forum SID、ONF Core、OASIS TOSCA、IETF和MEF等。
卡薩布蘭卡版本在設計態和運行態領域、ONAP安裝和S3P具有許多重要的新功能。
設計態：ONAP的SDC項目增加兩個新的儀錶盤——DCAE design studio和SO Workflow Designer，用於幫助設計人員、產品經理、運維人員和VNF的所有者在一個統一設計平臺上創建產品。
運行態：業務編排和生命周期管理項目具有支持物理網絡功能（PNF）、橫向擴展、重啟、流量遷移、擴展的硬體平臺感知（HPA），歸屬優化服務，地理冗餘和邊緣雲部署等新功能。 這將擴展生命周期管理工具包的操作集，提高性能和可用性，並解鎖邊緣自動化和5G用例。通過支持ETSI NFV-SOL003，可以讓ONAP兼容集成VNFM。
在監控、分析和服務保障方面ONAP在DCAE中提供對Linux Foundation PNDA項目的支持，為需要類似API的用戶提供CDAP的替代方案。另外，數據採集框架現在可以通過高容量採集器採集實時消息，處理PNF並支持SNMP和文件數據採集器。Policy項目引擎支持新的卡薩布蘭卡藍圖，而且可通過SDC中的策略設計功能分發策略，從而簡化設計過程。另外，Holmes告警關聯引擎具有新的GUI，並通過腳本提供更豐富的功能，再次簡化告警關聯規則的開發。
此外，A&AI具有新的能力，可通過提供歷史數據來支持審計功能。通過在MSB中集成Istio，ONAP服務可以訪問多種服務網格功能，從而提高可靠性、可觀察性和性能。ONAP的北向API持續與標準API對齊，包括TMForum（聚焦ServiceOrder）和MEF API（參考Legato和Interlude API），以簡化ONAP與OSS / BSS的集成。VID and UUI operations GUI項目可通過簡單的點擊界面支持更多的生命周期管理操作，使操作員可以輕鬆執行更多任務。此外，CLAMP項目提供了一個新的儀錶板，可用於在設計和運行期間觀測DMaaP和其它事件，以簡化控制環自動化的調試。
ONAP安裝：ONAP Operations Manager（OOM）通過利用Kubernetes（Docker和Helm Chart技術）進一步簡化ONAP的安裝。在卡薩布蘭卡版本中，OOM支持包括GlusterFS在內的可插拔的持久化存儲，為用戶提供更多的存儲選項。在多節點部署中，在可用資源和節點的選擇上，OOM可以對業務部署進行更多的控制。最後，OOM現在支持整套k8s部署的備份/恢復，從而引入數據保護。
卡薩布蘭卡版本引入了控制器設計工作室，將其作為控制器框架的一部分。它為ONAP控制器如何控制網絡資源以支持業務提供了模型驅動方法。
可部署性：卡薩布蘭卡版本延續了之前北京版本的7維指標體系（穩定性、安全性、可擴展性、性能，以及彈性、可管理性和可用性）。新的日誌項目——Post Orchestration Model Based Audit（POMBA）可以檢查設計模型和運行實例數據的偏差，從而提高網絡業務的可靠性。包括Logging、SO、VFC、A&AI、Portal、Policy、CLAMP和MSB在內的許多其他項目，在性能、可用性、日誌記錄、遷移到雲原生架構、身份驗證、穩定性、安全性和代碼質量等方面都有所改進。最後，集成在ONAP中的OpenDaylight和Kafka版本都更新到Oxygen和v0.11版本，分別提供P4和數據路由等新功能。
3. 微服務支持
作為由大量業務組成的雲原生應用，ONAP的初始部署和運營管理十分複雜
ONAP的部署方法應足夠靈活，以適應各種運營環境的不同場景和目標。用戶可能希望只選擇部分ONAP組件集成到他們自己的系統中。同時，ONAP平臺應該是高可靠、可擴展、安全且易於管理的。為了實現這些目標，ONAP被設計為服務化的系統，其所有組件都通過Docker容器發布。
OOM負責協調端到端的生命周期管理和ONAP組件的監控。 OOM通過Kubernetes來提高CPU利用率並提供平臺部署方法。另外，通過增強其管理組件的可擴展性和彈性，OOM有助於提升ONAP平臺的成熟度。
OOM是ONAP平臺的生命周期管理器，它利用Kubernetes容器管理系統和Consul提供以下功能：
部署 - 內置組件的依賴管理（包括多集群，跨站點的聯合部署和反親和性規則）配置 - 所有ONAP組件的統一配置監控 - 實時的健康監控，將監控的數據提供給Consul GUI和Kubernetes重啟 - 啟動失敗的ONAP組件將自動重啟集群和擴展 - 集群化的ONAP業務可實現無縫擴展升級 - 在輕微或不影響業務的情況下更換容器或配置刪除 - 清除單個容器或整套部署OOM支持大量雲基礎架構，以滿足您的個性化需求。
微服務總線（MSB）提供基礎的微服務支持，包括服務註冊/發現、外部API網關、內部API網關、客戶端軟體開發工具包（SDK）和Swagger SDK。MSB同時支持OpenStack（Heat）和裸機部署。當與OOM集成時，MSB有一個Kube2MSB註冊器，它可以從k8s元文件中獲取服務信息，並自動註冊ONAP組件的服務。
4. Portal
基於用戶角色，ONAP可以在設計態和運行態兩種環境下提供統一一致的用戶體驗。在單個ONAP實例中可以對角色進行修改定製。
ONAP的Portal對用戶體驗進行管理，它通過共享的、基於角色的菜單或儀錶盤，提了設計、分析和運營控制/管理功能的操作入口。Portal架構提供了基於Web的各種能力，包括應用的上線和管理、基於AAF的集中訪問控制、儀錶盤和託管應用程式小部件等。
Portal提供了SDK，可以使多個開發團隊利用內置模塊（服務/API/UI控制項）、工具和技術滿足其一致的UI開發需求。ONAP也為部分操作人員提供所需（例如：當他們需要與他們的腳本環境集成時）的命令行界面（CLI）。ONAP SDKs可以使運營/安全、第三方（例如：供應商和顧問）和其它領域的專家不斷地定義/優化新的採集、分析方法和策略（包括糾正和補救行為的策略），他們通過使用ONAP設計框架的Portal就可以完成這些工作。
5. 設計態框架
設計態框架是一個全面的開發環境，它包括了各種工具、技術以及定義/描述資源、服務和產品的資源庫。設計態框架有助於模型復用，隨著可用模型規模的增大，可以更進一步地提高效率。資源、業務和產品，以及它們的管理和控制功能都可以使用一套控制行為和流程執行的規範和策略（例如規則集）進行建模。流程規範可以自動完成資源、業務、產品和ONAP平臺組件的實例化、發布和生命周期管理。某些特定的流程規範和策略可以根據地理位置進行分發部署，從而提升混和雲環境下的性能優化和自動化程度。
SDC提供定義/模擬/驗證系統資產及其相關過程和策略所需的工具、技術和存儲庫。每一項資產都可以歸到資源、業務、產品、要約等四類的一種。
SDC環境通過通用服務和實用程序支持不同用戶。通過使用設計工作室，產品和業務的設計人員可以上線/擴展/下線資源、業務和產品。操作人員、工程師、客戶體驗經理和安全專家創建工作流、策略和方法，來實現閉環自動化/控制和管理彈性擴展能力。
為了支持和鼓勵一個健康的VNF生態，ONAP在VNF供應商API、VNF SDK和VVP組件中提供一套VNF打包和驗證工具。廠商可以在他們的CI（持續集成）/CD（持續交付）環境中集成這些工具，從而打包VNF，並將其上傳到驗證引擎。一旦經過測試，這些VNF就可以通過SDC上線。另外，VNFSDK的測試功能正在LFN合規性認證計劃中使用，以確保採用高度一致的VNF驗證方法。
Policy Creation組件用於處理策略；這些是必需提供、維護和/或強制執行的規則、條件、要求、約束、屬性或需求。在較低層面上，策略包括機器可讀的規則，使得機器可以基於觸發器或請求採取行動。策略通常考慮實際應用中的特定條件（無論是在符合條件時觸發特定的策略，還是採取特定的策略以接近特定的條件）。
策略允許通過更新規則進行快速修改，從而在不需要重寫軟體代碼的情況下，更新使用這些策略的組件的技術行為。策略允許通過抽象簡化對複雜機制的管理/控制。
CLAMP為閉環控制的設計和管理提供了一個平臺。CLAMP用於設計一個閉環，針對某一項網絡業務配置其特定的參數，然後部署和停止使用。一旦部署，用戶可以在運行期間內更新控制環的參數，也可以暫停和重新啟動它。
6. 運行態框架
運行態執行框架執行SDC分發的規則和策略。
運行態框架允許在不同的ONAP模塊（例如SO，控制器，DCAE，A&AI）中分發策略實施、模板，以及一個安全的框架。這些組件都使用了支持日誌、控制訪問和數據管理的通用服務。新組件MUSIC允許平臺註冊和管理多個站點的部署狀態。外部API為第三方框架（例如MEF、TM Forum等）提供訪問接口，從而支持運營商BSS與ONAP相關組件間的交互。日誌服務還包括基於事件的一致性校驗功能，從而支持編排後的一致性分析。
編排
SO組件通過自動順序執行按需創建、修改或移除網絡、應用或基礎架構業務和資源所需的活動、任務、規則和策略，從而執行指定的流程。SO在一個非常高的層次上進行編排，並提供基礎設施、網絡和應用的端到端視圖。
外部API北向接口組件在BSS和各個ONAP組件間提供標準化的接口，包括Service Orchestrator，A＆AI和SDC。這樣不需要通過長時間和高成本的基礎架構集成，就可以在現有BSS / OSS環境中提供平臺的抽象視圖。北京版本及後續ONAP版本將持續增強和標準化組織間的合作，最終實現支持MEF、TM Forum等相關標準機構定義的運營商之間的交互用例以及其它用例。
VID應用可以使用戶從SDC實例化基礎架構服務及其相關的組件，並執行變更管理操作，例如對現有VNF實例進行擴展和更新軟體。
策略驅動的工作負載優化
OOF提供一個策略驅動和模型驅動的框架，用於為各種用例創建優化應用。 OOF HAS是一個策略驅動的工作負載優化服務，可基於各種策略約束（包括容量，位置，平臺能力和其它特定的業務約束）實現跨多站點和多雲的業務優化部署。
ONAP MC和其它一些ONAP組件（如Policy、SO、A&AI等）在通過OOF-HAS實現跨雲站點的「策略驅動的性能/安全感知的自適應工作負載部署/調度」中發揮了重要的作用。 OOF-HAS利用HPA和ONAP MC提供的實時容量檢查，來確定最優的VIM /雲實例，這些實例可以為工作負載（VNF等）的部署和調度（歸屬）提供所需的性能SLA。現在運營商在保障性能和安全SLA的同時，可以通過雲資源的細粒度優化實現虛擬化的真正價值。這一特性已經在北京版本的vCPE用例中得到體現。
控制器
控制器是一些應用程式，這些應用程式將雲和網絡業務耦合，並執行配置和實時策略，以及控制分布式組件和業務的狀態。運營商可以選擇使用多種不同的控制器類型，來管理執行環境中與其分配的控制域中相應的資源，例如雲計算資源（網絡配置SDN-C和應用App-C），而不是僅使用單一的整體控制層。此外，VF-C提供符合ETST NFV標籤的NFVO功能，並負責虛擬業務和相關物理的（CTOS）通用伺服器基礎設施的生命周期管理。VF-C提供通過的VNFM功能，同時也可以與外部的VNFMS和VIM集成，作為NFO MANO堆棧的一部分。
新項目MUSIC將記錄和管理Portal和ONAP優化框架的狀態，以確保跨地理分布的ONAP部署的一致性，冗餘性和高可用性。
清單
A&AI提供系統資源、業務、產品及其相互關係的實時視圖，在卡薩布蘭卡版本中，它還保留了歷史視圖。A&AI提供的視圖將多個ONAP實例管理的數據、業務支持系統（BSS）、運營支持系統（OSS）和網絡應用進行關聯，從而形成一個從終端用戶購買的產品到形成產品原材的資源的自上而下的視圖。A&AI不僅形成產品、業務和資源的註冊表，還保持這些清單項目的相互關係的最新視圖。
為了保證SDN/NFV的承諾的動態特性，當控制器在網絡環境進行更改時，會對A&AI進行實時更新。A&AI是元數據驅動的，允許通過SDC產品目錄定義快速地動態添加新的清單類型，從而避免冗長的開發周期。
多雲自適應
Multi-VIM/Cloud為VIM /雲提供基礎設施適配層，除了標準功能外，還可以提供高級硬體平臺的感知和意圖功能，可用於OOF，以及為雲無關工作負載部署增強雲選擇和SO/VF-C的其他組件。其中，意圖功能是在卡薩布蘭卡版本中新引入的。
7. 閉環自動化
閉環控制是由許多設計態和運行態元素間的協作完成的。運行態環始於DCAE，然後經過微服務循環（如用於事件檢測的Homes、用於決定動作的Policy），最後由控制器和協調器實現動作。CLAMP用於監視這些循環自身。CLAMP、Policy和DCAE都可以在設計態中創建循環。
我們將這種自動化模式稱為「閉環自動化」，是因為它提供了必要的自動化功能，可以在沒有人工幹預的情況下對網絡和業務條件進行響應。圖3是「閉環自動化」的高級示意圖，顯示了使用自動化功能後業務生命周期內的不同階段。
閉環控制是通過DCAE和一個或多個其它ONAP運行態組件提供的。它們共同提供FCAPS功能。DCAE收集性能、使用情況和配置數據，提供分析計算，幫助排除故障和發布事件、數據和分析方法（例如向策略、編排器和數據湖發布）。另一個組件Holmes與DCAE連接，並為ONAP提供告警關聯功能。在卡薩布蘭卡版本中，DCAE可以利用PNDA支持新的分析功能，利用高容量VES和批量性能管理的支持可以提供新的數據採集功能。
通過與Policy Framework和CLAMP協作，這些組件可以檢測網絡中存在的問題，並確定適當的補救措施。在某些情況下，這個工作是自動的，並且它們會通知SO或其中一個控制器採取行動。在其它情況下，根據操作人員的配置，它們會發出一個警報，在人工幹預後再執行操作。通過引入自適應的策略執行，policy framework得到擴展，可以支持其他策略決策能力。
8. 通用服務
ONAP為所有ONAP組件提供通用的運行服務，包括活動記錄、報告、通用數據層、訪問控制、彈性和軟體生命周期管理。
這些服務提供訪問管理和安全執行、數據備件恢復和修復。它們支持標準化的VNF接口和指南。
在虛擬化的環境中運行會引入新的安全挑戰和機遇。ONAP通過在每個ONAP平臺組件中嵌入訪問控制來提供更高的安全性，同時專門設計用於檢測和調整違規操作的分析和策略組件來進一步增強安全性。
9. ONAP建模
ONAP提供的模型有助於業務設計，ONAP服務組件的開發以及標準互操作性的改進。
模型是設計態和運行態框架開發的重要組成部分。ONAP建模項目利用成員公司、標準化組織和其他開源項目的經驗，生成簡單、可擴展和可重用的模型。目的是滿足不同用例的需求，指導開發，保證ONAP組件間的一致性，並探索一個通用模型來提高ONAP的互操作性。
在卡薩布蘭卡版本中，ONAP支持下列模型：
基於ETSI NFV IFA011 v.2.4.1的VNFD信息模型，根據ONAP的需求進行了適當的修改；基於TOSCA實現（基於IM）的VNFD模型，模型遵循ETSI NFV SOL001 v 0.6.0中相同模型的定義。基於ETSI NFV SOL004規範的VNF包格式。通過VFC（使用建模項目提供的解析功能）實現了網絡業務描述符（NSD）。這些模型使ONAP可以與其它基於標準的實現進行交互，改善業界的協作。
10. ONAP藍圖
ONAP可以支持無限數量的用例。但是，為了提供如何使用ONAP解決實際問題的具體示例，開發社區已經創建了一套藍圖。除了通過端到端的解決方案幫助用戶快速採用ONAP平臺之外，這些藍圖還有助於社區優先處理他們的工作。隨著ONAP卡薩布蘭卡版本的發布，我們推出了兩個新的藍圖：5G和CCVPN。之前的藍圖：vCPE、VoLTE和vFW/vDNS也已經移植到卡薩布蘭卡版本。
5G藍圖5G藍圖是經過多個版本的努力的，卡薩布蘭卡版本圍繞PNF集成、邊緣自動化、實時分析、網絡切片、數據建模、歸屬、擴容和網絡優化引入了第一組功能。eMBB（承諾20 Mbps的峰值速率）、uRLLC（保證亞毫秒響應時間）和MMTC（可支持每平方英尺0.92個設備）的組合為它帶來一些獨特的需求。首先，ONAP需要支持除VNF之外還包括PNF的網絡業務。然後，ONAP需要支持邊緣雲場景，因為網絡業務將不再局限於大型數據中心，而是會擴散到大量分布式邊緣位置。最後，ONAP需要為分析和策略驅動的閉環自動化實時採集性能數據。這些需求引領了ONAP內部的一些方案，從而全面解決5G藍圖。
了解更多信息請閱讀5G Blueprint: https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_5G_112118FNL.pdf
vCPE藍圖本藍圖針對住宅用例場景，向租戶提供的業務目前限於寬帶住宅網關中設計的服務。 在這個藍圖中，客戶擁有一個纖薄的物理CPE（pCPE），它只包含橋接功能，連接到DSL或DOCSIS等傳統寬帶網絡（如圖5所示）。通過建立一條到託管各種VNF的數據中心的隧道，可以以低成本向租戶提供更多的業務。ONAP通過包括兩個關鍵組件：管理連接業務的SDN-C和管理虛擬化業務的APP-C，可以支持虛擬連接和底層連接的複雜編排和管理。在這種情況下，ONAP為端到端的業務提供了一個公共業務編排層。此藍圖展示了擴展，變更管理和HPA等高級功能。
了解更多信息請閱讀Residential vCPE Blueprint: https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_vCPE_112918 FNL.pdf
VoLTE藍圖本藍圖利用ONAP編排VoLTE業務。本藍圖演示了移動業務提供商（SP）如何基於SDN / NFV部署VoLTE服務。VoLTE藍圖通過與邊緣數據中心和核心數據中心之間的廠商組件（包括VNFM、EMS、VIM和SDN控制器）互通，整合商業VNF，以創建和管理底層vEPC和vIMS業務。ONAP通過幾個關鍵組件支持VoLTE用例，具體包括SO、VF-C、SDN-C和Multi-VIM /Cloud。 在本藍圖中，SO負責與VF-C和SDN-C協作的VoLTE端到端業務的編排。SDN-C建立網絡連接，而VF-C組件負責網絡業務和VNF生命周期管理（包括業務啟動、終止和手動擴展）和FCAPS（故障、配置、計費、性能、安全）的管理。
了解更多信息請閱讀VoLTE Blueprint: https://www.onap.org/wp-content/uploads/sites/20/2018/11/ONAP_CaseSolution_VoLTE_112918FNL.pdf
CCVPN藍圖CSP（如CMCC和Vodafone）發現承載網絡間對於高帶寬、扁平、高速OTN（光傳輸網絡）的強烈需求。他們希望為大客戶提供高速、靈活和智能化的業務，並為中小型企業提供即時靈活的VPN業務。
CCVPN（跨域和跨層VPN）藍圖結合了SOTN（超高速光傳輸網絡）和SD-WAN，它利用ONAP的編排能力，實現資源和業務的統一管理和調度。它實現了跨域編排和跨服務提供商的ONAP對等。ONAP多個關鍵組件支持CCVPN用例，其中包括：SO、VF-C、SDN-C、Policy、Holmes和DCAE。在本藍圖中，SO負責與VF-C和SDN-C協作的CCVPN端到端業務的編排。SDN-C建立網絡連接，然後VF-C組件完成網絡業務和VNF生命周期管理。跨運營商的ONAP對接使用的是東西向API，與MEF Interlude API保持一致。本用例的關鍵創新是物理網絡的發現和抽象建模、跨多個物理網絡的跨域編排、跨運營商端到端業務的開通以及跨域業務的閉環重路由。
了解更多信息請閱讀CCVPN Blueprint：https://www.onap.org/wp-content/uploads/sites/20/2018/12/ONAP_CaseSolution_CCVPN_112818FNL.pdf
虛擬防火牆、虛擬DNS藍圖是驗證ONAP正確安裝，以及初步了解ONAP的基本演示案例。 本藍圖由5個VNF組成：vFW、vPacketGenerator、vDataSink、vDNS和vLoadBalancer。本藍圖展示了ONAP的大部分內容，包括VNF裝載，網絡業務創建，業務部署和閉環自動化。涉及的關鍵組件包括SDC、CLAMP、SO、APPC、DCAE和Policy。
11. 結論
ONAP平臺為物理/虛擬的網絡功能提供了一個實時的、策略驅動的編排自動化綜合平臺，這將使軟體、網絡、IT、雲業務提供商和開發人員可以快速自動化的部署新的業務，並支持全生命周期管理。
聯合ONAP成員的資源，聚焦開放的標準體系，藉助全球共享的平臺架構和網絡自動化的實現，ONAP將比任何一個單獨的產品更快速地發展成為一個充滿活力的生態系統。
12. 資源
在Youtube和Youku上觀看主要平臺組件的相關視頻。
閱讀了解如何利用容器部署ONAP。
附：中英文對照表
1 operator 運營商
2 infrastructure 基礎架構
3 performance 性能
4 deploy 部署
5 response 響應
6 recipe 流程
7 policy 策略
8 instantiation 實例化
9 provisioning 供應
10 view 視圖
11 analytics 分析方法
12 dashboard 儀錶盤
13 onboard 上線
14 corrective 糾正
15 remedial 補救
16 design time 設計態
17 execution time / runtime 運行態
18 repositories 資源庫
19 retire 下線
20 process 流程
21 inventory 清單
22 create 創建
23 publish 發布
24 SDO 標準化組織
註：以下專用名詞在譯文中保持原文，以下翻譯僅供參考。
1. SLA（service-level agreements）：業務質量
2. VIM（Virtualised Infrastructure Manager）：虛擬化基礎設施管理器
3. VNFM（Virtualised Network Functions Manager）：虛擬化網絡功能管理器
4. VNF（Virtualised Network Function）：虛擬化的網絡功能
5. OSS（Office of Strategic Services）：運營支撐系統
6. SDC（Service Design and Creation）：業務設計和創建模塊
7. SDK（Software Development Kit）：軟體開發工具包
8. Policy Creation：策略制定
9. CLAMP（Closed Loop Automation Management Platform）：閉環自動化管理平臺
10. SO（Service Orchestrator）：業務編排器
11. DCAE（Data Collection, Analytics and Events）：數據採集、分析和事件模塊
12. A&AI（Active and Available Inventory）：活躍和可用清單
13. VF-C（Virtual Function Controller）：虛擬功能控制器
14. FCAPS（Fault Configuration Accounting Performance Security）：故障、配置、計費、性能、安全
15. Policy Framework：策略框架
16. OOF（ONAP Optimization Framework）：ONAP優化框架
17. OOM（ONAP Operations Manager）：ONAP運行管理模塊
18. MSB（Microservices Bus）：微服務總線
19. VVP（VNF Validation Program）：VNF驗證程序
20. MUSIC（Multi-Site State Coordination）：多站點狀態協調
21. VID（Virtual Infrastructure Deployment）：虛擬基礎架構部署
22. HAS（Homing and Allocation Service）：歸屬分配服務
23. MC（Multi-VIM / Cloud）：多VIM/雲
24. HPA（Hardware Platform Awareness）：硬體平臺感知