基于OAI的LTE通信平臺用戶面時延分析

陳洪達，劉子辰，黃茂碟

（1.重慶郵電大學 通信與信息工程學院，重慶 400065；2.中國科學院計算技術研究所 無線通信技術研究中心，北京 100190）

基于OAI的LTE通信平臺用戶面時延分析

陳洪達1，劉子辰2，黃茂碟1

（1.重慶郵電大學 通信與信息工程學院，重慶 400065；2.中國科學院計算技術研究所 無線通信技術研究中心，北京 100190）

針對當前流行的OAI（OpenAirInterface）LTE軟件無線電平臺缺少詳細的用戶面時延測試分析，提出關鍵模塊分離測試方法。首先，從OAI平臺通信架構(gòu)的角度出發(fā)，分割軟硬件模塊并進行逐一研究，分析產(chǎn)生時延的機制；然后，通過平臺測試，獲得實際情況下的時延數(shù)據(jù)；最后，對測試數(shù)據(jù)進行分析，驗證所提測試方法的正確性。實驗采用的測試平臺為OAI，能夠為其他SDR LTE平臺時延研究提供理論基礎和時延測試方法，同時也可為SDR在4G/5G通信系統(tǒng)的應用研究提供不可估量的科研價值。

SDR；用戶平面時延；時間標記；OAI；USRP

0 引 言

OAI是一個EURECOM引領的基于軟件無線電的開發(fā)平臺，旨在建立一個開放的、多制式融合、科技前沿的實驗平臺[1]。OAI是一個較為成熟的開源軟件工程，能夠?qū)υ创a進行修改并編譯；配合LTE核心網(wǎng)，能夠在真實的環(huán)境下實現(xiàn)對傳統(tǒng)4G手機進行接入測試。同時，OAI官方研究團隊正朝向5G的SDR的研究方向發(fā)展，目前已經(jīng)取得一部分成就。因此，OAI在未來的無線通信領域潛伏著巨大的科研價值[2-4]。目前，世界各地越來越多的科研人員加入此項目，此項目還獲得30多家科研高校和知名企業(yè)的支持，如在通信領域享有盛名的貝爾實驗室、肯特大學及國內(nèi)知名高校如北京郵電大學和中國科學院等。而用戶面時延不僅是反映整體網(wǎng)絡通信狀況的一個重要指標，還是各類業(yè)務實現(xiàn)的前提條件。但是，目前對于OAI的時延研究僅限于對某一部分的研究，沒有對整體系統(tǒng)進行詳細研究。因此，如何找到影響時延的關鍵模塊，如何降低時延，便成為OAI在未來無線通信領域作為前沿實驗平臺必須重視的問題。這需要一種能夠詳細解析OAI的時延分析方法[5]，而本文旨在從系統(tǒng)層面進行詳細的時延分析，以期為今后的時延優(yōu)化提供夯實基礎。

本文首先簡要介紹OAI的系統(tǒng)架構(gòu)，然后劃分關鍵模塊，重點分析引起時延的關鍵技術，最后做出測試方法和時延分析總結(jié)，并對下一步的工作做出展望。

1 OAI系統(tǒng)架構(gòu)

本節(jié)重點介紹OAI LTE通信平臺的系統(tǒng)架構(gòu)，如圖1所示。前端射頻板接收到攜帶信息的信號開始傳遞給匯聚信號模塊（Integrated RFIC），匯聚信息模塊主要負責信號的匯聚；之后將信號傳遞給DSP處理模塊，負責DAC/ADC的完成；然后硬件傳輸控制模塊（Hardware Transport Control Time）將數(shù)據(jù)通過高速總線傳遞給PC機，射頻板可采用高速率傳輸USB3.0總線，也可通過其他串口或網(wǎng)口連接PC機；經(jīng)過PC內(nèi)核處理，途經(jīng)硬件驅(qū)動到達GNU Radio（軟件無線電核心部分），GNU Radio是一種運行于普通PC上的軟件無線開發(fā)電平臺，OAI LTE就是借用GNU Radio的相關模塊進行開發(fā)的[6]。

