OpenNESS，開源的邊緣網絡服務平臺

目錄

文章目錄

• 目錄
• 參考文章
• OpenNESS 的電梯間演講
• OpenNESS 與 ETSI MEC
• Edge Controller Software 的功能清單
• Edge Platform Software 的功能清單
• OpenNESS 的部署方案
• On-Premise Edge Deployment
• Network Edge Deployment
• OpenNESS 的架構
• 抽象架構
• ME APP 的類型
• 軟件架構
• Edge Application APIs
• OpenNESS 做爲一個邊緣應用程序管理系統
• 邊緣應用下發（Onboarding）
• 邊緣應用控制以及流量策略下發
• 檢索 Edge Platform 上全部的 ME APP
• ME APP 雲適配器（Cloud Adapter）
• OpenNESS 做爲一個邊緣網絡的服務平臺
• NTS（Network Traffic Service）
• Upstream Traffic
• Downstream Traffic
• Traffic Rule Setup
• LTE CUPS 流量策略配置
• OpenNESS & OpenVINO
• OpenVINO
• OpenVINO 的架構
• 模型優化器（Model Optimizer）
• 推理引擎（Inference Engine）
• OpenNESS & OpenVINO 運行原理
• 部署架構
• 相關術語
• EPC（4G 核心網絡）
• uCPE（通用客戶端設備）
• vRAN（ 虛擬無線接入網）
• NGCO（新一代中央辦公室）
• GTP 協議
• S1 接口
• PDN
• PGW 與 SGi 接口
• LTE CUPS
• OAM
• LTE 網格架構

參考文章

《5G 與 MEC 邊緣計算》
《DPDK 網絡加速在 NFV 中的應用》
《數據中心網絡架構的問題與演進 — NFV》

OpenNESS 的電梯間演講

OpenNESS（Open Network Edge Services Software）是一個開源的邊緣應用程序管理系統，使服務提供商和企業可以在任何網絡的邊緣上構建、部署和操做本身的邊緣應用程序（ME APP），支持經過簡易的方式將運行在 Telco/Public Cloud 中的 APP 遷移到邊緣。

OpenNESS is an Open Platform that enables Service Providers and Enterprises to build, deploy, and operate an Edge Services Management System on any Network Edge.

同時，OpenNESS 仍是一個邊緣網絡的服務平臺，支持在多雲環境中跨越多種類型的網絡平臺（Network Platform，e.g. NTS、OvS、vPP）以及多種類型的訪問技術（Access Technologies，e.g. S1_U、SGi、IP）。讓用戶可以輕鬆的編排和管理運行在邊緣上的應用程序，併爲客戶端（UE）和邊緣應用程序提供端到端（End to End）的網絡鏈接服務。

An open source software toolkit to enable easy orchestration and management of edge services across diverse network platform and access technologies in multi-cloud environments.

注：端到端是一種網絡鏈接。網絡要通訊，必須創建鏈接，無論有多遠，中間要通過有多少機器，都必須在兩頭（源和目的）間創建鏈接，一旦鏈接創建起來，就說已是端到端鏈接了，即端到端是邏輯鏈路。端到端是傳輸層的，TCP 就是用來創建端到端鏈接的協議。好比你要將數據從 A 傳送到 E，中間可能通過 A→B→C→D→E，對於傳輸層來講並不知道 B，C，D的存在，傳輸層只認爲報文數據是從 A 直接到 E 的，這就叫作端到端。一旦通訊完成，這個端到端的鏈接就會釋放，物理線路可能又被別的應用用來創建鏈接了。

OpenNESS 與 ETSI MEC

簡而言之，OpenNESS 就是一個能夠充當 ETSI MEC 參考模型中的 MEPM、MEP 以及 Data Plane 角色的平臺級開源軟件。

• MEPM（ME platform manager，移動邊緣平臺管理器）：具備 MEP 元素管理、ME APP 生命週期管理以及 ME APP 的規則與需求管理等功能。
  • ME APP 生命週期管理：包括 ME APP 的建立和終止，而且爲 MEO 上報 ME APP 相關事件的指示消息。
  • ME APP 規則與需求管理：包括身份認證、流量規則、DNS 配置和 UE 切換致使的衝突協調（非合做博弈，納什均衡算法）等。
• MEP（ME platform，移動邊緣平臺）：從 MEPM、ME APP 或 ME Service（支撐 MEP 的底層 Services）處接收流量轉發規則（Traffic Rules），而且基於轉發規則向 Dataplane（數據面）下達轉發指令。另外，MEP 還支持本地 DNS 服務、代理服務器的配置，能夠將數據流量重定向到預期的 ME APP 或 ME Service。MEP 還能夠經過 Mp3 參考點與其餘的 MEP 進行通訊，在分佈式 MEC 系統的協做機制中，Mp3 參考點能夠做爲不一樣 MEP 互聯協做的基礎。
• ME APP（移動邊緣應用） ：是運行在 ME VIM 上的 Application 實例，ME APP 經過 Mp1 參考點與 MEP 相互通訊。Mp1 參考點要求提供 ME APP 可用性（Availability）標識，發生 UE 切換時爲用戶準備或重定位 ME APP 會話狀態等額外功能。

根據 ETSI MEC 參考模型，OpenNESS 採用了 Edge Controller Software（簡稱 Controller）與 Edge Platform Software（簡稱 Edge）分離的分佈式軟件架構設計思路。其中，Edge Controller Software 充當着 MEPM 的角色運行在 Data Center 或 Cloud 中，而 Edge Platform Software 則充當 MEP 以及 Dataplane 的角色運行在任何 Network Edge 之上，包括：uCPE（通用客戶端設備）、vRAN（虛擬無線接入網）以及 NGCO（新一代的電信機房，或稱中央辦公室）。

Edge Controller Software 的功能清單

