段向陽/DUAN Xiangyang

王衛(wèi)斌/WANG Weibin

（中興通訊股份有限公司，廣東 深圳 518057）

從2016年歐洲電信標(biāo)準(zhǔn)化協(xié)會移動邊緣計(jì)算行業(yè)規(guī)范小組（ETSI MEC ISG）發(fā)布邊緣計(jì)算7大業(yè)務(wù)場景定義開始，移動邊緣計(jì)算（MEC）概念逐漸受到通信運(yùn)營商、互聯(lián)網(wǎng)業(yè)務(wù)提供商和行業(yè)用戶的高度關(guān)注[1-3]。

MEC的成功需要5G切片網(wǎng)絡(luò)大帶寬、廣連接、高可靠低延遲等新型管道能力提供增值價(jià)值，也需要5G網(wǎng)元接口的開放性、基于服務(wù)架構(gòu)（SBA）導(dǎo)向的5G核心網(wǎng)（5GC）落地實(shí)現(xiàn)平臺貫通，更需要發(fā)揮邊緣計(jì)算商用價(jià)值的生態(tài)系統(tǒng)的建立；然而，各種技術(shù)因素和商業(yè)因素交織在一起，將給邊緣計(jì)算帶來較大的落地風(fēng)險(xiǎn)。

本文中，我們對邊緣計(jì)算的現(xiàn)狀和規(guī)模落地的相關(guān)制約因素進(jìn)行分析，以嘗試建立一些技術(shù)共識，為5G批量部署后的邊緣計(jì)算業(yè)務(wù)場景集中部署做好技術(shù)儲備。

1 MEC需要平衡“計(jì)算”和“連接”

MEC最早定義是移動邊緣計(jì)算；后來被修改為多址邊緣計(jì)算[4]，這體現(xiàn)了固移融合和多接入的趨勢。由此可見，MEC從一開始不僅關(guān)注在合適的物理位置提供算力，還注重在合適的物理位置為不同類型的設(shè)備提供對應(yīng)的連接方式。

傳統(tǒng)通信運(yùn)營商和設(shè)備商更關(guān)注和擅長提供“連接”，而互聯(lián)網(wǎng)服務(wù)提供商（ISP）和信息技術(shù)（IT）制造商則更關(guān)注和擅長提供“計(jì)算”。雙方在業(yè)務(wù)認(rèn)知和價(jià)值定位上有一定分歧。比如部分ISP仍然視5G網(wǎng)絡(luò)為透明管道，更認(rèn)同扁平化的MEC網(wǎng)絡(luò)，即Far-Edge邊緣盒子自備計(jì)算和存儲能力，通過通信網(wǎng)絡(luò)直達(dá)ISP分布式云化數(shù)據(jù)中心，開啟“云+端”一體化模式。而一些運(yùn)營商對OTT業(yè)務(wù)（OTT業(yè)務(wù)是指互聯(lián)網(wǎng)公司越過運(yùn)營商發(fā)展基于開放互聯(lián)網(wǎng)的各種視頻及數(shù)據(jù)服務(wù)業(yè)務(wù)）心存顧慮，在構(gòu)建MEC網(wǎng)絡(luò)時(shí)，過于強(qiáng)調(diào)自建平臺即服務(wù)（PaaS）基礎(chǔ)設(shè)施和移動邊緣平臺（MEP）能力平臺，希望OTT業(yè)務(wù)能直接運(yùn)行在電信運(yùn)營商提供的MEC平臺上。

客觀上看，5G網(wǎng)絡(luò)和4G網(wǎng)絡(luò)有了很大不同。5G的控制面和用戶面分離（CUPS）是在邊緣部署用戶面功能（UPF）的保證。而UPF的下沉使5G網(wǎng)絡(luò)可依據(jù)簽約信息和鑒權(quán)接入，基于移動性管理，在保證會話連續(xù)性和業(yè)務(wù)連續(xù)性前提下，根據(jù)服務(wù)質(zhì)量（QoS）為用戶選擇最優(yōu)的用戶面功能并記錄計(jì)費(fèi)和賬單。在可管、可控的前提下，提升體驗(yàn)質(zhì)量（QoE）和支持高可靠低時(shí)延通信（uRLLC）等關(guān)鍵業(yè)務(wù)。