圖1 SDR數(shù)據(jù)處理模塊框架

在圖1數(shù)據(jù)處理框架圖中，可以將其分割為GNU Radio自身、GNU Radio?Hardware Driver驅(qū)動模塊、Hardware Driver?Hardware Transport Control模塊及射頻板自身四個部分進行時延分析。GNU Radio的處理速度由PC機的性能決定，模塊之間的傳輸依靠于Buffer運行機制，而射頻硬件部分主要依賴于射頻板的性能及關鍵參數(shù)的設定。下面將詳細分析各部分的時延。

2 關鍵模塊時延分析

2.1 GNU Radio時延分析

在GNU Radio開發(fā)過程中，OAI的實現(xiàn)會依賴于一些開源的庫文件及內(nèi)核模塊，通過整體的編譯和運行，能夠?qū)崿F(xiàn)數(shù)據(jù)包從應用層到物理層的完整數(shù)據(jù)處理流程。內(nèi)核負責進程管理、系統(tǒng)調(diào)用及網(wǎng)絡通信等，而軟件無線電的軟件開發(fā)便包括LTE系統(tǒng)的架構(gòu)和功能的實現(xiàn)。GNU Radio可抽象為多個DSP模塊串聯(lián)，而每一個模塊通過Buffer傳遞給下一個DSP模塊[7]，其處理流程圖如圖2所示。

圖2 GNU Radio數(shù)據(jù)處理流程

對于內(nèi)核調(diào)用的處理時間，會依據(jù)實際任務的復雜度不同而不同。這就導致GNU Radio的處理時間處于某一范圍，且范圍較大。而DSP處理模塊包括DPCP加密和完整性保護、RLC包處理、MAC調(diào)度及物理層信道編碼、CRC、FFT、交織等，由相關代碼編寫而成。而目前已發(fā)表的論文并未對此DSP模塊的處理時間進行分析，而本文采用時間標記的方式進行預估，即在模塊調(diào)用起始位置標注開始運行時間點，在模塊調(diào)用結(jié)束位置標注結(jié)束時間點。結(jié)束時間點減去開始運行時間點，便可得到模塊數(shù)據(jù)處理時間，這樣能夠較為準確地測量模塊所用時間。

此外，Buffer的運行機制可分為兩種：第一種是填滿后發(fā)出，第二種是直接發(fā)出。填滿后發(fā)出的時延可以做如下理解：假如GNU Radio默認的是32 kB的Buffer，取樣率為4 Mb/s，每個樣本16 bit，填滿Buffer的時間為32 k×8/（4 M×16）=4 ms?？梢姡琤uffer越多，等待的時間越長。如果將buffer的容量調(diào)小，雖然時延會減小，但是吞吐率會降低。而GUN Radio?Hardware Driver驅(qū)動模塊的時延分析可通過Buffer進行分析。但是，實際編程過程會通過合理的運行機制，以減少Buffer引起的時延[7]。

2.2 Hardware Driver?Hardware Transport Control模塊時延

Hardware Driver?Hardware Transport Control時延可以理解為PC與射頻板之間的總線時延。而總線時延一方面是由射頻前端FPGA板的Buffer產(chǎn)生。平臺不同，默認的Buffer大小不同，但Buffer大小卻與總線的傳輸形式有關。例如，USRP B210[8-9]的默認Buffer容量為8 kB，采用的是USB3.0，在實際傳輸過程中可達30 Mb/s。填滿8 kB Buffer的時間為0.267 ms。高速率的總線方式往往能夠產(chǎn)生低時延效果，尤其是對大數(shù)據(jù)業(yè)務。

2.3 射頻前端時延