前端 WebUI、用戶帳號管理、邊緣應用鏡像註冊、EPC CUPS核心網配置、邊緣節點生命週期管理、邊緣應用生命週期管理、邊緣虛擬化基礎設施管理、監控。

• Web UI front end
• User account management
• Edge compute application image repository
• Core Network Configuration
• Edge Node Lifecycle Management
• Edge Application Lifecycle Management
• Edge virtualization infrastructure management
• Telemetry

Edge Platform Software 的功能清單

Edge Node 註冊、Edge Node 網絡接口配置、本地 DNS 服務、Edge Node 虛擬化基礎設施、ME APP 流量策略、數據平面服務、應用認證。

• Edge Node Enrolling（Edge Node 註冊）：在 Edge Node 首次啓動時，須要註冊到 Controller 中。由 ELA 完成。前提是須要拿到 Controller 頒發的 CA 證書來創建 TLS API 通訊。

• Edge node interface configuration（Edge Node 網絡接口配置）：在 Edge Node 註冊到 Controller 以後，Edge Node 會將自身的 Network Interface 信息上報到 Controller。以此做爲配置 Upstream、Downstream 或者 local breakout 網口（Local Break-out Port，LBP）的依據。由 ELA 完成。

• DNS service（DNS 服務）：爲 ME APP 提供 DNS 服務，屬於數據面的 DNS。基於 Go DNS library 實現。

• Edge Node Virtualization infrastructure（Edge Node 虛擬化基礎設施）：從 Controller/NFV-O 接收啓動或中止 ME APP VI 的請求，並執行操做。由 EVA 完成。

• Edge application traffic policy（ME APP 流量策略）：爲 ME APP 設置數據面流量轉發策略。由 EDA 完成。

• Data Plane Service（數據平面服務）：經過 Edge Node 上運行的 NTS 服務，將數據面的流量導向 ME APP 或 LBP APP。使用了 DPDK 進行 I/O 加速。

• Application Authentication（應用認證）：對 ME APP 進行身份認證/鑑權，以肯定 APP 之間具備權限可被調用。只有在 ME APP 打算調用 Edge Application Authentication APIs 時纔會進行認證，支持 TLS 鏈接。須要注意的是，Edge Application Authentication APIs 僅對 Native ME APP 有效，由於 LBP APP 和 Ported ME APP 都不會在 EAA 中進行註冊。

NOTE：Edge Node 資源使用要求

• 全部非關鍵/非實時（non-critical/non-realtime）的微服務推薦綁定在 Core 0 上運行。
• NTS Dataplane 微服務和 DPDK PMD 推薦進行 CPU 綁定。
• 爲 DPDK 庫使用大頁內存。
• 使用 RT kernel，在 VNFs 和 APPs 共存的場景中。

OpenNESS 的部署方案

OpenNESS 提供了兩種參考部署方案，On-Premise Edge 和 Network Edge。二者最明顯的標準在於 VI（虛擬化基礎設施）的提供形式，前者提供的是本地的 VI，即 Edge Node 之上的 Docker/Libvirt；然後者提供的則是 MEC VIM 基礎設施。用戶應該針對不一樣的場景，考慮使用不一樣的部署方案。

On-Premise Edge Deployment

On-Premise Edge Deployment，又稱爲企業級部署方式，Edge Platform Software 部署在 uCEP 上，處於企業網絡範圍內，而 Edge Controller Software 則部署在 Telco/Public Cloud 之上。

On-Premise Edge Deployment 面向的是將 Edge Node 做爲 IaaS 子系統的應用場景，是中心業務向邊緣的延伸。在該場景中，用戶的需求只是單純的但願 APP 能夠儘可能的靠近其服務的終端，來處理一些實時性要求比較強的業務。

因此只須要爲 ME APP 提供一個可用於運行的 x86 服務器做爲 Edge Node 便可，Edge Platform Software 直接經過 Edge Node 上的 Docker/Libvirt 部署 VI，無需添加 VIM。也所以，該部署方式也只能針對一個租戶來使用，而並不是是專門爲 MEC 而設計的部署方式（MEC 要求多租戶可使用同一邊緣雲）。經過應用於客戶辦公室、工廠、體育場或其餘單租戶設施中。

Network Edge Deployment

Network Edge Deployment，Edge Platform Software 部署在 NFVI 之上，運行於 NGCO 或 vRAM 的無線接入聚合點（Wireless Access aggregation point）中。而 Edge Controller Software 則一樣部署在 Telco/Public Cloud 之上。

該部署方式再也不面向單一或小規模的 Edge Node，而是擁有針對 MEC 的虛擬化基礎設施管理系統（VIM），即：邊緣計算基礎設施（OpenStack/Kubernets）。要求邊緣計算基礎設施位於網絡運營商的設施內，並做爲數據網絡（Data Network，包含接入網，核心網以及邊緣計算基礎設施）的一部分，與 OSS 集成在一塊兒。應用於多租戶場景，而且規模很是大。Edge Controller Software 不只能夠管理邊緣計算基礎架構，還能夠經過網絡鏈接管理網絡基礎架構。是更加貼近於 ETSI MEC 參考模型的部署方式。

OpenNESS 的架構

抽象架構

首先看 OpenNESS 的抽象架構與接口類型，徹底符合 ETSI MEC 參考架構標準。

• 紅色框爲 OpenNESS 核心組件：Edge Controller Software、Edge Platform Software 以及 Data Plane；
• 綠色框爲 ME APP：能夠分爲 Edge Native APP 和 Public Cloud APP。
  • Edge Native APP：原生在 Edge Platform 上運行的 APP，這是咱們討論的重點。
  • Public Cloud APP：即從公有云遷移到 Edge Platform 的 APP。
• 藍色框爲 OpenNESS 與蜂窩網絡（Cellular Network）集成所須要的互補性商業解決方案：好比 MEO、VIM 等等。

ME APP 的類型

從 ME APP 的做用區別，又能夠分爲：

