5G開源軟件平臺中LDPC加速的實現與優化

高震宇 趙靜雅 蘇晨 陳梅

摘要：為解決開源的軟件定義通信系統平臺OAI存在接口速度慢、功能模塊化不清晰、處理速度慢等問題。通過分析物理層LDPC編解碼的功能，找出目前OAI平臺的性能瓶頸。為提高整體性能，選擇采用GPU加速方法，替換性能較差模塊，最終通過實驗仿真結果分析，顯示出了方法的可行性和可靠性。

關鍵詞：5G;通用處理器;物理層;開源

中圖分類號：TP311? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）14-0031-03

1 引言

隨著第五代移動通信技術（5G）的商業化應用，基于5G的應用以及學術研究需求逐漸增大。由于系統龐大和專用設備昂貴，研究機構如果要建立一套完整的通信系統非常困難。近年來，隨著SDN、NFV等技術的成熟，科研機構可使用通用處理器（GPU）代替各種專用處理器，以建立小型的通信系統[1]。與此同時，大量的開源社區逐漸發展壯大，為實現5G通信系統的小型化提供了軟件支持。歐洲Eurecom組織發起建立了OpenAirInterface（OAI）項目，該平臺能夠提供3GPP蜂窩系統EPC和E-UTRAN協議的開源硬件和軟件平臺[2]，包括：LTE系統的從物理層到網絡協議層協議，以及R10標準版本的LTE接入側和核心網側的UE、eNB、MME、HSS、SGW和PGW等模塊[3]。OAI是3GPP堆棧的開源實現。它涵蓋3GPP棧的不同部分（eNodeB、UE、MME、HSS、S-GW、P-GW）。該軟件運行在通用計算平臺（例如因特爾/ARM）上，并與各種SDR平臺（EXMIMO、USRP、BladeRF、LimeSDR）連接。OAI目前為eNB/UE/EPC實現Rel 8/10棧。它運行在標準的ubuntu linux 14.04 LTS上，具有eNB/UE的低延遲內核。OAI需要支持（SSE3/SSE4）的因特爾處理器，但是支持AVX2是可選的。在與SDR平臺（USRP、BladeRF、EXMIMO和LimeSDR）接口的PC上安裝USB3/PCIe也是一項要求。該代碼使用Linux附帶的標準GNU工具鏈進行編譯。OAI也可以在模擬模式（OAISIM）下運行。用于部署運營商核心網絡的OAI軟件包，即增強包核心（Enhanced Packet core）或EPC，統稱為openairCN，而用于基站和終端的接入網軟件則以openair5G的名稱命名[4]。

2 LDPC模塊加速

LDPC碼由于可以達到更高的譯碼吞吐量和更低的譯碼時延，可以更好地適應高數據速率業務的傳輸，從而替代LTE的Turbo碼，被采納為5G NR數據的編碼方案[5]。

在OAI中，LDPC的實現主要分為三大板塊，分別為LDPC的編碼，LDPC的解碼和編解碼函數的調用。

LDPC編碼函數：

在OAI中，LDPC編碼函數的定義代碼如下所示：

1 int nrLDPC_encod（unsigned char **test_input，unsigned char **channel_input，

2 int Zc，int Kb，short block_length， short BG， encoder_implemparams_t *impp）

其中二級指針testinput指向編碼輸入數組。值得注意的是，在編碼函數看來，輸入數據中1比特代表1個信息位，即每比特代表輸入數據（0或1）;二級指針channel_input指向編碼輸出數組。此時輸出數據8比特表示1個信息位，即每字節代表輸出數據（0或1）;OAI中采用了QC-LDPC編碼方式，Zc、Kb以及BG均是QC-LDPC編碼矩陣所需的參數;block_length表示輸入碼塊長度;immp結構體用作編碼函數的指示。其定義的結構體代碼如下所示：

