黃 倩,黃 蓉,王友祥,陳 杲(中國聯通研究院,北京 100044)
2020年,5G商用引爆通信業發展。以往通信設備都是軟硬件一體,一旦標準技術換代,就得研制新設備,導致投資大、靈活性差。5G 引入SDN∕NFV 技術后,采用標準服務器、存儲器和交換機來承載軟件化網絡功能,替代原有軟硬件一體專有設備,解決了通信設備迭代更新難度大的問題。隨著5G 不斷向軟件定義網絡方向發展,網絡架構變得更加靈活,為了適應這種變化,傳統CT、IT、公有云廠商也適時推出了開源邊緣計算平臺項目。
萬物互聯時代到來,邊緣計算規模和業務復雜度發生了根本變化:邊緣實時計算、分析和邊緣智能等新型業務不斷涌現,對邊緣計算效率、可靠性和資源利用率提出了更高要求;因此,諸多廠家提出建設邊緣計算平臺,平臺涉及邊緣側網絡、計算以及存儲資源管理,提供基礎功能,如設備接入、安全校驗、監控等,其接口、架構、管理逐步成體系。但各廠家的邊緣計算平臺差異較大,行業邊緣應用部署時需要適配不同邊緣計算平臺,導致跨平臺應用部署難度大,故考慮引入開源技術打造5G MEC 邊緣計算架構和能力開放的事實標準,打破當前邊緣計算平臺市場煙囪式、碎片化現狀,降低產業應用客戶上車門檻,實現規模復制,通過開源協作方式構建統一5G MEC 平臺。下文從邊緣計算平臺參考架構入手,引出2 種開源邊緣計算平臺進行分析。
2020 年,在OSF 邊緣計算小組(Open Stack 基金會主導)發布的《邊緣計算:架構,設計和測試的下一步》白皮書中,開源基礎設施運營商和供應商聯合定義了以下2類典型邊緣參考體系結構模型。
a)集中式控制平面模式:傳統單數據中心環境下中心控制器和邊緣計算節點由廣域網連接。該模式從集中運營角度看有優勢,安全性高,但節點嚴重依賴集中式數據中心來承載管理和協調邊緣計算、存儲和網絡服務,邊緣節點自主性差,是一種傳統架構模式。
b)分布式控制平面模式:多數控制服務駐留在大∕中型邊緣數據中心上,也要求邊緣站點自身功能全面。這種體系結構比較靈活,尤其在網絡連接丟失情況下更凸顯其優勢,但由于需要跨地域運行大量控制功能,管理編排類型服務更復雜。KubeEdge 屬于此類去中心化架構模式。
KubeEdge和OpenNESS是市面上較為常見的開源平臺,均采用了通用VNF Manger 和NFV Orchestrator組件,參考了標準ETSI MANO 體系結構,但其特點不盡相同,詳細分析如下。
2019 年,KubeEdge 由華為捐給CNCF 基金會,基于Kubernetes(簡稱k8s)構建,100%兼容k8s API,是Kubernetes IoT Edge WG 關鍵參考架構之一,可提供云邊協同能力開放。
3.1.1 整體架構
該平臺分為云端、邊緣端和終端3層,是解耦式的架構,具體如圖1所示。

圖1 KubeEdge整體架構
a)云端:負責應用和配置策略下發,通過旁路設計開發CloudCore 組件,進行邊緣節點同步和維護,利用list watch與Kubernetes集群做信息同步。
b)邊緣端:負責運行邊緣應用和管理接入設備。Edgecore 支持CRI,底層可以對接多種container runtime、device Twin 和DEvent Bus,主要做設備元數據管理以及MQTT 協議訂閱和發布,從而完成與終端設備通信。
c)終端:運行各種邊緣設備。設備終端有多類訪問協議,部分新設備可能直接支持MQTT 協議。但部分專用設備存在專用協議,KubeEdge 采用Mapper 設計,可將專有設備協議轉換成MQTT協議,實現邊緣應用和云上設備數據同步和管理。
3.1.2 主要特點
KubeEdge針對邊緣側實際環境做了諸多優化。
a)云邊可靠協同:采用雙向多路復用消息通道,支持邊緣節點位于私有網絡中,云邊消息傳輸默認使用Websocket 消息封裝,減少通信壓力,高時延下仍可正常工作。
b)邊緣離線自治:通過消息總線和元數據本地存儲實現節點離線自治,節點故障恢復也無需listwatch,從而降低網絡壓力,提升故障恢復速度。
c)邊緣極致輕量化:邊緣側節點Edgecore 內存約70M,支持CRI 集成containerd 和CRI-O,優化了runtime 資源消耗,方便在資源受限邊緣上運行;保留了Kubernetes 的管理面,重新開發了節點agent,大幅降低邊緣組件資源占用率。
d)k8s 原生支持:云端可以通過k8s API 管理邊緣設備和邊緣應用程序。
但是作為一個開源項目,KubeEdge 仍有很多方面待繼續完善。
a)不支持設備協議如OPC-UA。
b)不支持使用數千個Edge 節點和數百萬個設備評估并啟用更大范圍的Edge群集。
c)不支持對大型Edge 集群的應用程序進行智能調度。
由Intel 主導,OpenNESS 是一套開源軟件開發套件,為在用戶邊緣側或網絡邊緣側等位置運行的應用提供單一應用托管環境,旨在多種網絡接入方式(Wi-Fi∕4G∕5G等)下助力邊緣業務管理與編排,通過抽象化去除網絡復雜性,讓開發人員可以像編寫云軟件一樣輕松編寫適用于邊緣的軟件,該項目在Akraino Edge Stack(Linux基金會項目)中被廣泛應用。
3.2.1 整體架構
OpenNESS 由邊緣節點和邊緣控制器2 個部分構成。
a)邊緣節點:支持多種網絡接入方式,能夠從IP、S1_U 或者SG1 接口提取數據;支持針對5G 延遲、多租戶和服務注冊流量定向,并支持部署邊緣應用。
b)邊緣控制器:一般處于數據中心、云中或邊緣等位置,進行邊緣平臺編排,采用GUI 方式,支持其他通信服務提供商采用API 方式鏈接到自己的控制器GUI 環境。圖2 為OpenNESS 抽象描述,展示邊緣節點上軟件和云控制器與其他技術相互配合的使用方式。

