呂華章 王友祥 唐雄燕

【摘? 要】邊緣云和邊緣計(jì)算技術(shù)目前已經(jīng)成為產(chǎn)業(yè)界和學(xué)術(shù)界的研究熱點(diǎn)，目前，中國(guó)聯(lián)通與中興通訊、英特爾、騰訊合作，在天津?qū)氎娲髮W(xué)城搭建了基于虛擬化的邊緣云測(cè)試床，開展了面向OTT業(yè)務(wù)的驗(yàn)證工作。重點(diǎn)介紹了基于邊緣云的vCDN的系統(tǒng)架構(gòu)實(shí)現(xiàn)方案，設(shè)計(jì)了相關(guān)的業(yè)務(wù)流程，開展了驗(yàn)證試驗(yàn)，最后給出了建設(shè)部署方案。測(cè)試結(jié)果表明，將應(yīng)用程序部署到網(wǎng)絡(luò)邊緣不僅能夠降低回傳帶寬壓力和延遲，而且優(yōu)化了用戶體驗(yàn)，同時(shí)幫助業(yè)務(wù)提供方降低了成本。

【關(guān)鍵詞】vCDN;邊緣云;邊緣計(jì)算;NAPT

doi：10.3969/j.issn.1006-1010.2019.01.004? ? ? ? 中圖分類號(hào)：TN929.5

文獻(xiàn)標(biāo)志碼：A? ? ? ? 文章編號(hào)：1006-1010（2019）01-0020-09

引用格式：呂華章， 王友祥， 唐雄燕. 面向5G MEC邊緣云的CDN下沉方案[J]. 移動(dòng)通信， 2019，43（1）： 20-28.

CDN Subsidence Scheme for 5G MEC Edge Cloud

LV Huazhang， WANG Youxiang， TANG Xiongyan

（China United Network Communication Network Technology Research Institute， Beijing 100048， China）

[Abstract]?Edge cloud and edge computing technology have become the research hotspot in the industry and academia. At present， China Unicom， in cooperation with ZTE， Intel and Tencent， has built a virtual edge cloud test bed in Tianjin University Town and carried out verification work for OTT business. In this paper， the implementation scheme of the system architecture based on edge cloud is descried in detail， the related business process is designed， the verification test is performed， and finally the construction deployment scheme is presented. The test results show that the deployment of applications at the network edge can not only decrease the backhaul bandwidth pressure and delay， but also optimize the user experience and reduce the cost of providers.

[Key words]vCDN; edge cloud; MEC; NAPT

1? ?引言

邊緣云技術(shù)（EC， Edge-Cloud）或多接入邊緣計(jì)算（MEC， Multi-Access Edge Computing）提供了全新的生態(tài)系統(tǒng)和價(jià)值鏈[1]。邊緣云其實(shí)就是將計(jì)算能力下沉到距離終端用戶更近的網(wǎng)絡(luò)邊緣，構(gòu)建面向業(yè)務(wù)的邊緣數(shù)據(jù)中心。邊緣云技術(shù)的興起對(duì)業(yè)務(wù)提供方和產(chǎn)業(yè)鏈的新企業(yè)是一次寶貴的機(jī)會(huì)，邊緣云平臺(tái)可以為業(yè)務(wù)提供豐富的平臺(tái)能力，快速地進(jìn)行業(yè)務(wù)部署。預(yù)計(jì)到2021年，邊緣云的市場(chǎng)規(guī)模將達(dá)到800億美元[2]。依托邊緣云平臺(tái)，電信運(yùn)營(yíng)商可以面向第三方應(yīng)用開發(fā)者，快速推出以用戶為導(dǎo)向的創(chuàng)新服務(wù)，縮短新業(yè)務(wù)上市時(shí)間[3]。

