999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

LTE空中接口協議棧的研究與實現

2013-11-30 05:01:16何蘇勤翟海超
計算機工程與設計 2013年1期
關鍵詞:功能

何蘇勤,翟海超

(北京化工大學 信息科學與技術學院,北京100029)

0 引 言

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

1 協議棧的構成

LTE系統中存在3個子層,如圖1所示,分別是:層1物理層(physical layer,PHY層)、層2數據鏈路層、層3無線資源控制層(radio resource control,RRC層)。其中,層2數據鏈路層又被劃分為以下幾個子層:媒體接入控制(media access control,MAC)子層、無線鏈路控制(radio link control,RLC)子層和分組數據匯聚協議(packet data convergence protocol,PDCP)子層[2]。

PHY層的主要功能是完成對數據的無線處理過程;數據鏈路層的主要任務是完成在發送或接收過程對數據的處理和控制;RRC層的主要功能是控制整個LTE系統的工作狀態。本文主要闡述的是協議棧的主體即整個數據鏈路層對數據的處理過程及實現方法。

圖1 協議棧的分層結構

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

2 協議棧的設計與實現

根據LTE協議棧層次的劃分,在對協議棧的空中接口層2的實現時過程中,對整體的處理過程分為3個處理模塊:PDCP模塊、RLC模塊、MAC模塊,分別對應3個子層。

2.1 PDCP子層的設計

PDCP子層的主要功能是完成對IP數據封裝,而在嵌入式程序開發中通常使用lwIP作為 TCP/IP協議棧[6-7]。lwIP協議中的采用的是pbuf結構。本文在進行PDCP子層的設計和實現時,引入了這個結構,以保證IP數據包的完整性。此外,為完成PDCP子層的發送端的功能,采用雙緩沖隊列,分別是處理緩沖隊列和發送緩沖隊列。其中,處理緩沖隊列的主要作用是緩存將要進行處理的IP數據,隊列結點定義為pdcp_sdu結點,如圖2所示。發送緩沖隊列的主要作用緩存封裝好的SDU,待下層允許發送時再進行發送,該結點與緩沖隊列結點定義類似,也是采用鏈表實現。

圖2 處理緩沖隊列結構定義

每當PDCP子層收到一個lwIP數據的pbuf結點時,都將生成一個pdcp_sdu結點,并將生成的sdu結點插入到處理緩沖隊列尾部等待封裝處理。而在對處理緩沖隊列進行封裝處理時,根據緩沖隊列結點的sn值和pbuf結點生成發送隊列結點pdcp_pdu,并插入到發送緩沖隊列尾部。最后在允許發送時,通過調用下層函數將生成的PDU的有效數據進行發送。PDCP子層發送端的數據處理過程如圖3所示。

圖3 PDCP子層發送端數據處理流程

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

圖4 PDCP子層接收端數據處理流程

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

2.2 RLC子層的設計

RLC子層為上層提供可靠的傳輸服務,分為3種模式:透明模式(transparent mode,TM)、無確認模式(un-acknowledgement mode,UM)、確認模式(acknowledgement mode,AM)[10]。TM模式對數據不做任何處理,而UM模式的處理方式和AM模式類似且要簡單,所以本文重點介紹AM的實現過程。

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

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

圖5 RLC子層AM模式數據發送流程

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

2.3 MAC子層的設計

MAC層一個重要功能是復用和解復用[13]。所謂復用即是將來自不同信道中的數據通過編碼,封裝到相應的MAC包中。圖6給出MAC層的發送過程流程圖。

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

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

圖6 MAC子層發送流程

3 系統硬件結構

硬件平臺采用的是Xilinx公司的Virtex-6ML605FPGA開發板。圖7給出了系統的硬件結構圖。ML605開發板提供了高性能的FPGA,該芯片內部有MicroBlaze軟核處理器,并提供了DDR3內存控制器、以太網控制器、串口控制器、中斷控制器、定時器、Aurora等外圍設備。其中在以太網部分,BSP(Board Support Package,板級支持包)中提供了lwIP的功能;Aurora是實現兩塊開發板互連通信的串行高速接口。圖7中的LTE_TX和LTE_RX是LTE物理層的發送和接收鏈路知識產權(Intellectual Property,IP)核,其中LTE_TX發送鏈路完成對數據的編碼、調制、映射與發送,而LTE_RX完成對數據的接收、解映射、解調與解碼過程。

