面向超級(jí)基站的PDCP層組件式設(shè)計(jì)與實(shí)現(xiàn)*

田永鏈 ，王鳳麗 ， 胡金龍 , ， 袁春經(jīng)

（1.重慶郵電大學(xué)通信與信息工程學(xué)院，重慶 400065；2.中國科學(xué)院計(jì)算技術(shù)研究所無線通信技術(shù)研究中心，北京 100190；3.移動(dòng)計(jì)算與新型終端北京市重點(diǎn)實(shí)驗(yàn)室，北京 100190）

0 引 言

隨著移動(dòng)通信技術(shù)的飛速發(fā)展，人們對(duì)移動(dòng)業(yè)務(wù)的需求日益增強(qiáng)，數(shù)據(jù)流量呈爆發(fā)式增長[1]。運(yùn)營商不得不通過增加基站數(shù)量，以滿足不斷增長的數(shù)據(jù)流量需求。然而，大量基站帶來的能源消耗問題、無線干擾問題變得日益嚴(yán)重，CAPEX/OPEX（資本支出/運(yùn)維支出）逐年增高。另外，傳統(tǒng)無線接入網(wǎng)的“垂直式”架構(gòu)，導(dǎo)致基站處理資源分配不均、利用率低、資源浪費(fèi)嚴(yán)重，無法應(yīng)對(duì)現(xiàn)代城市生活方式造成的網(wǎng)絡(luò)負(fù)載的“潮汐效應(yīng)”。為此，業(yè)界提出一種集中式接入網(wǎng)架構(gòu)，是一種行之有效的解決辦法，包括中國移動(dòng)的C-RAN（Centralized，Cooperative，Cloud RAN）[2]和中科院計(jì)算所提出的超級(jí)基站[3-5]。超級(jí)基站將軟硬件松耦合，將基站解耦為四層，包括射頻處理、基帶處理、協(xié)議處理和管理控制。將基站的軟/硬件資源進(jìn)行集中式部署形成大規(guī)模資源池，對(duì)基站資源進(jìn)行統(tǒng)計(jì)復(fù)用共享，實(shí)現(xiàn)資源按需動(dòng)態(tài)分配和部署。此外，超級(jí)基站的通信軟件設(shè)計(jì)不單單支持一種制式，而是能支持多種通信模式，具有多?？芍囟ㄖ乒δ?，即實(shí)現(xiàn)能夠根據(jù)網(wǎng)絡(luò)需求自組織、自生成相應(yīng)的協(xié)議軟件。為此，針對(duì)協(xié)議軟件的設(shè)計(jì)，提出了一種模塊化的設(shè)計(jì)方法。該方法不僅體現(xiàn)在協(xié)議軟件各層之間的解耦合，還包括層內(nèi)各功能模塊之間的解耦合，以此根據(jù)不同網(wǎng)絡(luò)需求，靈活配置和組合以兼容多種制式協(xié)議，并能夠?qū)崿F(xiàn)功能模塊的替換和制式間的切換。

PDCP層位于LTE協(xié)議棧層2的最高層，在控制面和用戶面都有相應(yīng)的協(xié)議處理功能，是超級(jí)基站協(xié)議棧的重要組成部分。本文將以PDCP層為例，研究超級(jí)基站的模塊化設(shè)計(jì)思想。傳統(tǒng)的PDCP層設(shè)計(jì)通常采用靜態(tài)架構(gòu)，每一種制式對(duì)應(yīng)其特有協(xié)議流程，能達(dá)到相應(yīng)功能和性能的要求。但是，它的業(yè)務(wù)處理流程固定，不能兼容多種制式，對(duì)制式改變和模塊替換的支持靈活度低，不能做到通過一種制式的PDCP層設(shè)計(jì)稍加變動(dòng)演變成支持其他制式的PDCP層，不滿足超級(jí)基站支持同一平臺(tái)兼容多制式的需求。