• Producer APP（生產者應用）：又稱 Edge services，爲其餘 ME APP（Consumer APP）提供服務。 它不直接爲最終用戶提供服務。e.g. 定位服務，地圖服務，代碼編譯服務等等。

  • 調用 Producer APP 必需要進行身份認證（Authenticate）以及獲取 TLS。
  • Producer APP 必須被其餘 ME APP 發現後纔可以被調用，而 Producer APP 被發現的前提是要激活它們。
  • Producer APP 必須具備若干個用於提供 Notification Update（更新通知）的字段，以此來傳遞消息。

• Consumer APP（消費者應用）：直接爲最終用戶提供服務，Consumer APP 能夠選擇訂閱若干個 Producer APP 爲其提供服務。E.g. CDN 服務，AR 服務，VR 服務，視頻服務等等。

  • 若是 Consumer APP 無需調用 Edge Application APIs，也就無需進行身份認證。Edge Application APIs 負責爲全部 ME APP 提供 API Endpoint，繼而對外提供 Services。
  • Consumer APP 能夠訂閱若干個 Producer APP，後續版本中要會加入建立 ACL（訪問控制列表）的功能。
  • Consumer APP 與 Producer APP 之間的 Notification Update 經過 Web Socket Connection 來完成，Connection 由 Consumer APP 發起建立。這種方式還能夠用於 ME APP 與其餘的 NFVI 組件（e.g. OVS/VPP/NIC-VF）進行通訊。

軟件架構

在看 OpenNESS 的軟件架構，Edge Controller Software 和 Edge Platform Software 均由一組特定的微服務組成，微服務之間使用 gRPC（Google Remote Procedure Calls）進行通訊。

• WebUI Font END：Web 前端操做界面。

• Edge Platform/Controller Gateway：Edge Controller Software 與 Edge Platform Software 之間進行通訊的物理路由網關。

• EAA（Edge Application Agent）：映射到 ETSI MEC Mp1 參考點，做爲 ME APP 與 MEP 交互的媒介。Mp1 參考點要求能夠標識 ME APP 的可用性、會話狀態重定位等功能。

  • EAA 提供了 Edge Application APIs 給 ME APP 調用，提供服務發現，服務註冊，服務間通訊等功能，而且支持驗證 ME APP 的可用性，支持 UE 切換（基站）時需求的 ME APP 會話狀態重定位。激活從 Edge Controller Software（MEPM）經過 ELA 下發的針對 ME APP 的 Traffic Rules 和 DNS rules 配置。
  • EAA 提供了 Edge Application Authentication APIs 對全部打算調用 Edge Application APIs 的 ME APP 進行身份認證，在驗證了 ME APP 的身份以後會向該 APP 頒發 TLS 證書，正式創建通訊通道。

• ELA（Edge LifeCycle Agent）：映射到 ETSI MEC Mm5 參考點，做爲 MEPM 和 MEP 交互的媒介。Mm5 參考點要求實現對 MEP 的配置、對 Traffic Rules 的配置，而且負責管理 ME APP 會話狀態重定位方式以及支持 ME APP 的生命週期管理。

  • ELA 提供了 Edge Lifecycle Management APIs 供 Edge Controller Software（MEPM）調用，進行 MEP 配置的下發（Configuration of Edge Platform）等操做；
  • ELA 經過調用 EAA 提供的 Edge Application APIs 下發的針對 ME APP 的 Traffic Rules 和 DNS rules 配置，同時也支持 ME APP 的會話狀態重定位等功能；
  • ELA 經過調用 EVA 提供的 Edge Virtualization Infrastructure APIs 來完成 ME APP 的生命週期管理；
  • ELA 經過調用 EDA（NTS）來完成針對 Upstream/Downstream Interface 的 Traffic Rules 和 DNS rules 配置的下發。

• EVA（Edge virtualization Agent）：映射到 ETSI MEC Mm6 和 Mm7 參考點。其中 Mm6 做爲 MEPM 和 VIM 的交互媒介，要求支持收集 VIM 虛擬資源信息以及 VIM 虛擬資源使用和管理；Mm7 做爲 VIM 和 Dataplane 的交互媒介，完成數據流量的過濾和轉發。

  • EVA 提供了 Edge Virtualization Infrastructure APIs，支持虛擬化資源的管理。須要注意的是，在 OpenNESS 中，虛擬化資源區分爲 On-Premise Edge Deployment 中的 Edge Node（Docker/Libvirt）或者是 Network Edge Deployment 中的 MEC VIM（OpenStack/Kubernets）。爲了實現後者，在 Edge Controller Software 實現了一個 External EVA Service， 該 Service 會直接調用 External Orchestrator（OpenStack/Kubernets）進行 VI 的部署。
  • 須要注意的是，OpenNESS 沒有實現 Mm7 參考點，而是直接經過 EDA 對 NTS 的調用來完成數據轉發規則的配置。

• EDA（Edge Dataplane Agent）：映射到 ETSI MEC Mp2 參考點，做爲 MEP 和 Data plane 之間的交互媒介。在 ME APP，網絡，ME Service 之間完成數據路由轉發。

  • OpenNESS 實現了 EDA 來對接 NTS。NTS 自己的 API 是沒有保留的，因此 EDA 能夠看做是 NTS 的 API。

• NTS Dataplane（Network Transport Service Data Plane）：數據面轉發模塊，將指定的流量規則應用到 Edge Platform 上，實現數據分發。

• DNS Server：做爲 Edge Platform DNS 服務器，應用於 ME APP。而對於不運行在 Edge Platform 的 APPs，則充當 DNS 轉發器（forwarder）。

• LTE/CUPS Agent：對接 EPC Control Plane，Edge Controller 用於爲 Edge Platform 配置 EPC Control Plane 和 EPC User Plane。

對於往返於 ME APP 與 EAA 之間、往返於 Edge Controller Software 與 EPC CP 之間的交互使用了 RESTful API。OpenNESS 就是經過微服務之間的交互，微服務與 ME APP 之間的交互、微服務於其餘第三方商業解決方案（e.g. VIM、MEO、NFVO）之間的交互來完成其功能的。