2014年，ETSI率先啟動(dòng)MEC標(biāo)準(zhǔn)項(xiàng)目，旨在移動(dòng)網(wǎng)絡(luò)邊緣為應(yīng)用開發(fā)商與內(nèi)容提供商搭建一個(gè)云化計(jì)算與IT環(huán)境的服務(wù)平臺(tái)，并通過該平臺(tái)開放無線側(cè)網(wǎng)絡(luò)信息，實(shí)現(xiàn)高帶寬、低時(shí)延業(yè)務(wù)支撐與本地管理。聯(lián)盟成員包括沃達(dá)豐、中興、Intel、華為、諾基亞、惠普等各大廠商，已完成了Phase I階段基于傳統(tǒng)4G網(wǎng)絡(luò)架構(gòu)設(shè)計(jì)，定義邊緣計(jì)算系統(tǒng)應(yīng)用場(chǎng)景、參考架構(gòu)、邊緣計(jì)算平臺(tái)應(yīng)用支撐API、應(yīng)用生命周期管理與運(yùn)維框架、以及無線側(cè)能力服務(wù)API（RNIS/定位/帶寬管理）等[4-10]，目前正在進(jìn)行Phase II階段的研究，主要聚焦在包括5G/Wi-Fi/固網(wǎng)在內(nèi)的多接入邊緣計(jì)算系統(tǒng)，重點(diǎn)覆蓋MEC in NFV參考架構(gòu)、端到端邊緣應(yīng)用移動(dòng)性、網(wǎng)絡(luò)切片支撐、合法監(jiān)聽、基于容器的應(yīng)用部署、V2X支撐、Wi-Fi與固網(wǎng)能力開放等研究項(xiàng)目，從而更好地支撐MEC商業(yè)化部署與固移融合需求。

隨著ETSI MEC標(biāo)準(zhǔn)化組織影響力的與日俱增，3GPP也開始把網(wǎng)絡(luò)架構(gòu)使能MEC列為重點(diǎn)研究課題。在4G CUPS[11]架構(gòu)和5G新核心網(wǎng)架構(gòu)里[12]，都重點(diǎn)強(qiáng)調(diào)了控制面和業(yè)務(wù)面的分離。在SA2 5G系統(tǒng)架構(gòu)中，未來將完成支持邊緣云和邊緣計(jì)算的諸多業(yè)務(wù)，包括本地分流、會(huì)話和服務(wù)連續(xù)性、網(wǎng)絡(luò)能力開放、QoS保證與策略控制等[13-14]。除此以外，SA5下一代網(wǎng)絡(luò)管理架構(gòu)和特性與SA6公共北向API接口兩個(gè)研究組也將邊緣云的各類需求考慮在內(nèi)[15]。3GPP正在加速邊緣計(jì)算標(biāo)準(zhǔn)化的研究工作，助力5G業(yè)務(wù)的商用部署。

3.3? 基于NAPT的vCDN實(shí)現(xiàn)方案

在天津?qū)氎娴脑囼?yàn)中，主要開展了騰訊視頻和沃視頻vCDN下沉的驗(yàn)證，MEC通過按域名和NAPT功能來進(jìn)行視頻業(yè)務(wù)的分流。如圖4所示，OTT廠家的CDN HTTP DNS服務(wù)器針對(duì)IP地址建立服務(wù)器選擇映射，確保經(jīng)MEC NAPT轉(zhuǎn)換的請(qǐng)求能夠根據(jù)負(fù)荷均衡策略映射到本地邊緣服務(wù)器上（邊緣vCDN）。

首先完成NAPT轉(zhuǎn)換規(guī)則的建立，對(duì)應(yīng)圖4的步驟1到步驟7：

（1）MEC配置特定域名，監(jiān)聽發(fā)往UE的DNS響應(yīng)，從DNS響應(yīng)里獲取到域名對(duì)應(yīng)的IP地址，針對(duì)該IP動(dòng)態(tài)生成分發(fā)規(guī)則;

（2）MEC匹配分發(fā)規(guī)則，對(duì)發(fā)往HTTP DNS的報(bào)文進(jìn)行NAPT（源IP替換為特定IP）;

（3）對(duì)HTTP DNS返回給UE的報(bào)文，MEC反向NAPT轉(zhuǎn)換后發(fā)給UE;

（4）MEC服務(wù)器建立分流機(jī)制，對(duì)目的地址指向邊緣服務(wù)器的數(shù)據(jù)包進(jìn)行本地分流。

然后，完成本地分流，對(duì)應(yīng)圖4的步驟8到步驟9：用戶向邊緣服務(wù)器請(qǐng)求資源，MEC直接從本地CDN中發(fā)送業(yè)務(wù)內(nèi)容給用戶，實(shí)現(xiàn)本地業(yè)務(wù)下發(fā)。