對于內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）時(shí)延敏感的直播類業(yè)務(wù)、云游戲，特別是隨著增強(qiáng)現(xiàn)實(shí)（AR）/虛擬現(xiàn)實(shí)（VR）顯示材料技術(shù)發(fā)展將要產(chǎn)生的一些交互式視頻業(yè)務(wù)，如果仍然將通信網(wǎng)絡(luò)視為透明管道，將不能通過應(yīng)用程序接口（API）管理UPF的分流規(guī)則把此類業(yè)務(wù)路由到最優(yōu)邊緣數(shù)據(jù)中心處理，這會導(dǎo)致很多業(yè)務(wù)機(jī)會的損失。

如圖1所示，UPF錨點(diǎn)與MEC結(jié)合，實(shí)現(xiàn)“計(jì)算”和“連接”平衡，具有如下優(yōu)勢：充分發(fā)揮運(yùn)營商對網(wǎng)絡(luò)連接的感知優(yōu)勢；可對網(wǎng)絡(luò)連接實(shí)現(xiàn)精細(xì)化管理如端到端QoS；有利于快速引入ISP應(yīng)用程序（APP）；通過對UPF分流后業(yè)務(wù)第一跳入口處的聯(lián)動和閉環(huán)處理，更快、更好地上線新業(yè)務(wù)；真正構(gòu)建“云-邊-端”協(xié)同業(yè)務(wù)模式，而不是簡單的“云+端”模式。

2 MEC連接能力需求分析

通過標(biāo)準(zhǔn)的管理接口在網(wǎng)絡(luò)業(yè)務(wù)呈現(xiàn)功能（NEF）接口實(shí)現(xiàn)UPF路由規(guī)則的可配置性后，用戶面數(shù)據(jù)流到達(dá)邊緣計(jì)算網(wǎng)關(guān)設(shè)備。該網(wǎng)關(guān)就將成為一個(gè)轉(zhuǎn)發(fā)集中點(diǎn)，特別是當(dāng)承載高清視頻等業(yè)務(wù)時(shí)，該網(wǎng)關(guān)的轉(zhuǎn)發(fā)面性能就成為關(guān)鍵點(diǎn)。即使某些流量不是特別巨大的應(yīng)用，如車聯(lián)網(wǎng)（V2X）網(wǎng)絡(luò)的控制信息，由于交互報(bào)文小而頻繁密集，對轉(zhuǎn)發(fā)面的包轉(zhuǎn)發(fā)率（PPS）要求也很高。

圖1 5G典型場景下移動邊緣計(jì)算部署組網(wǎng)

在云數(shù)據(jù)中心里面，網(wǎng)絡(luò)集中點(diǎn)的軟件轉(zhuǎn)發(fā)技術(shù)多采用基于用戶態(tài)的輪詢機(jī)制的驅(qū)動（PMD）和數(shù)據(jù)平面開發(fā)套件（DPDK）環(huán)形隊(duì)列支撐底層高效收發(fā)，配合vSwitch技術(shù)實(shí)現(xiàn)虛擬機(jī)之間的L2交換。當(dāng)需要使用網(wǎng)絡(luò)報(bào)文的高層次解析時(shí)，一般會采用快速數(shù)據(jù)項(xiàng)目（FD.io）矢量包處理器（VPP）快路徑開源軟件通過對報(bào)文向量化和充分利用處理器最后一級緩存（CPU LLC）緩存命中之類相關(guān)技術(shù)，將報(bào)文分發(fā)到開源用戶態(tài)協(xié)議棧處理。進(jìn)一步地，當(dāng)需要配合業(yè)務(wù)規(guī)則如URL解析、DNS解析實(shí)現(xiàn)業(yè)務(wù)負(fù)載均衡時(shí)，需要通過用戶態(tài)Linux 虛擬服務(wù)器（LVS）、Nginx反向代理等開源軟件技術(shù)支持高性能L4-L7轉(zhuǎn)發(fā)。

軟件轉(zhuǎn)發(fā)面加速技術(shù)基于X86平臺，充分利用單指令多數(shù)據(jù)流（SIMD）操作如高級向量擴(kuò)展（AVX）指令集和CPU提供的旋鎖等硬件原子操作指令，也可以達(dá)到較高的性能。當(dāng)前，一般在支持較為簡單的L7解析規(guī)則時(shí)，單臺2路Intel高配置SKU XEON可達(dá)到10 Gbit/s+ throughputs、5 M+PPS的包轉(zhuǎn)發(fā)率。