圖7 系統硬件結構

4 系統測試

本系統的測試以開發板上的網口作為UE的數據來源,調用網口的lwIP協議編寫了一個上層的應用程序,以實現對網口數據的捕獲和預處理;利用開發板提供的AURORA模塊,并用兩組SMA線將兩塊板上的TX、RX的N端和P端分別進行連接。系統測試框圖如圖8所示:在1號微機(PC1)和2號微機(PC2)上分別用VLC軟件將視頻進行編碼發送和接收顯示。

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

表1 協議棧處理速率測試結果

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

5 結束語

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

[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)系統架構與技術規范[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空中接口技術與性能[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系統中PDCP子層功能研究[J].現代電子技術,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協議棧RLC層的研究與實現[J].數字通信,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].

猜你喜歡
功能
拆解復雜功能
鐘表(2023年5期)2023-10-27 04:20:44
也談詩的“功能”
中華詩詞(2022年6期)2022-12-31 06:41:24
基層弄虛作假的“新功能取向”
當代陜西(2021年21期)2022-01-19 02:00:26
深刻理解功能關系
鉗把功能創新實踐應用
關于非首都功能疏解的幾點思考
基于PMC窗口功能實現設備同步刷刀功能
懷孕了,凝血功能怎么變?
媽媽寶寶(2017年2期)2017-02-21 01:21:24
“簡直”和“幾乎”的表達功能
中西醫結合治療甲狀腺功能亢進癥31例
主站蜘蛛池模板: 麻豆国产精品| 日韩欧美国产精品| 久久久精品国产SM调教网站| 亚洲婷婷丁香| 一级毛片免费高清视频| 亚洲无码A视频在线| 日韩精品一区二区三区swag| 中国黄色一级视频| 人人爱天天做夜夜爽| 欧美日韩国产在线观看一区二区三区| 免费一级毛片在线观看| 亚洲bt欧美bt精品| 亚洲男人的天堂久久香蕉| 熟妇无码人妻| 狠狠做深爱婷婷综合一区| 亚洲一级毛片在线观| 午夜激情福利视频| 国产Av无码精品色午夜| 91亚洲免费| h网站在线播放| 免费中文字幕在在线不卡| 亚洲无限乱码一二三四区| 日本黄色不卡视频| 亚洲国产日韩一区| 国产精品网址你懂的| 国产不卡一级毛片视频| 亚洲永久免费网站| 毛片最新网址| 少妇人妻无码首页| 456亚洲人成高清在线| 国产系列在线| 福利国产在线| 91成人在线免费视频| 99久久国产综合精品2023| 在线亚洲精品自拍| 日本亚洲成高清一区二区三区| 久久久久青草大香线综合精品| 色哟哟色院91精品网站| av尤物免费在线观看| 欧美日韩中文字幕在线| 亚洲精品波多野结衣| 午夜视频免费一区二区在线看| 日韩成人在线一区二区| 日韩福利在线观看| 福利小视频在线播放| 3p叠罗汉国产精品久久| 亚洲精品欧美重口| 思思热在线视频精品| 激情亚洲天堂| 噜噜噜综合亚洲| 玖玖精品视频在线观看| 91精品人妻一区二区| 久久婷婷人人澡人人爱91| 国内嫩模私拍精品视频| 99久久这里只精品麻豆| 国产最爽的乱婬视频国语对白| 成人午夜福利视频| 国产最爽的乱婬视频国语对白| 亚洲手机在线| 国产成人精品日本亚洲| 亚洲天堂网在线视频| 四虎影视库国产精品一区| 99久久精品免费视频| 欧美日韩精品一区二区视频| 国产精品女熟高潮视频| 国产麻豆aⅴ精品无码| 亚洲日韩AV无码一区二区三区人| 久久精品人妻中文系列| 午夜国产精品视频黄| 伊人五月丁香综合AⅤ| 欧美性精品| 亚洲欧美另类中文字幕| 一本大道香蕉高清久久| 欧美www在线观看| 区国产精品搜索视频| 九九线精品视频在线观看| 久久久久久久久久国产精品| 精品视频免费在线| 高清不卡一区二区三区香蕉| 永久免费无码日韩视频| 呦视频在线一区二区三区| 免费在线成人网|