軟件定義無(wú)線接入網(wǎng)絡(luò)的組件化研究

徐海東 王 江 易輝躍①

①(上海無(wú)線通信研究中心 上海 201899)

②(中國(guó)科學(xué)院上海微系統(tǒng)與信息技術(shù)研究所 上海 200050)

1 引言

傳統(tǒng)的無(wú)線接入網(wǎng)絡(luò)基于專用硬件進(jìn)行構(gòu)建，網(wǎng)絡(luò)硬件設(shè)備復(fù)雜，部署和維護(hù)困難，且不利于擴(kuò)展。為了解決這個(gè)問(wèn)題，基于軟件定義的各種接入網(wǎng)技術(shù)應(yīng)運(yùn)而生。比較著名的有中國(guó)移動(dòng)提出的基于實(shí)時(shí)云型基礎(chǔ)設(shè)施的無(wú)線接入網(wǎng)(Cloud-Radio Access Network, C-RAN)[1]，C-RAN的室內(nèi)基帶處理單元(Building Base band Unite, BBU)基帶池處理完全基于軟件無(wú)線電實(shí)現(xiàn)[2]。根據(jù)基帶運(yùn)行平臺(tái)的不同，可以將軟件定義接入網(wǎng)絡(luò)分為基于通用處理器平臺(tái)及基于DSP平臺(tái)兩類(lèi)。IBM提出的無(wú)線網(wǎng)絡(luò)云[3]屬于前者，中國(guó)科學(xué)院計(jì)算技術(shù)研究所提出的超級(jí)基站[4]屬于后者。近年還涌現(xiàn)出了很多基于通用處理器的無(wú)線接入網(wǎng)絡(luò)開(kāi)源軟件，以4G長(zhǎng)期演進(jìn)技術(shù) (Long-term Evolution, LTE)為例，有法國(guó)EURCOM組織的露天接口 (Open Air Interface, OAI)[5]和愛(ài)爾蘭SRS公司(Software Radio Systems limited)的srsLTE[6,7]。上海無(wú)線通信研究中心也曾經(jīng)在OAI開(kāi)源軟件的基礎(chǔ)上進(jìn)行過(guò)進(jìn)一步完善，實(shí)現(xiàn)了能夠支持?jǐn)?shù)十個(gè)商用終端接入，體積只有手掌大小的LTE全功能軟基站[8]。文獻(xiàn)[9]將軟件定義接入網(wǎng)絡(luò)應(yīng)用到車(chē)聯(lián)網(wǎng)中。

軟件定義網(wǎng)絡(luò)的靈活性很強(qiáng)，可以滿足各種客戶化的編排要求。但是軟件定義的系統(tǒng)也可以非常復(fù)雜，不易開(kāi)發(fā)與維護(hù)，這就背離了軟件定義網(wǎng)絡(luò)的初衷。于是虛擬化、切片化、組件化的概念應(yīng)運(yùn)而生，這其中，組件化是虛擬化和切片化的基礎(chǔ)，是軟件定義網(wǎng)絡(luò)發(fā)展的必然趨勢(shì)。進(jìn)入5G時(shí)代，隨著通信速率進(jìn)一步提高，物理層的處理壓力陡然加大，軟件定義網(wǎng)絡(luò)還面臨DSP或通用處理器的計(jì)算瓶頸，也迫切需要進(jìn)行組件化改造，以利于采用分布計(jì)算技術(shù)或者硬件加速技術(shù)。另一方面，由于5G需要滿足增強(qiáng)型移動(dòng)寬帶(enhanced Mobile BroadBand, eMBB)、海量機(jī)器類(lèi)通信(massive Machine Type Communications, mMTC)、超可靠及低時(shí)延通信(ultra-Reliable and Low-Latency Communications, uRLLC)等不同場(chǎng)景的應(yīng)用需求[10]，也需要對(duì)接入網(wǎng)進(jìn)一步分割，實(shí)現(xiàn)端到端的網(wǎng)絡(luò)切片，以達(dá)到網(wǎng)絡(luò)的靈活彈性。