On-Premise Edge Deployment 的軟件架構：

Network Edge Deployment 的軟件架構：

Edge Application APIs

• Edge Service Activation/Deactivation（邊緣服務註冊與激活/停用）：該 API Endpoint 使 Producer APP 能夠在 Edge Platform 上註冊並激活或者停用。執行此 API 以後，Producer APP 才能夠被 Consumer APP 發現並使用。e.g. 當 Location Service Producer APP（定位服務提供者應用程序）部署完成後，立刻就會調用此接口。

• Edge Service Discovery（邊緣服務發現）：該 API Endpoint 使 Consumer APP 能夠發現 Edge Platform 上全部已激活的 Producer APP 清單。e.g. CDN Application 經過此接口發現 Edge Platform 上的 Location Service Producer APP。

• Edge Service Subscription/Unsubscription（邊緣服務訂閱/取消訂閱）：該 API Endpoint 使 Consumer APP 能夠訂閱/取消訂閱指定的 Producer APP，並以此獲取 Producer APP 的更新通知。e.g. CDN Application 能夠訂閱 Location Service Producer APP 以得到更新通知。

• Edge Service Notification update（邊緣服務更新通知）：該 API Endpoint 的本質是 Web Socket，Socket Connection 由打算訂閱 Producer APP 的 Consumer APP 建立。當 Producer APP 有更新時，就經過該 Connection 通知（推送）給 Consumer APP。e.g. 當 Location Service 有更新時，就會推送給訂閱了 Location Service Producer APP 的 CDN Application。

• Edge Service data update（邊緣服務數據更新發布）：該 API Endpoint 使 Producer APP 能夠將其更新的數據發佈到 Edge Platform。e.g. Location Service Producer APP 使用該 API 將用戶的位置更新數據發佈到 Edge Platform。

• Edge Service list subscription（邊緣服務訂購列表）：該 API Endpoint 使 Consumer APP 得到其可使用的 Producer APP 清單。e.g. CDN Application 能夠經過該 API 得知其是否訂閱了 Local Service Application。

Edge Application APIs 做爲 Producer APP 與 Consumer APP 之間的消息總線：

OpenNESS 做爲一個邊緣應用程序管理系統

OpenNESS（Open Network Edge Services Software）是一個開源的邊緣應用程序管理系統，使服務提供商和企業可以在任何網絡的邊緣（Network Edge）上構建、部署和操做本身的邊緣應用程序（Edge APPs），而且支持簡易的方式將雲中的應用程序遷移到邊緣。

邊緣應用下發（Onboarding）

Controller 經過 HTTP 方式來提供應用鏡像（APP Image）的下載，支持 Docker Image（tar.gz）和 QOCW2 Image 兩種格式，ME APP 支持 VM/Container/Pod 三種 APPs 運行方式，對應 OpenStack/K8S/DockerCompose。

1. 在 Controller ui Container 上運行 HTTP/HTTPS Image server。
2. 經過 WebUI 將 APP Images 上傳到 Image server。
3. 經過 WebUI 將 APP Images 下載到 Edge Platform 並進行部署。
4. 經過 WebUI 啓動 ME APP（VM/Container/Pod）。

邊緣應用控制以及流量策略下發

檢索 Edge Platform 上全部的 ME APP

ME APP 雲適配器（Cloud Adapter）

所謂 ME APP 雲適配器，即 APP 經過 Connector（各廠家有不一樣的實現方式）的方式與 AWS/Baidu Cloud 提供的服務鏈接起來。例如：Amazon Greengrass 經過 AWS lambda functions 部署到 Edge，而且能夠經過 GreenGrass service 做爲 IoT 網關回連到 AWS cloud。該功能常被應用於 IoT 場景中，用於數據的收集與回傳。

起初要實現這個效果，就須要配合 AWS Edge 解決方案來完成。而 OpenNESS 則提出了一個通用的框架來解決這個問題。OpenNESS 將 Greengrass Core 做爲一個 ME APP。能夠是一個 Ported Edge APP，保持原來的運行方式；也能夠將其修改後的 Native Edge APP 並利用 Edge Application APIs 的優點。

經過 OpenNESS 解決方案，能夠在同一個 Edge Node 上運行來自多個不一樣雲廠商（暫時支持 AWS cloud 和 Baidu cloud）的 APPs，輕鬆的爲用戶提供多雲體驗。

NOTE：對於 Public Cloud APP。用戶只須要將公有云中的 APP Upload 到 Controller，而後選擇 Edge Node 並執行部署便可。該場景中，APP 不能夠調用任何的 Edge Application APIs，即不能夠與 Edge Node 中的其餘 APP 進行交互，僅僅直接爲最終用戶提供服務而已。

OpenNESS 做爲一個邊緣網絡的服務平臺

OpenNESS 做爲一個邊緣網絡的服務平臺，支持在多雲環境中跨越多種類型的網絡平臺（Network Platform）以及多種類型的訪問技術（Access Technologies），例如：LTE 網絡、IP 網絡。讓用戶可以輕鬆的編排和管理運行在邊緣上的應用程序，併爲客戶端（UE）和邊緣應用程序提供端到端（End to End）的網絡鏈接服務。

NTS（Network Traffic Service）

NTS 的前身是 Intel NEV SDK。架構圖以下：

NTS 提供如下功能：

• Provide Reference API for REST/grpc to C API：提供可供 REST/grpc 調用的 C API。

• Implement Scatter and Gather in upstream and downstream：定義 Edge Platform 的 Upstream/Downstream 接口，並在 Upstream/Downstream 上實現 Scatter（分發）和 Gather（匯聚）。

• Reference Packet forwarding decision independent of IO：獨立於 I/O 的分組轉發策略。

