楊 俊，王園園

(1.重慶郵電大學 通信與信息工程學院，重慶 400065；2.移動計算與新型終端北京市重點實驗室，北京 100190)

0 引言

隨著通信技術(shù)的迅猛發(fā)展，移動網(wǎng)絡支撐的無線業(yè)務越來越豐富多樣。無線業(yè)務負載在時間和空間呈現(xiàn)出強烈的不均勻性，隨著用戶的移動，系統(tǒng)流量負載呈現(xiàn)隨時間變化的“潮汐效應”。在工作時段(9：00-17：00)，大量用戶從住宅區(qū)移動到辦公區(qū)的移動流量急劇增加；而在其余時段(20：00-23：00)，用戶從辦公區(qū)移動到住宅區(qū)的移動流量急劇增加，而商業(yè)區(qū)移動流量明顯下降。傳統(tǒng)基站固有潮汐效應現(xiàn)象造成基站處理資源分配不均，零星負載基站與高負載的基站消耗相同功率，移動網(wǎng)絡的平均負載情況遠低于忙時負載。

針對傳統(tǒng)離散分布的基站架構(gòu)，其資源按用戶峰值匹配，難以從全局進行資源分配，通過研究分析，新一代集中式接入網(wǎng)絡架構(gòu)是一種有效的解決途徑。針對集中式接入網(wǎng)的概念，很多研究機構(gòu)提出相應的架構(gòu)設計，包括IBM的無線網(wǎng)絡云架構(gòu)[1]，中國移動的C-RAN(Centralized，Cooperative，Cloud RAN)[2-3]，以及文獻[4-6]提出的超級基站。與傳統(tǒng)基站架構(gòu)相比，集中式接入網(wǎng)對基站資源進行集中并池化，通過構(gòu)造射頻軟件池、基帶軟件池和協(xié)議棧軟件池，承載一個小區(qū)的數(shù)據(jù)處理任務。在集中式接入網(wǎng)中，傳統(tǒng)無線基站的功能抽象為運行在特定基站硬件資源上的虛擬基站軟件，虛擬基站由動態(tài)分配的實際物理計算資源與軟件處理邏輯組合而成，對虛擬基站而言，其屏蔽了底層硬件資源細節(jié)，所以具有硬件資源可動態(tài)配置、映射資源可遷移的特點。

虛擬基站的遷移是實現(xiàn)集中式網(wǎng)絡架構(gòu)下資源高效分配的關鍵技術(shù)。遷移虛擬基站的技術(shù)核心是采用遷移機制將負載較高的虛擬基站遷移到負載較低的基站板卡上，從而實現(xiàn)基站負載的動態(tài)調(diào)整、負載均衡。針對通用處理器組成協(xié)議計算資源池，對于基站協(xié)議棧而言，為保證遷移過程中用戶可靠穩(wěn)定接入，需要滿足以下兩方面的要求：

① 最小的用戶中斷時間(建議值100 ms)[7-8]。因為在遷移的過程中，不可避免地會有一定的中斷時間，對于用戶而言，必須要足夠小且不能讓用戶感知，否則影響用戶體驗。通過LTE相關定時器分析，影響用戶感知的定時器為T310，T310設置得越大，此時間內(nèi)相關資源無法及時釋放，也無法發(fā)起恢復操作或響應新的資源建立請求，從而影響用戶體驗。

② 基站遷移過程中，總遷移時間不能過長[9-10]。因為在遷移的過程中，會耗費大量的帶寬資源，如果遷移時間過長，會影響其他用戶的正常使用。

云計算平臺和集中式基站有一定的相似性，目前云計算平臺廣泛地應用遷移技術(shù)解決資源負載問題，但對于其應用到基站方面還沒有確定結(jié)論。因此針對超級基站架構(gòu)中協(xié)議層計算任務的遷移需求，進行3種遷移方案的基站協(xié)議棧遷移仿真實驗，得出了預拷貝遷移基本符合基站協(xié)議棧遷移需求。

