LTE空中接口協(xié)議棧的研究與實現(xiàn)

何蘇勤，翟海超

（北京化工大學 信息科學與技術(shù)學院，北京100029）

0 引 言

為了提高無線移動傳輸速率，3GPP（the 3rdgeneration partnership project）啟動了LTE（long term evolution）技術(shù)的研究與實施［1］。LTE也稱為3.9G或準4G無線通信技術(shù)，它采用多天線和正交頻分復用的技術(shù)，支持更高的移動速度和更高的帶寬。LTE空中接口協(xié)議棧是運行于物理層之上的軟件部分，其主要作用是為終端和基站之間的通信提供服務。現(xiàn)階段LTE的研究和應用依然處于試驗階段，離大規(guī)模商用還有一定距離，且其關(guān)鍵技術(shù)多為大公司所掌握。但是，LTE的技術(shù)優(yōu)點決定了它在將來必將得到廣泛地推廣和應用，而且也會得到小型無線通信設備廠商尤其是無線實時視頻監(jiān)控系統(tǒng)廠商的青睞和關(guān)注。然而在面向小型無線通信系統(tǒng)的設計和實現(xiàn)中，LTE空中接口標準協(xié)議棧顯得過于龐大且存在部分冗余功能，因此對標準的接口協(xié)議棧進行精簡和優(yōu)化成為一種需求。針對這種問題，本文對標準協(xié)議做了簡化并實現(xiàn)了該簡化后的設計，最終在Xilinx Virtex－6開發(fā)板上驗證了該設計的可行性和有效性。

1 協(xié)議棧的構(gòu)成

LTE系統(tǒng)中存在3個子層，如圖1所示，分別是：層1物理層（physical layer，PHY層）、層2數(shù)據(jù)鏈路層、層3無線資源控制層（radio resource control，RRC層）。其中，層2數(shù)據(jù)鏈路層又被劃分為以下幾個子層：媒體接入控制（media access control，MAC）子層、無線鏈路控制（radio link control，RLC）子層和分組數(shù)據(jù)匯聚協(xié)議（packet data convergence protocol，PDCP）子層［2］。

PHY層的主要功能是完成對數(shù)據(jù)的無線處理過程；數(shù)據(jù)鏈路層的主要任務是完成在發(fā)送或接收過程對數(shù)據(jù)的處理和控制；RRC層的主要功能是控制整個LTE系統(tǒng)的工作狀態(tài)。本文主要闡述的是協(xié)議棧的主體即整個數(shù)據(jù)鏈路層對數(shù)據(jù)的處理過程及實現(xiàn)方法。

圖1 協(xié)議棧的分層結(jié)構(gòu)

最新的無線通信協(xié)議包括LTE協(xié)議都是支持全IP協(xié)議標準，并且使用標準的協(xié)議棧如TCP／IP協(xié)議棧［3］，所以數(shù)據(jù)鏈路層中PDCP子層的主要功能是實現(xiàn)LTE系統(tǒng)對IP數(shù)據(jù)包的兼容，即完成對IP包的封裝并組成本層的通信單元 PDCP協(xié)議數(shù)據(jù)單元（protocol data unit，PDU）［4］。RLC子層主要功能是對PDCP PDU進行分段和級聯(lián)組成RLC PDU，以保證PDU的大小符合無線TB（transport block）幀的格式要求。MAC子層的功能是將不同信道的信息復用并添加相應的頭部后組成MAC PDU，最后添加相應的CRC校驗組成物理層的發(fā)送幀［5］，并利用物理層的發(fā)送功能進行發(fā)送。

2 協(xié)議棧的設計與實現(xiàn)

根據(jù)LTE協(xié)議棧層次的劃分，在對協(xié)議棧的空中接口層2的實現(xiàn)時過程中，對整體的處理過程分為3個處理模塊：PDCP模塊、RLC模塊、MAC模塊，分別對應3個子層。

2.1 PDCP子層的設計

PDCP子層的主要功能是完成對IP數(shù)據(jù)封裝，而在嵌入式程序開發(fā)中通常使用lwIP作為 TCP／IP協(xié)議棧［6－7］。lwIP協(xié)議中的采用的是pbuf結(jié)構(gòu)。本文在進行PDCP子層的設計和實現(xiàn)時，引入了這個結(jié)構(gòu)，以保證IP數(shù)據(jù)包的完整性。此外，為完成PDCP子層的發(fā)送端的功能，采用雙緩沖隊列，分別是處理緩沖隊列和發(fā)送緩沖隊列。其中，處理緩沖隊列的主要作用是緩存將要進行處理的IP數(shù)據(jù)，隊列結(jié)點定義為pdcp＿sdu結(jié)點，如圖2所示。發(fā)送緩沖隊列的主要作用緩存封裝好的SDU，待下層允許發(fā)送時再進行發(fā)送，該結(jié)點與緩沖隊列結(jié)點定義類似，也是采用鏈表實現(xiàn)。