• Provide Reference ACL based Application specific packet tuple filtering：提供基於數據包五元組（5 Tuple）的 ACL 過濾方式。

• Implement KNI based interface to Edge applications running as Containers/POD：爲運行在 Containers/Pod 的 ME APP 提供基於 KNI（Kernel Network Interface）的 interface。

• Implement DPDK vHost user based interface to Edge applications running as Virtual Machine：爲運行在 VM 中的 ME APP 提供基於 DPDK vHost user 的 interface。

• Reference implementation which does not depend on EPC implementation：不依賴 EPC 的實現。

• Provide reference Simultaneous IP and S1 deployment：提供 Simultaneous IP（SGi） 和 S1_U deployment 方式。

• Provide reference GTPU base packet learning for S1 deployment：爲 S1_U deployment 提供基於分組學習（Packet Learning）的 GTP-U 協議封裝/解封裝。

• Future enhancement of UE based traffic steering for authentication (not there now)：未來會增長爲了身份認證（Authentication）而提供的基於 UE 的流量控制（Traffic Steering）。

NOTE：

• Upstream：從客戶端到接入點。
• Downstream：從接入點到客戶端。

Upstream Traffic

Edge Platform 能夠部署在 LTE 或 IP（Wireless/Wireline，無線/有線）網絡上。Edge Platform 在 NTS Dataplane 上提供了一個網絡抽象層，將多種協議的差別進行了抽象與封裝，因此，不管在什麼網絡環境中部署，ME APP 都只會看看法封裝以後的 IPv4 流量。Edge Node 上的 EDA 與 NTS 提供了配置網絡和數據平面的方法，以提供流量控制和進行任何所須要的協議傳輸單元封裝。

• S1_U：Edge Platform 從 LTE eNodeB 掛接到 S1 接口上。該模式下，流量會首先被 NTS Data Plane 截獲，再由 NTS 將流量重定向到 ME APP 或上游 EPC。 在該過程當中，NTS 須要對 Upstream 流量根據須要進行 GTP-U 封裝與解封裝。

• SGi：Edge Platform 直接掛接到 SGi 接口上，EPC 出來的 Upstream IP 流量到達 NTS Data Plane，NTS 根據 Traffic Rule 進行轉發到 ME APP 或 PDN。

Downstream Traffic

• Native：OpenNESS 原生（Native）支持將流量引導到 Edge Node 上運行的 ME APP 或 IoT GW。ME APP 運行在 Container/VM 上，經過實現 ETSI MEC & NFV 參考架構，ME APP、IoT GW、VNFs 其實是能夠共存、共享 VIM 平臺資源的。

• Local Breakout：OpenNESS 支持將流量引導到在用戶現存的 IT 基礎設施上運行的 LBP APP，即 Applications On Local Breakout Port（LBP）。以下圖，用戶可使用 Controller 配置流量轉發規則（Traffic Rules），將 Downstream 導向企業 TOR Switch 最終流入 LBP。這種部署方式能夠在不修改企業 IT 基礎設施的前提下接入 Edge Node，並對原有的 APP 進行創新。

• Packet Data Network（PDN，分組數據網）：統稱提供數據服務的網絡，例如：因特網。OpenNESS 支持將流量引導至 PND，假如不對這些數據不感興趣的話。

Traffic Rule Setup

TrafficPolicy 的數據結構以下：

• TrafficPolicy：爲指定的 Interface（e.g. ME APP Interface、ME Host Interface）定義一組 TrafficRule。

• TrafficRule：單個流量規則，內含 TrafficSelector 。

• TrafficSelector：定義了須要處理的數據流量類型。

  • MACFilter：指定 Frame 的相關過濾參數。
  • IPFilter：指定 Packet 的相關過濾參數。
  • GTPFilter：指定 GTP 協議封裝包的相關過濾參數。

• Add Traffic Rule
  

• Delete Traffic Rule
  

LTE CUPS 流量策略配置

Controller LTE/CUPS Agent（Core Network Configuration APIs edge compute）經過 HTTP RESTful 的方式與 EPC CP 進行通訊，以此來配置 EPC CUPS 的流量策略，將 EPC UP 的流量導向 Edge Platform。

NOTE：因爲 ETSI MEC 並無給出 MEPM和 4GEPCControlPlane之間的接口標準，但最起碼 HTTP REST 這一調用方式是知足標準的。EPC 能夠很方便的將本身的 API 集成到 OpenNESS Controller 中，這裏面須要一些定製開發的工做。這樣就作到了 MEPM 和 OAM Agent 的徹底解耦。

NOTE：

• OAM：操做（Operation）、管理（Administration）、維護（Maintenance）

同時，當 EPC UP 和 Edge Platform 處於同一物理位置（用戶面下沉）的狀況下，MEAO 會調用 NFVI 資源來爲 EPC UP NF 提供VI。在 NFV & MEC 混合的場景中，OpenNESS 建議經過 Controller 來配置和管理這些 NF，MEO 直接調用 Controller API 就能夠管理運行在各個 Edge Platform 上的 NF 了。即徹底由 OpenNESS Controller 充當 MEPM 角色。

OpenNESS 經過 Controller API 來配置和管理運行在各個 Edge Platform 上的 NF。即徹底由 OpenNESS Controller 充當 MEPM 角色，這樣就作到了 MEPM 和 OAM Agent 的徹底解耦。

• LTE CPUS Traffic setup
  
  

OpenNESS & OpenVINO

OpenVINO

OpenVINO 是英特爾基於自身現有的硬件平臺開發出的一款能夠加速高性能計算機視覺和深度學習視覺應用開發速度的工具包，支持在各類英特爾平臺的硬件加速器上進行深度學習，也支持異構計算。 支持 Windows/Linux 操做系統，支持 Python/C++ 編程語言。簡而言之，OpenVINO 工具包能夠快速部署模擬人類視覺的應用程序和解決方案。

OpenVINO 的特色：