圖2 OpenNESS整體架構
3.2.2 主要特點
OpenNESS 當前側重4G∕5G 功能集成、底層Cloud native能力以及不同硬件資源適配能力。
a)支持獨立5G NR 和增強平臺感知部署。有5G接入模塊,AF可與NEF通過N33接口或者與PCF通過N5 接口通信,幫助MEP 下發分流規則以及事件訂閱等,支持HTTP∕2、HTTPS∕oAuth2 協議;OpenNESS 的DataPlane模塊是所有邊緣開源項目中比較獨特的。
b)高效擴展簡化編排:可以與Kubernetes(將來還包括Openstack)配合使用,可用于預配邊緣資源并為網絡邊緣配置增強型平臺感知功能,雖然本身不包含服務編排,但具備可連接到服務編排器的控制API。
c)提供應用使能服務能力:提供API,可供應用實現服務注冊、發現、訂閱和已訂閱服務查詢。
d)靈活擴展性強,多云兼容:基于微服務和開源API,OpenNESS可以為AWS Green grass、Microsoft Azure IoT Hub 和百度IntelliEdge 提供云連接器,因此更易于實施升級和更新管理。
整體來看,各平臺涉及的技術棧基本一致,但在部署形態、架構、編排策略、可靠性和應用場景等方面仍有差異(見表1),因此未來多平臺共存將是常態,如何加強各平臺間的協作將是未來的研究重點。

表1 開源邊緣計算平臺性能分析對比
3GPP 主要關注的是網絡架構對MEC 特性的支持,其中5G 網元UPF 作為邊緣計算的數據錨點、涉及用戶面重選、靈活業務疏導和計費等服務質量保障方面內容;MEC 與5G 的融合架構主要關注3 個接口:MEC 平臺與NEF 的接口N33,與PCF 的接口N5,與UPF的接口N6。目前由Intel開發的OpenNESS平臺也已經搭建了5G+MEC測試床。
ETSI 對MEC 的定義為在移動網絡的邊緣提供IT服務環境和計算能力。MEC 架構設計遵守基礎資源開放、平臺能力開放(通過MP1 接口,為APP 提供ME services )、網絡能力開放(RNS API、Location API、bandwidth API、UE identity API)、管理能力開放、本地流量卸載以及移動性管理等原則。
OpenNESS 符合ETSI MEC 框架,其中邊緣控制器對應MEPM,邊緣服務對應MEP,邊緣應用對應ME APP。OpenNESS主要參考ETSI MEC規范,OpenNESS與ETSI 的映射關系如圖3 所示,其中藍色及橘色部分由OpenNESS實現。

圖3 OpenNESS與ETSI的映射關系
隨著企業大步向云原生時代邁進,電信運營商也逐步將云原生技術擴展到邊緣側,并密切關注全過程中的安全性、服務遙測、計算性能、彈性和擴展性,以便未來以開放互操作的方式調整組織、業務和運營流程,加快部署節奏,降低總成本和運維風險,筆者建議如下。
a)提供統一邊緣計算參考實現標準,聚焦整體框架、接口定義及實現方式,并進一步統一面向應用的接口,降低應用開發伙伴上車門檻,逐步打破各家煙囪式MEC方案,打破市場隔離。
b)積極與公有云廠商合作,作為當前公有云服務提供商的補充,可避免重復部署資本密集型基礎設施,實現快速上市和測試新行業用例,共享行業應用程序生態系統資源。
c)打造新協作生產關系,改善運營商與廠家之間的關系,由傳統的供應關系改為合作,聯合設備廠家、應用廠家以及科研機構從不同角度加強協作共建,構建開放的生產關系,打破傳統的封閉式合作模式,激活商業創新。
d)重點關注邊緣計算平臺的異構硬件支持、移動性支持、IT∕CT鴻溝的關鍵技術點以及平臺是否支持邊緣節點輕量化部署和邊緣離線自治。
總體看來,當前邊緣計算相關創新和開源化進程仍處于早期階段。雖然開源將打破舊有設備供應鏈格局,但在開放架構下,如何加強各開源平臺間協同創新,保障各方利益,平衡開源和專利保護,這些有待進一步研究與探討。