1? ? typedef struct {

2? ? ? ?int n_segments;

3? ? ? ?unsigned int macro_num;

4? ? ? ?unsigned char gen_code;

5? ? ? ?time_stats_t *tinput;

6? ? ? ?time_stats_t *tprep;

7? ? ? ?time_stats_t *tparity;

8? ? ? ?time_stats_t *toutput;

9? ? ? ?}encoder_implemparams_t;

總結而言，OAI提供了原始的編碼函數、AVX2優化后的編碼函數以及AVX2優化下最高8個碼塊一起編碼的編碼函數。immp結構體為編碼函數提供了碼塊數以及時間測量，以適應不同的編碼函數。

LDPC解碼函數：

在OAI中，LDPC解碼函數的定義代碼如下所示：

1 int32_t nrLDPC_decod（t_nrLDPC_dec_params* p_decParams， int8_t* p_llr，

2 int8_t* p_out， t_nrLDPC_procBuf* p_procBuf， t_nrLDPC_time_stats* p_pr3529DBB4-0592-409E-B621-2A611E9124B9

3 ofiler）

p_decParams結構體為解碼函數提供解碼所需的指示參數。其中BG指示了QC-LDPC解碼方式的矩陣塊，Z代表移位因子，R代表解碼率，numMaxIter代表最大迭代次數，而outMode則代表輸出數據的格式，OAI中支持三種格式的輸出，分別為32個比特每一個32位無符號輸出，1比特每8位符號輸出，一個LLR數值每8位符號輸出。p_llr與p_out則分別代表編碼輸入與編碼輸出，均是每字節代表每個信息位;p_procBuf是解碼函數所需的緩存空間結構體;p_profiler是為編碼函數所提供的時間狀態指示，用于指示各個步驟所耗費時間。

函數調用：

OAI中LDPC相關函數均是先編譯成動態鏈接庫（.so文件）的形式，再對庫進行調用。通過調用函數int load_nrLDPClib（void）實現對nrLDPC_decoder以及nrLDPC_encoder的調用。該函數需要提供loader_shlibfunc_t結構作為加載函數的接收對象，同時傳遞給最終編解碼函數的中間容器。在load_nrLDPClib函數中會調用load_module_shlib函數，實現對指定目錄下共享庫文件的加載以及函數加載。以LDPC解碼為例，其調用函數的過程代碼如下所示：

1 shlib_fdesc[0].fname = "nrLDPC_decod";

2 int ret=load_module_shlib（"ldpc"，shlib_fdesc，sizeof（shlib_fdesc）/sizeof（loa der

3 _shlibfunc_t），NULL）;

4 AssertFatal（ （ret >= 0），"Error loading ldpc decoder"）;

5? nrLDPC_decoder = （nrLDPC_decoderfunc_t）shlib_fdesc[0].fptr;

3 GPU加速

3.1 GPU加速原理

目前OAI仿真軟件功能的實現都是基于CPU的，整個程序運行在CPU上。而LDPC編解碼過程涉及大量數據的處理，并且其數據碼塊可以支持同時進行處理而不影響最終數據的正確性，正是基于這兩點的考慮，本文提出了利用GPU對LDPC編解碼進行加速的解決方案。

3.2 加速實現

本文采用了英偉達的Tesla V100顯卡，其算力能力評估分值高達7.0，可以滿足本文設想需要。除此之外，英特爾的各種軟件開發工具包也為本文GPU加速的實現提供了支持。在本文中需要用到的軟件開發工具包是指物理層組件，其能夠提供部分基于GPU的物理層實現。接下來所有的安裝操作均在Ubuntu18.04系統下進行的，首先需要對相關的依賴庫文件進行安裝，值得注意的是，因為DPDK組件需要在GCC特定版本的環境下進行編譯，需要滿足GCC的版本是8.5與7.5;CMake的版本需要在3.12以上。在安裝好庫文件依賴后，需要對英偉達的驅動和CUDA進行安裝。在安裝的軟件開發工具包中，許多組件都提供基于H5文件的測試。通過將數據按照規定的格式寫入H5測試向量文件中，供給加速組件讀寫測試，所以需要對HDF5庫進行安裝，最后在設置好環境變量之后，便可以對物理層軟件開發工具進行安裝了。

