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

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

0 引 言

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

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

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

1 PDCP層架構(gòu)

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

2 PDCP層設計與實現(xiàn)

2.1 PDCP層設計

PDCP的組件式設計方案，使各功能組件功能獨立，具有高封裝、低耦合性，即替換即用的特點。需要考慮以下四個問題。

2.1.1 組件劃分

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

圖1 PDCP功能視圖

頭壓縮/解壓縮功能庫：負責實現(xiàn)相應的IP頭壓縮和解壓縮功能。

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

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

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

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

2.1.2 庫方式

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

2.1.3 組件間通信方式

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

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

目標：協(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é)議流程和功能進行映射。設超級基站有m個流程要求，令PR={PRa,PRb}T={PR1,PR2…,PRm}T。其中，PRa表示基本流程要求，PRb表示自定義流程要求。此m個流程需要n個功能，令FM={FMc,FMd}T={FM1,FM2…,FMn}T，記FMc為必選功能，F(xiàn)Md為可選功能，其數(shù)目分別有p、q個（p+q=n），從而定義本文設計的抽象數(shù)學模型如下：

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

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

具體實例如下：

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

加密也同理。

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

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

2.2 PDCP層實現(xiàn)

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

步驟1：準備好預先生成的頭壓縮/解壓縮功能組件庫libpdcpCompress.so、libpdcpDeCompress.so和無頭壓縮/解壓縮功能組件庫libpdcpNocompre.so、libpdcp NoDecompre.so，加/解密功能組件庫libeea0.so、libeea1.so、libeea2.so，完整性保護/驗證功能組件庫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，完整性保護/驗證功能庫為libProtect.so、libVeriry.so，加/解密功能庫為libCiper.so、libDeciper.so，加/去頭功能庫為libAddHeader.so、libCutHeader.so，路由功能庫為libRouter.so，重排序功能庫為libReordering.so；

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

3 實驗結(jié)果

3.1 運行環(huán)境

硬件平臺：Intel x86平臺；

軟件平臺：Linux CentOS6.2；

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

為了驗證本文設計方法可以實現(xiàn)功能庫靈活替換，實驗使用開源網(wǎng)絡性能測試工具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進行測試。

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

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

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

圖4 DRB處理流程

圖5 SRB處理流程

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

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

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

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

4 結(jié) 語

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