射頻前端，負責基站與終端空中接口的通信任務。FPGA Buffer處理、ADC/DAC、天線收發(fā)切換等都由射頻板完成。大量的測試實驗證明，高性能的射頻板能為科研帶來更加真實準確的數(shù)據(jù)[10]。而射頻板的參數(shù)不同，如Buffer大小、收發(fā)間隔時間、硬件保護間隔（預留進程間隔時間，以免進程沖突）等，對時延的影響也不同。目前，一些科研工作者并未對射頻前端做出理論分析，而本文從OAI平臺硬件調(diào)用代碼中最重要的幾個參數(shù)入手，主要包括sample_rate（樣本率，每秒產(chǎn)生的樣本個數(shù)）、samples_per_packet（包的樣本數(shù)）、tx_sample_ advance（發(fā)送接收樣本間隔數(shù)）以及tx_scheduling_ advance（發(fā)送數(shù)據(jù)的延遲等待）等，對硬件進行時延研究。例如，樣本率為7 680 000，包的樣本數(shù)為1 024，則一個包的時間約為0.133 ms；若發(fā)送數(shù)據(jù)延遲等待5個數(shù)據(jù)包，則時間為5×0.133=0.665 ms。

tx_scheduling_advance數(shù)值為發(fā)送數(shù)據(jù)前的等待時間，是作為發(fā)送端的特殊保護間隔。這個數(shù)值的增大雖然會提高系統(tǒng)的穩(wěn)定性，但是會增加數(shù)據(jù)發(fā)送的等待時間，從而時延變大。此處說明，系統(tǒng)的穩(wěn)定性指標主要參考系統(tǒng)運行時出現(xiàn)的錯誤標識。出錯的標識越多，系統(tǒng)越不穩(wěn)定。而下節(jié)所測試的OAI的錯誤標識由U/L表示?！癠”錯誤的出現(xiàn)，意味著host PC或其上運行的應用程序的處理能力不足，不能處理設定的采樣速率；而“L”錯誤的出現(xiàn)，則意味著應用程序中存在邏輯錯誤；正常情況下無U或L?？梢?，以OAI運行過程中出現(xiàn)U/L的個數(shù)判定系統(tǒng)的穩(wěn)定度，能夠反映當下的系統(tǒng)穩(wěn)定情況[11]。下面將開始各個模塊的時延測試。

3 測試與數(shù)據(jù)分析

當終端接入到OAI搭建的LTE網(wǎng)絡時，手機則分配有IP地址。這為測試真實環(huán)境下的整體網(wǎng)絡時延奠定了基礎。

3.1 GNU Radio及Buffer時延

首先，通過時間標記的方式估算出AS（接入層）數(shù)據(jù)處理的時間及物理層信道編碼、CRC、FFT、調(diào)制/解調(diào)等處理時間，如1 024點FFT的處理時間為15～32 μs。通過對模塊進行時間標記，可以預估GNU Radio處理時間大約為1 500～4 500 μs。這里，每個處理模塊的處理時間不穩(wěn)定是由于系統(tǒng)內(nèi)核進程調(diào)度產(chǎn)生的。因為系統(tǒng)內(nèi)核進程調(diào)度與CPU、內(nèi)存和主機當前運行狀態(tài)有關，主機狀態(tài)較差時，產(chǎn)生的時延較高。

其次，對于各個模塊之間Buffer的時延影響，則采用單一改變Buffer大小進行測試。但是，在測試過程中發(fā)現(xiàn)，單一改變Buffer的大小對整體的時延影響可以忽略，歸其原因是編程時采用的自適應發(fā)送機制。當數(shù)據(jù)到達時，并非需要填滿Buffer才發(fā)送，而是直接發(fā)送，這就大大減少了GNU Radio處理時間。而對于Hardware Driver?Hardware Transport Control模塊時延，也是主要由Buffer的大小和Buffer的運行機制決定，此外還與平臺所采用總線的形式有關。本實驗采用的是USB3.0（180 Mb/s）總線，此部分的時延測量主要參考Nguyen所提出的總線傳輸理論[6]，可以預估傳輸2 kB數(shù)據(jù)需要0.088 ms。

3.2 射頻硬件時延

單一改變某一硬件參數(shù)，其他均不變。經(jīng)過測試，射頻參數(shù)設定中與時延最相關的射頻硬件參數(shù)是tx_scheduling_advance（值為1時，表示一個包的樣本數(shù)間隔，時間約為0.133 ms）。本文所測試的時延為雙向時延，即收包時刻減去發(fā)包時刻，且只改變tx_scheduling_advance的值。如圖3所示，測得tx_scheduling_advance不同值下的時延。