• 在英特爾硬件平臺上提高計算機視覺相關深度學習性能達 19 倍以上。
• 解除 CNN-based 的網絡在邊緣設備的性能瓶頸。
• 對 OpenCV，OpenXV 視覺庫的傳統 API 實現加速與優化。
• 基於通用 API 接口在 CPU、GPU、FPGA 等設備上運行加上。

OpenVINO 工具套件可以：

• 在邊緣啓用基於 CNN 的深度學習推理。
• 支持跨英特爾 CPU，英特爾集成顯卡，英特爾 FPGA，英特爾 Movidius 神經計算棒，英特爾神經計算棒 2 和採用英特爾 Movidius VPU 的英特爾視覺加速器設計的異構計算。
• 經過易於使用的計算機視覺功能庫和預優化的內核，加快產品上市速度。
• 包括針對計算機視覺標準的優化調用，包括 OpenCV，OpenCL 和 OpenVX。

OpenVINO 工具套件包括：

• 深度學習部署工具包（DLDT）
  • 深度學習模型優化器：一種跨平臺的命令行工具，用於導入模型並使用推理引擎爲最佳計算作好準備。模型優化器導入，轉換和優化模型，這些模型在流行的框架中進行訓練，例如：Caffe、TensorFlow 、MXNet、Kaldi 和 ONNX 等。
  • 深度學習推理引擎：一種統一的 API，容許對許多硬件類型進行高性能計算，例如：英特爾 CPU，英特爾集成顯卡，英特爾 Movidius 神經計算棒等。
  • 演示和示例：一組簡單的控制檯應用程序，演示如何在應用程序中使用推理引擎。
  • 工具：一組簡單的控制檯工具，用於校準和測量模型的精度。
  • 預先訓練的模型：一套用於學習和演示目的的預訓練模型或開發深度學習軟件。
• OpenCV：一個爲英特爾硬件編譯的 OpenCV 社區版本，包括用於計算機視覺的 PVL 庫。
• OpenCL 2.1 版本的驅動程序和運行時。
• Intel®MediaSDK
• OpenVX：英特爾針對在英特爾硬件（CPU，GPU，IPU）上運行而優化的 OpenVX 部署。

OpenVINO 的架構

OpenVINO 工具包主要包括兩個核心組件，模型優化器（Model Optimizer）和推理引擎（Inference Engine）。

模型優化器（Model Optimizer）

模型優化器將給定的模型轉化爲標準的 Intermediate Representation（IR） ，並對模型進行優化。支持一下深度學習框架：

• ONNX
• TensorFlow
• Caffe
• MXNet
• Kaldi

推理引擎（Inference Engine）

推理引擎支持硬件指令集層面的深度學習模型加速運行，同時對傳統的 OpenCV 圖像處理庫也進行了指令集優化，有顯著的性能與速度提高。支持如下硬件設備：

• CPU
• GPU
• FPGA
• VPU

OpenNESS & OpenVINO 運行原理

• OpenVINOProducer APP：服務於 Consumer APP，藉助於 OpenNESS EAA 更改通知的方式，將 OpenVINO模型優化器輸出的標準的 IR 推送到 Consumer APP 中。
• OpenVINOConsumer APP：服務於最終用戶，經過 OpenVINO 推理引擎應用 IR結合各類硬件加速設備對輸入的視頻流進行圖像識別分析。
• 視頻流從嵌入式 Linux 客戶端設備（UE）上安裝的網絡攝像頭捕獲（綠線）。
• 視頻流在 OpenNESS Edge Platform上推理分析完成以後再次傳輸回到 UE 繼續進一步的數據分析與應用（紅線）。

部署架構

相關術語

EPC（4G 核心網絡）

4G 做爲第四代移動通訊技術，有着沒法比擬的優越性，它可以快速傳輸語音、文本、視頻和圖像信息，可以知足幾乎全部用戶對於無線服務的要求，國際電信聯盟對於 4G 系統的標準爲符合 100 Mbit/s 數據傳輸速度的系統，當之無愧的被稱爲機器之間的高速對話。

LTE（Long Term Evolution）主要研究 3GPP 無線接入網的長期演進技術，升級版的 LTE Advanced 將最終知足國際電信聯盟對 4G 系統的要求。SAE（System Architecture Evolution）則是研究核心網的長期演進，它定義了一個全 IP 的分組核心網 EPC（Evolved Packet Core，分組核心演進），該系統的特色爲僅有分組域而無電路域、基於全 IP 結構、控制與承載分離且網絡結構扁平化，其中主要包含 MME、SGW、、PCRF 等網元。其中 SGW 和 PGW 經常合設並被稱爲 SAE-GW。

• MME（Mobility Management Entity，移動管理實體），管理會話（Session）狀態和認證並追蹤網絡上的用戶。
• SGW（Serving Gateway，服務網關），經過訪問網絡路由數據。
• PGW（Packet Data Node Gateway，分組數據節點網關），做爲 LTE 網絡和其它分組數據網絡間的端口，管理服務質量（QoS）並提供深度數據包檢測（DPI）。
• PCRF（Policy and Charging Rules Function，策略及收費規則功能），支持服務數據流檢測、策略執行和計流量收費方式。

uCPE（通用客戶端設備）

uCPE（Universal Customer Premise Equipment，通用客戶端設備）：uCPE 一詞來源於 CPE，後者指位於用戶端的網絡終端設備（Customer premises equipment，CPE），用於與電信運營商對接服務，是用戶端服務提供商解決方案的重要組成部分，這些解決方案提供商經過使用專用集成鏈路（ASIC）來提供各類服務。

可是，傳統 CPE 缺少靈活性而且成本高昂，安裝和維護要求服務提供商部署網絡技術人員，耗時很長且很是昂貴。此外，網絡基礎設施的設備長期以來都是由不一樣廠商的專用設備構成，例如，一家廠商提供路由器，另外一家廠商提供防火牆、WAN 加速器和無線局域網控制器等。所以，業界提出了在通用硬件上來實現不一樣功能，將兩個或更多的網絡功能放在標準硬件上來減小購買的設備。以期消除須要不一樣技能來安裝、配置、測試和維護的專有設備，還能下降整體功率和 HVAC 要求。由此，業界產生了如今大行其道的 uCPE。

