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

何蘇勤，翟海超

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

0 引 言

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

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

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

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

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

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

2 協(xié)議棧的設(shè)計(jì)與實(shí)現(xiàn)

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

2.1 PDCP子層的設(shè)計(jì)

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

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

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

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

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

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

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

2.2 RLC子層的設(shè)計(jì)

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

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

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

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

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

2.3 MAC子層的設(shè)計(jì)

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

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

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

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

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

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

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

4 系統(tǒng)測(cè)試

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

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

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

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

5 結(jié)束語(yǔ)

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

［1］ZHAO Xunwei，LIN Hui，ZHANG Ming，et al.3GPP long term evolution：architecture and specification［M］.Beijing：Post ＆ Telecom Press，2010（in Chinese）.［趙訓(xùn)威，林輝，張明，等.3GPP長(zhǎng)期演進(jìn)（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）.［孫遠(yuǎn)欣，杭小飛，張雪梅.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）.［李責(zé)勇，趙國(guó)會(huì).LTE協(xié)議棧RLC層的研究與實(shí)現(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］.