圖3 在tx_scheduling_advance不同值下的時延

隨著tx_scheduling_advance值增大，時延也會呈現(xiàn)遞增的規(guī)律，而且以0.133 ms左右線性遞增，從而印證了硬件參數(shù)對時延的影響，也說明了硬件確實會影響OAI系統(tǒng)的整體時延。此外說明，其值為4時，時延很高，原因是系統(tǒng)不穩(wěn)定。如圖4所示，U/L個數(shù)很多時，系統(tǒng)處于不穩(wěn)定狀態(tài)，會導致丟包或重傳現(xiàn)象出現(xiàn)。綜合觀察圖3、圖4發(fā)現(xiàn)，當硬件處于穩(wěn)定狀態(tài)時，時延趨于穩(wěn)定。

圖4 在tx_scheduling_advance不同值下U/L統(tǒng)計

時延還與測試包的大小有著直接關系，測試包所采用的大小依次為64 B、128 B、256 B、512 B、1 024 B。測試包越大，時延越大，如圖5所示。

圖5 測試包不同大小下的時延統(tǒng)計

隨著包攜帶的信息增加，OAI平臺處理的數(shù)據(jù)也相應增加，與之相關的各個模塊處理效率達到最高，包的容量越大，處理的時間就會越長。而時延隨著測試包的大小增加呈現(xiàn)接近線性遞增的規(guī)律，可以得出每64 B數(shù)據(jù)處理時間約為1.5 ms，這也就說明了OAI在處理數(shù)據(jù)時是按照固定的模式進行，當模塊的處理能力達到最高時，時延就會呈現(xiàn)線性遞增趨勢。

3.3 測試數(shù)據(jù)分析

由于傳輸64 B的雙向時延為10.9 ms，因此基底處理時間就是雙向時延減去64 B數(shù)據(jù)包的處理時間，即10.9-1.5=9.4 ms。而除去包解析時間0.3 ms，幀調(diào)整時間2 ms，OAI平臺整體處理時間的均值為基底處理時間減去包解析時間和幀調(diào)整時間，即9.4-2-0.3=7.1 ms。此時間為OAI平臺的整體處理時間，對于硬件影響最大的是保護時間間隔（tx_scheduling_advance），硬件產(chǎn)生的時延大約為5×0.133=0.665 ms（在tx_scheduling_advance值為5，硬件產(chǎn)生的時延以0.133 ms左右線性遞增規(guī)律的規(guī)律下）。此外，傳輸總線的時間約為0.088 ms，則單向時延大約為（7.1-0.665-0.088）/2=3.17 ms，而實際預估的GNU Radio時間為1 500～4 500 μs。此處分析的單向時延在GNU Radio預估時間范圍內(nèi)，用同樣方法分析其他不同大小數(shù)據(jù)包的情況，均在GNU Radio預估時間范圍內(nèi)。這也證明了本文所提測量分析方法的正確性。

4 結(jié) 語

本文采用OAI作為主流SDR LTE的時延分析平臺，從軟硬件的角度對系統(tǒng)的時延進行了模塊分離時延分析，通過測試結(jié)果驗證了此方法的實用性，解決了OAI缺少詳細時延分析的問題，還能夠為其他的SDR平臺的時延優(yōu)化提供方法和思路。但本文的不足是并未考慮復雜環(huán)境下的時延及丟包率，而是在普通的環(huán)境下，通過手機與基站的通信進行測試和分析，而今后的重點為從某些算法上進行改進，以解決GNU Radio產(chǎn)生較高時延的問題。

[1] Chun Yeow Yeoh,Mohammad Harris Mokhtar,Abdul Aziz Abdul Rahman,et al.Performance Study of LTE Experimental Tested Using OpenAirInterface [C].2016 18th International Conference on Advanced Communication Technology,2016:617-622.

[2] Jeroen Declerck,Praveen Raghavan,Frederik Naessens,et al.SDR Platform for 802.11n and 3GPP LTE[C].2010 International Conference on Embedded Computer Systems,2010:318-323.