本文首先分析了無(wú)線接入網(wǎng)絡(luò)架構(gòu)的現(xiàn)狀，接著分析了無(wú)線接入網(wǎng)絡(luò)組件化面臨的問(wèn)題，并提出了一種組件化架構(gòu)的無(wú)線接入網(wǎng)絡(luò)，此架構(gòu)由有源天線單元(Active Antenna Unit, AAU)、射頻單元(Radio Unit, RU)、分布單元(Distributed Unit,DU)、集中單元(Centralized Unit, CU)、集中控制單元(Centralized Control Unit, CCU)等5種基本通信單元組成，在此基礎(chǔ)上可以構(gòu)建易部署、可切片的軟件定義無(wú)線接入網(wǎng)絡(luò)。本文還實(shí)現(xiàn)了基于該架構(gòu)的試驗(yàn)原型，試驗(yàn)原型的測(cè)試結(jié)果表明，這種組件化方案在提供高度靈活性的同時(shí)，還能夠顯著提升軟件定義無(wú)線電接入網(wǎng)(Radio Access Network,RAN)的處理能力，有效降低通用公共無(wú)線接口(Common Public Radio Interface, CPRI)[11]流量。

2 無(wú)線接入網(wǎng)架構(gòu)現(xiàn)狀與組件化難點(diǎn)

從4G到5G，無(wú)線接入網(wǎng)的基站從eNodeB的BBU和遠(yuǎn)端射頻單元(Remote Radio Unit,RRU)兩級(jí)架構(gòu)演化為gNodeB的CU, DU, AAU 3級(jí)架構(gòu)[12]，網(wǎng)元變得更小、更多了，反映了無(wú)線接入網(wǎng)絡(luò)組件化的發(fā)展趨勢(shì)。然而，5G接入網(wǎng)架構(gòu)存在以下問(wèn)題，不利于采用軟件無(wú)線電方法實(shí)現(xiàn)：

(1) 集中式的CU存在時(shí)延問(wèn)題。5G的uRLLC場(chǎng)景，需要在1 ms的極短時(shí)間內(nèi)響應(yīng)，而集中式的CU傳輸路徑長(zhǎng)，時(shí)延難以達(dá)標(biāo)。

(2) DU的計(jì)算量大，且難以分割，不利于引入分布式計(jì)算或FPGA硬件加速引擎等機(jī)制。DU橫跨物理層、MAC層以及RLC層等多個(gè)協(xié)議層次，功能結(jié)構(gòu)復(fù)雜而龐大，處理時(shí)延要求高，分割難度大。

(3) CPRI接口流量巨大，對(duì)承載網(wǎng)是非常大的負(fù)擔(dān)。類(lèi)似C-RAN的集中式架構(gòu)都存在這個(gè)問(wèn)題。特別是在5G eMBB場(chǎng)景下，隨著空口帶寬和天線數(shù)量的增加，CPRI接口流量比4G LTE成倍增加。按照5G標(biāo)準(zhǔn)，空口帶寬1 GHz，天線數(shù)256情況下，CPRI接口流量將達(dá)到12800 Gbps[12]。

從以上分析不難看出，物理層的分割是接入網(wǎng)組件化的重點(diǎn)和難點(diǎn)所在。3GPP各方經(jīng)過(guò)長(zhǎng)期的研究和討論，在TR38.801協(xié)議文檔列舉了物理層分割的Option7.1, Option7.2和Option7.3等多種選項(xiàng)[12]。愛(ài)立信、華為、諾基亞等設(shè)備廠商在CPRI接口的基礎(chǔ)上推出了eCPRI(evolved CPRI)接口規(guī)范[13]，給出了ID, IID和IU等多種物理層切割選項(xiàng)，由各個(gè)廠商在實(shí)現(xiàn)eCPRI接口的時(shí)候選擇。然而，由于物理層的復(fù)雜性，無(wú)論是3GPP還是eCPRI規(guī)范都未能形成最終的標(biāo)準(zhǔn)，各個(gè)廠商的實(shí)現(xiàn)不盡一致。