5G MEC面對的轉(zhuǎn)發(fā)場景能力很有可能是100 Gbit/s+、50 M+PPS入口L4 負(fù)載均衡（LB）的需求。僅僅為解決入口網(wǎng)關(guān)的分發(fā)而在邊緣機(jī)房中放置5～10臺服務(wù)器顯然是比較浪費(fèi)的，為此，需要更高性耗比和性價(jià)比的MEC高性能轉(zhuǎn)發(fā)面解決方案來解決這一問題。

此外，針對特殊的數(shù)據(jù)流如視頻流傳輸，也需要對傳統(tǒng)傳輸控制協(xié)議（TCP）滑窗機(jī)制進(jìn)行連接優(yōu)化，以降低延遲、減少重傳流量開銷，如Google提出的新型擁塞控制算法（Google BBR）等?？梢?，這部分技術(shù)因素也需要一并予以考慮。

3 MEC計(jì)算力需求分析

經(jīng)過L4-L7 LB后的報(bào)文到達(dá)APP Server資源池后進(jìn)行業(yè)務(wù)場景的處理，而MEC計(jì)算力需求與業(yè)務(wù)場景緊密相關(guān)。業(yè)務(wù)場景決定了該APP是應(yīng)該放在云中心抑或是放在邊緣中心處理。傳統(tǒng)上認(rèn)為，以下幾種業(yè)務(wù)場景是比較適合放在MEC的。

（1）流量大且需要就近分發(fā)以減少流量迂回的應(yīng)用場景，如CDN網(wǎng)絡(luò)。

（2）終端處理功耗高影響續(xù)航能力的場景，如需要圖形處理器（GPU）渲染的云游戲或者直播類業(yè)務(wù)。

（3）需要人工智能（AI）感知類的場景，如非結(jié)構(gòu)化視頻數(shù)據(jù)的信息本地提取結(jié)構(gòu)化處理過程。

（4）視頻、雷達(dá)點(diǎn)云等流式數(shù)據(jù)壓縮/解壓縮進(jìn)一步本地處理的場景。

（5）安全相關(guān)的場景，如出入口數(shù)據(jù)流的加解密/防火墻處理過程。

（6）有關(guān)通用計(jì)算存儲能力的場景，如高性能非易失材料存儲介質(zhì)的本地?cái)?shù)據(jù)存取、預(yù)處理、清洗過程。

除了這些計(jì)算需求外，還有一部分新技術(shù)需求。如在物聯(lián)網(wǎng)（IoT）系統(tǒng)中引入?yún)^(qū)塊鏈和分布式記賬（DLT）等技術(shù)解決用戶接入認(rèn)證、設(shè)備資產(chǎn)管理、隱私數(shù)據(jù)保護(hù)等授信問題。還有針對用戶數(shù)據(jù)孤島，采用聯(lián)邦學(xué)習(xí)等分布式機(jī)制支持AI模型在線增量訓(xùn)練、遷移學(xué)習(xí)過程等。這些都是通過計(jì)算代價(jià)換取可信性的業(yè)務(wù)場景。

總的來說，當(dāng)前主要存在如下相關(guān)算力要求：

（1）AI深度學(xué)習(xí)計(jì)算。目前深度學(xué)習(xí)以卷積計(jì)算為核心，輔助以非線性變換（如Relu、Sigmoid函數(shù)）、池化、歸一化等計(jì)算操作（部分可以轉(zhuǎn)化為卷積操作與累加和操作）。此外，還包括在輸出層通常需要做對數(shù)據(jù)帶寬要求很高的全連接操作。其中，卷積操作計(jì)算量非常大，這是由于：目前深度學(xué)習(xí)層數(shù)普遍較深，多達(dá)百層以上的神經(jīng)網(wǎng)絡(luò)屢見不鮮；雖然卷積核普遍在縮小，但是按照Strip=1或者2的步長從左至右、從上至下迭代點(diǎn)乘累加下來的計(jì)算量卻非常巨大。以目前作為Benchmark比較簡單的AlexNet 8層卷積神經(jīng)網(wǎng)絡(luò)（CNN）為例，單張圖片計(jì)算力就達(dá)到了1.5 GFlops，而當(dāng)前主流的CNN普遍在5～10 GFlops之間。主流的神經(jīng)網(wǎng)絡(luò)模型尺寸普遍較大，幾百兆尺寸的模型也不在少數(shù)，依靠片內(nèi)靜態(tài)隨機(jī)存取控制器（SRAM）一次性載入顯然不現(xiàn)實(shí)，而使用動態(tài)隨機(jī)存取存儲器（DRAM）存放又不滿足數(shù)據(jù)帶寬需求。