[3] Rajeshree D Raut,Dr. Kishore D Kula.SDR Design forCognitive Radio[C].2011 4th International Conference on Kuala Lumpur,2011:1-8.

[4] Florian Kaltenberger,Raymond Knopp,Martin Danneberg,et al.Experimental Analysis and Simulative Validation of Dynamic Spectrum Access for Coexistence of 4G and Future 5G Systems [C].2015 European Conference on Networks and Communications,2015:497-501.

[5] Antonio Virdis,Niccolò Iardella,Giovanni Stea,et al.Performance Analysis of OpenAirInterface System Emulation [C].2015 3rd International Conference on Future Internet of Things and Cloud,2015:662-669.

[6] Nguyen B.Truong,Young-Joo Suh,Chansu Yu.Latency Analysis in GNU Radio/USRP-Based Software Radio Platforms[C].2013 IEEE Military Communications Conference,2016:305-310.

[7] Nguyen B Truong,Chansu Yu.Investigating Latency in GNU Software Radio with USRP Embedded Series SDR Platform[C].2013 Eighth International Conference on Broadband and Wireless Computing, Communication and Applications,2013:9-14.

[8] Ettus.USRP B200/B210 Product Overview [EB/OL]. (2015-08-10)[2016-08-04].https://www.ettus.com/ content/files/b200-b210_spec_sheet.pdf.

[9] Navid Nikaein. OPENAIRINTERFACE SIMULATOR /EMULATOR[EB/OL].(2015-07-01)[2016-08-06]. http://www.openairinterface.org/docs/oai_oaisim_desc. pdf.

[10] 陳通.寬帶射頻電路中若干關鍵技術的研究與實現(xiàn)——寬帶射頻合路模塊的設計與實現(xiàn)[D].北京:北京郵電大學,2011:5-8. CHEN Tong.Research and Implementation of Several Key Technologies in Broadband Radio Frequency Circuits--Design and Implementation of Broadband RF Circuits[D].Beijing:Beijing University of Posts and Telecommunications,2011:5-8.

[11] 博客.淺析USRP運行過程中出現(xiàn)“U”“O”“L”錯誤的原因[EB/OL].(2015-05-12)[2016-08-06].http: //www.cnblogs.com/atomic-pulse/p/4496620.html. Blog.Analysis on the Causes of the Error of "U" "O" "L" in the Process of USRP Operation(2015-05-12) [2016-08-06].http://www.cnblogs.com/atomic-pulse/ p/4496620.html.

陳洪達（1990—），男，碩士，主要研究方向為專網(wǎng)通信、軟件無線電；

劉子辰（1984—），男，博士，中級軟件工程師，主要研究方向為綠色無線電；

黃茂碟（1992—），女，碩士，主要研究方向為移動互聯(lián)網(wǎng)應用。

Delay Analysis for User Space of LTE Platform based on OAI

CHEN Hong-da1, LIU Zi-chen2, HUANG Mao-die1
(1.Chongqing University of Posts and Telecommunications, Chongqing 400065, China; 2.Institute of Computing Technology, Chinese Academy of Sciences, Beijing 100190, China)

Due to lack of user-space delay measurement to the popular OAI(OpenAirInterface), the SDR LTE communication platform, the solution with key-module separation analysis to this problem is proposed. First of all, starting from the angle of OAI platform communication architecture, the hardware and software modules are carved up and analyzed one by one, thus finding the mechanism for producing the time delay. And then via platform test, the delay date under actual circumstance is acguired. Finally the test result is analyzed, and the validity of this approach verified. With OAI as the test platform, the experiment could provide theoretical basis and test methods for delay research of other SDR LTE platform, and thus is of invaluable scientific value for research of SDR application in 4G/5G communication systems..

SDR(Software Defined Radio); delay of user space; time-marker; OpenAirInterface(OAI); USRP(Universal Software Radio Peripheral)

TN919.1

A

1002-0802(2016)-12-1659-05

10.3969/j.issn.1002-0802.2016.12.016

2016-08-06

2016-11-13 Received date:2016-08-06;Revised date:2016-11-13