1 超級基站

首先對超級基站架構(gòu)進行闡述。文獻[11-13]提到超級基站物理架構(gòu)包括大規(guī)模計算資源池(BBU)和分布式異構(gòu)射頻池(RRU)。BBU是由大規(guī)?？蓴U縮的CPU構(gòu)建而成，為計算資源的虛擬化、并行處理提供強力的硬件支撐。對于分布式異構(gòu)RRU池，主要的特點是采用虛擬化智能資源管理，實現(xiàn)按需動態(tài)部署、智能覆蓋。超級基站為實現(xiàn)基站資源的統(tǒng)計復用，將傳統(tǒng)基站資源進行集中式部署，采用虛擬化技術(shù)對集中計算資源進行水平池化，在基礎硬件層面構(gòu)建射頻資源池、基帶處理資源池和通用計算資源池。在資源池內(nèi)提供大量虛擬基站，每個虛擬基站由協(xié)議、基帶和射頻共同構(gòu)造，并從資源池內(nèi)獲取相應處理資源，完成完整的基站處理任務。超級基站水平架構(gòu)圖如圖1所示。

圖1 超級基站水平架構(gòu)

在超級基站內(nèi)部，有2個重要模塊：計算資源管控模塊和資源監(jiān)測模塊。計算資源管控模塊功能為虛擬基站動態(tài)地分配資源，并根據(jù)基站負載情況為資源不足的虛擬基站制定資源調(diào)整策略，實現(xiàn)基站處理資源的按需分配、動態(tài)管理。而資源監(jiān)測模塊負責監(jiān)測基站板卡運行所占用的CPU、內(nèi)存和I/O等資源，該信息返回給計算資源管控模塊。例如，資源監(jiān)測模塊發(fā)現(xiàn)某塊基站單板負載相對較高，而另一塊基站單板負載較低，這時將反饋給計算資源管控模塊，計算資源管控模塊將發(fā)起遷移要求，將負載較高的基站單板上運行的虛擬基站遷移到負載較低的單板。在超級基站單板負載都較低的情況，可以將其上運行的虛擬基站都遷移到1個或幾個基站單板上。通過上述分析，有效的遷移機制可顯著改善基站資源負載均衡問題。

2 基站協(xié)議棧遷移算法

在沒有利用虛擬機時，板卡之間的協(xié)議棧遷移依靠的是系統(tǒng)備份和恢復技術(shù)。在源板卡上實時備份操作系統(tǒng)和協(xié)議棧程序的狀態(tài)，然后把存儲介質(zhì)傳輸?shù)侥繕税蹇ㄉ?，最后在目標板卡上恢復協(xié)議棧的運行。在這種情況下，遷移協(xié)議棧會造成較大的停機時間，并且在停機時間內(nèi)基站協(xié)議棧無法處理任何業(yè)務，嚴重影響用戶體驗。

虛擬機遷移技術(shù)實現(xiàn)基站板卡上的虛擬機與協(xié)議棧在幾乎間斷運行的情況下實時移動，為確保遷移前后的基站協(xié)議棧狀態(tài)保持一致，必須傳遞虛擬機網(wǎng)絡狀態(tài)信息、存儲狀態(tài)信息以及最為關鍵的運行狀態(tài)信息。在這些狀態(tài)信息和數(shù)據(jù)之中，遷移內(nèi)存的狀態(tài)信息和數(shù)據(jù)最復雜，內(nèi)存不僅存儲的信息量巨大、地址映射相對復雜，而且頁面變化較大。與內(nèi)存遷移相比，CPU運行狀態(tài)和I/O設備遷移數(shù)據(jù)量較少、結(jié)構(gòu)單一。因此本文的研究重點是針對內(nèi)存的遷移機制，下面分別介紹3類遷移對象。