3.4? 基于NAPT的vCDN實(shí)現(xiàn)

方案優(yōu)勢(shì)分析

NAPT方案的提出是實(shí)現(xiàn)整個(gè)端到端vCDN方案打通的關(guān)鍵，其優(yōu)勢(shì)同傳統(tǒng)的HTTP代理等方式有明顯的不同，可以簡(jiǎn)單地歸納為以下三點(diǎn)：

首先，對(duì)于OTT廠商而言，其業(yè)務(wù)要在全國(guó)范圍鋪開，需要避免對(duì)整體CDN架構(gòu)的調(diào)整。因此，不能因?yàn)榇舜螌?duì)接而影響騰訊現(xiàn)網(wǎng)業(yè)務(wù)，NAPT方式完全滿足騰訊的需求。

其次，MEC服務(wù)器目前能夠支持一定程度的流量處理和包解析功能，但是其只能處理數(shù)據(jù)域的IP包頭解析，無法實(shí)現(xiàn)深度的DPI解析。深度解析需要MEC服務(wù)器進(jìn)行深層次開發(fā)，短期內(nèi)無法實(shí)現(xiàn)。而NAPT方案能夠?qū)⒄麄€(gè)業(yè)務(wù)局限在IP包頭的解析，很大程度上降低了MEC業(yè)務(wù)處理的復(fù)雜度，能夠?qū)崿F(xiàn)業(yè)務(wù)的快速部署和運(yùn)營(yíng)。

最后，NAPT方案能夠節(jié)約大量的公網(wǎng)IP，目前公網(wǎng)出口不足，NAPT方案能夠?qū)^(qū)域內(nèi)的相關(guān)UE都轉(zhuǎn)換為相同的IP地址，實(shí)現(xiàn)業(yè)務(wù)下沉判斷的同時(shí)也節(jié)約了IP資源，適合運(yùn)營(yíng)商目前的部署策略。

4? ?業(yè)務(wù)實(shí)踐部署與結(jié)果分析

4.1? 實(shí)際部署

目前，天津的邊緣云平臺(tái)由10余臺(tái)X86通用服務(wù)器構(gòu)成計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)資源池。平臺(tái)的計(jì)算節(jié)點(diǎn)與存儲(chǔ)節(jié)點(diǎn)采用融合部署方案，控制節(jié)點(diǎn)分離部署，可實(shí)現(xiàn)系統(tǒng)管理、告警管理和性能管理。同時(shí)，平臺(tái)搭載了高性能轉(zhuǎn)碼集群與高性能存儲(chǔ)集群，提升了邊緣云平臺(tái)整體的業(yè)務(wù)性能和業(yè)務(wù)流暢程度。本次vCDN業(yè)務(wù)的驗(yàn)證是該平臺(tái)能夠提供的一個(gè)業(yè)務(wù)，詳細(xì)的部署架構(gòu)如圖5所示。

4.2? 業(yè)務(wù)時(shí)延與下載速率測(cè)試

業(yè)務(wù)驗(yàn)證測(cè)試結(jié)果如表1所示，RTT循環(huán)時(shí)延得到降低，同時(shí)HTTP下載速率有所提升。RTT時(shí)延下降了近50%，而HTTP下載速率提升了43%，邊緣云的效果顯而易見。未來我們將驗(yàn)證更多的業(yè)務(wù)類型，包括AR/VR、定位服務(wù)、安防監(jiān)控等。

在ping測(cè)試試驗(yàn)中，移動(dòng)終端連接到MEC，采用了Python腳本的形式。該腳本執(zhí)行系統(tǒng)的ping數(shù)據(jù)包，同時(shí)將ping包的結(jié)果保存下來。天津部署有騰訊的省級(jí)CDN節(jié)點(diǎn)，同時(shí)山東部署有騰訊的公網(wǎng)服務(wù)器，廣東部署有全國(guó)性質(zhì)的GSLB負(fù)載均衡調(diào)度DNS服務(wù)器，如果不使用MEC邊緣云，那么所有的CDN流程將在公共CDN和省級(jí)CDN節(jié)點(diǎn)上完成，試驗(yàn)發(fā)現(xiàn)業(yè)務(wù)在該流程的建立過程中，存在明顯的丟包和高時(shí)延現(xiàn)象。