圖2 處理緩沖隊列結(jié)構(gòu)定義

每當PDCP子層收到一個lwIP數(shù)據(jù)的pbuf結(jié)點時，都將生成一個pdcp＿sdu結(jié)點，并將生成的sdu結(jié)點插入到處理緩沖隊列尾部等待封裝處理。而在對處理緩沖隊列進行封裝處理時，根據(jù)緩沖隊列結(jié)點的sn值和pbuf結(jié)點生成發(fā)送隊列結(jié)點pdcp＿pdu，并插入到發(fā)送緩沖隊列尾部。最后在允許發(fā)送時，通過調(diào)用下層函數(shù)將生成的PDU的有效數(shù)據(jù)進行發(fā)送。PDCP子層發(fā)送端的數(shù)據(jù)處理過程如圖3所示。

圖3 PDCP子層發(fā)送端數(shù)據(jù)處理流程

在接收端的PDCP的對等實體中，接收的數(shù)據(jù)是PDCP PDU，所以設計了一個由pdcp＿pdu結(jié)點組成的隊列來構(gòu)成PDCP子層的接收窗口。圖4給出了PDCP接收端處理流程圖，其中最重要的部分是根據(jù)sn值進行窗口排序，并按照順序提交［8］。盡管有RLC子層保證數(shù)據(jù)的有效傳輸，但是依然存在數(shù)據(jù)丟失的情況。如果確實有數(shù)據(jù)始終沒有接收到，并且已經(jīng)超時（通過定時器和中斷控制器協(xié)同完成），則直接跳過等待數(shù)據(jù)并進入下一個編號為sn＋1的pdu的接收或處理。

圖4 PDCP子層接收端數(shù)據(jù)處理流程

相對于標準協(xié)議的設計，本文在設計PDCP子層時去除了健壯性頭壓縮（robust of header compress，ROHC）功能和加密功能。因為ROHC主要針對VoIP數(shù)據(jù)進行數(shù)據(jù)壓縮［9］，而在該系統(tǒng)中，沒有VoIP數(shù)據(jù)且傳輸?shù)腎P數(shù)據(jù)包都比較大。而在數(shù)據(jù)包比較大時IP頭壓縮并不能帶來明顯的性能提升，反而消耗處理器資源，降低其性能。去除加密是因為此系統(tǒng)對安全性可以由TCP／IP網(wǎng)絡保證。

2.2 RLC子層的設計

RLC子層為上層提供可靠的傳輸服務，分為3種模式：透明模式（transparent mode，TM）、無確認模式（un－acknowledgement mode，UM）、確認模式（acknowledgement mode，AM）［10］。TM模式對數(shù)據(jù)不做任何處理，而UM模式的處理方式和AM模式類似且要簡單，所以本文重點介紹AM的實現(xiàn)過程。

在設計實現(xiàn)RLC AM發(fā)送端時，依然采用雙緩沖隊列，分別是處理緩沖隊列和發(fā)送緩沖隊列。每次收到上層發(fā)送PDCP PDU的請求時，函數(shù)將PDCP PDU的有效數(shù)據(jù)放到處理緩沖隊列中。RLC子層的處理函數(shù)將緩沖隊列中的數(shù)據(jù)依次進行封裝成大小一致的RLC PDU并放入到發(fā)送緩沖隊列。在允許發(fā)送的時刻，RLC子層按照發(fā)送窗口的要求進行發(fā)送，而發(fā)送窗口只是利用了發(fā)送緩沖隊列的一部分。

圖5給出了RLC子層AM模式工作流程圖，其中重傳緩沖區(qū)是實現(xiàn)ARQ（自動重傳請求）功能重要組成部分。ARQ功能的實現(xiàn)過程是RlcArq（）處理函數(shù)根據(jù)收到來自接收端的狀態(tài)報告［11］，將發(fā)送窗口中沒有得到確認的RLC PDU數(shù)據(jù)拷貝至重傳緩沖區(qū)（實際為了節(jié)省內(nèi)存在實現(xiàn)過程中只拷貝了指向相應的PDU指針）。在發(fā)送端將重傳緩沖區(qū)中數(shù)據(jù)部分發(fā)送完成之后，需要及時將AMD PDU的輪詢字段（Poll字段）置1，通知接收端對所接收的數(shù)據(jù)進行狀態(tài)報告［12］。

