TM5005GNR系統下行多載波聚合下系統時延優化設計

鄭旸

摘 ?要：該文圍繞解決TM500測試終端載波聚合下行吞吐率和系統時延問題，提出了使用多核多線程并行處理來優化系統時延的方案。通過對比分析方案前后的數據，確定了基于多核多線程并行處理的優點，針對上述方案的具體實現進行詳細論述。最后，通過測試儀表與基站聯調，證明了該測試方案的有效性和可行性。

關鍵詞：通信與信息系統;載波聚合;吞吐率測試;多核多線程

中圖分類號： TN929.5 ? ? ? ? ? ? 文獻標志碼：A

1 項目概況

5G NR基站測試儀表被用在5G NR基站的研發、生產、入網認證、維修等多個環節，測試儀表的成熟度和高效性對5G NR產業鏈的發展和產品研發起著重要的推動作用[1]。唯亞威公司生產的符合3GPP標準的TM500網絡測試儀被認為是無線網絡測試的事實標準，在5G研發生命周期的測試中被市場廣泛采用，并被應用于新服務推出前的網絡性能壓力測試。5G NR基于毫米波的多載波聚合技術可以給用戶提供超高速及短時延的服務，但這對基站及基站測試儀表性能都提出一個不小的課題。

2 多載波聚合技術原理

載波聚合（Carrier Aggregation，簡稱CA），通過將多個連續或非連續的載波（Component Carrier，簡稱CC）聚合成更大的帶寬，從而提高頻譜資源的利用率，提升上下行速率。下行N個小區載波聚合的最大吞吐率計算公式如公式（1）所示。

式中：J 表示聚合的載波個數，表示每個小區的層數，表示每個小區的最大調制方式，為調節因子，可以配置為1、0.8、0.75和0.4，Rmax為常數，值為 948/1024，為每個小區的最大帶寬，為每個小區的平均每子幀的OFDM符號數，參數在FR2下行時配置為0.18。以FR2 120 kHz子載波間隔的8載波為例，當每小區為2層，PDSCH調制方式為256-QAM，小區帶寬為100 M時，下行最大速率可達8.6 Gbps。

3 5G NR系統下行鏈路載波聚合方案設計

3.1 TM500的架構設計

每個5G小區對應一個獨立的基帶服務器，運行在Dell R630 Intel（R） Xeon（R） Gold 6140 CPU @ 2.30GHz上。由于載波聚合后的下行數據要在MAC層聚合，所以有一臺層2服務器運行在Dell R630 CPU： E5-2687W v4 @ 3.00GHz上，負責運行L2協議棧以及管理8個基帶服務器。另外一臺層3服務器負責運行實時的L3協議棧。TM500作為基站負載測試儀表，可以模擬每個eMBB小區的256個UE，而每個UE的PCC，SCC1，SCC2…SCC7可以隨意分布在任何一個基站服務器上。

因此層2服務器作為TM500架構的中心節點，要同時接收并處理來自8個基帶服務器的各個UE的下行數據，在MAC層聚合后傳給RLC和PDCP層處理，并再對各個UE遍歷其所有基帶服務器的下行數據CRC結果，匯總后計算其HARQ反饋的碼本，再把計算結果發送給其PCC對應的基帶服務器。TM500架構設計示意圖如圖1所示。

3.2 下行載波聚合的HARQ反饋設計

根據3GPP協議，在下行載波聚合時，其DL的HARQ反饋是承載在PCC的PUCCH信道上的（當有上行載波聚合時，也可以承載在SCC的PUSCH信道上）。因各個基帶服務器每個時隙獨自解碼下行PDCCH和PDSCH信道，并把解碼結果通過消息發送給L2服務器。L2服務器接收到信息后，保存到HARQ反饋目標時隙，并計算該基帶服務器目標時隙上PUCCH的SR信息。當等齊系統中全部基帶服務器的消息后，L2服務器輪詢每個UE在各個載波上的HARQ反饋并計算碼本，保存到目標時隙。然后L2服務器還需要計算各個基帶服務器在目標時隙上PUCCH的CSI信息。最后根據每個UE的PCC所對應的基帶服務器位置，發送PUCCH的SR/CSI/HARQ反饋信息給相應的基帶服務器。

3GPP在dl-DataToUL-ACK中規定了下行HARQ反饋的值域（后用HARQ RTT代替）為0～15個時隙，以FR2 120 kHz子載波間隔中常用配置的4個時隙來計算。手機只有4 × 125us/slot = 500 us的反饋時延預算。再扣除下行解碼和上行編碼的開銷，實際留給L2服務器計算時間只有100 us左右。由于各個基帶服務器的編解碼優化空間是有限的，所以解決系統時延的關鍵在于L2服務器。

4 系統延時優化設計

4.1 L2服務器代碼重構

Dell R630為戴爾雙插槽機架式服務器，屬于第13代PowerEdge服務器，采用E5-2687W v4 @ 3.00GHz處理器和四通道DDR4 ECC內存。擁有12核，開啟超線程時可同時運行24個線程，L3緩存為30 MB。

在代碼重構前，3.2章節所述的L2服務器的HARQ反饋模塊是一個線程運行在一個核上，其運行時間約為50 us。在1載波和2載波時，系統的時延還是能滿足的?？僧斚到y擴展到8載波時，發現整個模塊需要350 us的時間才能運行完，遠遠大于100 us的預算。但同時，服務器上還有很多核處于空閑狀態，并沒有把Dell R630的性能發揮到極致，可以通過把該模塊并行運行在多個核上，以此來獲取并行處理的增益。但如3.2章節所述的，該模塊需要輪詢各個基帶處理器的數據來計算碼本的步驟，由于各個基帶處理器上報的消息到達順序不同、計算量不同，簡單的多核多線程并行處理就會有線程間空閑數據競爭的風險。