每次測(cè)試的結(jié)果都有丟包的現(xiàn)象，有一定的丟包率。同時(shí)，最大的回環(huán)時(shí)延主要受到現(xiàn)網(wǎng)環(huán)境影響。從統(tǒng)計(jì)學(xué)的角度來看，可以對(duì)比公網(wǎng)CDN和本地CDN的結(jié)果，對(duì)比結(jié)果如圖6和表2所示。根據(jù)測(cè)試結(jié)果分析，使用MEC分流以后，ping包的丟包率明顯降低，同時(shí)時(shí)延降低將近一半。

下面是對(duì)HTTP下載速率的測(cè)試。使用如下的測(cè)試方法：騰訊視頻給出HTTP下載URL，該地址可以直接被IP所訪問。在移動(dòng)終端建立一個(gè)腳本，該腳本用于在完成TCP數(shù)據(jù)傳輸之前的TCP建立URL接入、連接。記錄下數(shù)據(jù)傳輸?shù)氖状螘r(shí)間和結(jié)束時(shí)間，同時(shí)記錄下數(shù)據(jù)傳輸?shù)乃俾?，每次測(cè)試都執(zhí)行固定數(shù)量的下載內(nèi)容。

騰訊視頻公網(wǎng)測(cè)試的網(wǎng)絡(luò)環(huán)境是較好的，所以可以輕易地對(duì)比出本地CDN比公網(wǎng)CDN存在巨大的優(yōu)勢(shì)：本地網(wǎng)絡(luò)的平均下載速率是94.5 Mbit·s-1，而公網(wǎng)的下載速率僅僅為68.71 Mbit·s-1。表3展示CDN測(cè)試中HTTP下載測(cè)試的結(jié)果，圖7展示了本地CDN的抓包情況，而圖8展示的是在公網(wǎng)CDN下的抓包情況。從圖中還可以看出，公網(wǎng)CDN容易受到鏈路環(huán)境影響，下載速率波動(dòng)較大，而本地CDN能夠一定程度上保證用戶體驗(yàn)速率較高而不出現(xiàn)波動(dòng)。

圖7中，UE到騰訊本地服務(wù)器：10.20.97.120：38883到10.160.130.20：80。該地址是一個(gè)IP地址和端口號(hào)的結(jié)合表示方法。下載時(shí)間為1.932 s，文件長(zhǎng)度為25.036 4 MB，最大下載速率為104.15 Mbit·s-1，而最低下載速率為13.02 Mbit·s-1。

圖8中，UE到騰訊公網(wǎng)服務(wù)器：10.20.97.120： 55142到125.39.6.153：80。該地址是一個(gè)IP地址和端口號(hào)的結(jié)合表示方法。下載時(shí)間為2.71 s，文件長(zhǎng)度為25.036 4 MB，最大下載速率為73.90 Mbit·s-1，而最低下載速率為9.24 Mbit·s-1。

可以明顯地比較出，MEC可以降低RTT，同時(shí)提升下載速率。

4.3 所提方案對(duì)ETSI參考架構(gòu)的改進(jìn)

ETSI MEC017協(xié)議于2018年2月最新發(fā)布，重點(diǎn)描述了MEC在NFV環(huán)境下的部署，突出了MEC平臺(tái)架構(gòu)的虛擬化部署的色彩。MEC作為與生俱來的帶有NFV屬性的一套生態(tài)，MEC017協(xié)議可以認(rèn)為是MEC003協(xié)議的進(jìn)一步的擴(kuò)展，更加面向?qū)嶋H部署和落地。MEC017中詳細(xì)的參考架構(gòu)如圖9所示，整個(gè)架構(gòu)遵循以下原則：已有的電信網(wǎng)NFV架構(gòu)網(wǎng)元部分盡可能地重用，MEC模塊可調(diào)用NFV部分功能，MEC內(nèi)部功能模塊之間的信令不受NFV管理編排器控制，MEC同NFV之間的接口要重新定義。