① 存儲設備的遷移：存儲設備因為其數(shù)據(jù)量最大，會浪費大量的時間和網(wǎng)絡帶寬。為了減少遷移的時間和空間損失，采用NFS共享的方式共享數(shù)據(jù)和文件系統(tǒng)[14]，實現(xiàn)虛擬硬盤資源零遷移。

② 網(wǎng)絡的遷移：在遷移時虛擬機的所有網(wǎng)絡設備，包括協(xié)議狀態(tài)以及 IP 地址都要封裝在一起遷移。在局域網(wǎng)內(nèi)，通過發(fā)送 ARP重定向包，就可以把虛擬機的 IP 地址與目的主機的 MAC 地址相綁定，遷移之后所有的數(shù)據(jù)包就可以成功抵達目的主機。

③ 內(nèi)存的遷移：虛擬機動態(tài)遷移的內(nèi)存遷移是遷移的難點，目前，遷移算法主要有3種：靜態(tài)遷移、預拷貝遷移算法和后拷貝遷移算法。

靜態(tài)遷移：靜態(tài)復制遷移首先暫停源主機上的虛擬機運行，然后將虛擬機所有的內(nèi)存頁面通過網(wǎng)絡傳輸?shù)侥康闹鳈C，在完成所有的頁面遷移后，在目的主機恢復虛擬機在暫停前的運行狀態(tài)[15]。

后拷貝遷移：文獻[16-18]提到了后拷貝遷移算法，其主要流程：首先在兩端主機之間同步支持虛擬機基本運行的最小工作集，將內(nèi)存的同步過程推遲到虛擬機在目的主機上恢復運行之后，然后目的主機接收到這個最小工作集，并立即恢復虛擬機運行，這時由于虛擬機內(nèi)存數(shù)據(jù)在之前沒有傳輸?shù)侥康闹鳈C，需要通過按需取頁的方式從源主機上同步虛擬機內(nèi)存頁面。

預拷貝遷移：文獻[19-20]提出預拷貝遷移算法的核心思想是迭代傳輸內(nèi)存頁面。其內(nèi)存?zhèn)鬏斨饕譃?個階段：首先將源主機上虛擬機所有的內(nèi)存頁面全部標記為臟頁面并傳輸?shù)侥康闹鳈C，在這個遷移過程中，虛擬機仍保持不間斷正常的運行，接下來對上一輪復制傳輸過程中被修改且本輪到目前為止沒有被修改的內(nèi)存頁面進行迭代復制傳輸，每一次迭代傳輸后都要判斷是否滿足停機拷貝條件，如果不滿足則繼續(xù)進行迭代復制傳輸，如果滿足停機拷貝條件，源端上虛擬機被停止運行，并將剩余的內(nèi)存臟頁面復制傳輸?shù)侥康闹鳈C。預拷貝遷移停機條件是經(jīng)多輪復制傳輸后內(nèi)存臟頁面總量收斂到預先規(guī)定的最少剩余臟頁面。

3 基站協(xié)議棧遷移實驗

在超級基站實驗平臺搭建了基于KVM虛擬化的虛擬基站遷移平臺，分別進行基于靜態(tài)遷移、后拷貝遷移、預拷貝遷移情況下基站協(xié)議棧遷移實驗。

3.1 實驗環(huán)境

實驗在安裝了Qemu的Ubantu14.04系統(tǒng)上進行，共有3臺超級基站硬件平臺，具體軟硬件配置如表1所示。

表1 超級基站硬件平臺軟硬件配置

名稱配置信息硬件CPU：Intel?CoreTMi7-3612QE2．1GHz內(nèi)存：8GBDDR31600MHz軟件操作系統(tǒng)：64位Ubutnu14．04網(wǎng)絡環(huán)境網(wǎng)絡帶寬：1000Mb/s