uCPE 由在開放服務器上託管的標準操做系統上運行的 VNF 組成，理想的 uCPE 部署須要支持多廠商多組件構建。所以，uCPE 將雲引入電信網，併成爲推進創新的動力。一般狀況下，服務提供商但願經過單個通用平臺上運行的 VNF 替換專用設備，從而簡化用戶現場部署，uCPE 提供了經過使用 NFV 將以雲計算爲核心的技術一直延伸到電信網絡接入部分來實現這一願景的途徑。

長期以來，NFV 部署的主要推進力之一是 vCPE，後者能簡化操做，減小資本支出和運營成本，加速服務交付。但因爲這些設備成本低廉，所以它們一般不夠快速或者功能不夠強大，而且會限制一些更復雜的服務。uCPE 一樣也是一種運行 VNF 的軟件解決方案，做爲一個可遠程管理的平臺，託管服務提供商能夠經過 WAN 輕鬆部署、修改或刪除客戶端 VNF。uCPE 設備一樣基於商用硬件，可是它比 vCPE 提供的功能更增強大。所以，uCPE 能夠視爲 vCPE 的進一步演進的結果。

目前，業界都已承認，uCPE 的真正價值在於按需服務，它具有的優點包括、簡化硬件安裝，能夠在各個站點之間交替混合和匹配、消除對專有網絡設備和相關技能的需求、開放式架構使企業可以更快更高效地推出新應用程序、快速有效地部署按需虛擬網絡功能、可遠程管理的平臺簡化操做並下降運營成本、單個平臺承載多個 VNF、與 OpenStack 等多個主要的第三方編排器兼容。

在部署企業級 uCPE 時，隨着帶寬消耗的增長，與 SD-WAN 的集成變得相當重要。 SD-WAN 提供了一種在 Internet 上分層的網絡結構，所以企業能夠自由選擇廉價的帶寬而不是昂貴的 MPLS 服務。可是，在某些服務級別協議的狀況下，公司須要有保證的服務，可能仍然須要 MPLS。在這些狀況下，uCPE 仍然能夠經過簡單地部署適用的 VNF 來處理每項服務來處理 SD-WAN 覆蓋網絡和 MPLS。企業領域的這種靈活性使得 uCPE 設備確實很是有利。

隨着 NFV 進程推動，NFV 項目已覆蓋全部核心網網元，5G 成爲 NFV 新的最大驅動力，也必將對於網絡設備的靈活性提出更高要求。能夠預見，在這一背景下，uCPE 市場還將迎來進一步的繁榮。

簡單來講 uCPU 就是放在企業內部的 「類路由器」 網關設備，經過 VNF 的方式來代替傳統的網絡設備，例如：防火牆設備。由於 uCPU 一般是 x86 架構的服務器，因此也能夠在之上運行 Edge Platform Software。

vRAN（ 虛擬無線接入網）

vRAN（虛擬無線接入網）是移動網絡發展的新趨勢，致力於智能化提高容量，大幅下降成本並提高用戶體驗。它還將提供支持將來服務和應用所需的靈活性和動態可擴展性。基於網絡功能虛擬化（NFV）的原則，vRAN 架構經過在商用服務器硬件上運行虛擬化基帶功能，超越了集中式 RAN（C-RAN）的最新迭代版本。

因爲 CSP（通訊服務提供商）面臨着知足容量需求的壓力，並需在競爭異常激烈的移動服務市場推出差別化產品，所以此時將 NFV 的優點從核心網絡擴展到 RAN 的時機恰到好處。

http://www.windriver.com.cn/downloads/files/WP-vRAN-The-Next-Step-in-Network-Transformation-White-Paper-CN.pdf

簡單來講，vRAN 就是運行在 RAN 設備上的 VNF。UE 發送的信號會被 RAN 設備接收，而後再封裝爲標準數據包後發送到 UPF，最終進入核心網。由於如今 RAN 設備也能夠是 x86 架構因此也能夠在之上運行 Edge Platform Software。

NGCO（新一代中央辦公室）

NGCO（Next Gen Central Offices，新一代中央辦公室），又稱新一代電信機房，是以軟件爲中心的網絡基礎架構。一般每一個小區都會由一個 CO，每一個區鎮會有一個更大的 CO。CO 是一個 x86 服務器機房因此也能夠運行 Edge Platform Software。

GTP 協議

GTP（GPRS Tunnelling Protocol，GPRS 隧道協議）是一組基於 IP 的通訊協議，用於在 GSM 、UMTS 和 LTE 網絡中承載 GPRS（General Packet Radio Service，通用分組無線業務）。

GTP 協議目前有 3 個版本：

• Version 0：是早期版本，被 1999 年標準化的 Version 1 替代；
• Version 1：使用於 GSM 和 UMTS 網絡，也應用於 LTE 網絡中以傳輸用戶面數據；
• Version 2：使用於 LTE 核心網（EPC）。

GTP 協議的用途：GTP 是 GPRS 核心網中使用的主要協議。它使得 GSM 或 UMTS 網絡的終端可以在網絡中移動位置，同時能持續的經過同一個 GGSN 鏈接到因特網。爲了實現這一功能，GTP 協議老是將用戶面數據從用戶位置所屬的 SGSN 傳輸到它開戶信息所對應的 GGSN。

GPRS 核心網使用三種 GTP 協議：

• GTP-U：用於爲每一個 PDP 上下文提供一個或多個隧道，用以傳輸用戶數據。
• GTP-C：用於控制目的。包括：PDP 上下文的創建和刪除；GSN 可及性驗證；位置更新。例如，當簽約用戶從一個 SGSN 移動到另外一個 SGSN。
• GTP’：用於從各個 GSN 傳送計費數據到計費網關功能（CGF，Charging Gateway Function）。