此次CDN實(shí)驗(yàn)方案，如果映射到整個(gè)ETSI所提出的參考架構(gòu)中，其改動(dòng)就在于，在MEP邊緣云平臺(tái)內(nèi)部增加了包檢測(cè)（packet sniffer）這一模塊，該模塊的用途在于能夠跟蹤、發(fā)現(xiàn)、劫持DNS請(qǐng)求和響應(yīng)。在NAPT流程中，步驟三就用到包檢測(cè)這一功能，用于正確地建立NAPT規(guī)則。而與此同時(shí)，提供這一功能的可以是MEP平臺(tái)自帶的平臺(tái)服務(wù)，也可以在data plane數(shù)據(jù)平面內(nèi)建立NAPT規(guī)則。未來，包檢測(cè)功能將用于流量分流、業(yè)務(wù)下沉、負(fù)載均衡等多個(gè)場(chǎng)景，這一改變將是對(duì)ETSI所定義的MEC平臺(tái)架構(gòu)的有利影響。

5? ?結(jié)論

作為一項(xiàng)新的ICT融合技術(shù)，邊緣云可以整合電信運(yùn)營(yíng)商的各類資源，為5G時(shí)代業(yè)務(wù)的快速部署和運(yùn)行提供豐富的平臺(tái)能力。一種新興技術(shù)和生態(tài)的誕生與興起，需要背后商業(yè)模式的強(qiáng)有力支撐。面向未來，業(yè)界對(duì)邊緣業(yè)務(wù)平臺(tái)的各種應(yīng)用場(chǎng)景有著無限的憧憬與期待。但美好的愿望要變成現(xiàn)實(shí)，需要整個(gè)產(chǎn)業(yè)鏈的共同努力。此次CDN業(yè)務(wù)的試驗(yàn)是中國(guó)聯(lián)通整個(gè)Edge-Cloud規(guī)模試點(diǎn)及商用推進(jìn)過程中的一部分，未來我們希望攜手更多的行業(yè)合作伙伴，共同探討邊緣業(yè)務(wù)平臺(tái)的合作模式，共建5G網(wǎng)絡(luò)邊緣生態(tài)系統(tǒng)，全面推動(dòng)邊緣業(yè)務(wù)的蓬勃發(fā)展。

參考文獻(xiàn)：

[1] European Telecommunications Standards Institute （ETSI）. Mobile-Edge Computing Introductory Technical White Paper[EB/OL]. [2016-12-03]. https：//portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile edge Computing Introductory Technical White Paper_V1%2018-09-14.pdf.

[2] China Unicom. China Unicom edge computing technology white paper[R]. 2017.

[3] China Unicom. White Paper for China Unicoms Edge-Cloud Service Platform Architecture and Industrial Eco-System[R]. 2018.

[4] European Telecommunications Standards Institute （ETSI）. Mobile Edge Computing （MEC）： Framework and Reference Architecture[R]. 2016.

[5] European Telecommunications Standards Institute （ETSI）. Mobile Edge Computing （MEC）： General principles for Mobile Edge Service APIs[R]. 2017.

[6] European Telecommunications Standards Institute （ETSI）. Mobile Edge Computing （MEC）： Mobile Edge Platform Application Enablement[R]. 2017.

[7] European Telecommunications Standards Institute （ETSI）. Mobile Edge Computing （MEC）： Bandwidth Management API[R]. 2017.

[8] European Telecommunications Standards Institute （ETSI）. Mobile Edge Computing （MEC）： Location API[R]. 2017.

[9] European Telecommunications Standards Institute （ETSI）. Mobile Edge Computing （MEC）： Mobile Edge Management; Part 2： Application lifecycle， rules and requirements management[R]. 2017.

[10] European Telecommunications Standards Institute （ETSI）. Mobile Edge Computing （MEC）： Radio Network Information API[R]. 2017.

[11] 3rd Generation Partnership Project （3GPP）， 3GPP TR， 23.214. Architecture enhancements for control and user plane separation of EPC nodes （Release 14）[S]. 2017.

[12] 3rd Generation Partnership Project （3GPP）， 3GPP TR， 38.211. NR; Physical channels and modulation; （Release 15）[S]. 2018.

[13] 3rd Generation Partnership Project （3GPP）， 3GPP TR， 23.501. System Architecture for the 5G System; （Release 15）[S]. 2017.

[14] 3rd Generation Partnership Project （3GPP）， 3GPP TR， 23.502. Procedures for the 5G System （Release 15）[S]. 2017.

[15] 3rd Generation Partnership Project （3GPP）， 3GPP TR， 23.222. Common API Framework for 3GPP Northbound APIs （Release 15）[S]. 2018.