圖5 RLC子層AM模式數(shù)據(jù)發(fā)送流程

與RLC發(fā)送端一樣，在RLC接收端，也設計了一個隊列來實現(xiàn)接收窗口，它的大小和形式與發(fā)送端發(fā)送緩沖隊列一致。通過調(diào)整接收指針來保證與發(fā)送端匹配工作完成數(shù)據(jù)接收。另外在接收到數(shù)據(jù)時會根據(jù)輪詢字段的值，對是否生成狀態(tài)報告進行判斷。如果輪詢字段為1且SN處于接收窗口內(nèi)，就生成狀態(tài)報告，發(fā)送給發(fā)送端。

2.3 MAC子層的設計

MAC層一個重要功能是復用和解復用［13］。所謂復用即是將來自不同信道中的數(shù)據(jù)通過編碼，封裝到相應的MAC包中。圖6給出MAC層的發(fā)送過程流程圖。

在MAC層發(fā)送端，沿用了前面介紹的雙緩沖隊列。但如果發(fā)送的是RLC PDU，則它的大小和TB塊大小相同，可以直接調(diào)用物理層功能進行發(fā)送。如果是其它信道的MAC業(yè)務數(shù)據(jù)單元（service data unit，SDU），需要先將其放入到緩沖隊列中，然后根據(jù)按先后順序封裝到大小合適的MAC PDU中，再進行發(fā)送。

接收端的解復用恰恰是一個相反的過程，即根據(jù)MAC子頭中的信息，恢復出原始數(shù)據(jù)，并將數(shù)據(jù)遞放到緩沖隊列中，利用分發(fā)函數(shù)將數(shù)據(jù)傳遞給相應的操作過程。

圖6 MAC子層發(fā)送流程

3 系統(tǒng)硬件結(jié)構(gòu)

硬件平臺采用的是Xilinx公司的Virtex－6ML605FPGA開發(fā)板。圖7給出了系統(tǒng)的硬件結(jié)構(gòu)圖。ML605開發(fā)板提供了高性能的FPGA，該芯片內(nèi)部有MicroBlaze軟核處理器，并提供了DDR3內(nèi)存控制器、以太網(wǎng)控制器、串口控制器、中斷控制器、定時器、Aurora等外圍設備。其中在以太網(wǎng)部分，BSP（Board Support Package，板級支持包）中提供了lwIP的功能；Aurora是實現(xiàn)兩塊開發(fā)板互連通信的串行高速接口。圖7中的LTE＿TX和LTE＿RX是LTE物理層的發(fā)送和接收鏈路知識產(chǎn)權(quán)（Intellectual Property，IP）核，其中LTE＿TX發(fā)送鏈路完成對數(shù)據(jù)的編碼、調(diào)制、映射與發(fā)送，而LTE＿RX完成對數(shù)據(jù)的接收、解映射、解調(diào)與解碼過程。

圖7 系統(tǒng)硬件結(jié)構(gòu)

4 系統(tǒng)測試

本系統(tǒng)的測試以開發(fā)板上的網(wǎng)口作為UE的數(shù)據(jù)來源，調(diào)用網(wǎng)口的lwIP協(xié)議編寫了一個上層的應用程序，以實現(xiàn)對網(wǎng)口數(shù)據(jù)的捕獲和預處理；利用開發(fā)板提供的AURORA模塊，并用兩組SMA線將兩塊板上的TX、RX的N端和P端分別進行連接。系統(tǒng)測試框圖如圖8所示：在1號微機（PC1）和2號微機（PC2）上分別用VLC軟件將視頻進行編碼發(fā)送和接收顯示。

測試方案共兩種，第一種是數(shù)據(jù)通過LTE物理層鏈路后用AURORA模塊連接，在LTE鏈路采用不同的編碼方式和不同發(fā)送速率下測試協(xié)議棧的處理速率；第二種是數(shù)據(jù)不通過LTE物理層鏈路而是直接利用AURORA模塊發(fā)送到接收端，在不同發(fā)送速率下測試協(xié)議棧的處理速率。測試結(jié)果見表1。

表1 協(xié)議棧處理速率測試結(jié)果