因此，本文針對(duì)PDCP現(xiàn)有設(shè)計(jì)的問題，結(jié)合基站協(xié)議棧多模共平臺(tái)的特點(diǎn)，提出了組件化的設(shè)計(jì)方案。主要貢獻(xiàn)：使PDCP層在滿足功能和性能需求的情況下，更注重靈活性，能夠根據(jù)不同網(wǎng)絡(luò)需求，自組織、自生成相應(yīng)的協(xié)議流程。本文的組織結(jié)構(gòu)如下：第1小節(jié)介紹PDCP層架構(gòu)，第2小節(jié)介紹PDCP組件化設(shè)計(jì)方案和實(shí)現(xiàn)，第3小節(jié)進(jìn)行仿真實(shí)驗(yàn)。仿真結(jié)果表明：本文提出的組件式設(shè)計(jì)方案，能支持功能組件的靈活替換、刪除和擴(kuò)展，自組織、自生成相應(yīng)協(xié)議流程，滿足超級(jí)基站多模共平臺(tái)的需求。

1 PDCP層架構(gòu)

PDCP位于LTE協(xié)議棧層2，其上層是RRC層和GTP-U，分別對(duì)應(yīng)控制面和用戶面，其下層為RLC層[6-7]。在基本操作方面，PDCP層的作用非常簡單。對(duì)于下行鏈路，只是將PDCP報(bào)頭添加到輸入數(shù)據(jù)并轉(zhuǎn)發(fā)到下層；對(duì)于上行鏈路，將PDCP報(bào)頭移除并轉(zhuǎn)發(fā)到相應(yīng)的上層。但是，如果啟用了完整性保護(hù)/驗(yàn)證、加密/解密、頭壓縮/解壓縮等各種附加功能，對(duì)于其控制面，PDCP需要對(duì)信令數(shù)據(jù)進(jìn)行完整性保護(hù)/驗(yàn)證、加/解密和PDCP序列號(hào)維護(hù)。對(duì)于用戶面，PDCP需要對(duì)IP數(shù)據(jù)包進(jìn)行頭壓縮/解壓縮、加/解密和PDCP序列號(hào)維護(hù)，則PDCP可能會(huì)非常繁忙。而5G支持雙鏈接（分離承載）增加了路由和重排序功能，PDCP層變得更加繁忙[8-9]，如圖1所示。

2 PDCP層設(shè)計(jì)與實(shí)現(xiàn)

2.1 PDCP層設(shè)計(jì)

PDCP的組件式設(shè)計(jì)方案，使各功能組件功能獨(dú)立，具有高封裝、低耦合性，即替換即用的特點(diǎn)。需要考慮以下四個(gè)問題。

2.1.1 組件劃分

組件劃分的目的是將整個(gè)PDCP層解耦和，為后續(xù)的操作奠定基礎(chǔ)。常見的劃分方式包括：以使用方式為單位劃分，包括靜態(tài)和動(dòng)態(tài)兩種方式；以層次結(jié)構(gòu)為單位劃分，每一層劃分為一個(gè)組件；以功能為單位進(jìn)行劃分等[10-11]。劃分時(shí)，應(yīng)充分分析其特點(diǎn)，因?yàn)槿绻M件劃分粒度太大，組件就越少，各組件間的相關(guān)性、耦合性就會(huì)增加，不利于各組件的替換、更新。如果組件劃分粒度過小，則組件會(huì)越多，組件管理也存在一定復(fù)雜性。在該部分設(shè)計(jì)中綜合分析LTE與5G PDCP層多模制式的協(xié)議流程的相同點(diǎn)和不同點(diǎn)，考慮組件劃分的粒度。通過分析以功能為單位進(jìn)行組件劃分，構(gòu)成支持不同協(xié)議流程的功能庫，具體內(nèi)容如下。

圖1 PDCP功能視圖

頭壓縮/解壓縮功能庫：負(fù)責(zé)實(shí)現(xiàn)相應(yīng)的IP頭壓縮和解壓縮功能。

加/解密功能庫：負(fù)責(zé)實(shí)現(xiàn)各加密和解密算法，對(duì)數(shù)據(jù)進(jìn)行加解密處理。

完整性保護(hù)/驗(yàn)證功能庫：負(fù)責(zé)實(shí)現(xiàn)各完整性保護(hù)和完整性驗(yàn)證算法，對(duì)數(shù)據(jù)進(jìn)行保護(hù)和驗(yàn)證處理。