其中PHY1、PHY2分別作為虛擬機遷移的源主機和目的主機，同時PHY3提供NFS服務，作為虛擬機鏡像文件的共享存儲，在源端PHY1創(chuàng)建了虛擬機VM，在其上運行由中科院計算所無線中心開發(fā)的面向超級基站的LTE協(xié)議棧軟件，虛擬機相應配置如表2所示。

表2 虛擬機VM軟硬件配置

名稱配置信息硬件CPU：4VCPU內(nèi)存：512M操作系統(tǒng)64位Ubutnu14．04服務器

為分析超級基站協(xié)議棧業(yè)務遷移的特點，進行4種場景實驗：

① 虛擬機運行協(xié)議棧軟件，協(xié)議棧不處理任何業(yè)務，模擬空載；

② 虛擬機運行協(xié)議棧軟件，通過iperf向協(xié)議棧發(fā)送音頻流的數(shù)據(jù)，模擬終端的音頻業(yè)務；

③ 虛擬機運行協(xié)議棧軟件，通過iperf向協(xié)議棧發(fā)送視頻流的數(shù)據(jù)，模擬終端的視頻業(yè)務；

④ 虛擬機運行協(xié)議棧軟件，通過iperf向協(xié)議棧發(fā)送UDP數(shù)據(jù)報，模擬終端的下載數(shù)據(jù)任務。

在實驗中，通過計算資源管控模塊發(fā)動遷移，將虛擬基站從源主機節(jié)點遷移到目的主機所用的時間定義為總遷移時間，在遷移過程中，造成基站協(xié)議棧中斷業(yè)務處理的時間定義為停機時間，由基站協(xié)議棧軟件日志測定。

3.2 基于靜態(tài)遷移算法

基于靜態(tài)遷移的協(xié)議棧遷移實驗數(shù)據(jù)如表3所示。

表3 基于靜態(tài)遷移的基站協(xié)議棧遷移實驗數(shù)據(jù)

實驗類型總遷移時間/ms停機時間/ms空載47634723音頻流52335211視頻流56495431UDP數(shù)據(jù)報64236367

通過這組實驗測量采用靜態(tài)遷移對基站協(xié)議棧業(yè)務遷移的影響，從表3可以看出，基站協(xié)議棧進行4種業(yè)務處理時遷移，其總遷移時間與停機相差不大，在停機時間內(nèi)，基站協(xié)議棧無法處理任何業(yè)務，這對于用戶來說是無法接受的，顯然靜態(tài)遷移算法難以滿足基站協(xié)議棧遷移要求。

3.3 基于后拷貝遷移算法

基于后拷貝的協(xié)議棧遷移實驗數(shù)據(jù)如表4所示。

表4 基于后拷貝的基站協(xié)議棧遷移實驗數(shù)據(jù)

實驗類型總遷移時間/ms停機時間/ms空載77907787音頻流1102511023視頻流1436014356UDP數(shù)據(jù)報1789017886

當前實驗采用后拷貝遷移算法，基站協(xié)議棧處理空載、音頻流、視頻流和UDP數(shù)據(jù)報業(yè)務時，在遷移未完成期間，基站協(xié)議棧需要頻繁的從源端獲取內(nèi)存頁面，由于后拷貝遷移算法是基于按需取頁機制，基站協(xié)議棧不能總是及時的獲取相關頁面，造成基站協(xié)議?？倳r間過大。從表4還可以看出，基站協(xié)議棧總遷移時間與停機時間僅差3 ms左右，這是后拷貝算法首先傳輸?shù)氖菫橹С痔摂M機及基站協(xié)議?；具\行的最小工作集，這個最小工作集比較小且相對固定，但由于基站協(xié)議棧維持較多的定時器，且協(xié)議棧處理數(shù)據(jù)有1 ms調(diào)度周期的要求，后續(xù)從源端取頁引發(fā)的缺頁中斷造成了基站協(xié)議棧反復的中斷，從基站協(xié)議棧日志里看出存在大量的丟包現(xiàn)象，顯然后拷貝遷移算法并不符合基站協(xié)議棧遷移需求。