（2）GPU渲染。GPU渲染包括邊緣計(jì)算云游戲、交互式視頻、虛擬/增強(qiáng)/混合現(xiàn)實(shí)業(yè)務(wù)等基本計(jì)算力需求。其本質(zhì)是對渲染方程求近似解的過程。計(jì)算架構(gòu)從最早的固定Pipeline發(fā)展到目前可編程的Pipeline，并通過多數(shù)據(jù)（矢量化并發(fā)）、多指令（空間分區(qū)）、高主頻超標(biāo)量體系（時(shí)分和硬件調(diào)度）+Wrap多線程（數(shù)據(jù)流并發(fā)優(yōu)化）實(shí)現(xiàn)了具有高性能、靈活性和通用性的主流通用圖形處理器（GPGPU）。

（3）視頻編解碼。通過實(shí)時(shí)編解碼技術(shù)可以對音視頻內(nèi)容進(jìn)行有效的信息有損壓縮。數(shù)據(jù)容量壓縮比可達(dá)到數(shù)百比一，這在節(jié)省傳輸帶寬實(shí)現(xiàn)高效率傳輸方面有重要意義。視頻編解碼計(jì)算力要求要比AI深度學(xué)習(xí)計(jì)算更為復(fù)雜：一方面，對視頻幀數(shù)據(jù)宏塊/子塊劃分和I/B/P幀間預(yù)測編碼都需要高效的數(shù)據(jù)流調(diào)度機(jī)制以節(jié)省數(shù)據(jù)帶寬；另一方面，涉及到空間數(shù)據(jù)冗余消除（幀內(nèi)預(yù)測）、時(shí)間數(shù)據(jù)冗余消除（幀間預(yù)測）時(shí)，需要進(jìn)行移位、累加等操作，這對殘差數(shù)據(jù)還有離散余弦變換（DCT）相關(guān)性消除、游程/字碼類編碼無損壓縮等都有較高的算力要求。由于存在通用格式標(biāo)準(zhǔn)可遵循，以及編解碼算法便于專用集成電路（ASIC）化，目前高性能高密度視頻編解碼大部分以固化形態(tài)存在。當(dāng)然也可以通過CPU/GPU/數(shù)字信號處理（DSP）進(jìn)行軟處理，只是效率相對較低。

（4）其他相關(guān)算力要求。比如，在V2X應(yīng)用中，還存在LiDAR激光雷達(dá)的點(diǎn)云數(shù)據(jù)壓縮和信息結(jié)構(gòu)化處理的需求。隨著顯示材料技術(shù)的發(fā)展，AR/VR/混合現(xiàn)實(shí)（MR）等前瞻性業(yè)務(wù)有可能會被作為殺手級應(yīng)用進(jìn)行開展，這將產(chǎn)生新的計(jì)算力需求。對于混合現(xiàn)實(shí)業(yè)務(wù)，相關(guān)算力要求主要是解法拉第光場方程實(shí)現(xiàn)光場技術(shù)和卡爾曼濾波（KF）獲取深度信息。雖然目前可以使用GPGPU完成相關(guān)計(jì)算過程，但這并不是性耗比和性價(jià)比最優(yōu)的解決方案。

這些計(jì)算力都是不以分支跳轉(zhuǎn)判斷為主處理路徑，而是基于數(shù)據(jù)流驅(qū)動的迭代型計(jì)算。在進(jìn)行超標(biāo)量體系處理時(shí)，會存在分支預(yù)測失敗率高、Cache命中率低、Von-Neumann架構(gòu)取指令、譯碼執(zhí)行代價(jià)大等問題，需要通過SIMD矢量指令來支持軟加速。

這里以Intel Skylake微架構(gòu)（2.3 GHz主頻/12核心/105 W 散熱設(shè)計(jì)功耗（TDP））支持AVX-512，單核、單時(shí)鐘周期64 浮點(diǎn)（FP）32/85整數(shù)（INT）8每秒操作數(shù)（OPS）為例，總算力為2.3 TOPS，性能功耗比僅僅為0.023 T/W（假設(shè)OpenVino調(diào)度和數(shù)學(xué)函數(shù)庫-深度神經(jīng)網(wǎng)絡(luò)（MKL-DNN）計(jì)算庫最優(yōu)化狀況）。以目前常見神經(jīng)網(wǎng)絡(luò)模型如Inception/暫態(tài)混沌神經(jīng)網(wǎng)絡(luò)（MTCNN）/Yolo/ResNet50等做圖片推理（檢測或分類），按照平均5 GFlops的計(jì)算量計(jì)算，一顆XEON大約能處理460 幀/秒的圖像深度學(xué)習(xí)，參照H.264 Main Profile 24 幀/秒，處理能力不到20路視頻。即5臺服務(wù)器處理不了200路視頻深度學(xué)習(xí)（不包含視頻編解碼）。