同樣是從改造CPRI接口的缺點(diǎn)出發(fā)，中國(guó)移動(dòng)提出了下一代前傳接口(Next Generation Forward Interface, NGFI)方案，其思路是將切分后的傳輸流量與小區(qū)公共流量和天線端口解耦[14,15]，中國(guó)移動(dòng)還將NGFI方案與C-RAN架構(gòu)相結(jié)合，提出了基于CU-DU的C-RAN架構(gòu)[16]。在這個(gè)方案中，運(yùn)營(yíng)商有兩種選擇，其一是把DU與RRU放在一起，其二是把DU與CU放在一起。其缺點(diǎn)是，要么消耗CPRI接口流量，要么降低集中式網(wǎng)絡(luò)的運(yùn)營(yíng)優(yōu)勢(shì)，兩者不能兼得。這種情況在5G中尤為明顯，巨大的CPRI接口流量導(dǎo)致DU必須要與RRU部署在一起。而DU計(jì)算消耗要比CU高一個(gè)數(shù)量級(jí)，云資源池如果僅能集中CU的計(jì)算消耗，那么所占的比例是很小的，C-RAN的集中性優(yōu)勢(shì)將被削弱，與集中性優(yōu)勢(shì)相捆綁的能耗節(jié)省、運(yùn)維成本降低等好處將大為減少。

文獻(xiàn)[17-19]提出了在C-RAN接入網(wǎng)中共享基站的分布式緩存降低傳輸流量的方法，可以在一定程度上緩減傳輸壓力。但是這類(lèi)方法的效果取決于緩存的命中率，與實(shí)際網(wǎng)絡(luò)應(yīng)用場(chǎng)景相關(guān)性較大。

與5G接入網(wǎng)組件化架構(gòu)演進(jìn)困難重重、裹足不前情況不同的是，5G對(duì)核心網(wǎng)進(jìn)行了全面的重構(gòu)，徹底改變了過(guò)去幾代核心網(wǎng)以點(diǎn)到點(diǎn)的信令控制為主、各種業(yè)務(wù)緊密耦合的設(shè)備形態(tài)，變成了一種全微服務(wù)架構(gòu)的、完全組件化的系統(tǒng)[20,21]，非常值得接入網(wǎng)借鑒。

3 組件化的無(wú)線接入網(wǎng)協(xié)議處理架構(gòu)

為了更好地適應(yīng)軟件定義接入網(wǎng)絡(luò)切片化、虛擬容器化的趨勢(shì)，合理的組件化架構(gòu)應(yīng)該滿足以下要求：(1)組件的粒度應(yīng)該盡量小，符合微服務(wù)的特點(diǎn)，便于編排和調(diào)度。(2)組件間的消息流量應(yīng)該盡可能得低，減少拆分引起的額外處理消耗。(3)組件的功能應(yīng)該具有獨(dú)立性，與其他組件耦合性小，便于可編程FPGA實(shí)現(xiàn)硬件加速并替換，也便于使用分布式處理技術(shù)進(jìn)行負(fù)荷分擔(dān)。

圖1是本文的組件化接入網(wǎng)絡(luò)架構(gòu)。該架構(gòu)由CCU, CU, RU, DU和AAU等5種組件組成，其中CCU和RU是新增的組件。CCU是集中控制單元，根據(jù)功能又可以細(xì)分為移動(dòng)管理CCU、負(fù)載管理CCU、干擾協(xié)調(diào)CCU、切片管理CCU等。RU是射頻處理單元，負(fù)責(zé)物理層底層的處理。CU和DU依然保留，但是功能有一些調(diào)整。CU和DU還可以分裂為多個(gè)，以支持接入網(wǎng)切片。圖1中物理小區(qū)的CU和DU都分裂成了3個(gè)運(yùn)行在不同計(jì)算節(jié)點(diǎn)上的功能組件，對(duì)應(yīng)3個(gè)切片，可用于5G的3種應(yīng)用場(chǎng)景。通過(guò)將計(jì)算消耗負(fù)荷分擔(dān)到多個(gè)計(jì)算節(jié)點(diǎn)，軟件定義基站的整體處理能力將大大提升，更容易滿足5G的速率要求。