一個完整的CUDA程序包括以下步驟：1）設置顯卡設備（單GPU不用）;2）分配顯存空間;3）從內存拷貝數據到顯存;4）執行并行函數;5）從顯存拷回數據到內存;6）釋放顯存空間;7）設備重置（單GPU不用）。在LDPC的編解碼中也不例外。在英偉達的CUDA給出的物理層程序中，有LDPC編解碼的實現，但其實現的方法和OAI中不盡相同。首先，其定義了一個LDPC類ldpc_tv，其中設置了LDPC編解碼所需要的各種參數，例如編碼塊的數量、碼字的比特數、基準碼塊等;其次，還定義了各種獲取編解碼前后的數據的函數，以及一些其他輔助函數。

在LDPC編碼的示例程序中，首先需要獲取一個HDF5文件，文件中的數據即為待編碼數據，也可以通過類中的生成函數完成，但需要傳入基本圖樣的類型BG，偏移位置Z和分段數量C，根據3GPP的38.212協議生成每個代碼塊的比特數K，當偏移位置小于64時，填充比特數F，以及編碼后輸出序列長度N，值得注意的是，GPU中只支持32位的LDPC計算，故K和N必須要為32的倍數。然后將原有或生成的數據拷貝到指定位置，做好數據的準備工作。需要通過cuphyLDPCEncodeLaunchConfig完成編碼運行的參數配置工作，分配描述符并設置LDPC編碼工作，接下來，再通過make_unique_device申請特有的GPU設備，將指示符與GPU相關聯，最后，通過輸入相關參數，啟動cuphySetupLDPCEncode函數完成LDPC的編碼工作。在此過程中，可以通過CUDA特有的event_timer函數，對程序完成的時間進行統計。

在LDPC解碼的示例程序中，其為了驗證編解碼的正確性，采用了先生成數據再編碼數據、再通過信道加擾，接著解碼數據，最后將解碼數據與生成數據對比，計算誤比特率的方式，驗證了其編解碼的正確性。雖然這種既做裁判又做運動員的方式，有一定的不可靠性，但是若其編解碼中的一個函數正確，那么兩個函數的正確性就都得到了驗證。接下來，本文將目標轉到其示例程序的具體實現上。在得到經過加擾的數據后，第一步仍是獲取相關參數，但需要的參數更多，增加的參數有解碼率R和最大迭代次數numIterations等。隨后，根據輸入設置輸出格式，創建cuPHY上下文，并創建LDPC解碼器實例，分配工作區緩沖區，以供LDPC實現使用。接著，初始化LDPC解碼描述符結構，準備工作完成后，便可進行解碼工作。3529DBB4-0592-409E-B621-2A611E9124B9

從上面的描述可以看出，OAI中的LDPC編解碼和CUDA有很大不同，雖然編解碼的最終實現都采用了封裝好的函數，但其數據接口大相徑庭。所以需要對接口進行統一化編排。考慮到OAI程序的主體地位，數據格式的轉化都會在CUDA中的程序實現。除了數據接口的統一，還有外部文件的調用問題。OAI的代碼采用C語言，而CUDA采用的是C++，兩者并不相同，無法直接調用。在OAI中對外部程序的調用都是采用先尋找外部庫文件的位置和相應函數名，再將其賦給內部定義的一個空殼函數的方法，具體操作代碼如下所示。

1 char fname[] = "_Z15ldpc_encode_gpuPPhS0_iiii";

2 void *handle = dlopen（"/home/ubuntu/cuBB/build/cuPHY/examples/error_

3 correction/libgpuldpc.so"， RTLD_LAZY|RTLD_NODELETE|RTLD_GLOBA

4 L）;ldpc_encode_gpu = （gpuldpc_encode_t） dlsym（handle， fname）;