因此，目前主流做法普遍是采用優(yōu)化脈動陣列，使用基于數(shù)據(jù)流驅(qū)動的新型計(jì)算架構(gòu)，并通過超標(biāo)量主處理器實(shí)現(xiàn)異構(gòu)計(jì)算來支持相關(guān)算力需求。針對AI深度學(xué)習(xí)的深度學(xué)習(xí)加速器（DLA），在采用16 nm以下的工藝時(shí)，可以達(dá)到1～2 T Flops/W（FP16）以上的計(jì)算效率。

數(shù)據(jù)流驅(qū)動的計(jì)算方式需要對算力抽象并進(jìn)行調(diào)度，以支持新出現(xiàn)的算法、算子和多實(shí)例運(yùn)行。因此，在神經(jīng)網(wǎng)絡(luò)模型和實(shí)際物理算力之間需要采用軟件開發(fā)工具包（SDK）軟件進(jìn)行封裝，將模型轉(zhuǎn)譯成中間表達(dá)式，并通過量化壓縮、稀疏化等處理手段來降低模型尺寸和算力要求。由此可見，通過調(diào)度算子、算力來完成層內(nèi)計(jì)算優(yōu)化和層間計(jì)算融合可以實(shí)現(xiàn)算法建模與真實(shí)硬件的適配。

視頻編解碼在邊緣計(jì)算應(yīng)用中還存在一個(gè)較大的問題，即引入了較大的群延遲。在5G的諸多應(yīng)用中，比如V2X的攝像頭視頻數(shù)據(jù)結(jié)構(gòu)化感知公共環(huán)境信息、基于5G uRLLC的遠(yuǎn)程操作都依賴低延遲和確定性的端到端傳輸。即使5G空口+MEC實(shí)現(xiàn)了端到端10 ms的延遲，經(jīng)典視頻編解碼算法引入的延遲卻是數(shù)量級的：如果不做任何優(yōu)化，H.264典型延遲將達(dá)到400～500 ms。通過對傳輸協(xié)議和幀緩沖的優(yōu)化，一般可以將延遲降低到200 ms內(nèi)。但如果要實(shí)現(xiàn)50 ms內(nèi)的延遲，從攝像頭快門定制到ISP處理器端到端都需要進(jìn)行優(yōu)化。

4 MEC異構(gòu)計(jì)算和虛擬化、資源池的矛盾分析

從MEC計(jì)算力需求分析可以看出，異構(gòu)計(jì)算加速是邊緣機(jī)房無法回避的選擇。而構(gòu)建“云-邊-端”一體的協(xié)同業(yè)務(wù)模式，需要考慮開發(fā)運(yùn)營（DevOps）快速部署、軟件組件的平滑移植和第3方應(yīng)用的開發(fā)成本；因此，這將會不可避免地對異構(gòu)計(jì)算資源產(chǎn)生虛擬化和資源池化的需求。

從技術(shù)上看，異構(gòu)計(jì)算屬于一種領(lǐng)域定制架構(gòu)。在硬件虛擬化層面仍存在著較大的技術(shù)問題。

目前異構(gòu)計(jì)算主要以GPU、現(xiàn)場可編程門陣列（FPGA）和網(wǎng)絡(luò)處理器（NP）以及部分內(nèi)置DSP的ASIC為主。考慮到虛擬化基礎(chǔ)設(shè)施的優(yōu)勢，主流方案采用：主處理以通用X86作為主平臺，通過串行總線（PCI）Express總線外掛異構(gòu)計(jì)算協(xié)處理器，對迭代類型、數(shù)據(jù)流驅(qū)動類型等強(qiáng)計(jì)算工作負(fù)載進(jìn)行Look-Aside方式的卸載。該方案的主處理器是X86平臺，保證了第三方應(yīng)用在云和邊的平滑移植，有利于實(shí)現(xiàn)APP與基礎(chǔ)設(shè)施的三層解耦。此外，也可以通過異構(gòu)計(jì)算實(shí)現(xiàn)性價(jià)比和性耗比的兼顧。