組件化方案將為接入網(wǎng)的切片化提供更為有效的途徑。目前5G網(wǎng)絡(luò)切片主要是核心網(wǎng)切片[22]，接入網(wǎng)切片不具備差異處理能力和完善的隔離機(jī)制[23,24]，各個(gè)設(shè)備廠商一般通過(guò)給予不同業(yè)務(wù)的DRB不同調(diào)度優(yōu)先級(jí)的方法來(lái)實(shí)現(xiàn)接入網(wǎng)切片功能，這是3G和4G早就有的業(yè)務(wù)QoS技術(shù)，與完全隔離、高度差異化的網(wǎng)絡(luò)切片還有差距。組件化的切片將提供更好的隔離性，并且更容易實(shí)現(xiàn)不同業(yè)務(wù)切片的差異性。

3.1 CU與DU切分方案分析

從3GPP發(fā)布的TR38.801文檔可以看到，3GPP提出了Option1到Option8共8種CU和DU拆分選項(xiàng)，最后選擇了Option2作為5G標(biāo)準(zhǔn)[12]。按照這個(gè)方案，CU與DU在PDCP層與RLC層之間進(jìn)行分割。如圖2所示，CU包括RRC和PDCP的功能，DU包括RLC，MAC以及PHY的功能。

3GPP將RLC協(xié)議實(shí)體放在DU中主要考慮的是時(shí)延因素。因?yàn)樵?GPP 5G的網(wǎng)絡(luò)架構(gòu)中，CU是一個(gè)集中式節(jié)點(diǎn)，對(duì)上通過(guò)NG接口與核心網(wǎng)(NGC)相連接，對(duì)下控制和協(xié)調(diào)多個(gè)小區(qū)。如果將RLC放在CU，那么對(duì)于低時(shí)延業(yè)務(wù)，CU與DU之間的傳輸時(shí)間就會(huì)影響時(shí)延目標(biāo)的達(dá)成。

然而，采用Option2選項(xiàng)之后，RLC協(xié)議實(shí)體劃入DU，使得DU的實(shí)現(xiàn)過(guò)于復(fù)雜。按照傳統(tǒng)的做法，物理層一般會(huì)采用FPGA進(jìn)行加速處理，然而RLC協(xié)議的加入，極大地增加了工程實(shí)現(xiàn)難度。

如前文所述，在本文的方案中，負(fù)載管理、切換管理、干擾協(xié)調(diào)等控制和管理功能由專門(mén)的CCU組件負(fù)責(zé)，這樣，CU不再必須是集中節(jié)點(diǎn)，可以與單個(gè)DU共點(diǎn)部署，時(shí)延就不再是問(wèn)題。因此，本文的方案將CU與DU的切分點(diǎn)從Option2下移到Option4，也就是說(shuō)將RLC協(xié)議層從DU移到CU，這樣DU的實(shí)現(xiàn)更為簡(jiǎn)潔，更容易用可編程FPGA器件實(shí)現(xiàn)并進(jìn)行組件化替換。此外，RLC協(xié)議的AM和UM模式有很好的消息包順序保證機(jī)制，可以解決CU和DU之間數(shù)據(jù)包的亂序問(wèn)題。從消息流量來(lái)說(shuō)，選項(xiàng)Option4與Option2差別不大，僅增加了RLC協(xié)議幀頭的開(kāi)銷(xiāo)。

圖1 組件化、可切片的分布式軟基站架構(gòu)

3.2 DU與RU切分方案分析