加/去頭：負(fù)責(zé)構(gòu)成LTE和5G PDCP相應(yīng)PDU格式。路由：負(fù)責(zé)對(duì)雙連接技術(shù)的分離承載的路由。重排序：負(fù)責(zé)對(duì)雙連接技術(shù)接收路由數(shù)據(jù)后的重排序。

每個(gè)功能庫里還可具體根據(jù)有無此功能，或此功能涉及的不同算法分為不同的功能組件，具體包括有無頭壓縮/解壓縮組件、EEA0EEA1EEA2加解密組件、EIA0EIA1EIA2完整性保護(hù)/驗(yàn)證組件、加/去LTE 5G頭組件、有無路由組件和有無重排序組件。

2.1.2 庫方式

庫一般分兩種：靜態(tài)鏈接庫和動(dòng)態(tài)鏈接庫。兩者的區(qū)別在于，靜態(tài)鏈接庫對(duì)函數(shù)的鏈接是在編譯階段，即編譯時(shí)，編譯器會(huì)把用到的函數(shù)全部鏈接到一起編譯成可執(zhí)行文件，占用內(nèi)存大，且每次很小的改動(dòng)都會(huì)導(dǎo)致整個(gè)程序全量更新，要重新編譯整個(gè)工程。而動(dòng)態(tài)鏈接庫是在程序運(yùn)行時(shí)才將相應(yīng)的庫函數(shù)鏈接載入。在運(yùn)行時(shí)間上，動(dòng)態(tài)鏈接庫相比靜態(tài)鏈接庫慢，但隨著計(jì)算機(jī)的發(fā)展，差異已經(jīng)不明顯。動(dòng)態(tài)庫方式可以支持分離編譯，每次變動(dòng)只重新編譯其相應(yīng)的功能組件，靈活性好。本文結(jié)合組件式設(shè)計(jì)的特點(diǎn)，選用動(dòng)態(tài)庫方式對(duì)各功能函數(shù)進(jìn)行編譯生成可執(zhí)行文件，可以隨時(shí)添加、刪除、和擴(kuò)展庫文件，為支持不同制式的協(xié)議共平臺(tái)奠定基礎(chǔ)。

2.1.3 組件間通信方式

為了滿足靈活性，打破了原本PDCP層內(nèi)功能的耦合性，原本的通信方式不再存在，需要重新設(shè)計(jì)各組件間的通信方式。為此，通信方式變?yōu)椋焊鞴δ軒觳捎每偩€式的業(yè)務(wù)處理結(jié)構(gòu)，獨(dú)立鏈接到通信總線上，將整個(gè)協(xié)議流程串通；相同功能庫里的各組件間定義統(tǒng)一的接口，以支持功能組件的替換。各功能庫對(duì)外的接口是統(tǒng)一的，鏈接時(shí)只需要將該組件庫替換為此統(tǒng)一的對(duì)外鏈接庫，直觀且操作簡單。通信方式如圖2所示。

假設(shè)實(shí)現(xiàn)某協(xié)議流程需要A、B、C、D四個(gè)功能，每個(gè)功能還存在不同方式，那么上述通信方式可將其抽象表達(dá)為：

目標(biāo)：協(xié)議流程=A+B+C+D

約束條件：

（1）A、B、C、D統(tǒng)一連接到通信總線上。

圖2 通信方式

（2）A.1，A.2…B.1，B.2…C.1，C.2…D.1，D.2…屬于相同功能庫的各組件庫之間使用統(tǒng)一接口；不同功能庫的組件間不統(tǒng)一。

根據(jù)GDT（General Design Theory）理論，將協(xié)議流程和功能進(jìn)行映射。設(shè)超級(jí)基站有m個(gè)流程要求，令PR={PRa,PRb}T={PR1,PR2…,PRm}T。其中，PRa表示基本流程要求，PRb表示自定義流程要求。此m個(gè)流程需要n個(gè)功能，令FM={FMc,FMd}T={FM1,FM2…,FMn}T，記FMc為必選功能，F(xiàn)Md為可選功能，其數(shù)目分別有p、q個(gè)（p+q=n），從而定義本文設(shè)計(jì)的抽象數(shù)學(xué)模型如下：

其中，功能FM可以由不同算法實(shí)現(xiàn)，因此還可以有：