3.4 基于預拷貝遷移算法

基于預拷貝的協(xié)議棧遷移實驗數(shù)據(jù)如表5所示。

表5 基于預拷貝遷移協(xié)議棧遷移實驗數(shù)據(jù)

實驗類型總遷移時間/ms停機時間/ms空載56084音頻流577110視頻流582724UDP數(shù)據(jù)報654967

從表5可以看出，基站協(xié)議棧在處理空載、音頻流、視頻流和UDP數(shù)據(jù)報等不同業(yè)務時，其總遷移時間、停機時間也相應增加，這是因為協(xié)議棧處理空載、音頻流、視頻流和UDP數(shù)據(jù)報時負載是逐漸上升的，在協(xié)議棧處理數(shù)據(jù)量增大時，需要對內(nèi)存進行頻繁讀寫操作，顯然隨著內(nèi)存讀寫操作增加，源主機將虛擬機的所有內(nèi)存頁面復制傳送到目的主機的數(shù)據(jù)量也相應增大，即增大了遷移數(shù)據(jù)傳輸量，由于遷移數(shù)據(jù)傳輸量和總遷移時間成正比例關系，故總遷移時間也相應增大。此外，預拷貝停機時間主要以數(shù)據(jù)傳輸時間為主，而數(shù)據(jù)包括兩部分：剩余的內(nèi)存臟頁以及CPU、外設狀態(tài)。CPU、外設狀態(tài)是某些寄存器的信息，數(shù)據(jù)量極少，因此剩余內(nèi)存臟頁將對停機時間起決定性作用，當協(xié)議棧處理數(shù)據(jù)量增大時，需對內(nèi)存進行頻繁的讀寫操作，顯然這會使得剩余內(nèi)存臟頁也相應增加。

3.5 實驗結(jié)果分析

基站協(xié)議棧遷移過程中，總遷移時間與停機時間不能過長，需要以LTE的1 ms的調(diào)度時延要求來看待；由于LTE數(shù)據(jù)處理的兩端都會維持較多的定時器來控制數(shù)據(jù)處理的時延，而一旦超過數(shù)據(jù)處理時延會引起控制交互，以及數(shù)據(jù)重傳，進而會造成鏈路中斷，則會直接體現(xiàn)影響用戶的使用。預拷貝遷移算法很好地平衡了二者的關系，在遷移過程穩(wěn)定性高且停機時間基本不影響基站協(xié)議棧正常處理業(yè)務。

4 結(jié)束語

本文重點研究了以超級基站為基礎的基站協(xié)議資源的動態(tài)管理。對超級基站協(xié)議計算資源采用KVM虛擬化技術(shù)，在此基礎上采用虛擬機遷移技術(shù)進行基站協(xié)議任務遷移。在超級基站硬件平臺進行了測試，驗證了預拷貝遷移算法的可用性和可靠性。仿真結(jié)果表明，基站協(xié)議棧在處理空載、音頻、視頻和下載任務時，遷移所用的總時間不大，且導致的停機時間并沒有嚴重影響基站協(xié)議棧業(yè)務處理。未來，將重點改善基站協(xié)議棧遷移的停機時間，如選擇更加高效的壓縮算法對內(nèi)存頁面進行壓縮，以盡可能減少停機時間對基站協(xié)議棧處理數(shù)據(jù)的影響。

[1] LIN Y，SHAO L，ZHU Z，et al.Wireless Network Cloud：Architecture and System Requirements[J].IBM Journal of Research & Development，2010，54(1)：4：1-4：12.

[2] WU J，ZHANG Z，HONG Y，et al.Cloud Radio Access Network (C-RAN)：a Primer[J].Network IEEE，2015，29(1)：35-41.

