面向超級基站的PDCP層組件式設計與實現*

田永鏈 ，王鳳麗 ， 胡金龍 , ， 袁春經

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

0 引 言

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

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

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

1 PDCP層架構

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

2 PDCP層設計與實現

2.1 PDCP層設計

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

2.1.1 組件劃分

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

圖1 PDCP功能視圖

頭壓縮/解壓縮功能庫：負責實現相應的IP頭壓縮和解壓縮功能。

加/解密功能庫：負責實現各加密和解密算法，對數據進行加解密處理。

完整性保護/驗證功能庫：負責實現各完整性保護和完整性驗證算法，對數據進行保護和驗證處理。

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

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

2.1.2 庫方式

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

2.1.3 組件間通信方式

為了滿足靈活性，打破了原本PDCP層內功能的耦合性，原本的通信方式不再存在，需要重新設計各組件間的通信方式。為此，通信方式變為：各功能庫采用總線式的業務處理結構，獨立鏈接到通信總線上，將整個協議流程串通；相同功能庫里的各組件間定義統一的接口，以支持功能組件的替換。各功能庫對外的接口是統一的，鏈接時只需要將該組件庫替換為此統一的對外鏈接庫，直觀且操作簡單。通信方式如圖2所示。

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

目標：協議流程=A+B+C+D

約束條件：

（1）A、B、C、D統一連接到通信總線上。

圖2 通信方式

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

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

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

令A為協議功能配置參數。對于不同協議流程，配置其相應功能參數。

具體實例如下：

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

加密也同理。

2.1.4 組件擴展支持多制式協議流程

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

2.2 PDCP層實現

具體按以下步驟操作，驗證PDCP層具備動態添加、替換、刪除相應功能組件，以支持多制式不同協議流程切換。預先將各統一功能庫寫入makefile；各功能庫、各功能組件庫路徑如果處于默認庫搜索路徑之外，需要將當前庫的路徑添加到庫的搜索路徑之中。切記當庫變動時，需要執行/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：系統加載頭壓縮/解壓縮功能庫為libpdcpRohc.so、libpdcpDeRohc.so，完整性保護/驗證功能庫為libProtect.so、libVeriry.so，加/解密功能庫為libCiper.so、libDeciper.so，加/去頭功能庫為libAddHeader.so、libCutHeader.so，路由功能庫為libRouter.so，重排序功能庫為libReordering.so；

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

3 實驗結果

3.1 運行環境

硬件平臺：Intel x86平臺；

軟件平臺：Linux CentOS6.2；

編譯環境：gcc。

為了驗證本文設計方法可以實現功能庫靈活替換，實驗使用開源網絡性能測試工具iperf，調用Linux下的虛擬網卡tun，自行封裝了IP數據包，添加了20字節IP頭，8字節UDP頭。發送端通過iperf模擬GTP-U/RRC→PDCP→RLC，接收端再通過模擬RLC→PDCP→GTP-U/RRC進行測試。

3.2 運行結果與分析

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

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

圖4 DRB處理流程

圖5 SRB處理流程

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

圖6 性能對比結果

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

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

4 結 語

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