但是，針對外設(shè)部件互連標(biāo)準(zhǔn)（PCIe）輸入輸出（IO）的虛擬化方案仍然存在一些問題。目前主要采用單根IO虛擬化（SR-IOV）虛擬化方案，通過PCIe總線枚舉過程中對虛擬功能（VF）的功能發(fā)現(xiàn)并分配IO、Memory空間和中斷路由資源，將其視為虛擬設(shè)備的同時(shí)Bypass掉主機(jī)操作系統(tǒng)內(nèi)核，通過客戶操作系統(tǒng)來直接控制設(shè)備。這就帶來了虛機(jī)熱遷移和安全機(jī)制的一些問題。針對GPU設(shè)備，由于其具有多指令多數(shù)據(jù)（MIMD）特性，當(dāng)實(shí)現(xiàn)VF功能時(shí)，還會存在任務(wù)調(diào)度核心互聯(lián)網(wǎng)協(xié)議地址（IP）暴露等問題；因此，目前2家主流GPU廠商都只針對基于Windows DirectX的系統(tǒng)提供閉源或部分開源的收費(fèi)軟件。由此可見，當(dāng)邊緣需要實(shí)現(xiàn)視頻渲染類業(yè)務(wù)時(shí)，這樣的虛擬化方案是存在問題的。因此，一些方案采用基于物理GPU功能，通過遠(yuǎn)程直接內(nèi)存訪問（RDMA）這類低延遲網(wǎng)絡(luò)來實(shí)現(xiàn)客戶-服務(wù)器資源池拉遠(yuǎn)，加載基于開源的任務(wù)調(diào)度軟件以替代GPU虛擬化。

針對異構(gòu)協(xié)同的Look-Aside架構(gòu)，也有一些基于半虛擬化IO（VirtIO）的虛擬IO技術(shù)。VirtIO本質(zhì)是一種Share Memory通信技術(shù)，通過“連接”在Backend上的前、后端驅(qū)動實(shí)現(xiàn)硬件設(shè)備的抽象和隔離，解決了單根IO虛擬化（SRIOV）的安全性和“熱插拔”缺陷。但是VirtIO機(jī)制本身是一種軟件處理方式，在沒有硬件加速輔助的條件下，其性能與SRIOV存在明顯差距。此外，VirtIO支持的驅(qū)動類型也需要生態(tài)鏈的廣泛支撐。也有一些廠家將虛擬操作系統(tǒng)模擬器（QEMU）和VirtIO的大部分功能下沉進(jìn)入FPGA等加速硬件中，通過將Hypervisor定制化做薄，實(shí)現(xiàn)無宿主機(jī)的裸金屬虛擬化硬件方案（注意與寄居型虛擬化方案中的裸金屬資源調(diào)度區(qū)分），在安全性和性能上都能取得良好效果。值得一提的是，VirtIO當(dāng)前主線版本由于對硬件加速考慮不足，數(shù)據(jù)結(jié)構(gòu)存在3套隊(duì)列，并不利于硬件的實(shí)現(xiàn)；因此，后續(xù)版本仍需要再繼續(xù)優(yōu)化。

FPGA是一種細(xì)粒度可編程異構(gòu)計(jì)算芯片。完成編程固化的FPGA可以等效ASIC性能。針對虛擬化管理要求，2大廠家都提供了靜態(tài)分區(qū)和可編程分區(qū)的動態(tài)重構(gòu)技術(shù)路線。通過將異構(gòu)接口、雙倍速率數(shù)據(jù)傳輸存儲器（DDR）、直接存儲器存取引擎（DMA Engine）等必需的數(shù)據(jù)通道固化到靜態(tài)分區(qū)，同時(shí)動態(tài)分區(qū)On-Fly在線重構(gòu)，可以加載加速應(yīng)用。針對資源發(fā)現(xiàn)和管理，2家都提供了OpenStack下Cyborg異構(gòu)管理組件的相關(guān)插件對FPGA裸設(shè)備發(fā)現(xiàn)、枚舉支撐Nova資源分配；然而，F(xiàn)PGA存在加速架構(gòu)對外部Memory帶寬和內(nèi)部數(shù)據(jù)流的要求存在太多定制化設(shè)計(jì)的問題。比如，AI DLA往往需要2組72 bit（8 bit 糾錯碼（ECC））DDR4支持64 Gbit/s+的預(yù)取帶寬，更有一些大吞吐設(shè)計(jì)需外部支持多組第六版圖形用雙倍數(shù)據(jù)傳輸率存儲器（GDDR6）顆粒提供大帶寬。而在網(wǎng)絡(luò)加速如智能網(wǎng)卡應(yīng)用時(shí)，又往往需要支持精確匹配表（如基于三態(tài)內(nèi)容尋址存儲器（TCAM）的訪問控制列表（ACL）查找算法）和支持多級Hash模糊匹配表相結(jié)合。這需要大位寬外存總線的同時(shí)，也需要多組小位寬總線甚至外置4倍數(shù)據(jù)倍率（QDR）SRAM配合片內(nèi)算法來實(shí)現(xiàn)。從這個(gè)角度來講，能夠滿足特定應(yīng)用的加速卡都是定制化的。另外，F(xiàn)PGA的綜合、布線資源對內(nèi)部邏輯單元和外部IO引腳都有苛刻的時(shí)序級配合需求；因此，很難在A廠家的FPGA卡上，靜態(tài)把B廠家的固件綜合進(jìn)去，也很難把A廠家自己的固件使用動態(tài)分區(qū)與其他固件動態(tài)重構(gòu)。

