工業技術研究院 資訊與通訊研究所 方士豪 高健育 劉俊男 陳佳蘋 林明哲 吳秋萍 李威廷 陳家銘
O-RAN開放式架構是一種破壞式的創新，打破傳統大型基地台設備業者壟斷市場的情況，營運商欲提供5G網路服務，不需要透過傳統電信設備商採購硬體設備，可直接與資通訊業者採購基地台設備，因此有望帶來龐大的市場商機。工研院已深根O-RU/O-DU設計，且協助多家廠商完成O-RU/O-DU設備自主性與相關功能和穩定性測試，本文將詳細介紹工研院開發之O-RU/O-DU系統之設計與驗證。
精彩內容
1. O-RAN網路系統與市場介紹
2. O-RAN開放前傳介面與OTIC測試
3. O-RU系統設計與驗證
4. O-DU系統驗證 |
O-RAN網路系統與市場介紹
由於近期5G網路產業的興起，O-RAN架構有機會成為大型／小型基地台通用的網路建置基礎架構，此開放式架構可讓電信營運商有效的節省支出成本，並且能建構5G行動網路的解決方案。目前全球市場上使用O-RAN開放式架構的營運商較著名的案例為日本樂天電信，此電信商於2019年宣布採用O-RAN架構來進行4G／5G之網路布建。
由於樂天電信為全新營運商且採用O-RU、O-DU、O-CU之開放式架構，相較於把軟體、韌體、硬體整合在一起之傳統電信營運商，樂天電信進行網路布建時，無須直接採購國際電信設備供應商，只要購買符合開放式架構之白牌基地台供應商之電信設備即可進行5G網路布建，可避免被傳統基地台設備供應商所壟斷的限制，可提高相關電信設備的議價能力，網路部署成本也大幅降低，因此可有效建立高靈活性與高開放性之網路架構，並且透過軟體調整來提供不同的通訊服務。
藉由5G O-RAN開放式架構的興起，相較於傳統的大型基地台電信設備營運模式，台灣資通訊業者將更有機會搶攻白牌基地台供應鏈的商機，例如鴻海集團旗下的台揚科技，拿下美國電信運營商Dish Network的5G O-RAN RU訂單，且與日本NEC成為策略夥伴，提供O-RAN系統下的各種無線射頻產品，將可有效滿足5G市場需求，搶攻5G O-RAN市場之龐大商機。除了電信設備的供應商機之外，測試設備的相關商機也不容小覷。由於不同業者做出來的O-RAN設備彼此之間不一定能夠相容，因此，勢必要有一家測試單位來提供O-RAN設備測試服務。目前耀登科技旗下耀睿實驗室獲O-RAN聯盟認證，且已經引進是德科技（Keysight Technology）相關測試儀器，並且建置開放無線網路測試與集成中心（Open Testing and Integration Centre, OTIC）的第三方公正測試實驗室給台廠的O-RAN設備來進行一致性測試（Conformance Test）、互通性測試（Interoperability Test, IoT）、以及端對端測試（End-to-End Test, E2E）等測試服務，將可有效協助台廠所開發之O-RAN設備測試方面的需求。此測試實驗室不僅是台灣首座符合O-RAN Alliance測試規範，而且具有資安檢測的5G O-RAN測試實驗室，此外，目前也是中華電信指定的O-RAN測試實驗室。
工研院資通所已深耕4G／5G行動通訊系統多年，且主要進行4G／5G小型基地台之相關設計，針對5G小型基地台之O-RU與O-DU的設計，目前已有與廠商合作的O-RAN小型基地台系統架構解決方案，且成功協助多家台灣資通訊廠完成相關O-RAN電信設備之自主性，並通過OTIC實驗室測試。以下章節將深入介紹O-RAN系統的規範與測試細節，及工研院資通所開發之O-RU與O-DU之相關設計與驗證內容。
O-RAN開放前傳介面與OTIC測試
O-RAN Alliance主要由8個Working Group組成，其中WG4定義了Open Fronthaul Interface（O-FH），讓O-DU和O-RU間可進行資料傳送（如圖1），其中C/U/S Plane規格[1]定義了資料於O-RU與O-DU之間的傳輸方式與時間同步方法，細部資訊對應如表1。M Plane規格[2]主要透過網管協定NETCONF與資料模型YANG，管理參數及波束形成、天線陣列維度等相關資訊。
OTIC為確保O-FH能準確交換O-DU和O-RU訊息，O-RAN中的WG4針對功能與介面分別制定IoT Testing[3]和Conformance Testing[4]。IoT Testing著重於不同廠商的裝置間能否透過O-FH傳送Packet並正常運作，且測試重點放在O-DU和O-RU系統級驗證，其中包含M-Plane的啟動、S-Plane的同步和Layer-3 C-Plane建立、U-Plane資料Packet的收送，以及C/U-Plane的延遲管理。Conformance Testing則針對待測裝置設計相對應測項，以確保待測裝置有能力支援O-DU和O-RU間的各種功能是否運作正常，其中包含了UC-Plane測項、M-Plane測項、與S-Plane測項三大部分。
圖1 O-RAN基地台架構
表1 C/U/S Plane資訊對應[1]
O-RU系統設計與驗證
工研院FR1 O-RU系統（如圖2）遵循O-RAN標準規範採用Option 7-2x前傳架構，透過10GbE網路介面與O-DU互通，O-RU系統使用FPGA實現O-RU功能，FPGA包含PS與PL兩個部分，PS有多個處理器單元，可在其上透過軟體實現包含O-RAN M-plane、S-plane（PTP Sync.）、功率校準、AGC、RF前端控制、數位預失真（Digital Pre-Distortion, DPD）等功能。PS模組中的DPD主要是補償功率放大器（Power Amplifier, PA）的失真，提高PA輸出效能；時間同步的目的是要讓O-RU與GPS達成時間同步；功率校準與AGC則是使最後接收的訊號保持在固定功率區間內以維持訊號品質。PL是可程式化邏輯單元，主要實現10G網路介面、O-RAN C/U-plane以及RF前端介面轉換等功能。
圖2 FR1 O-RU系統架構圖
圖3 DPD架構圖
- PS模組-功率校準與AGC設計
RU使用ADI之ADRV9025，搭配PA為SKYWORKS的SKY66318-11與ADI的LNA ADRF5545A。不同RU雖使用相同元件，但對收發訊號有一定的偏差，因此必須要功率校準。圖4（a）與圖4（b）為KYWORKS元件特性[5]，可看出相同頻率下，輸出功率接近定值，不同頻率下輸出功率為Linear。圖5（a）與圖5（b）分別為接收端ADRF5545A[6]與ADRV9025[7]元件特性。可看出相同頻率下，LNA在接收端的增益在相同頻率下，其輸出功率接近定值，不同頻率下輸出功率為Linear。因此，針對RU功率校準原則是對同一頻率會以一固定偏差值來做校準，不同頻率則會使用線性內插得到校準值。
為維持接收訊號的品質，RU設計了AGC演算法，使最後接收的訊號保持在固定區間內。區間範圍訂定的準則是讓ADC最大輸入功率後退25dB，避免PAPR的效應，並在ADC的雜訊水平上保留20dB的SNR值。另外也設計了一個平滑因子來防止接收訊號瞬間劇烈變化造成PA的增益變化過大造成錯誤率增加的問題。
圖4 KYWORKS元件特性[5]（a）不同頻率下Gain vs POUT,（b）不同溫度下Gain vs Frequency
圖5（a）ADRF5545A不同頻率下之Gain v.s. Frequency [6]（b）ADRV9025不同Receiver衰減之Gain值[7]
- 時間同步設計
O-DU與O-RU間的C/U-plane Packet裡有帶frame、subframe、slot、symbol等時間訊息，所以O-DU與O-RU需在同樣的時間上做C/U-plane Packet的交換才能正確傳收資料。O-RAN系統時間是以GPS為基準，當O-DU與O-RU各自與GPS時間達到同步時，即確定兩者是在相同的時間基礎做溝通。
PTP時間同步的系統架構如圖6所示，GM首先透過天線與GPS衛星完成時間同步，之後藉由Ethernet與O-RU利用廣播的方式交換PTP Packet訊息達到時間同步效果。O-RU時間同步系統架構如圖7所示。SEP模組State Machine如圖8所示，當State進入SLAVE，代表O-RU已經與GM完成時間同步。GM與O-RU間的PTP Packet交換流程如圖9所示。State Machine的時間同步演算法主要是O-RU透過Ethernet與GM完成PTP Packet交換流程，可以從中獲得t1～t4訊息，進而獲得GM至O-RU與O-RU至GM間網路路徑延遲，並進一步的計算出GM與O-RU的時間誤差。O-RU與GM每完成一次Packet交換，便可以得到一次時間誤差，O-RU可依誤差大小，調整本地振盪器的快慢，直到誤差縮小到符合測試規範。由ITU G8273.2[8]的Time Error Noise Generation測項的測試規範，可得知O-RU的時間同步能力等級，目前O-RU的能力目標為Class B。時間同步測試結果為cTE=-13.237ns、MTIE<40ns、TDEV<4ns，均符合ITU G8273.2 Class B的測試規範。
圖6 PTP時間同步系統架構
圖7 O-RU時間同步系統架構
圖8 SEP State Machine
圖9 PTP Packet交換流程
- PL模組設計
PL主要實現10G網路介面、O-RAN C/U-plane及RF前端介面轉換。首先O-RAN Packet透過10GbE模組來進行與O-DU間資料的傳送與接收，當接收到DL的Packet時，會先經過網路介面處理模組進行初步的資料篩選然後將C/U/S-plane的資料送到對應的處理單元，經過DL資料處理模組完成Low-PHY運算後便可以將資料傳送至射頻介面經由射頻模組發射訊號。在UL的部分，射頻模組接收到訊號後先經由射頻介面處理後即可進到UL資料處理模組以及RACH模組，完成Low-PHY運算後便可透過網路介面處理模組進行資料的封裝動作再經由10G介面傳送至O-DU。
圖10為O-RU DL處理單元之細部架構圖，DL資料處理模組是以單天線為基本的處理單位，可彈性設定系統所需之天線數，當接收到De-framer的Packet，會先透過dl_ecpri_parser模組將C-plane資訊進行解譯，獲得後續相關模組的控制資訊，而U-plane的資料也經由dl_ecpri_parser模組解譯後存入dl_up_data buffer中，此時buffer中儲存的I/Q資料仍是經過壓縮的，需透過dcmprss模組將I/Q資料還原至未壓縮前的大小，之後則是透過IFFT模組將頻域上的資料轉換到時域的訊號，在進入RF收發器之前則是透過Add CP模組加入循環字首，最後時域上的訊號便可經過RF收發器打到載波的中心頻率上。
圖10 O-RU DL處理單元架構圖
圖11為O-RU的UL處理方塊圖，每一個UL Data Path方塊可處理一路天線埠的UL資料。在系統初始時，系統的參數可透過axi_regs模組由PS進行設定，並且經由RTC模組將UL Data Path的時間與其他模組對齊。在O-RAN的規格中提到，UL資料可分成C-plane及U-plane兩類，O-DU在每一個Slot的U-plane資料接收之前，必須將每個Slot所需的控制參數通過C-plane Packet傳送到O-RU，以利O-RU可以正確的處理所需的資料。Ethernet De-framer模組負責將每個O-DU傳送的eCPRI Packet頭解譯，並且篩選出每一路天線埠的UL所需的C-plane參數，傳送給相對應的UL Data Path模組。U-plane的射頻資料經天線接收並降至基頻，由ADC進行取樣，並透過JESD將取樣後的數位資料流串送給 UL Data Path進行後續的資料處理，而每個天線埠的資料時序控制由adc_control模組進行。最後，UL Data Path將處理過的資料透過Ethernet framer加上eCPRI Packet頭、組成Packet傳送給O-DU，並將相關的Packet狀態輸出給eCPRI performance counter統計。
圖11 O-RU UL處理單元架構圖
- FR2 O-RU FR2 O-RU架構設計
（如圖12）與FR1 O-RU最大差異在於多了控制外部毫米波模組波束的功能。RU收到O-RAN C-Plane Packet內容裡包含波束指標、波束接換時間等參數後，就可在符碼間或Slot間進行波束的切換傳送收發訊號。此外，在RU端所產生的中頻訊號與外部毫米波模組界接時 會再透過升頻器產生成高頻（28/39GHz）訊號，在透過前端天線元件收發訊號。其他PS與PL的功能設計上皆與FR1 O-RU是類似的。
圖12 FR2 O-RU系統架構
- O-RU驗證與ITRI DU Emulator
工研院開發了ITRI DU Emulator來驗證O-RU正確性，測試環境如圖13。DL部分可透過DU Emulator發O-RAN Signal給O-RU，讓O-RU打出DL訊號，並透過5G Signal Analyzer來解調且觀察DL解調訊號EVM；UL部分則可透過DU Emulator發C-Plane Data給O-RU，O-RU則收到5G Signal Generation所產生的NR訊號，並且發U-Plane Data回傳給DU Emulator來解調UL訊號，解調結果如圖14。
圖13 ITRI O-RU測試環境
圖14 UL NR訊號解調結果分析
O-DU系統驗證
FlexRAN為Intel所開發的4G／5G實體層參考設計，可在Intel架構下之中央處理器運行，包含Intel Xeon SkyLake與Intel Xeon CascadeLake等平台。目前工研院資通所採用Intel FlexRAN架構來進行O-RAN系統中O-DU之驗證，測試環境如圖15。圖15中包含了DL與UL兩種測試環境，DL測試環境主要是測試O-DU與O-RU對接後，實際測試O-RU所發射的5G NR Waveform給5G訊號分析儀（Signal Analyzer）、5G Sniffer Wavejudge、及5G UE Emulator（E500）的訊號解調狀況。圖15中的UL測試環境主要是藉由5G訊號產生器（Signal Generator）產生5G NR UL訊號後，直接給O-RU來接收，並且透過10GbE Fiber傳送給O-DU來解調訊號。以下分別針對之FR1/FR2之DL/UL驗證結果進行說明。
圖15 ITRI O-DU DL/UL測試環境
- FR1 DL/UL Channel
FR1的DL主要包含SSB、PSS/SSS、PBCH、PDCCH、PDSCH，手機開機後透過搜尋SSB與基站達到時間與頻率同步後，再透過PBCH取得系統資訊，透過DL控制信號通道得知DL Packet位置、Packet大小及其調變與編碼策略，完成DL的解調。DL驗證則可透過UE Emulator進行DL Throughput驗證，驗證方式可先行設定UE Emulator基頻信號頻寬、SSB位置，PDCCH與PDSCH之RRC相關參數，UE Emulator透過SSB與基站達成同步後，解調PDCCH與PDSCH即可解DL訊號，進而計算DL通道Throughput驗證（如圖16）。
圖16 DL Throughput
FR1 FlexRAN O-DU的UL主要包含PUSCH、PUCCH、PRACH、SRS，目前O-RAN基地台已經與R&S訊號產生器有線對接驗證過不同UL通道的正確性。圖17為PUSCH在TDD模式且100% UL的狀況下之L1 Only UL Peak Throughput驗證圖，使用的參數為頻寬100MHz、273RB、2 Layers、4 Antennas、MCS26（256QAM Table）。從圖上可看到，此設定下最高的UL Data Throughput可接近1.2Gbps且UL BLER趨近於0。
圖17 UL Peak Throughput
- FR2 DL/UL Channel
FR2毫米波系統主要基頻物理通道與FR1次系統相同。圖18為毫米波DL頻寬100MHz下，驗證64QAM與2 Layer結果圖。透過網路訊號分析儀可以得知各個物理通道的傳送訊號實現皆符合3GPP規範，且EVM約-30dB。在Frame比例為97.5%為DL排程下，其DL Throughput約623.188Mbps。若測試頻寬設定為400MHz的話，可預估Throughput約可接近2.5Gbps。約是2倍次系統FR1相同64QAM調變且4 Layer的Throughput。
圖18 FR2 DL基頻訊號驗證與效能分析
圖19為毫米波UL頻寬100MHz下，驗證64QAM與2 Layer結果圖。透過訊號產生器傳送符合3GPP規範的UL資料訊號，透過有線接線方式將訊號送入基站接收端。下圖可看到在訊框比例為100%皆UL的排程下，其UL Throughput約639.183Mbps且其解調錯誤率為0%。若測試頻寬設定為400MHz的話，可預估Throughput約可接近2.56Gbps。約是4倍次系統FR1相同64QAM的Throughput。圖20為毫米波在頻寬100MHz下，驗證TDD模式在DL/UL為8:2的結果圖。
圖19 FR2 PUSCH驗證與效能分析
圖20 FR2 TDD DL:UL=8:2模式下驗證與效能分析
結語
工研院資通所已深耕研發5G O-RAN小型基地台，主要目標是協助廠商提高白牌基地台設備開發之自主性，其中O-RU與O-DU方面的研發能量已協助台灣多家廠商通過OTIC實驗室測試；此外，也協助廠商進行UE端與gNB端之E2E OTA測試，並且針對廠商客戶需求完成功能與穩定性測試，後續將會持續協助廠商在O-RAN網路系統架構下之5G小型基地台電信設備市場占有一席之地。
參考文獻
[1] O-RAN Fronthaul Working Group, Control, User and Synchronization Plane Specification, v04.00
[2] O-RAN Alliance Working Group 4, Management Plane Specification, v04.00
[3] O-RAN Alliance Working Group 4, Fronthaul Interoperability Test Specification (IOT), v04.00
[4] O-RAN Alliance Working Group 4, Conformance Test Specification, v03.00
[5] https://www.skyworksinc.com/-/media/SkyWorks/Documents/Products/2901-3000/SKY66318- 11_204986D.pdf
[6] https://www.analog.com/media/en/technical-documentation/data-sheets/ADRF5545A.pdf
[7] https://www.analog.com/media/radioverse-adrv9026/adrv9026.pdf
[8] ITU-T G.8273.2/Y.1368.2 (01/2017) Timing characteristics of telecom boundary clocks and telecom time slave clocks
