【正文】 隨后驗證生成的MATLAB代碼。初步進行的實驗測量是由MATLAB的輸出保存到磁盤，使用此文件作為USRP2輸入源，同時用一個傳統(tǒng)的無線信號接收器解碼傳輸信號。在這些試運行中我們在USRP2固件互換同步和正交上變頻的過程發(fā)現(xiàn)一個錯誤。這個路由錯誤已經(jīng)被Ettus Research LLC開發(fā)者修正的最近的固件版本所更正。實驗設(shè)備的完整版本信息見表1。表1DEVELOPMENTSYSTEM 細節(jié)分布Ubuntu 內(nèi)核版本平臺x86 64bitGNURadio的版本Python版本USRP2硬件版本號0x0301USRP2固件版本r11370子板模型XCVR2450測試時載波頻率 (頻道176)圖1 編碼過程的流向圖。由此產(chǎn)生的復雜基帶樣品隨后上轉(zhuǎn)換 USRP和傳播版本2。在第二階段的發(fā)展我們逐步移植MATLAB編碼鏈GNURadio框架。一個重要目標是復用信號處理模塊盡可能在GNURadio中已經(jīng)可用。結(jié)果的表示流向圖如圖1所示。在此階段，關(guān)鍵是要明白是GNURadio區(qū)分基于流的操作和基于塊的操作。采用純粹的基于塊的MATLAB代碼的原始方法不是一個好的選擇，因為它會導致高度最優(yōu)化GNURadio代碼編碼過程的延遲。例如一個長幀由幾百個OFDM符號。純粹的基于塊的實現(xiàn)，編碼鏈中每個函數(shù)(由圖1)在為后續(xù)生產(chǎn)輸出塊之前將需要處理整個框架。這將禁止任何并行的編碼程序，從而增加了系統(tǒng)的延遲。繞過這個問題的一個簡單的解決方案是使用GNURadio調(diào)度程序，它能夠策劃輸入/輸出數(shù)據(jù)流處理模塊和控制所需之間的緩沖邏輯。在我們的例子中, 塊流的轉(zhuǎn)換發(fā)生在符號映射塊中。這一塊的輸入是一個完整的物理層協(xié)議數(shù)據(jù)單元 (PLCPDU)(塊編碼的比特在一個OFDM幀)。輸出是一個復雜的符號流( 48，見表2)。基本上，處理塊，跟隨的符號映射器把一塊復雜的符號–對應一個OFDM符號，對它們進行相應的轉(zhuǎn)換，為了鏈的后續(xù)處理立即輸出塊。對每個OFDM符號的幀重復此過程。然而，IEEE ，在每個OFDM符號：被映射在四個導頻子載波的每個OFDM符號的復雜的符號是不同的。他們根據(jù)一個特定的二進制序列改變極性，所以駕駛儀插入函數(shù)需要知道在該幀被加工的符號。為了考慮到這些特殊的編碼規(guī)則，我們在導頻插入處理塊中實現(xiàn)了內(nèi)部的全局計數(shù)器。表2 OFDMKEY參數(shù),根據(jù)草稿標準文檔[6]數(shù)據(jù)子載波的數(shù)量48導頻子載波的數(shù)目4子載波的頻率間隔占用帶寬短序列的持續(xù)時間16μs長序列的持續(xù)時間16μs序列的保護間隔PLCP報頭的持續(xù)時間32μs保護間隔的持續(xù)時間OFDM符號的持續(xù)時間8μs3 驗證結(jié)果第三階段的發(fā)展是致力于最終質(zhì)量的全面實施，檢查（基帶編碼器加前端）使用空中測量。我們使用臺式電腦4 GBytes的RAM和一個英特爾酷睿2雙核E8400 CPU時鐘頻率為3兆赫運行了發(fā)射機的代碼。綜合1000BASET以太網(wǎng)接口連接到USRP2， GHz [ 2 ] 的xcvr2450子板。我們的系統(tǒng)更多的細節(jié)總結(jié)在表Ⅰ中。測量活動是結(jié)合使用的各種方法進行：首先，我們使用二臺機器連接到另一個USRP2向下轉(zhuǎn)換和記錄發(fā)送信號。這樣做是為了評估得到的功率譜的形狀在發(fā)射機輸出。第二，[ 7 ] 。第三，基于一種修改的Atheros的芯片組。該設(shè)備正在使用中的一切項目[ 8 ]和[ 9 ]請由維也納理工大學通信與射頻工程所提供給我們。整個活動的非時變和無干擾的信道測量是在固定功率衰減器組合使用直接電纜連接的發(fā)射機和接收機單元之間建立。A．Tx功率譜形狀圖2和圖3所示的結(jié)果表明在傳輸我們GNURADIO的實現(xiàn)和產(chǎn)業(yè)的原型芯片組之間的功率譜的差異。它們對應于輸出的FFT頻譜分析儀的工具，包括在GNURADIO的框架，在這兩種情況下的傳輸信號包括最大長度的幀，使用低傳輸為連續(xù)產(chǎn)生的增益水平避免放大器中的非線性。顯然，該GNURADIO的譜包含在fc177。6MHz的，不是在Atheros的頻譜峰。此外，在主帶的邊緣頻率（fc177。4MHz）的衰減，在fc強曲率可見。我們認為，這些缺陷的功率譜的形狀是由于版輥的上轉(zhuǎn)換處理的USRP2插值濾波器的特性。這個問題可以通過插值已經(jīng)在GNURADIO的編碼器部分和使用較低的插值因子在USRP2固定。注意圖2中GNURADIO的發(fā)射信號似乎也包含載波分量在Atheros譜fc = （我們將在第IIIC的后果）。B．幀錯誤率與信噪比性能這兩個并排比較發(fā)射源如圖4所示。這些測量曲線描繪的幀錯誤率的觀察（Atheros芯片組提供了一個衡量的接收信噪比的信號強度（RSSI）讀出）。大膽的曲線與FTW GNURADIO的發(fā)射機的性能，每個測量點對應的105發(fā)送幀。雖然我們在圖2和圖3的功率譜的形狀顯然是次優(yōu)的實施表明。這表明該USRP2本地振蕩器漂移和相位噪聲特性與行業(yè)的芯片組。圖2 的GNURADIO的實現(xiàn)功率譜，第二USRP2記錄。衰減的直接電纜連接，USRP2 TX增益5dB，載波頻率fc = 5880mhz。紅色的線對應于一級頻譜掩模。圖3 基于原型Atheros的功率譜，與USRP2記錄。再次，直接電纜連接采用低增益的發(fā)射機設(shè)置組合。C．基帶信號分析然而，當使用GNURADIO的發(fā)射機在高信噪比（在圖4 21dB）Atheros接收機中開始出現(xiàn)一些意想不到的行為。例如被檢測（但損壞）的幀的數(shù)目超過實際發(fā)送的幀的數(shù)目和FER測量方法變得不可用（因此失分超過圖4 21dB為GNURADIO的發(fā)射機）。我們推測，這種現(xiàn)象的主要原因是虛假的排放是目前不斷的USRP2輸出盡快GNURADIO的編碼器軟件初始化子卡的硬件。它觸發(fā)了載波偵聽機制在Atheros芯片組的結(jié)果在接收器邏輯試圖同步的雜散信號和失蹤的實際幀傳輸。圖4 這個數(shù)字顯示的幀錯誤率超過接收信噪比在非時變使用兩種類型的發(fā)射器，無干擾信道。在這兩種情況下，一個程式的原型是用來解碼幀計算接收信號強度（RSSI讀數(shù)）。一個1612bytes每幀的最大層長度，由1574bytes MSDU負荷，30個字節(jié)的MAC頭和4字節(jié)的CRC是用于測量運行在這個數(shù)字了。圖5和圖6所示的比較證實了這一假說。復雜的數(shù)字基帶信號是由GNURADIO的編碼器發(fā)送到uspr2（圖5）不包含任何直流分量。經(jīng)過轉(zhuǎn)換，傳輸，接收和下變頻（在接收端使用另一個USRP2）的直流分量是目前全時間的發(fā)射機側(cè)USRP2活性（圖6）。這個問題不能適應GNURADIO的編碼器軟件是由xcvr2450子板固定容易引起的。圖5 在發(fā)送到uspr2上轉(zhuǎn)換和傳輸一幀的復基帶數(shù)字表示的大小。圖6 同樣的框架如圖5在數(shù)字上變頻，傳輸，接收和數(shù)字下變頻。那是在幀突發(fā)了可見的直流分量，很可能是由缺陷引起的xcvr2450子板。4 結(jié)論和未來的工作我們已經(jīng)展示了一種快速原型的一個完全符合標準的OFDM幀的編碼器使用GNURADIO的框架和通用軟件無線電外設(shè)（2版）。由于實際的編碼過程涉及到大量復雜的處理步驟是分開的開發(fā)方法為連續(xù)的階段的關(guān)鍵。首先，在高級語言中一個參考設(shè)計是來自標準的文件。隨后，一部分的參考編碼器移植到目標平臺在一步一步地。最后基于測量的評估階段使用標準兼容的接收機完成開發(fā)過程。由此產(chǎn)生的基礎(chǔ)是GNURADIO的發(fā)射器能夠生成OFDM幀完全符合IEEE 。我們的下一個目標是在GNURADIO的實施互補OFDM幀的解碼器。該接收機與發(fā)射機實現(xiàn)合并將一個完全交互式的軟件無線電收發(fā)器，包括基本的介質(zhì)訪問的功能如載波檢測和確認幀傳輸提供依據(jù)。一個重要的目標就是盡可能地靠近嚴格的幀定時約束，需要維護，為了符合IEEE 。參考文獻[1] 官方GNU軟件無線電的網(wǎng)站 。[2] Ettus研究有限公司網(wǎng)站 。[3] 。[4] IEEE （MAC）和物理層（PHY）規(guī)格。[5]無線局域網(wǎng)介質(zhì)訪問控制（MAC）和物理層（PHY）規(guī)格修訂8：[6] rt2500芯片設(shè)備清單 [7]CVIS的項目網(wǎng)站 [8]通信和射頻工程學院，維也納理工大學 HTTP：附錄B 外文文獻IEEE Transmission Using GNURadioAbstractIn this work we present an implementation of a fully functional IEEE transmitter in softwaredefined radio. We describe the rapidprototyping methodology that was used to implement the frameencoder within the opensource GNU Software Radio (GNURadio) platform [1]. The encoder generates OFDM frames in digital plex baseband representation and uses the USRP2 [2] as digitaltoanalog frontend for upconversion and final transmission. Since the actual encoding process involves a large number of plex steps we split the development approach into three sequential stages. First, a referenceencoder in a highlevel language (MATLAB) is derived from the IEEE standard documents. Second, the individual blocks of the MATLAB encoding chain are progressively ported to GNURadio, crosschecking with the reference after each step. Finally, standard pliance is verified by conducting parative overtheair measurements with an early prototype of a mercial 11p transceiver. Initial measurement results indicate that the fidelity of the resulting GNURadio implementation is on par with nonsoftwaredefined radio industry solutions and capable of generating truly standardpliant OFDM frames. The encoder presented here has been released under GPLv3 and is also capable of encoding frames according to the 11a and 11g amendments, thus making it a valuable building block for uping softwaredefined radio projects.I. INTRODUCTION AND RELATED WORKThe IEEE standard (which will be finalized in late 2010 [3]) aims at providing reliable wireless munication for vehicular environments. It will serve as an underlying protocol for future cartocar and cartoinfrastructure applications worldwide. At the physical layer it has essentially the same structure as and : the modulation format, based on orthogonal frequencydivision multiplexing(OFDM), the forwarderrorcorrection (FEC), the structure of the preamblesequences and the pilotsymbol schemes are identical. Furthermore, uses the same medium access scheme mon to all IEEE standards, known as carrier sensing multiple access with collision avoidance (CSMA/CA) [4].In the current draft version of the standard, the frame encoding procedure for IEEE differs from 11a and 11g only in two key aspects: the operating frequencyband is shifted to around and the duration of OFDM symbols is doubled from 4μs to 8μs. The rationale behind