針對上述難題，業(yè)內(nèi)提出了資源池的解決方案。針對FPGA異構(gòu)資源池，微軟有過并不成功的實(shí)踐，最終還是選擇分布式同構(gòu)服務(wù)器形態(tài)[5]。從技術(shù)上看，在邊緣將FPGA異構(gòu)服務(wù)器單獨(dú)做成資源池，會存在網(wǎng)絡(luò)流量迂回、單點(diǎn)故障和維護(hù)困難等工程問題。

5 MEC設(shè)備部署位置和硬件形態(tài)

MEC部署位置區(qū)包括“邊緣”“超邊緣”和“現(xiàn)場級邊緣”，并與“邊緣云”“邊緣網(wǎng)關(guān)”和“邊緣設(shè)備”相對應(yīng)。邊緣硬件的形態(tài)千差萬別：從通用架式服務(wù)器、定制化服務(wù)器等上架設(shè)備形態(tài)，到掛墻機(jī)箱、“盒子”，再到手持式現(xiàn)場終端。在軟件部署上形態(tài)也很多樣：從虛機(jī)/容器“雙核”虛擬化云計(jì)算架構(gòu)+微服務(wù)，到嵌入式OS和極簡化協(xié)議棧。

眾所周知，邊緣計(jì)算得益于QoE提升與高效率網(wǎng)絡(luò)傳輸相結(jié)合的理念。通過提供用戶低延遲的業(yè)務(wù)感受和可控的網(wǎng)絡(luò)傳輸成本，來支撐以人為中心的如沉浸式/交互式視頻類新型業(yè)務(wù)，以及以物為中心的如車聯(lián)網(wǎng)等萬物互聯(lián)應(yīng)用。這充分發(fā)揮了5G網(wǎng)絡(luò)大帶寬、低延遲、廣連接的優(yōu)勢；因此，邊緣計(jì)算不僅要距離戶足夠近，使之處在網(wǎng)絡(luò)較低位置，還要實(shí)現(xiàn)一定的收斂匯聚，具備較強(qiáng)的本地處理能力。從這個(gè)方面來說，邊緣計(jì)算最理想的位置是大量無線和有線接入之后的位置，如中心單元（CU）/分布單元（DU）分離后的CU，甚至是DU，或者有線傳輸中的光線路終端（OLT）等接入點(diǎn)。位置既不適宜太高，也不適宜太低。太高或太低都將會使MEC失去價(jià)值。

位于縣區(qū)、接入/站點(diǎn)級的眾多邊緣接入機(jī)房是運(yùn)營商的寶貴財(cái)富，但邊緣接入機(jī)房不同于云數(shù)據(jù)中心，存在如下限制條件：

圖2 中興通訊OVS+VirtIO加速方案

（1）面積受限，通?？捎檬Ｓ嗝娣e小于100 m2，缺乏騰挪空間。

（2）機(jī)房承重普遍偏低，多為4～6 kN/m2標(biāo)準(zhǔn)，達(dá)不到數(shù)據(jù)中心8 kN/m2的要求。

（3）機(jī)柜深度多是600 mm或者300 mm并柜，不支持700 mm以上深度的通用服務(wù)器。

（4）機(jī)柜功率預(yù)算受限（散熱限制），單機(jī)柜為1～3 kW，平均2 kW。

（5）機(jī)房空調(diào)和制冷受限，需要滿足電信級環(huán)境溫度要求（網(wǎng)絡(luò)設(shè)備構(gòu)建系統(tǒng)標(biāo)準(zhǔn)3（NEBS L3））。