DU與RU的切分在物理層中進(jìn)行，是組件化的重點(diǎn)和難點(diǎn)所在。3GPP在TR38.801文檔中討論了物理層中間拆分的可選方案Option7。對(duì)于上行業(yè)務(wù)的物理層切分，3GPP在TR38.801文檔的Option7方案中給出了Option7.1和Option7.2兩個(gè)子選項(xiàng)。本文另外給出了Option7.1a和Option7.3選項(xiàng)，作為對(duì)比分析方案進(jìn)行比選。對(duì)于下行流程的切分，Option7共給出了3個(gè)子選項(xiàng)：Option7.1,Option7.2和Option7.3。具體切分點(diǎn)的位置如圖3所示。

決定RU和DU拆分方案的重要因素是RU和DU之間的交互消息流量和時(shí)延。拆分點(diǎn)越低，流量越大，時(shí)延要求越高。表1為以單天線、正常循環(huán)前綴的LTE FDD為例所做的各拆分方案流量分析。

表1中，除了Option8選項(xiàng)為RU與RRU的邊界，不作考慮之外，其他都是RU和DU切分的可選方案。

(1) RU與DU下行切分選項(xiàng)Option7.1, Option7.2和Option7.3的比較。

Option7.1選項(xiàng)位于映射模塊與iFFT模塊之間，傳輸?shù)氖侨コh(huán)前綴的頻域數(shù)據(jù)。

Option7.2位于預(yù)編碼與層映射之間，對(duì)于下行來(lái)說(shuō)傳輸?shù)臑楦餍诺勒{(diào)制、預(yù)編碼之后的數(shù)據(jù)，應(yīng)用層滿負(fù)荷情況下流量比Option7.1略小，主要是因?yàn)橄滦袇⒖夹盘?hào)、下行同步信號(hào)、PCFICH、PHICH、PBCH等不包括Option7.2在內(nèi)，這些是在信道映射階段產(chǎn)生的。Option7.2接口流量的計(jì)算如式(1)

其中，第1項(xiàng)為PDCCH信道的流量，第2項(xiàng)為PDSCH信道公共信息的流量，第3項(xiàng)為PDSCH信道用戶流量。其中， αpdcch, αpdsch_com和αpdsch_user,i分別為各項(xiàng)對(duì)應(yīng)的調(diào)制系數(shù)； D Lpdcch, DLpdsch_com和D分別為各項(xiàng)對(duì)應(yīng)的調(diào)制前流量。D為用戶的調(diào)制前流量，它和用戶應(yīng)用層凈流量關(guān)系如式(2)

圖2 CU和DU拆分選項(xiàng)

圖3 DU和RU拆分選項(xiàng)

表1 拆分方案流量分析，以LTE單天線、正常循環(huán)前綴為例

其中， γencode_dl_user,i為用戶i的信道編碼碼率，在LTE中是指Turbo編碼的碼率，在5G中是指LDPC編碼的碼率； DLapp,i為用戶i 的應(yīng)用層流量；Cupper,i為用戶上層協(xié)議的開(kāi)銷(xiāo)。調(diào)制系數(shù)是指調(diào)制后與調(diào)制前的位寬比。

Option7.3位于下行編碼、擾碼與調(diào)制之間，相當(dāng)于eCPRI規(guī)范的ID選項(xiàng)，其流量為編碼、擾碼模塊處理后的比特?cái)?shù)據(jù)，其計(jì)算公式為

對(duì)比式(1)和式(3)可知，Option7.3接口的流量比Option7.2明顯下降，是較佳的切分方案。

對(duì)于多個(gè)DU按照載頻進(jìn)行切分的多切片場(chǎng)景，Option7.3方案也是可行的。此時(shí)，RU同時(shí)接收多個(gè)DU切片的數(shù)據(jù)，將各切片的PDSCH信道數(shù)據(jù)調(diào)制、加擾后映射到PDSCH信道對(duì)應(yīng)的載頻，將各切片的DCI數(shù)據(jù)調(diào)制并綜合后映射到PDCCH信道對(duì)應(yīng)的載頻。