令A(yù)為協(xié)議功能配置參數(shù)。對(duì)于不同協(xié)議流程，配置其相應(yīng)功能參數(shù)。

具體實(shí)例如下：

其中，完整性保護(hù)還可表示為以下三種形式之一：

加密也同理。

2.1.4 組件擴(kuò)展支持多制式協(xié)議流程

要實(shí)現(xiàn)PDCP協(xié)議層對(duì)多制式協(xié)議流程的兼容，首先要求PDCP協(xié)議層能夠支持多種制式協(xié)議流程下規(guī)定的功能。要實(shí)現(xiàn)組件擴(kuò)展，只需要在原來組件的基礎(chǔ)上再進(jìn)行新組件的開發(fā)。組件的擴(kuò)展是支持多種制式流程的基礎(chǔ)。組件的劃分、動(dòng)態(tài)鏈接庫鏈接方式、總線式通信方式的設(shè)計(jì)以及組件的擴(kuò)展，為支持協(xié)議軟件能自定義和自生成奠定了基礎(chǔ)。通過原協(xié)議流程和新協(xié)議流程的比較，在進(jìn)行協(xié)議流程自定義前需要先對(duì)涉及的功能組件進(jìn)行自配置，將各個(gè)動(dòng)態(tài)庫在原協(xié)議流程的基礎(chǔ)上進(jìn)行選擇是否鏈接相應(yīng)擴(kuò)展組件，以支持多制式協(xié)議流程。

2.2 PDCP層實(shí)現(xiàn)

具體按以下步驟操作，驗(yàn)證PDCP層具備動(dòng)態(tài)添加、替換、刪除相應(yīng)功能組件，以支持多制式不同協(xié)議流程切換。預(yù)先將各統(tǒng)一功能庫寫入makefile；各功能庫、各功能組件庫路徑如果處于默認(rèn)庫搜索路徑之外，需要將當(dāng)前庫的路徑添加到庫的搜索路徑之中。切記當(dāng)庫變動(dòng)時(shí)，需要執(zhí)行/sbin/ldconfig -v命令，再一次重新將庫加入緩存。功能庫加載流程如圖3所示，具體替換某組件還需要進(jìn)一步通過讀取配置文件的配置。

步驟1：準(zhǔn)備好預(yù)先生成的頭壓縮/解壓縮功能組件庫libpdcpCompress.so、libpdcpDeCompress.so和無頭壓縮/解壓縮功能組件庫libpdcpNocompre.so、libpdcp NoDecompre.so，加/解密功能組件庫libeea0.so、libeea1.so、libeea2.so，完整性保護(hù)/驗(yàn)證功能組件庫libeia0.so、libeia1.so、libeia2.so，加 /去頭功能庫 libaddlteheader.so、libadd5gheader.so、libcutlteheader.so、libcut5gheader.so，路由功能組件庫librouter.so、libnorouter.so，重排序功能組件庫libreorder.so、libnoreorder.so；

圖3 功能庫加載流程

步驟2：系統(tǒng)加載頭壓縮/解壓縮功能庫為libpdcpRohc.so、libpdcpDeRohc.so，完整性保護(hù)/驗(yàn)證功能庫為libProtect.so、libVeriry.so，加/解密功能庫為libCiper.so、libDeciper.so，加/去頭功能庫為libAddHeader.so、libCutHeader.so，路由功能庫為libRouter.so，重排序功能庫為libReordering.so；

步驟3：讀取配置文件，系統(tǒng)會(huì)將步驟1的對(duì)應(yīng)功能組件庫拷貝給步驟2對(duì)應(yīng)的功能庫，待運(yùn)行程序，查看數(shù)據(jù)打印，以驗(yàn)證PDCP層可支持功能組件庫靈活替換。

3 實(shí)驗(yàn)結(jié)果

3.1 運(yùn)行環(huán)境

硬件平臺(tái)：Intel x86平臺(tái)；

軟件平臺(tái)：Linux CentOS6.2；

編譯環(huán)境：gcc。