GGSN 和 SGSN（合稱爲 GSN），在 UDP 端口 2123 上監聽 GTP-C 消息，在端口 2152 上監聽 GTP-U 消息。GTP 協議通訊能夠經過 GPRS 漫遊交換（GPRS Roaming Exchange）發生在不一樣運營商之間。

計費網關功能（CGF，Charging Gateway Function）在 TCP/UDP 端口 3386 上監聽發送自 GSN 的 GTP’ 消息。核心網發送計費信息到 CGF，計費信息至少包含 PDP 上下文激活次數以及終端用戶傳送的數據量。與 GTP-C 和 GTP-U 不一樣，GTP’ 協議承載的報文一般只在單個運營商網絡內部使用，所以並不那麼標準化。運營商能夠作特殊的配置，使用特別的編碼，甚至使用徹底不一樣的系統來完成計費。

GPRS 核心網和 UMTS 接入網之間的 Iu-PS 接口上，用戶面也使用 GTP-U 協議。然而在控制面上並不使用 GTP-C，而是用 RANAP 協議。GTP-U的 隧道在 Iu-PS 接口上也是以 RANAP 協議管理的。

LTE 網絡中的 GTP 協議功能與 GSM/UMTS 網絡中基本相同。在控制面上 LTE 網絡使用 GTPv2-C，用戶面上使用 GTP-U，計費相關功能使用 GTP’。在 S1 接口（eNodeB 和 SGW 之間）上，用戶面使用 GPT-U 協議。在接入網 X2 接口（兩個 eNodeB 之間）上，用戶面也使用 GTP-U 協議，控制面使用 X2AP。

S1 接口

S1 接口是 LTE eNodeB（基站）與 EPC（分組核心網）之間的通信接口。將 LTE 系統劃分爲無線接入網和核心網。

S1 接口沿襲了承載和控制分離的思想，又分紅兩個接口，一個用於控制平面（S1-MME），一個用於用戶平面（S1-U）。

• 控制平面接口 S1-MME 將 eNodeB 和移動性管理實體（MME）相連，主要完成 S1 接口的無線接入承載控制、接口專用的操做維護等功能。
• 用戶平面接口 S1-U 將 eNodeB 和服務網關（S-GW）鏈接，用於傳送用戶數據和相應的用戶平面控制幀。
  

PDN

PDN（Packet Data Network，分組數據網）是對提供數據服務的網絡的通常描述。分組交換（Packet switching）是一種數據傳輸的模式，這種模式下，一條消息被分紅若干部分，這些部分經過對每一個分組最合適的路由獨立發送，並在目的地從新組合起來。因特網就是一個典型的 PDN。

PGW 與 SGi 接口

P-GW（PDN Gateway，PDN 網關），是面向 PDN 終結於 SGi 接口的網關，若是 UE 訪問多個 PDN，UE 將對應一個或多個 P-GW。P-GW的 主要功能包括基於用戶的包過濾功能、合法偵聽功能、UE 的 IP 地址分配功能、在上/下行鏈路中進行數據包傳輸層標記、進行上/下行業務等級計費以及業務級門控、進行基於業務的上/下行速率的控制等。另外，P-GW 還提供上/下行鏈路承載綁定和上行鏈路綁定校驗功能。

在移動網絡中，P-GW 的主要功能是向 UE 分配 IP 地址。UE 能夠經過多個 P-GWs 鏈接到多個 PDN，也能夠鏈接到舊的、不符合 3GPP 的 IP 網絡。在 LTE 架構中，P-GW 充當着 user plane mobility 的錨點。用戶流量能夠在 P-GW 處被過濾，以區分 packet flows 之間的 QoS（服務質量）。P-GW 會收集到充值信息並轉發到 CDRs（Charging Data Records）進行處理。

• EPS Bearer：這是與 P-GW 相關聯的 UE 的接口。它是一個隧道，用於 IP 地址分配。

• Rx：雖然不與 P-GW 直連，但該接口用於策略和收費規則功能（PCRF，policy and charging rules function），並做爲 PCRF 與 IP 多媒體子系統（IMS，IP Multimedia Subsystem）網絡之間的交互媒介。IMS 向用戶設備提供諸如 IP 語音（VOIP，Voice Over IP）之類的服務。該接口使用 Diameter 協議，經過 Steam 控制傳輸協議（SCTP）和 TCP 實現，並將 PCRF 權限傳遞給服務網絡。

• SGi：這是 P-GW 與 PDN 之間的接口，一般在這裏提供服務。例如用於語音的 IMS、Web、Internet 訪問等等。全部流量都是以 IP 數據包和流的形式存在。

• S5：這是與 P-GW 相關聯的 S-GW 之間的接口。支持用戶平面（User Plane）的 GPRS 隧道協議（GTP）。

LTE CUPS

LTE CPUS（Control and User Plane Separation of EPC nodes），表明 EPC 的控制和用戶平面分離。3GPP 爲此提出了用於分離演進 SGW、PGW 和 TDF 的功能架構加強。CUPS 使得網絡的部署和操做更加靈活，在分佈式或集中式的部署場景中，控制平面和用戶平面都可以獨立進行伸縮，而不影響現有 EPC 節點的功能。

https://www.3gpp.org/cups

OAM

OAM（Operation Administration and Maintenance，操做、維護、管理）是指根據運營商網絡運營的實際須要，一般將網絡的管理工做劃分爲 3 大類：操做（Operation）、管理（Administration）、維護（Maintenance），簡稱 OAM。操做主要完成平常網絡和業務進行的分析、預測、規劃和配置工做；維護主要是對網絡及其業務的測試和故障管理等進行的平常操做活動。

LTE 網格架構

http://dasheyuan.com/post/lte-network-architecture/