(2) RU與DU上行切分選項(xiàng)Option7.1a, Option7.2和Option7.3的比較。

Option7.1a選項(xiàng)位于解映射與信道估計(jì)之間，相當(dāng)于eCPRI規(guī)范的IU選項(xiàng)，是解映射模塊處理完之后傳遞給信道估計(jì)模塊的流量。在滿負(fù)荷情況下，Option7.1a選項(xiàng)的流量與選項(xiàng)Option7.1相等。在沒(méi)有滿負(fù)荷情況下，計(jì)算流量的方法如式(4)

其中，第1項(xiàng)U Lprach為PRACH信道流量；第2項(xiàng)為PUCCH信道流量，Cpucch_rs為 參考信號(hào)開(kāi)銷(xiāo)，ULpucch為加參考信號(hào)前的流量；最后一項(xiàng)為PUSCH信道流量，其中 Cpusch_rs為參考信號(hào)開(kāi)銷(xiāo)，U Lpusch為加參考信號(hào)前的流量，該流量可根據(jù)用戶應(yīng)用層的流量按式(5)計(jì)算

其中， ULapp,i為用戶i應(yīng)用層上行消息的凈流量，αpusch_user,i為 用戶i信道調(diào)制的調(diào)制比，γencode_ul_user,i為用戶i上行信道編碼的碼率，Culsch,i為用戶i ULSCH傳輸信道的開(kāi)銷(xiāo)，Cupper,i為i用戶上層協(xié)議的開(kāi)銷(xiāo)。

Option7.2選項(xiàng)位于信道估計(jì)與均衡之間，是信道估計(jì)模塊處理完之后傳遞給信道均衡模塊的流量。信道估計(jì)會(huì)對(duì)PUSCH信道中參考信號(hào)進(jìn)行估計(jì)，并根據(jù)插值算法為每一個(gè)載頻產(chǎn)生一個(gè)信道估計(jì)值，作為信道均衡模塊的輸入信息。此時(shí)需要將每一個(gè)載頻的信道估計(jì)值連同未作均衡的數(shù)據(jù)一起從RU發(fā)送到DU，流量需要增加近1倍，其流量計(jì)算公式為

Option7.3選項(xiàng)位于調(diào)制與譯碼之間，是調(diào)制模塊處理完之后傳遞給譯碼模塊的流量。LTE的Turbo譯碼一般采用最大后驗(yàn)概率(MAximum Posteriori, MAP)算法[25]，或?qū)ζ浜?jiǎn)化的Max-Log-Map算法，都是軟判決譯碼算法，對(duì)軟信息寬度有要求，軟信息寬度越大，譯碼效果越好。為此，需要將調(diào)制之后的信息完整地送入Turbo譯碼器，由此可知Option7.3選項(xiàng)上行流量的計(jì)算公式為

比較式(4)和式(7)可知，Option7.3選項(xiàng)的流量相當(dāng)于Option7.1a的流量除去上行參考信號(hào)開(kāi)銷(xiāo)，流量降低并不是很明顯。5G數(shù)據(jù)信道采用LDPC編碼，常用的譯碼算法是最小和算法[26]，也是一種軟判決譯碼算法，面臨的問(wèn)題與LTE是一樣的。

把RU-DU切分點(diǎn)放在Option7.1a的一個(gè)重要好處是RU在這個(gè)點(diǎn)可以很容易地實(shí)施切片數(shù)據(jù)分離，RU在信道解映射的同時(shí)順便把上行數(shù)據(jù)按載頻分配給各個(gè)切片對(duì)應(yīng)的DU。另外，Option7.1a把處理開(kāi)銷(xiāo)非常大的譯碼和均衡模塊從RU分解出去，對(duì)分布式軟基站整體處理速率的提升將較為有利。

綜上，本文選擇Option7.1a作為DU和RU上行的拆分方案，選用Option7.3作為下行的拆分方案。

4 試驗(yàn)原型實(shí)現(xiàn)與性能測(cè)試