從表1中可以看出，當LTE物理鏈路采用最高速度的64QAM編碼，且發(fā)送速率為13Mbps時，通過LTE物理層時，測試結(jié)果是有TB溢出，說明此時傳輸速率是受限于物理層。而不通過LTE鏈路，直接用AURORA模塊傳送數(shù)據(jù)時，協(xié)議棧的速率最高可以達到15.5Mbps。由此也證明協(xié)議棧的速率是完全滿足該系統(tǒng)LTE物理鏈路的收發(fā)速率要求。

5 結(jié)束語

本文以Virtex－6ML605的開發(fā)板為硬件環(huán)境，采用雙緩沖機制，成功開發(fā)并實現(xiàn)了一個可以在MicroBlaze軟核上正常工作的LTE空中接口協(xié)議棧。雖然經(jīng)過精簡，但是作為一個數(shù)據(jù)通信所依賴的協(xié)議，依然能夠在保證速率的基礎上為數(shù)據(jù)提供可靠的傳輸。最后通過對協(xié)議棧的測試實驗，表明這種實現(xiàn)協(xié)議棧的方法是有效的，同時也表明該實現(xiàn)完全滿足采用LTE技術(shù)的小型無線通信系統(tǒng)對于傳輸數(shù)據(jù)速率的要求。而在未來的通訊發(fā)展中，隨著LTE技術(shù)的推廣和應用，這種面向小型設備的LTE空中接口協(xié)議棧的研究和實現(xiàn)有很廣泛的現(xiàn)實意義和應用前景。

［1］ZHAO Xunwei，LIN Hui，ZHANG Ming，et al.3GPP long term evolution：architecture and specification［M］.Beijing：Post ＆ Telecom Press，2010（in Chinese）.［趙訓威，林輝，張明，等.3GPP長期演進（LTE）系統(tǒng)架構(gòu)與技術(shù)規(guī)范［M］.北京：人民郵電出版社，2010.］

［2］3GPP TS 36.300V9.4.0.Evolved universal terrestrial radio access（E－UTRA）and evolved universal terrestrial radio access network（E－UTRAN）；Overall description；Stage 2［S］.

［3］Vijay T Raisinghani，Sridhar Iyer.Cross－layer design optimizations in wireless protocol stacks［J］.Computer Communications，2004，27（8）：720－724.

［4］ZHANG Xincheng，TIAN Tao，ZHOU Xiaojin，et al.LTE air－interface technology and performance［M］.Beijng：Post ＆ Telecom Press，2009（in Chinese）.［張新程，田韜，周曉津，等.LTE空中接口技術(shù)與性能［M］.北京：人民郵電出版社，2009.］

［5］Anna Larmo，Magnus Lindstrm，Michael Meyer，et al.The LTE link－layer design［J］.IEEE Communications Magazine，2009，47（4）：52－59.

［6］XILINX.lwIP 1.3.0Library（v3.00.a）［EB／OL］.［2010－10－5／2012－03－15］.http：／／www.xilinx.com／support／documentation／sw＿manuals／xilinx12＿4／oslib＿rm.pdf.

［7］Stephen MacMahon，Nan Zang，Anirudha Sarangi.Light－Weight IP（lwIP）application examples［EB／OL］.［2011－04－21／2012－03－15］.http：／／www.xilinx.com／support／documentation／application＿notes／xapp1026.pdf.

［8］3GPP TS 36.323V9.0.0.Evolved universal terrestrial radio access（E－UTRA）；Packet data convergence protocol（PDCP）specification［S］.

［9］SUN Yuanxin，HANG Xiaofei，ZHANG Xuemei.Function of PDCP sublayer in LTE system［J］.Modern Electronics Technique，2011，34（7）：44－48（in Chinese）.［孫遠欣，杭小飛，張雪梅.LTE系統(tǒng)中PDCP子層功能研究［J］.現(xiàn)代電子技術(shù)，2011，34（7）：44－48.］

［10］3GPP TS36.322V9.2.0.Evolved universal terrestrial radio access（E－UTRA）；Radio link control（RLC）protocol specification［S］.

［11］Luis Alonso，Ramon Agusti.LTE，Optimization of wireless communication systems using cross－layer information［J］.Signal Processing，2006，86（8）：1755－1772.

［12］LI Zeyong，ZHAO Guohui.Research and implementation of RLC Layer in LTE protocol stack［J］.Digital Communication，2012，38（1）：48－51（in Chinese）.［李責勇，趙國會.LTE協(xié)議棧RLC層的研究與實現(xiàn)［J］.數(shù)字通信，2012，38（1）：48－51.］

［13］3GPP TS36.321V9.2.0.Evolved universal terrestrial radio access（E－UTRA）；Medium access control（MAC）protocol specification［S］.