其中RTLD_LAZY：代表在dlopen返回前，對于動態庫中存在的未定義的變量（如外部變量extern，也可以是函數）不執行解析，就是不解析這個變量的地址。RTLD_NODELETE代表在dlclose（）期間不卸載庫，并且在以后使用dlopen（）重新加載庫時，不初始化庫中的靜態變量。RTLD_GLOBAL：代表使得庫中解析的定義變量在隨后其他鏈接庫中可以使用。因為此處為一個初始化定義，并且本文希望在初始化后一直保持使用相關函數的狀態，故采用如上參數。

本文先將CUDA中的相關程序采用-fPIC -shared -o libgpuldpc.so編譯命令，將所需文件編譯為動態鏈接庫，有時候函數被封裝進.so后名稱會變化，比如在前后加點字符，例如上面示例中的函數名_Z15ldpc_encode_gpuPPhS0_iiii在CUDA的程序中名稱為ldpc_encode_gpu。這時想查看生成的.so文件中的函數名稱只需運用nm命令即可查看。

值得注意的是，在正式運行編解碼程序前，都需要對進行GPU預熱，預熱的方式和編解碼相同，系統在每一次編解碼或者說預熱時消耗的時間都比較長，所用時間會達到秒這一數量級，故建議在整個OAI程序初始化時便對GPU進行預熱，利用其自帶數據完成一次編解碼，其中函數的各種定義和.so庫函數的引用不再贅述。如此便完成了整個LDPC函數的GPU加速。

4優化結果仿真分析

為了驗證本文論述的GPU對LDPC編解碼的正確性，本文在保證初始條件不變的情況下，用GPU代碼替換了CPU的代碼，并進行了實驗仿真，實驗仿真結果如圖2、圖3所示：

利用GPU加速后，從LDPC編碼的時間消耗與TBS的關系，可以看出當TBS較大時，LDPC編碼完成的時間皆在35微秒左右，而當TBS較小時其所用時間反而較長。可以看出相較于CPU，當數據量較大時GPU加速的效果明顯。

為了明確當TBS較小時，所用時間反而較長這種情況的原因，本文單獨對GPU的LDPC模塊進行了測試，實驗結果如圖4所示：

圖4是當BG=2時，碼塊長度與編碼消耗時間的關系圖（碼塊長度與TBS呈線性關系），經過數據查看可以發現，這些消耗時間較長的碼塊長度都是32的整倍數，聯系到上一章所描述的初始定義數據長度時必須是32的整倍數才能完成數據定義，故猜測這可能和GPU自身數據處理的方式相關。

5結論

開源項目OAI基本實現了5G NR中的物理層，但仍有很多功能未完善。本文通過仿真實驗，找出了系統瓶頸在于LDPC編解碼的時間過長，提出了一種基于GPU代替CPU完成編解碼功能的方案，即統一化了OAI與GPU的接口，實現了OAI對外部代碼的調用，完成了對OAI的優化。仿真實驗表明，該方案降低了系統處理數據的時間。

參考文獻：

[1] 王子凡，溫向明，陳亞文，等.面向5G無縫連接的云無線接入網系統及實現[J].北京郵電大學學報，2018，41（5）：143-148，158.

[2] Liu Y F，Olmos P M，Mitchell D GM.Generalized LDPC codes for ultra reliable low latency communication in 5G and beyond[J].IEEE Access，2018，6：72002-72014.

[3] Chen Y，Guo Z，Yang X Q，et al.Optimization of coverage in 5G self-organizing small cell networks[J].Mobile Networks and Applications，2018，23（6）：1502-1512.

[4] Salhab N，Langar R，Rahim R.5G network slices resource orchestration using Machine Learning techniques[J].Computer Networks，2021，188：107829.

[5] Chen Y，Liu Y，Zhao J Y，et al.Mobile edge cache strategy based on neural collaborative filtering[J].IEEE Access，2020，8：18475-18482.

收稿日期：2021-12-30

基金項目：北京電子科技職業學院科技一般項目（基金號：2021Z029-KXY）

作者簡介：高震宇（1969—），女，吉林省吉林市人，講師，學士，主要研究方向為電子信息工程技術、無線通信等。3529DBB4-0592-409E-B621-2A611E9124B9