4.1 組件化無(wú)線接入網(wǎng)原型設(shè)計(jì)方案

為了驗(yàn)證組件化的無(wú)線接入網(wǎng)絡(luò)的可行性，本文開(kāi)發(fā)了組件化的原型系統(tǒng)，并重點(diǎn)對(duì)組件化之后CU, DU, RU等組件的處理開(kāi)銷(xiāo)和組件間流量進(jìn)行了測(cè)試。組件化的基站原型以LTE軟件定義基站為基礎(chǔ)，將其在功能上拆分為RU, DU和CU等3個(gè)組件進(jìn)行實(shí)現(xiàn)。圖4為本文的原型基站模塊圖。

從圖4可見(jiàn)，RU負(fù)責(zé)物理層底層處理，上行包括時(shí)域到頻域的變換、解映射等功能模塊，下行包括下行信道調(diào)制、信道映射和OFDM時(shí)域信號(hào)生成等功能模塊。DU負(fù)責(zé)物理層高層和MAC層協(xié)議處理，上行包括信道估計(jì)、信道均衡、解調(diào)、解擾、譯碼和MAC上行處理等功能模塊，下行包括MAC調(diào)度、MAC下行處理、PDSCH信道編碼、DCI調(diào)度信息生成、PHICH信息生成等功能模塊。CU負(fù)責(zé)高層協(xié)議處理，包括RLC, PDCP和RRC等協(xié)議處理模塊。

4.2 組件化試驗(yàn)原型性能測(cè)試

本實(shí)驗(yàn)所用的測(cè)試機(jī)器是Z230工作站，處理器為至強(qiáng)E3 1226v3型號(hào)的4核CPU，內(nèi)存容量為32 GB。終端與核心網(wǎng)同樣采用軟件定義模塊進(jìn)行模擬，操作系統(tǒng)是Ubuntu14.04.03 LTS版本，并加載low-latency 3.19低時(shí)延內(nèi)核。本文的試驗(yàn)原型使用的是LTE FDD模式，空口帶寬為5 MHz。軟基站上行支持16QAM，最大速率5 Mbps，下行支持64QAM，最大速率14 Mbps。

4.2.1 組件間流量測(cè)試

圖5是上、下行數(shù)傳時(shí)CU, DU, RU 3大組件間的數(shù)據(jù)流量變化情況。圖5(a)為上行數(shù)傳1 Mbps到5 Mbps時(shí)的組件間流量，圖5(b)為下行數(shù)傳從1 Mbps到14 Mbps時(shí)的組件間流量。

從圖5(a)可知，在上行數(shù)傳時(shí)，隨著上行速率從1 Mbps上升到5 Mbps, DU～CU的流量從1.2 Mbps上升到5.9 Mbps，這個(gè)數(shù)值相當(dāng)于在應(yīng)用層流量的基礎(chǔ)上增加約20%的各協(xié)議層開(kāi)銷(xiāo)。隨著上行傳輸速率的加大，RU～DU的流量逐步增加，在上行速率為5 Mbps時(shí)，RU～DU的流量為114 Mbps。而傳統(tǒng) CPRI接口下行流量是固定的，5 MHz空口帶寬情況下，不管有沒(méi)有上行業(yè)務(wù)，流量都是固定的245.76 Mbps。這表明，通過(guò)組件化方案可以動(dòng)態(tài)地控制上行流量，在沒(méi)有上行業(yè)務(wù)或上行業(yè)務(wù)量較小時(shí)流量比較少。

從圖5(b)可見(jiàn)，在下行數(shù)傳時(shí)，CU～DU,DU～RU的流量與應(yīng)用層的數(shù)傳流量大致相當(dāng)，與前面理論計(jì)算相吻合。其中，CU～DU由于處在更高的協(xié)議層次，流量比DU～RU稍小。在下行14 Mbps時(shí)，DU～RU的流量只有20.1 Mbps，相對(duì)于傳統(tǒng)的CPRI接口流量245.76 Mbps，壓縮了10倍以上。