為了驗(yàn)證本文設(shè)計(jì)方法可以實(shí)現(xiàn)功能庫靈活替換，實(shí)驗(yàn)使用開源網(wǎng)絡(luò)性能測(cè)試工具iperf，調(diào)用Linux下的虛擬網(wǎng)卡tun，自行封裝了IP數(shù)據(jù)包，添加了20字節(jié)IP頭，8字節(jié)UDP頭。發(fā)送端通過iperf模擬GTP-U/RRC→PDCP→RLC，接收端再通過模擬RLC→PDCP→GTP-U/RRC進(jìn)行測(cè)試。

3.2 運(yùn)行結(jié)果與分析

讀取配置文件一，功能庫libpdcpRohc.so、libCiper.so、libAddHeader.so、libCutHeader.so、libDeciper.so、libpdcpDeRohc.so會(huì)根據(jù)配置文件加載 libpdcpCompress.so、libeea1.so、libaddlteheader.so、libcutlteheader.so、lipdcpDeCompress.so組件庫。對(duì)數(shù)據(jù)包進(jìn)行頭壓縮和加密處理，再進(jìn)行解密和頭解壓縮處理，完成DRB數(shù)據(jù)處理流程。如圖4所示，其中⑤解密后數(shù)據(jù)與③頭壓縮后數(shù)據(jù)一致，⑥頭解壓縮后數(shù)據(jù)與②收到的數(shù)據(jù)包一致。

讀取配置文件二，功能庫libpdcpRohc.so、libCiper.so、libDeciper.so、libpdcpDeRohc.so會(huì) 根 據(jù)配置文件將原本的組件庫libpdcpCompress.so、libeea1.so、lipdcpDeCompress.so替 換 為 libpdcpNocompre.so、libeea2.so、libpdcpNoDecompre.so。增加libProtect.so、libVeriry.so功能庫為libeia1.so，而libaddlteheader.so、libcutlteheader.so組件庫保持不變，進(jìn)行加載并實(shí)現(xiàn)完整性保護(hù)和加密功能，完成SRB處理流程。如圖5所示，其中⑤解密后數(shù)據(jù)與③完整性保護(hù)后數(shù)據(jù)部分一致，⑥完整性驗(yàn)證成功后數(shù)據(jù)與②收到的數(shù)據(jù)一致。

圖4 DRB處理流程

圖5 SRB處理流程

圖4 、圖5證明了組件式設(shè)計(jì)方法其處理流程功能的正確性。對(duì)于它的性能，通過iperf模擬了不同速率的數(shù)據(jù)包，對(duì)組件式設(shè)計(jì)、非組件式設(shè)計(jì)以及組件式設(shè)計(jì)替換了功能組件后的性能進(jìn)行了對(duì)比，如圖6所示。

圖6 性能對(duì)比結(jié)果

由圖6仿真結(jié)果分析可知，組件式設(shè)計(jì)相對(duì)非組件式設(shè)計(jì)額外增加了約0.2 ms的時(shí)延代價(jià)，但最大不超過總時(shí)延3%，且隨著速率的增大，比值越小，實(shí)際工程中可以忽略其影響?？梢?，所提方法以較小的性能犧牲帶來了協(xié)議流程能自組織、自生成的靈活性，且仍能滿足PDCP層處理要求。

通過上述實(shí)驗(yàn)，證明本文組件式設(shè)計(jì)方法能在滿足功能和性能的基礎(chǔ)上，支持庫靈活替換，自組織、自生成相應(yīng)協(xié)議流程。

4 結(jié) 語

由于超級(jí)基站協(xié)議棧多模共平臺(tái)的需求，為實(shí)現(xiàn)能根據(jù)不同網(wǎng)絡(luò)需求，自組織、自生成相應(yīng)的協(xié)議流程。在PDCP層設(shè)計(jì)中，除了保證基本的功能和性能要求外，更注重靈活性，提出了組件式的設(shè)計(jì)方法。通過讀取配置文件，加載相應(yīng)功能組件庫，實(shí)現(xiàn)整個(gè)完整的協(xié)議流程。仿真結(jié)果表明，本文組件式設(shè)計(jì)方法能以較低的處理時(shí)延代價(jià)換來功能庫的靈活替換，以支持協(xié)議流程的自組織、自生成。未來，可以考慮如何在不停止當(dāng)前運(yùn)行程序的情況下，在運(yùn)行過程中進(jìn)行相應(yīng)庫的替換，以實(shí)現(xiàn)不同協(xié)議流程。