4.2 下行多載波L2服務器并行處理設計

首先為該模塊啟動8個線程，每2個線程在一個核上。指定核#0上線程#0為主線程，其余為輔線程。8個線程分別和一個基帶服務器綁定，接收其上報的下行解碼數據，并預計算其上PUCCH的SR信息。主線程計算完后負責檢查其他輔線程是否也計算完畢PUCCH的SR信息，而其他輔線程計算完畢SR信息處于等待狀態。

當主線程發現全部線程都計算完PUCCH的SR信息后，開始遍歷全部基帶服務器的下行解碼數據，并匯總計算HARQ反饋碼本，保存在目標時隙的該UE的PCC所在的基帶服務器的緩存里。當所有UE的HARQ反饋碼本計算完畢后，主線程通知各個輔線程可以開啟后續計算。

接下來8個線程同時并行計算其所對應的基帶服務器上PUCCH的CSI信息。最后再分別并行，把PUCCH的CSI/SR/HARQ反饋信息一起發送給其對應的基帶服務器，基帶服務器完成PUCCH信道編碼。

這其中多線程之間的同步是設計的關鍵。Linux下提供了多種方式來處理線程同步，最常用的是互斥鎖、條件變量、信號量和讀寫鎖。但為了節省耗時，采用了原子操作、內存屏障和揮發變量相結合的方法。

原子操作是一種基于基本數據類型的同步形式，底層用匯編鎖來控制變量的變化，保證數據的正確性，好處在于不會block互相競爭的線程，且相比鎖耗時很少。

內存屏障則是為了達到最佳性能，編譯器通常會對匯編級別的指令進行重新排序，從而保持處理器的指令管道盡可能的滿。作為優化的一部分，編譯器可能會對內存訪問的指令進行重新排序（在認為不會影響數據正確性的前提下），然而，這并不一定都是正確的，順序的變化可能導致一些變量的值得到不正確的結果。內存屏障是一種不會造成線程擁塞的同步工具，它用于確保內存操作的正確順序。內存屏障像一道屏障，迫使處理器在其前面完成必須的加載或者存儲的操作。內存屏障常被用于確保一個線程中，可被其他線程訪問的內存操作按照預期的順序執行。

揮發變量是另外一種針對變量的同步工具。眾所周知，CPU訪問寄存器的速度比訪問內存速度快很多，因此，CPU有時候會將一些變量放置到寄存器中，而不是每次都從內存中讀取（例如for循環中的i值）從而優化代碼，但是可能會導致錯誤。對一個變量加上volatile關鍵字，可以迫使編譯器每次都重新從內存中加載該變量，而不會從寄存器中加載。

因此，在判斷SR數據是否收集齊處加上原子或的操作，來檢查各個輔線程是否完成了PUCCH的SR計算。而每個輔線程在判斷是否遍歷完畢處會有一個原子異或的操作來表示其已經完成，由主線程完成HARQ碼本計算后，通過原子與的操作來釋放輔線程進行后續的計算，并通過空循環來等待主線程完成該處的同步釋放工作。通過定義揮發變量的操作，以此來保證各個輔線程從內存中讀取同步變量。遍歷完畢后，調用了內存屏障，從而確保各個輔線程再次計算時內存訪問次序的正確性。

5 仿真與結果分析

在和基站聯調運行1個UE，FR2 120 kHz子載波間隔的下行8載波聚合的用例時可知，在代碼重構前，由于HARQ反饋來不及反饋給基站，出現了一定概率的HARQ重傳，最大速率只能達到1.2 Gbps。而在代碼重構后，則可以穩定達到理論上的最大峰值速率4.2 Gbps。重構前后指標對比見表1。

但隨著模擬UE個數的增加，發現每個時隙需要上報的PUCCH個數也會增加，從而導致L2服務器的該模塊負載也在增加，并最終會導致來不及上報PUCCH的信息（RTT margin為負數）。從圖2中可見，RTT margin的趨勢不僅和小區數目有關還和UE數目有關。而當線程增加后，對RTT margin是有所提高的。

另外，L2服務器上其他模塊如PDCP、RLC在下行8載波聚會時，也存在負載過高的現象，會出現丟包現象，并對發包率、加密算法以及包的大小敏感。

6 結論

該文提出的利用Dell R630服務器E5-2687W v4 @ 3.00GHz多核多線程并行計算的方法，可以有效解決TM500基站測試儀表在FR2 120KHz子載波間隔，下行8載波，64-QAM時的最大吞吐率和HARQ反饋時延的問題。也意識到多核多線程增加了代碼的復雜度和調試難度，不同線程間的同步方法各有利弊，如果根據架構實際情況合理設計和利用，可以獲得最大化收益。但也看到了在UE個數增加時依舊面臨的問題。在未來載波聚合的小區有可能達到32個或者更多，除了升級更高級的硬件服務器之外，更加充分地利用多核多線程并行計算的優勢，或許是在不增加產品成本下的一個不錯的解決方案。

參考文獻

[1]王順.載波聚合下行吞吐率測試的設計與實現[J].軟件，2015，36（10）：68-71.