從圖5(a)和圖5(b)都可以看到，RU～DU的流量即使在上行數(shù)傳速率為0時(shí)，也保持在14.7 MB，這是PUCCH信道、PRACH信道產(chǎn)生的與上行速率大小無(wú)關(guān)的固定流量，可以由式(4)右側(cè)的前兩項(xiàng)確定。

圖4 組件化的原型基站模塊圖

圖5 CU, DU和RU組件間流量測(cè)試結(jié)果

4.2.2 組件化與非組件化對(duì)比測(cè)試

表2為組件化與非組件化兩種系統(tǒng)的對(duì)比測(cè)試數(shù)據(jù)。從測(cè)試結(jié)果可以看到，時(shí)延相關(guān)的指標(biāo)兩種方案的差異不是很明顯，而內(nèi)存與CPU開(kāi)銷(xiāo)指標(biāo)差異較大。組件化方案內(nèi)存和CPU的開(kāi)銷(xiāo)有一定程度上升，這是由于組件間消息收發(fā)的處理需要額外內(nèi)存和CPU處理資源。

表2 組件化與非組件化對(duì)比測(cè)試結(jié)果

4.2.3 基于組件化的C-RAN架構(gòu)與基于CU-DU的C-RAN架構(gòu)的比較

接入網(wǎng)組件化之后，具有更為靈活多樣的組網(wǎng)實(shí)施方式，將其與C-RAN架構(gòu)相結(jié)合便是可行的實(shí)施方案之一，這將為運(yùn)營(yíng)商提高更為豐富的組網(wǎng)選擇。表3是當(dāng)下行速率為10 Mbps時(shí)組件化的C-RAN方案與傳統(tǒng)CU-DU架構(gòu)的C-RAN方案的比較，相關(guān)數(shù)據(jù)基于前面測(cè)試數(shù)據(jù)推算而得。從表3可以看到，在非理想前傳條件時(shí)，采用DU部署在中心資源池的組件化方案相對(duì)于傳統(tǒng)CU-DU方案優(yōu)勢(shì)明顯，此時(shí)站址傳輸流量?jī)H是后者的1.35倍，而中心資源池的計(jì)算集中度卻是后者的35.60倍。這表明組件化方案在不顯著增加傳輸開(kāi)銷(xiāo)的情況下依然能夠保持C-RAN架構(gòu)的集中化優(yōu)勢(shì)，這將為C-RAN架構(gòu)在5G應(yīng)用場(chǎng)景中繼續(xù)發(fā)揮運(yùn)維簡(jiǎn)化、能耗降低等優(yōu)勢(shì)創(chuàng)造條件。

表3 組件化C-RAN方案與CU-DU C-RAN方案比較(以10 Mbps下行傳輸為例)

5 結(jié)束語(yǔ)

本文針對(duì)軟件定義方法實(shí)現(xiàn)5G接入網(wǎng)的問(wèn)題，提出了一種新的組件化方案，該方案是一種由CCU, CU, DU, RU和AAU等組件構(gòu)成的分布式軟基站架構(gòu)。本文通過(guò)對(duì)各種物理層切分選項(xiàng)的組件間流量進(jìn)行理論分析之后確定了切分方案，并按此方案實(shí)現(xiàn)了試驗(yàn)原型。軟件定義無(wú)線接入網(wǎng)的組件化架構(gòu)既有利于通過(guò)分布式計(jì)算技術(shù)或者硬件組件加速技術(shù)克服軟件定義接入網(wǎng)的計(jì)算能力瓶頸，又有利于降低CPRI接口流量，實(shí)現(xiàn)基于組件的RAN切片。從前面的比較也能看到，組件化方案與CRAN架構(gòu)相結(jié)合還能充分發(fā)揮C-RAN架構(gòu)集中度高的優(yōu)勢(shì)，在集中度與傳輸開(kāi)銷(xiāo)之間獲取平衡，降低接入網(wǎng)的運(yùn)維成本和能耗。