[3] LIU L，ZHANG R.Optimized Uplink Transmission in Multi-Antenna C-RAN With Spatial Compression and Forward[J].IEEE Transactions on Signal Processing，2015，63(19)：5083-5095.

[4] ZHAI G，TIAN L，ZHOU Y，et al.Real-time Guaranteed TDD Protocol Processing for Centralized Super Base Station Architecture[C]∥Wireless Communications and Networking Conference.IEEE，2015：989-994.

[5] QIAN M，WANG Y，ZHOU Y，et al.A Super Base Station Based Centralized Network Architecture for 5G Mobile Communication Systems[J].Digital Communications & Networks，2015，1(2)：152-159.

[6] 田霖，翟國偉，黃亮，等.基于集中式接入網(wǎng)架構(gòu)的異構(gòu)無線網(wǎng)絡資源管理技術(shù)研究[J].電信科學，2013，29(6)：25-31.

[7] LIU J，KATO N，MA J，et al.Device-to-Device Communication in LTE-Advanced Networks：A Survey[J].IEEE Communications Surveys & Tutorials，2017，17(4)：1923-1940.

[8] MA Z，ZHANG Y，ZHENG K，et al.Performance of 3GPP LTE-Advanced Networks with Type I Relay Nodes[C]∥International ICST Conference on Communications and Networking in China.IEEE Xplore，2010：1-5.

[9] GARCIA V,ZHOU Y,SHI J.Coordinated Multipoint Transmission in Dense Cellular Networks With User-Centric Adaptive Clustering[J]. Wireless Communications IEEE Transactions on,2014,13(8):4297-4308.

[10] 方義秋，唐道紅，葛君偉.云環(huán)境下基于虛擬機動態(tài)遷移的調(diào)度策略研究[J].微電子學與計算機，2012，29(4)：45-48.

[11] LIU L,ZHOU Y,GARCIA V,et al.Load Aware Joint CoMP Clustering and Inter-cell Resource Scheduling in Heterogeneous Ultra Dense Cellular Networks[J].IEEE Transactions on Vehicular Technology,2017,PP(99):1-1.

[12] ZHOU Y,LIU H,PAN Z,et al.Two-Stage Cooperative Multicast Transmission with Optimized Power Consumption and Guaranteed Coverage[J]. IEEE Journal on Selected Areas in Communications,2014,32(2):274-284.

[13] ZHAI G W,TIAN L,ZHOU Y Q,et al.Load Diversity Based Optimal Processing Resource Allocation for Super Base Stations in Centralized Radio Access Networks[J].Science China Information Sciences,2014,57(4):1-12.

[14] LOMBARD P，DENNEULIN Y，VALENTIN O，et al.Improving the Performances of a Distributed NFS Implementation[J].Lecture Notes in Computer Science，2017，3019：405-412.

[15] 劉鵬程.云計算中虛擬機動態(tài)遷移的研究[D].上海：復旦大學，2009.

[16] JIN Hai，DENG Li，WU Song，et al.Live Virtual Machine Migration with Adaptive Memory Compression[C]∥Cluster Computing and Workshops.Wuhan，China：IEEE，2009：1-10.

[17] HINES M R，DESHPANDE U，GOPALAN K.Post-copy Live Migration of Virtual Machines[J].Acm Sigops Operating Systems Review，2009，43(3)：14-26.

[18] HIROFUCHI T，NAKADA H，ITOH S，et al.Reactive Consolidation of Virtual Machines Enabled by Postcopy Live Migration[C]∥International Workshop on Virtualization Technologies in Distributed Computing，2011：11-18.

[19] CLARK C，F(xiàn)RASER K，HAND S，et al.Live Migration of Virtual Machines[C]∥Symposium on Networked Systems Design and Implementation.DBLP，2005：273-286.

[20] WU T Y，GUIZANI N，HUANG J S.Live Migration Improvements by Related Dirty Memory Prediction in Cloud Computing[J].Journal of Network & Computer Applications，2017，90：83-89.