經(jīng)過充分調(diào)研，目前大家都意識到：對存量接入機(jī)房的改造耗費(fèi)巨大，而且缺乏可實(shí)施的工程方案；同時(shí)，邊緣機(jī)房需要定制化硬件形態(tài)予以支撐。為此，開放數(shù)據(jù)中心委員會（ODCC）組織制訂開放電信IT基礎(chǔ)設(shè)施（OTII）電信服務(wù)器白皮書以促進(jìn)邊緣定制化服務(wù)器硬件形態(tài)的建設(shè)。

6 中興通訊對MEC開展的針對性研究工作

中興通訊充分認(rèn)識到邊緣規(guī)模部署的相關(guān)制約因素，已經(jīng)開展了針對性的研究工作，并建立了開放邊緣平臺（OEP）。OEP是一個(gè)開放的軟硬件平臺，專為異構(gòu)計(jì)算加速定義，支持多種定制化硬件形態(tài)。該平臺不僅很好地解決了UPF用戶面下沉和MEC共同部署的問題，還支持多種計(jì)算加速方案，同時(shí)還可以結(jié)合ZTE基礎(chǔ)設(shè)施即服務(wù)（IaaS）/PaaS基礎(chǔ)設(shè)施平臺，提供MEP能力封裝，為第三方應(yīng)用平滑移植和業(yè)務(wù)創(chuàng)新提供高性價(jià)比、高性耗比、易于集成和部署的基礎(chǔ)平臺服務(wù)。

智能網(wǎng)卡提供的VirtIO網(wǎng)絡(luò)隔離方案（參見圖2），可達(dá)到與SRIOV同樣性能，不僅同時(shí)支持虛機(jī)熱遷移，還同時(shí)支持開放虛擬交換標(biāo)準(zhǔn)（OVS）加速和軟件定義網(wǎng)絡(luò)疊加（SDN overlay）組網(wǎng)虛擬擴(kuò)展局域網(wǎng)（Vxlan）加速。

如圖3所示，智能網(wǎng)卡通過In-Line加速對UPF下沉提供加速能力。2路XEON 與2塊智能網(wǎng)卡可實(shí)現(xiàn)近200 Gbit/s的報(bào)文轉(zhuǎn)發(fā)處理能力。單塊加速卡功耗僅60 W，并且延遲低于10 um。這對uRLLC業(yè)務(wù)價(jià)值尤高。

圖3 網(wǎng)絡(luò)加速模式

中興通訊視頻結(jié)構(gòu)化方案（參見圖4）通過視頻編解碼加速卡、AI加速卡支持2路XEON服務(wù)器系統(tǒng)對200路H.264 1 080P 24幀/秒的視頻進(jìn)行實(shí)時(shí)結(jié)構(gòu)化。同時(shí)還支持人臉識別、人形識別、車型識別、車輛監(jiān)測等AI業(yè)務(wù)。

中興通訊OEP系列邊緣定制化服務(wù)器（參見圖5）功能豐富、風(fēng)格統(tǒng)一：3U高度，450 mm深度；支持寬溫工作（0～45 ℃）；支持前走線維護(hù)（含前置多模電源）；散熱風(fēng)扇三冗余設(shè)置，支持不開箱熱插拔維護(hù)。

圖4 中興通訊視頻結(jié)構(gòu)化加速方案

圖5 中興通訊開放邊緣平臺系列邊緣定制化服務(wù)器

此外，針對邊緣計(jì)算應(yīng)用，中興通訊還研發(fā)了網(wǎng)絡(luò)加解密、防火墻、邊緣高性能L4-L7 LB等加速智能網(wǎng)卡方案、邊緣用戶態(tài)高性能固態(tài)存儲方案、裸金屬GPU虛擬化方案以及超低延遲視頻傳輸方案等多種異構(gòu)計(jì)算和網(wǎng)絡(luò)加速方案，以更好地服務(wù)各類邊緣計(jì)算應(yīng)用。

中興通訊秉持開放、合作、共贏的態(tài)度，與整個(gè)生態(tài)鏈上的合作伙伴共同努力，為實(shí)現(xiàn)邊緣計(jì)算的規(guī)模部署、落地和產(chǎn)業(yè)繁榮，積極貢獻(xiàn)力量。

致謝

本文得到了中興通訊股份有限公司無線產(chǎn)品經(jīng)營部唐雄、錢健忠、強(qiáng)鵬輝、張啟明、徐東和張景濤的鼎力幫助，謹(jǐn)致謝意。