802 11p_ivc

UNIVERSITA DELSALENTO

Implementation of an IEEE 802.11ptransmitter in open-source SoftwareDefined Radio

Relatore: Fabio RICCIATO

Laureando: Andrea COSTANTINI

A.A. 2008/2009

Acknowledgements

This thesis would have not been possible without the kind support, the trenchantcritiques, the probing questions, and the remarkable patience of my thesis advisorFABIO RICCIATO. He gave me the great opportunity to study in the beautifoul cityof Vienna in ftw. Here I have known fantastic people who will remain forever in myheart.

I am grateful to Danilo Valerio for being so good to me. I shared with him mostof my problems. He was beside me in every step of my work and he helped me toovercome several problems. He showed me to be a sincere friend more than once.Thank DANILO!

I would like to thank also THOMAS ZEMEN. He gave me the chance to work sideby side with the “signal processing” guys. I would like to thank particularly PAOLOCASTIGLIONE and PAUL FUXJAEGER, who taught me the secrets of OFDMtransmission and excellent working methods!

Last but not least I would like to thank GIAMMARCO ZACHEO and ALESSAN-DRO D’ALCONZO, because they are just fantastic people and it was a pleasure towork and talk with them.

Thanks everybody!

Universita del Salento I

Ringraziamenti

Eccoci qua! Arrivati alla fine di questo lungo percorso di studio che sta per terminarecon il conseguimento della laurea specialistica.

Dopo tanti anni passati a studiare e sperare in un futuro migliore finalmente il primotraguardo della mia vita sta per essere raggiunto.

Arrivato a questo punto sono, ovviamente, d’obbligo i miei pi sentiti ringraziamentia tutti coloro che mi sono stati vicini in questi anni.

Vorrei cominciare (e non potrei fare altrimenti) ringraziando i miei cari GENITORIai quali devo tutto quello che sono riuscito a fare di buono nella mia vita. Lorosono stati per me degli ottimi maestri di vita (e credo che continueranno ad esserloper molti anni ancora). Mi hanno insegnato quali sono i veri valori della vita, mihanno insegnato che bisogna sempre battersi per i principi nei quali crediamo e anon mollare mai di fronte alle difficolt e ai problemi che la vita ci mette davantiogni giorno. Senza il conforto, l’aiuto, e il sostegno morale di loro due io credo chedifficilmente sarei riuscito a raggiungere questo traguardo. Grazie PAPA’, grazieMAMMA.

Ringrazio i miei due FRATELLINI, anche se ormai sono grandi e grossi pi di me.Li ringrazio per avermi sempre rotto le scatole e per avermi sempre disturbato inquesti anni di studio. Infatti con le loro litigate furibonde, i loro rumori molesti, ei loro inverosimili racconti, sono riusciti a movimentare ed alleviare le mie grigie enoiose giornate di studio. Grazie MARIA e grazie GIU’.

Un ringraziamento speciale va sicuramente a DANIELA, una ragazza veramente spe-ciale che riuscita a conquistarmi con la sua gentilezza e il suo amore. La ringraziodi cuore per aver sopportato per tutti questi anni le mie lamentele e le mie scon-tentezze. La ringrazio anche per tutti gli utili consigli che mi ha dato durante il miopercorso di studi e per avermi sostenuto nei momenti pi difficili. Grazie DANI.

Ringrazio tanto anche tutti gli ZII. Alcuni vicini e altri lontani, ma sempre tuttiattenti e interessati al mio percorso di studi. Loro mi hanno sempre sostenuto eaiutato in ogni momento della vita. Grazie zio PIERO, zia ANNA, VECCHIA, ziaTIZIANA e zio PIERINO.

Un grazie particolare alla famiglia CHIRONI e al distaccamento famiglia De LUME’(compresa la piccola nipotina in arrivo dal nome ancora da definire) i quali nel corsodi questi ultimi anni sono diventati la mia seconda famiglia. Anche loro mi sonostati sempre vicini e mi hanno confortato nei momenti pi bui. Grazie MPA’ LUIGI,ROSETTA,EUGENIO, SARA, VINCENZO e neo NIPOTINA (forse Elisa :)).

Ringrazio tutti gli AMICI dell’universit con i quali ho trascorso tanti anni fianco a

Universita del Salento II

fianco a studiare, a fare esami e a progettare il nostro futuro. Insieme a loro hosuperato tante difficolt che da solo non sarei mai e poi mai riuscito a superare. Gra-zie PIERO ANDRIULO, ALFONSO CARROZZO, ANDREA DONNO, DAVIDESARACINO, GIUSEPPE COCCIOLO, PATRIZIO PRIMICERI, ANNACHIAVASPAGNOLO, RINO, LINO, MARCELLO . e tutti coloro che ora non sto qui ascrivere perch sono veramente tanti.

Come dicono gli inglesi, last but not least e cio ultimi ma non per questo menoimportanti vorrei ringraziare tutti gli AMICI di una VITA (in particolare cucinuLUCIO amico fedele e sincero come nessun altro). Con loro ho condiviso tutte lepi belle esperienze della mia vita. Il loro sorriso e la loro amicizia vera sono statifondamentali sia durante tutto il corso della mia vita universitaria sia nella vitaquotidiana. Grazie CUCINU, EMANUELE, IVAN.

GRAZIE A TUTTI!!

Martano 2 gennaio 2010

Universita del Salento III

A me

e alla mia famiglia

Universita del Salento IV

Abstract

Abstract

This work aims at providing a tool for the empirical assessment of the IEEE 802.11pperformance. The main contribution is the implementation of a fully functionalsoftware-defined radio (SDR) 802.11p transmitter. We present the rapid-prototypingmethodology that was used to implement an 802.11p frame-encoder within the open-source GNU Software Radio (GnuRadio) platform as well as a detailed overview ofthe technologies involved. Finally, we show some preliminary results that indicatethe compliance of our transmitter with the physical layer requirements of the 802.11pstandard.

The developed code will be released under the GPL license on the comprehensive gnuradio archive network (CGRAN). We hope that the deployment of an SDR 802.11ptransmitter will help the research community to overcome the limitations and inac-curacies of the simulation environments, paving the way towards the deployment ofa complete 802.11p testbed for real-world performance assessment.

Universita del Salento V

CONTENTS

Contents

1 Introduction 4

2 IEEE 802.11 basics 6

2.1 Overview ............................................................................... 6

2.2 Physical layer ......................................................................... 7

2.3 Medium Access ....................................................................... 9

2.3.1 Basic Access Scheme ...................................................... 9

2.3.2 Virtual Carrier Sensing ................................................... 10

2.4 Frame Format ........................................................................ 11

2.5 IEEE 802.11p ......................................................................... 13

2.5.1 The basic OFDM concepts............................................... 13

2.5.2 Comparison between 802.11a and 802.11p ........................... 15

3 Software Defined Radio 17

3.1 Introduction ........................................................................... 17

3.2 Universal Software Radio Peripheral............................................ 19

3.2.1 Motherboard ................................................................ 19

3.2.2 FPGA ......................................................................... 20

3.2.3 ADC-DAC ................................................................... 22

3.2.4 Daughter boards............................................................ 23

Universita del Salento 1

CONTENTS

3.3 GnuRadio .............................................................................. 23

3.3.1 Architecture ................................................................. 25

3.3.2 Brief Flow Graph Overview ............................................. 26

3.3.3 Signal processing blocks .................................................. 27

3.3.4 Existing implementations ................................................ 28

4 IEEE 802.11p Implementation 31

4.1 Methodology adopted............................................................... 31

4.2 USRP2 testing/debugging ......................................................... 33

4.3 GnuRadio OFDM and 802.11p: State of the Art............................ 33

4.4 802.11p: From Data link layer to Physical layer ............................. 34

4.4.1 MAC and PLCP header .................................................. 34

4.4.2 CRC-32 ....................................................................... 35

4.4.3 Scrambler..................................................................... 36

4.4.4 Convolutional encoder .................................................... 36

4.4.5 Interleaver.................................................................... 37

4.4.6 Symbols mapping .......................................................... 38

4.4.7 Pilots insertion.............................................................. 39

4.4.8 Carrier permutation ....................................................... 40

4.4.9 IFFT, cyclic prefix and scaling ......................................... 40

4.4.10 Training sequence .......................................................... 41

4.4.11 From floating point numbers to E.M. waves ........................ 41

5 Testing and validation 44

5.1 Testbed Description ................................................................. 44

5.2 Results.................................................................................. 45


CONTENTS

5.2.1 Spectral shape .............................................................. 45

5.2.2 IEEE 802.11a transmission .............................................. 46

5.2.3 IEEE 802.11p transmission .............................................. 47

6 Conclusions 48

A MATLAB Code 49

B C++ code 59

C Python code 69

List of Abbreviations 78

List of Figures 81

References 81


CHAPTER 1. INTRODUCTION

Chapter 1

Introduction

In the last few years inter-vehicle communication has gained considerable interestin the research community. Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure(V2I) communication will play an important role in future automotive and trafficmanagement technologies. The final goal is to improve passenger safety and re-duce fatalities by providing services such as collision warning, electronic brake light,intersection control, etc.

Recently, the Institute of Electrical and Electronics Engineers (IEEE) created a newworking group aimed at defining a new standard for V2I and V2V communication,i.e. the IEEE 802.11p [1]. As suggested by the name, the IEEE 802.11p is an amend-ment to the IEEE 802.11 standard to add wireless access in vehicular environments.It defines enhancements to IEEE 802.11 required to support Intelligent Transporta-tion Systems (ITS) applications. This includes data exchange between high-speedvehicles and between the vehicles and the roadside infrastructure in the licensedITS band of 5.9 GHz (in the US). The IEEE 802.11p is still in development and ispart of the so-called Wireless Access for Vehicular Environment (WAVE) standard,which defines an architecture and a complementary standardized set of services andinterfaces.

Due to a lack of hardware implementations, most of the recent scientific works onV2V and V2I are based on simulations. However, the inaccuracy introduced bysimplistic channel and mobility models makes simulation tools unreliable for theevaluation of wireless standards in high-mobility scenarios.

In this thesis we developed a standard-compliant IEEE 802.11p transmitter by usingan open-source Software Defined Radio (SDR) platform, i.e. GnuRadio [2]. Theadvantages of using a SDR solution instead of a full-hardware implementation isgiven by its flexibility and its higher customizability.


The work presented in this thesis is part of a joint experimental activity carried outby the networking and signal processing groups at the Telecommunications ResearchCenter Vienna (FTW) - a Competence Center for Excellent Technologies supportedby the Austrian Government and the City of Vienna. In particular, the study hasbeen supported by the FTW strategic projects N0 and I0.

Part of the work was conducted in team. A workshop publication derived fromthe present work [3] will be presented at the 6th Karlsruhe workshop on SoftwareRadios.

This thesis contains six chapters and is organized as follows:

• Chapter 2 presents an overview of the IEEE 802.11 family of standards andexplores the extensions of the 802.11p amendment.

• Chapter 3 presents the platform that has been used for implementing the trans-mitter. Both hardware and software parts are described in details, highlightingadvantages and limitations of using SDR for testing wireless standards.

• Chapter 4 describes in details our GnuRadio 802.11p physical and data linklayer implementation.

• Chapter 5 presents experimental results of our transmitter, validating its com-pliance to the 802.11p standard.

• Chapter 6 presents the main conclusions and discusses future works/improvements.


CHAPTER 2. IEEE 802.11 BASICS

Chapter 2

IEEE 802.11 basics

2.1 Overview

IEEE 802.11 is a family of standards for Wireless Local Area Networks (WLAN). Itdefines design requirements for the MAC and PHY layer of WLAN transceivers. Theoriginal IEEE 802.11 specification was published on 1997 and provides a commonMAC layer specification on top of three different PHY layers. In the following years,in order to improve performance and security for different applications, the IEEEpublished several amendments (e.g. 802.11a, 802.11g, 802.11n, etc) supporting otherphysical layers.

The legacy IEEE 802.11 supported rates up to 2Mbps by using Frequency HoppingSpread Spectrum (FHSS), Direct Sequence Spread Spectrum (DSSS) and Infrared(IR). The IEEE 802.11a and IEEE 802.11g amendments added support for Orthog-onal Frequency Division Multiplexing (OFDM) for bit rates up to 54Mbps. Picture2.1 shows an overview of the 802.11 family in the context of the Open System In-terconnection model (OSI).

The 802.11 supports two different networking frameworks called respectively “ad-hoc” and “infrastructure” mode. In “Ad-hoc” mode, the wireless devices can directlycommunicate with each other in a peer-to-peer fashion without involving any centralnode (access point). In “infrastructure” mode, all the nodes communicate with awireless access point. The latter can be cabled to the wired network in order toallow access to network services, such as internet connections, printers, etc.


2.2. PHYSICAL LAYER

Figure 2.1: The IEEE 802 family

2.2 Physical layer

Due to the support of different transmission techniques, the PHY layer is split intotwo generic components: the Physical Layer Convergence Protocol (PLCP), whichdefines a method of mapping the IEEE 802.11 MAC sub-layer Protocol Data Units(MPDUs) into a framing format suitable to the medium, and a Physical MediumDependent (PMD) system, whose function defines the method of transmitting andreceiving data through the wireless medium.

LLC sublayer

Datalink layer

PMD_SAP

PLCP sublayer

PMD sublayer

Physical layer

PHY_SAP

MAC sublayer

Figure 2.2: The IEEE 802.11 physical and data link layers

The PLCP sub-layer adds a preamble and a header to each frame coming from theMAC layer. The structure of the PLCP header is showed in figure 2.3. It containsthe following fields:


2.2. PHYSICAL LAYER

Figure 2.3: DS PLCP frame format

• PLCP Preamble: It allows the synchronization between the transmitter andreceiver stations. The modulation format is DBPSK and the rate is 1 Mbps.It is composed of a “Sync” field and a “Start Frame Delimiter” field:

– Sync: it carries 128 ones bits.

– Start Frame Delimiter: set to 0000 0101 1100 1111, it is utilized bythe receiver to recover the start of the frame.

• Header: the PLCP header is placed after the preamble and contains someparameters of the physical transmission. It contains the following four fields:

– Signal: it delivers the information about the rate that shall be used bythe transmitter.

– Service: it is reserved for future use and it must be set to 0.

– Length: it carries the information about frame duration The format isleast significant bit first (LSBF).

– CRC: it consists of 16 bits that are used to reveal with high reliability anincorrect header detection. The receiver verifies the CRC before furtherframe processing.

The different types of standardized physical layer can be divided in:

• Frequency Hopping Spread Spectrum (FHSS)

• Direct Sequence Spread Spectrum (DSSS)

• Infrared light (IR)

• High Rate Direct sequence (HR/DS)

• Orthogonal Frequency Division Multiplexing (OFDM) e.g. 802.11a , 802.11p


2.3. MEDIUM ACCESS

2.3 Medium Access

The 802.11 supports two operation modes: the Point Coordination Function (PCF)and the Distributed Coordination Function (DCF). The PCF provides contentionfree services. Special stations called Point Coordinators are used to ensure that themedium is provided without contention. Point Coordinators reside in access points,so the PCF is restricted to infrastructure networks. The DCF provides distributed,but coordinated access, such that a station can only transmit while no other stationis transmitting. Particularly, DCF is based on carrier sense multiple access withcollision avoidance (CSMA/CA).

Two carrier sensing mechanisms are defined in the standard: Physical Carrier Sens-ing (PCS) and Virtual Carrier Sensing (VCS). PCS is mandatory while VCS isoptional (it can be switched off by the users) and has been developed to mitigatethe well-known hidden node problem. The channel is marked busy if either PCS orVCS mechanisms indicate that the channel is busy.

2.3.1 Basic Access Scheme

When the MAC has a frame to transmit, it interrogates the PLCP layer about thestatus of the channel. If the PLCP indicates that the status of the medium is “idle”,i.e. no other station is transmitting, for an interval that exceeds the Distributed InterFrame Space (DIFS), the transmission of the frame can be initiated. The MAC indi-cates to the PLCP some of the parameters to include in the PLCP header and somephysical setting (e.g. Antenna, Power Level, etc.). The PLCP then forwards thephysical parameters to the PMD layer through dedicated PMD primitives, generatesthe PLCP header and issues a request to the PMD to start the transmission. ThePHY entity immediately initiates data scrambling and transmission of the PLCPpreamble followed by the transmission of the data.

If PLCP indicates that the medium is busy, the station enters into a ContentionWindow and the transmission is deferred until the end of the ongoing transmission.A random interval, referred to as the back-off interval, is then selected and is usedto initialize the back-off timer. Every time the medium is detected to be “idle” theback-off timer decreases. When the back-off timer reaches zero, the station initi-ates the transmission. To reduce the probability of collisions, after each unsuccessfultransmission attempt the expected value of the random back-off interval is increasedexponentially until a predetermined maximum is reached (exponential random back-off). Immediate positive acknowledgments are employed to determine the successfulreception of each data frame. The receiver checks the Cyclic Redundancy Checkand after a time interval, called Short Inter Frame Space (SIFS), sends an acknowl-edgment packet (ACK), without sensing the state of the channel. In case an ACK


2.3. MEDIUM ACCESS

is not received the data frame is presumed lost and a retransmission is scheduled bythe transmitter. This access method is often referred to as Basic Access and it isdepicted in Figure 2.4.

DATA Frame

Contention Window

Contention Window

Source

Destination

SIFS

ACK

DIFS

DIFS

Figure 2.4: Basic Access Scheme

2.3.2 Virtual Carrier Sensing

The virtual carrier-sensing mechanism is achieved by distributing reservation infor-mation announcing the impending use of the medium. The exchange of Request-To-Send (RTS) and Clear-To-Send (CTS) frames prior to the actual data frame isone means of distribution of this medium reservation information. When a node hasa frame to send, it initiates the process by sending an RTS frame. This basicallysilences any stations that hear it. If the target station receives an RTS, it respondswith a CTS. Like the RTS frame, the CTS frame silences stations in its transmissionrange. Once the RTS/CTS exchange is complete, the sending node can transmit itsframes without worry of interference. The RTS and CTS frames contain a Dura-tion/ID field that defines the period of time that the medium is to be reserved totransmit the actual data frame and the returning ACK frame. At the end of theRTS/CTS exchange all stations within the reception range of either the originatingnode (which transmits the RTS) or the destination node (which transmits the CTS)save the information of the medium reservation by updating the so-called NetworkAllocation Vector (NAV) according to the Duration field of the RTS/CTS frame.The NAV indicates the amount of time that elapses until the current transmissionsession is complete. Figure 2.5 depicts a frame transmission between two nodesusing the RTS/CTS procedure.

The RTS/CTS transmission procedure consumes a fair amount of capacity, espe-cially because of the additional latency incurred before transmission can commence.As a result, it is used only in high-density environments and environments withsignificant contention on transmission.


2.4. FRAME FORMAT

Figure 2.5: Typical RTS/CTS sequence in a frame transmission

2.4 Frame Format

Figure 2.6 depicts the structure of a generic 802.11 data frame at MAC layer.

Figure 2.6: Typical 802.11 MAC frame format

Frame control

Each frame starts with a two bytes Frame Control field, which contains eleven sub-fields:

• Protocol: It is composed by two bits indicating which version of 802.11 MACis used.

• Type and sub-type: It indicates the type of frame (for example RTS, CTS,ACK, Power Save, etc)

• ToDS and FromDS: These bits indicate if a frame is dedicated for thedistribution system. All frames in the infrastructure will have one of thedistribution system’s bits.


2.4. FRAME FORMAT

• More fragment: This field is set to 1 when the receiver has to expect anotherfragment of the frame. All non-fragmented frames have this field set to 0.

• Retry: When a frame is retransmitted, this field is set to 1 in order to aidthe receiving station to delete the possible duplicate frame.

• Power Management: This field is set to 1 when the transmitter is in power-saving mode, otherwise is set to 0. This power-save mode is only allowedat the nodes and it is forbidden for the access point, which perform a lot ofimportant management operations.

• More data: To accommodate stations in “power-saving” mode, the accesspoints may buffer frames received from the distribution system. An accesspoint sets this bit to indicate that at least one frame is available.

• WEP: Wired Equivalent Privacy is a encryption routine for wireless protec-tion. When a frame has been processed by WEP, this field is set to 1.

• Order: The frame and the fragments cam be sent in order (so-called “strictordering”) and when this happens he order bit is set to 1.

Duration/ID

It is two bytes long and it has two different roles, depending on the type of framebeing transmitted. In a situation of power-saving message this field transports thetransmitting station associated ID. In the other cases it indicates the time duration(expressed in milli seconds) necessary for the current frame transmission.

Address

In a general 802.11 frame it is possible to find up to four field called Address.Their use depend on the setting of the ToDS and FromDS in the frame controlfield. In general the Address1 contains information address used for the receiver,Address2 contains information address about the transmitter, the Address3 containsinformation dependent on the FromDS setting, and the Address4 is utilized onlywhen a wired distribution system is used.

Sequence control

It is a 16 bits field used for defragmentation and for discarding duplicate frames ifa retransmission occurs. The first four bits indicate the fragmentation number andthe other 12 bits indicate the sequence numbers.


2.5. IEEE 802.11P

Frame body

It is the field that carries the higher layer payload. It can transport maximum 2304bytes. Actually the implementation can support payload up to 2312 bytes in orderto arrange the WEP overhead.

Frame Check Sequence

This field is often also called Cyclic Redundancy Check (CRC). It allows the stationto check potential errors in the received frame. In particular the transmitting stationcalculates the FCS before transmitting its frame and put it into the header. Thenat the receiver side the station calculates again the FCS of the frame. A differencein the two FCSs indicates that the frame was corrupted during the transmission.

2.5 IEEE 802.11p

According to the official IEEE 802.11 Work Plan, the final 802.11p amendment willbe published in November 2010. The 802.11p specification defines:

• the functions and services of the WAVE-compliant stations;

• the WAVE signaling technique and the interface between the physical andMAC layers.

The reference IEEE standard guide is available in [1].

2.5.1 The basic OFDM concepts

Orthogonal Frequency Division Multiplexing (OFDM), a.k.a. multi-carrier or dis-crete multi-tone modulation, is the modulation technique adopted in 802.11p. In or-der to highlight the basic concepts and the advantages of this technique we should re-call the basic Frequency Division Multiplexing (FDM). In traditional FDM systems,see figure 2.7, the signal is modulated independently per each sub-band through atime-domain multiplication with the sub-carrier signal (the cosine and the sine withfrequency at the center of the corresponding sub-band). At the receiver, a filtersbank allows for the mitigation of the inter-carrier interference (ICI). By increasingthe guard interval between the sub-bands, the complexity of the filters is reduced,at the cost of a decrease in spectral efficiency.


2.5. IEEE 802.11P

Figure 2.7: Traditional view of receiving signals in FDM

On the other hand, in OFDM systems, the sub-bands are inherently orthogonal (seeFigure 2.8). This statement is actually true only if the channel has a negligibleDoppler spread compared to the bandwidth of each sub-band. This condition isnormally fulfilled in real-world scenarios. The main steps of the OFDM modulation

Figure 2.8: OFDM Subcarriers spectrum

are the following: first, the code symbols are mapped onto the discrete frequencydomain (each symbol is associated to a sub-carrier); second, the discrete inverseFourier transform (IFT) of the mapped symbols is performed; third, the wholeensemble (OFDM symbol) is over-sampled and modulated by the the carrier signal.At the receiver, the demodulated signal is transformed back to the discrete frequencydomain. The equivalent base-band channel in the frequency domain is memoryless(diagonal), provided that the channel has been cyclically convoluted with the OFDM


2.5. IEEE 802.11P

symbol in the time domain. In order to artificially induce a cyclic convolutionbetween the OFDM symbol and the channel, the cyclic prefix, containing the tailof the OFDM symbol, is added before each OFDM symbol. If the cyclic prefixis longer then the channel delay spread, each OFDM symbol experiences only itsown interference in the discrete time domain, which emulates a cyclic convolutionbetween the signal and the the channel. Hence, the equalization of the channel atthe receiver side results easier in the frequency domain. The orthogonality of thesub-bands is again paid by a decrease in spectral efficiency due to the cyclic prefixinsertion (that acts practically as a guard time interval as depicted in Figure 2.9).However, compared to a traditional FDM system, the trade-off between complexityand efficiency is greatly improved.

Figure 2.9: Guard time in OFDM transmission

Another advantageous characteristic of OFDM is that the payload is spread across ahigh number of carriers. In fact the spectral notches (deep fade) caused by the multi-path propagation affect only a small number of sparsely distributed sub-carriers.Traditional forward error correcting (FEC) codes, like convolutional codes are ableto exploit this frequency diversity and to correctly reconstruct the transmitted in-formation.

2.5.2 Comparison between 802.11a and 802.11p

The main system parameters of the 802.11a and 802.11p are shown in Table 2.1, inorder to underline the differences between the two standards.

In the current draft version of the standard, the frame encoding procedure for IEEE802.11p differs from 11a only in two key aspects: the operating frequency band isshifted to around 5.9GHz and the duration of OFDM symbols is doubled from 4µs


2.5. IEEE 802.11P

Parameter 802.11 a 802.11 p

Sample rate 20 MHz 10 MHz

Chip duration 50 ns 100 ns

Number of fft points 64 64

Number of sub carriers 52 + DC 52 + DC

Number of data sub carriers 52 52

Number of pilot sub carriers 4 4

OFDM symbol period TSymbols = 80 chips = 4 µs 8 µs

Cyclic prefix 16 chips = 0.8 µs 1.6 µs

FFT Symbol period 64 chips = 3.2 µs 6.4 µs

Modulation scheme BPSK-QPSK-16QAM-64QAM BPSK-QPSK-16QAM-64QAM

Coding scheme 1

2industry convolutional 1

2

Puncturing optional puncturing 3

4or 2

3

3

4or 2

3

Available data rate 6-9-12-18-24-36-48-54 Mbps 3-4.5-6-9-12-18-24-27 Mbps

Table 2.1: Main system parameters in 802.11a and 802.11p standard and relativedifference

to 8µs. The rationale behind these modifications is the following: first, using adedicated part of the spectrum reduces interference with legacy systems, second,doubling the symbol-time also means doubling the cyclic-prefix-duration - a modifi-cation that helps to decrease the OFDM inter-symbol-interference (ISI) when oper-ated in outdoor channels. The detailed guide about the difference between 802.11aand 11p is available in [1].


CHAPTER 3. SOFTWARE DEFINED RADIO

Chapter 3

Software Defined Radio

3.1 Introduction

The term “Software Defined Radio” was coined in 1991 by Joseph Mitola, whopublished the first paper on the topic in 1992 [4]. The basic idea behind the termSoftware Defined Radio is of a radio communication system where components thathave typically been implemented in hardware (e.g. filters, modulator, amplifiers,detectors. etc.) are instead implemented using some software on a personal com-puter or other embedded devices. So, more in general, we define an SDR as a radioplatform that uses software techniques on digitized radio signals. Therefore, at acertain stage in the receiving chain the signal should be digitized and passed to thesoftware domain. By using SDR, engineers try to move the software domain as closeas possible to the antenna in order to guarantee a higher flexibility. In addition tothat, the main aim of SDR is to turn “hardware problems into software problems”[5], enabling radio engineers to work in a more accessible domain. By a general pointof view, we can divide a SDR system into two subsystems: the hardware-defined sub-system and the software-defined subsystem. The separation between hardware andsoftware subsystems is not fixed. The decision of what should be implemented insoftware and what in hardware depends on the performance requirements of eachparticular implementation. Ideally, an SDR could consist of an antenna, an ADC,and a software-defined subsystem as depicted in figure 3.1.

Realizing such a device would require that each of the three following conditions aremet:

• The antenna should be capable to operate at the frequency of all radio signalsof interest

• The ADC and the DAC should have a sampling rate greater than two times


3.1. INTRODUCTION

ADCSoftware

Subsystem

Receive signal path

Antenna

DACSoftware

Subsystem

Transmit signal path

Antenna

Figure 3.1: Ideal Software Defined Radio blocks diagram

the frequency of the signals of interest and for this reason a very high samplingrate to support wide signal bandwidths

• The software subsystem should have enough processing power to handle thesignal processing of all radio signals of interest

In practice ADCs and DACs are not fast enough to process a large portion of thespectrum and antennas are designed for specific frequency bands. As a result, idealSDR are realized only for particularly simple technologies (e.g. AM radio).

In a typical SDR the hardware-defined subsystem consists of a wide-band RadioFE that takes a portion of spectrum and shifts it to the IF prior to digitization(see figure 3.2). The software-defined subsystem receives the digital wide-band sig-nal, sends it to a set of digital down converters to isolate the required carrier, andproceeds with the demodulation. Further filtering is also done in the software do-main. The designing goal of SDR remains to make the FE as general as possibleand act on the software subsystem for the implementation of new functionalities.The software-defined subsystem can also be composed by a combination of pro-grammable devices, provided that the connection between them is fast enough totransfer DSP data. There are several SDR solutions available on the market. Inthis thesis we opted for an open-source SDR platform that combines GnuRadio(as software-defined subsystem) and the Universal Software Radio Peripheral (ashardware-defined subsystem).


3.2. UNIVERSAL SOFTWARE RADIO PERIPHERAL

Receive signal path

Antenna

Transmit signal path

Antenna

Radio

Front!End

Radio

Front!End

Hardware!based subsystem Software!based subsystem

ADC

DAC

Programmable

device(s)

(e.g. FPGA, GPP)

Management

Software

Figure 3.2: Real Software Defined Radio blocks diagram

3.2 Universal Software Radio Peripheral

The Universal Software Radio Peripheral (USRP) was designed within the GnuRadioproject [2] and is currently produced by Ettus Research [6]. As a consequence,it perfectly fits with the GnuRadio framework. In this thesis we used the USRPversion 2 (in the following simply referred to as USRP2). This version overcomes thelimitations of the USRP1 in terms of bandwidth and processing power. The USRP2contains a motherboard with four plugs (for the Radio Front Ends) and a GigabitEthernet controller (for the connection to the host PC). The USRP hardware designis open source and all schematics and circuit layout are freely available on line at[7]. In the following sections we describe the details of the main components.

3.2.1 Motherboard

The main features of the motherboard are listed below:

• FPGA, which contains a 32-bit RISC microprocessor

• Two 14-bit ADCs @ 100MHz

• Two 16-bit DACs @ 400MHz



• Digital down-converters with programmable decimation rates

• Digital up-converters with programmable interpolation rates

• Gigabit Ethernet Interface

• Two Gbps high-speed serial interface for expansion

• Fully coherent multi-channel systems (MIMO capable) with up to 8 antennas

• One Megabyte of on-board high-speed SRAM

The simplified scheme of the USRP2 is depicted in figure 3.3.

Figure 3.3: Simplified scheme of the USRP2

As we can see, the ADCs and the DACs are connected to the daughter boards,while the FPGA is connected to a Gigabit Ethernet interface chip toward a generalpurpose computer. All these components work with a 100MHz master clock. Nowlet us look more in detail at the main functions of each component.

3.2.2 FPGA

The FPGA performs all the operations indispensable to reduce the signal bandwidthin order to obtain a sustainable flow trough the Gigabit Ethernet, e.g. signal pro-



cessing, interpolation, decimation, filtering, etc. Two other important operationsmade inside the FPGA are the Digital Down Conversion (DDC) and the Digital UpConversion (DUC).

Digital Down Converter

Figure 3.4 depicts the Digital Down Conversion performed in the FPGA. The com-plex signal at intermediate frequency from ADC is multiplied by a complex signal(also at IF frequency). The result is a complex signal with central frequency 0 Hz.

Sin( i)

NCO

Cos( i)From ADC

Sampling rate Fs

4 Stage

CIC Filter

4 Stage

CIC Filter

31 Tap

HBF

31 Tap

HBF

I

Q

Base band 16-bit I/Q

data with bandwidth

Fs/NDecimators

(division by N)

Figure 3.4: USRP FPGA DDC

After that, the signal goes through a 4 stage Cascaded Integrator-Comb (CIC)filters for a decimation by a factor N. In this way, the data rate can be adaptedto flow in the Gigabit Ethernet and for a subsequent software computing in thehost computer. The decimator can be treated as a low pass filter followed by adown sampler. If we suppose a decimation factor of N, the low pass filter removethe band out the range [-Fs/N, Fs/N], and then the down sampler de-spread thespectrum from [-Fs, Fs] to [-Fs/N, Fs/N]. In the end, in order to obtain the bestspectral shaping possible and to reject the out of band signals there is a 31 taps HalfBand Filter (HBF). Regarding the bandwidth, we can sustain 1 Gb/s = 128MB/sacross the GigaEthernet. All samples sent over the GigaEthernet interface are in16-bit signed integers in IQ format, i.e. 16-bit I and 16-bit Q data (complex) whichmeans 4 bytes per complex sample. This means that we can send 128MBps / 4Byte



= 32Mega complex samples per sec across the GigaEthernet. Recalling that ADCssampling rate is 100Msample per second, then we can immediately find the minimumdecimation factor as 100Msamples per second / 32M samples per second = 3.123better 4. Since complex processing was used, this provides a maximum effective totalspectral bandwidth of 32MHz by Nyquist criteria. Of course we can select muchnarrower ranges by increasing the decimation factor. In any case the decimationfactor must be in the range [4, 512]. The standard FPGA configuration implements2 complete digital down converters (DDC). Also there is an image with 4 DDCsbut without half-band filters, so this allows 1, 2 or 4 separate RX channels. Notethat when there are multiple channels (up to 4), the channels are interleaved. Forexample, with 4 channels, the sequence sent over the Ethernet would be I0 Q0 I1Q1 I2 Q2 I3 Q3 I0 Q0 I1 Q1, ...etc. In multiple RX channels (1,2, or 4) , all inputchannels must be the same data rate (i.e.same decimation ratio).

Digital Up Converter

At the TX path, the story is the same, except that it happens reversely. In fact wesend a baseband I/Q complex signal to the USRP2 board. The digital up converter(DUC) will interpolate the signal, up convert it to the IF band and finally sendit through the DAC. The only transmit signal processing blocks in the FPGA arethe CIC interpolators. These CIC are an optimized class of finite impulse responsefilters combined with interpolators or decimators. The CIC outputs can be routedto any of the 4 CODEC inputs. In multiple TX channels (1 or 2) all output channelsmust be the same data rate (i.e. same interpolation ratio). Note that we could havedifferent Tx and RX rate.

3.2.3 ADC-DAC

The DAC chip used in the USRP2 motherboard is the AD9777 16-bit. The maximuminput data rate is 160 M samples per second (no interpolation) while the maximumDAC update rate is 400 M samples per second (8x interpolation). This chip presentsa selectable interpolation rate (2x/4x/8x) and a complex modulator that can mix atFs/2, Fs/4 or Fs/8. All configuration are accomplished through a 3 or 4-wire SPIinterface.

The ADC chip used in the USRP2 motherboard is the LTC2284. This is a 14-bit105 Msps (but used in the USRP2 at 100Msamples per second), low power dual 3VA/D converter designed for digitizing high frequency, wide dynamic range signals.


3.3. GNURADIO

3.2.4 Daughter boards

A daughter board represents the core of the analog process. Usually it encompassesa RF filter to discard the out band components, a LNA (Low Noise Amplifier), amixer to move the signal from the RF frequency to IF Frequency, an IF filter, and anIF amplifier. The structure is pretty similar to a typical Etherodyne receiver. Thedaughter board together with the motherboard let us use the USRP2 as a completeRF transceiver system. Several daughter boards are available in [6]. Usually, asingle daughter board can be either a receiver or a transmitter. Recently, a fewtransceiver daughter boards have been released. We have chosen the XCVR-2450daughter board, which is a transceiver board operating at 2.4-2.5 GHz and 4.9-5.9GHz. Therefore, it is suitable for the IEEE 802.11 family of standards. The mainfeatures of the XCVR2450 are:

• 30 MHz transmit and receive bandwidth

• Frequency range 2.4 to 2.5 GHz and 4.9 to 5.9 GHz

• Transmit power 100 mW (20dBm)

• Independent local oscillators for TX and RX chain

• 70 dB range of Automatic Gain Control

• Adjustable transmit power

• 16 digital I/O lines to control external device like antenna switches

• All function controllable from software or FPGA.

3.3 GnuRadio

GnuRadio is a free software toolkit licensed under the GPL for implementing software-defined radios. The GnuRadio project was founded by Eric Blossom. The goal ofGnuRadio is to bring the code as close to the antenna as possible, and thereforeturn hardware problems into software problems [5]. It supports natively Linux, andpackages are precompiled for the major Linux distributions. A port to Windows hasbeen also developed, but it provides limited functionalities. Initially, it was mainlyused by radio amateur enthusiasts, but it gained increase interest from the researchworld, in an attempt to stay away from closed source firmwares/drivers, and lowlevel of customizability of commercial chips.


3.3. GNURADIO

In GnuRadio, a transceiver is represented by a graph, where the vertices are signalprocessing blocks and the edges represent the data flow between them. In otherwords, the design of a radio transceiver with GnuRadio is similar to what is donein the hardware design, where physical RF components are connected to each otherto create a hardware radio. Figure 3.5 depicts a simple example of a gnuradio flowgraph. Any graph must have at least a signal source block (in the example the “Sig-nal Generator” and the “Noise generator”) and a signal sink block (in the examplethe “USRP2 Sink”). Additionally, the flow graph usually contains intermediatesignal processing blocks (in the example the “Adder” block).

Figure 3.5: Typical graph representation

The GnuRadio package provides several building blocks for signal and informationprocessing, as well as the framework to control the data flow between them. Anincomplete list of the functions provided by GnuRadio is divided in the followingfunctional blocks [8]:

• Mathematical operations (log, add, multiply, .. . )

• Interleaving, delay blocks, . . .

• FFT blocks

• Interpolation and decimation

• Filters (FIR, Infinite Impulse Response (IIR), . . . )


3.3. GNURADIO

• Automatic Gain Control (AGC) blocks

• Modulation and demodulation (FM, AM, PSK, QAM, GMSK, OFDM, . . . )

• Trellis and Viterbi support

Apart from signal processing blocks, GnuRadio also provides support for varioussignal sources and sinks, such as:

• Signal generators

• Noise generators

• Pseudo random number generators

• Audio source and sink

• USRP source and sink (to transmit/receive signals via USRP)

• File source and sink (reads/writes samples from/to a file)

• Graphical sinks (Oscilloscope, FFT, Waterfall, . . . )

• User Datagram Protocol (UDP) source and sink

Unfortunately, it is very hard to find documentation about the blocks providedby GnuRadio. In order to understand the hundreds of implemented blocks, theonly practicable way is to look at the source code and the documents generated bydoxygen [9].

3.3.1 Architecture

Figure 3.6 depicts the general GnuRadio framework structure. Python is used tocreate high level graphs. The signal processing blocks that are included in the graphsare programmed in C++. SWIG 1 is then used to interface the two programminglanguages (e.g. making C++ functions available to python). Information aboutSWIG can be found in [10]. This approach allows to combine the efficiency of C++coding with the simplicity of Python.

With reference to figure 3.5, the blocks (vertices), such as the signal generator, thenoise generator, the adder, and the USRP sink are written in C++ and they rep-resent the body of the graph. The edge i.e. the connection between the blocks are

1SWIG is an acronym for Simplified Wrapper and Interface Generator


3.3. GNURADIO

Figure 3.6: GnuRadio framework structure

written in Python and represent an high level view of the graph. In other wordsall the signal processing operations, the critical operations and the real time opera-tions are written in a lower level language (C++), while the logical interconnectionsbetween them are written in a higher level language (Python).

3.3.2 Brief Flow Graph Overview

Creating a GnuRadio flow graph in Python does not require full knowledge of theC++ code in each block. The concept is similar to the OSI reference model. Signalprocessing blocks use the services offered by the hardware, and provide services tothe python code through the SWIG interface.

In GnuRadio each block is characterized by attributes that indicate the numberof input and output ports, and the type of data that it can process. Clearly, asource block has only outgoing ports, a sink block has only incoming ports, and aprocessing block can have multiple incoming and outgoing ports. Signal processingblocks can be either synchronous or asynchronous. As far as regards the data format,the blocks process usually complex floats, but other data formats are also possible(float, short, and chars). From the python point of view, GnuRadio provides a dataflow abstraction. What the python does is to select all the necessary signal sources,sinks and processing blocks, set the parameters correctly, and then connect them


3.3. GNURADIO

together. It does not know anything about how the C++ blocks work internally.It does not care about the implementation details. The only important thing isthat all parameters and logical connections must be consistent. This abstraction isimplemented in the top block class.

Let us suppose that we want to use the USRP2 as receiver. In this case we want thatthe signals received and processed (digitized) by the USRP2 flow through the GigabitEthernet towards the host computer and are further processed by GnuRadio. In thiscase, the USRP2 is the signal source of our flow graph. Vice versa in a situationwhere the USRP2 acts as transmitter, the signal is first generated and processed bythe GnuRadio flow graph, and finally flow to the USRP2 sink.

To create an application, we should derive our own class either from the classtop block of the module gr (or any of its subclasses) or from the class std top block

of the module stdgui in the package gnuradio.wxgui (depending on whether theapplication requires a GUI or not). This can only be done in Python. Supportfor pure C++ applications, which may sometimes be preferable (e.g. for embeddedsystems), is under development. Once our blocks have been instantiated, they canbe connected with the connect method of the main class in Python (i.e. the classwhich is derived from top block that represents the flow graph). This is the analogof drawing edges in the graph as in figure 3.5. To get a runnable graph, all portsof each block must be connected. Then signal processing can be started with thestart method of the flow graph. A complete and detailed guide can be found in[11] and [12].

3.3.3 Signal processing blocks

In a running GnuRadio application, the scheduler of the GnuRadio framework man-ages the blocks and the flow of samples between them, assisted by some importantmethods that are defined in the c++ code of the blocks. The forecast() methodcan be used by the programmer to tell the scheduler how many input samples ablock requires to produce a given number of output samples. The general work

and work methods are used for the actual signal processing steps. These functionsare called by the scheduler and are given a certain number of input samples (whichis not fixed, but can be modified by the programmer). After processing the samples,they write the output into the memory and return the number of processed inputsamples and produced output samples.

GnuRadio also takes care of buffering the data. While signal processing blocksusually process samples as fast as they come in (or as fast as the CPU allows), somesignal sources and sinks require a constant sample rate (e.g. the audio sink). Inthis case, it is the programmers responsibility to make sure, that data is processed


3.3. GNURADIO

fast enough. If a source delivers more samples than the application can process,then some buffer will eventually overflow, and samples are lost (this is called anoverrun). If the sample rate at the input of a sink is too low on the other hand, thebuffer will eventually be empty resulting in glitches in the signal (an under run).Such problems can also occur, if some interface (e.g. the Gigabit Ethernet betweenthe USRP2 and the PC) is too slow, or if data streams with different fixed samplerates are connected without appropriate interpolation or decimation. Obviously, it iscrucial to avoid such problems as much as possible for a real-time radio application.For a detailed guide on how to write a block refer to [13].

3.3.4 Existing implementations

The GnuRadio package contains some python/C++ examples that can be used forreproducing simple applications, such as real-time capture and display of analogTV stations, transmission and reception of FM signals, transmission of dial tonesto the sound card, etc. However, several groups around the world implementednew modules, reproducing a variety of widely used technologies. Unfortunately, tothe best of our knowledge there is no on line listing directory that groups all theavailable implementations. Extensive research is required in order to identify whathas been already implemented and with which limitations. We list here some ofthe existing GnuRadio implementations, that use either the USRP or the USRP2board. A complete GPS receiver has been implemented in [14]. It uses the DBSRXdaughter-board for receiving GPS signals, and contains interfaces to the GoogleEarth data. Eric Blossom presented in [15] a passive radar by using FM frequencies(the code is included in the CVS GnuRadio repository). A DVB-T module has beenpresented in [16], which is capable of receiving (and playing) DVB-T signals. WiserSRL [17] claims to have implemented a GSM-R Signal Integrity Detection System(code is not available at the time of writing). Implementations for IEEE 802.11b,Bluetooth, IEEE 802.15.4. Since these applications have some similarities with thewireless technology implemented in this thesis, we elaborate more on them in thefollowing subsections.

IEEE 802.11

There have been several attempts to reproduce the IEEE 802.11 standard withGnuRadio. All these implementations are designed for use with USRP1. The latteruses a USB connection instead of the Gigabit Ethernet, therefore it is exposed to theUSB bandwidth limitation of 32MB/s. The IEEE 802.11 signal spectrum is 11 MHz,therefore the minimum sampling rate would be 22 Msamples/s. By using 16 bitssamples (8 bits for each I and Q sample) we would require a bandwidth of 2*22 Ms =44 MB/s, which is above the USB limit. There are two implementations that try to


3.3. GNURADIO

avoid this bottleneck. A first well-known implementation has been developed withinthe ADROIT project funded by the DARPAs ACERT program and is available in[18]. In this implementation the signal bandwidth is reduced to 4 MHz before beingpassed to the USB controller. In this way, the signal is basically sub sampled,therefore the Signal to Noise Ratio (SNR) degrades. Several posts in [19] report asuccessful reception of IEEE 802.11 data at 1Mbps (DBPSK). More information canbe gathered by looking at the available source code.

Hamed Firooz [20] proposed another implementation. In its architecture, despread-ing operation is performed in the FPGA prior to the USB, rather than in the hostCPU. In this way, the data to be transfered through the USB connection is con-siderably reduced. Recall that IEEE 802.11 uses Direct-Sequence Spread Spectrum(DS-SS), with a code sequence of 11 chips per symbol. By despreading the signalbefore the USB connection, the symbol rate is reduced to 1Msymbol per second,which is easily supported by the USRP.When the signal arrives at the PC, theIEEE 802.11 demodulator and Physical Layer Convergence Protocol (PLCP) fromthe ADROIT project is used for decoding the frame. Details on the implementationand the Verilog code for the Altera FPGA are freely available in [20].

IEEE 802.15.4 ZigBee

IEEE 802.15.4 is a relatively simple protocol at the basis of the Zigbee stack designedfor sensor networks. It is meant to work in different frequency bands, although the2.4 GHz ISM band is the most widely used. The latter is divided in 16 channelsspaced 5 MHz apart from each other. The radios use direct-sequence spread spec-trum coding and a remodulated by using Orthogonal Quadrature Phase Shift Keying(O-QPSK). The raw, over-the-air data rate is 250 kbit/s per channel in the 2.4 GHzband. One bit at the source is encoded in 4 source symbols, which are in turn codedinto 32 chips in the spreading process. This results in a chip rate of 2 Mchips/s.Since O-QPSK transports two bits on each modulation symbol, we have finallya channel symbol rate of 1Msymbols/s. A complete implementation of the IEEE802.15.4 PHY/MAC layer has been presented in [21]. The code is open and freelyavailable at [22]. However the authors measured Round Trip Times (RTT) three tosix times larger than conventional radio chips. They found that this is due to theimpossibility of the current implementation to reach a RX-TX turnaround time of12 symbol periods (192 s) as mandated by the standard. Another implementationhas been presented in [23]. The source code however is not publicly available.


3.3. GNURADIO

Bluetooth

At a glance it could seem that the low power and data rate characteristics of Blue-tooth make it easy to be implemented in the USRP/GnuRadio. A more accurateanalysis reveals that this is not always true. Bluetooth communications use frequen-cies from 2402 MHz to 2480 MHz. One bluetooth channel is 1 MHz wide resultingin a total of 79 channels. The data is modulated using Gaussian Frequency ShiftKeying (GFSK) with a symbol rate of 1 MSamples/s. GFSK is not explicitly imple-mented in GnuRadio, but since it is a variant of Gaussian Minimum Shift Keying(GMSK) it can be easily implemented by using the included modules. Also thesymbol rate does not pose any problem in the USRP. However Bluetooth uses atechnique known as Frequency Hopping Spread Spectrum (FH-SS). A communica-tion does not take place on a single channel (as in IEEE 802.11) but hops betweendifferent channels. In bluetooth the channel changes every 625 s, and the hoppingsequence is calculated from the clock and the MAC address of the master device(exchanged during the pairing procedure). Therefore, tuning the USRP on one chan-nel would allow us to retrieve only sporadic packets from a communication. For aUSRP to decode an entire bluetooth communication one needs to monitor the entirebluetooth spectrum, which is clearly unfeasible, or try to follow the hops sequence.The RFX-2400 daughter board takes around 200 s to settle to a frequency when atune command is issued. This means that roughly the first third of a transmissionslot will be missed as the radio tunes to the frequency. Some tests on a bluetoothimplementation has been performed by Dominic Spill [24], who proposes the useof two bluetooth daughter boards in order to avoid the frequency settlement issue(while one daughter board listens to one channel, the other one settles to the nextchannel). In [25] the problem is avoided by forcing the communication to a singlechannel. The most explicative words on the issue are probably given in [26], a threadon the GnuRadio mailing list.


CHAPTER 4. IEEE 802.11P IMPLEMENTATION

Chapter 4

IEEE 802.11p Implementation

Due to the current lack of commercial 802.11p chip sets, using a GnuRadio prototypeis an attractive basis for conducting empirical measurements for assessing the linkperformance of the IEEE 802.11p standard. Implementing a wireless technologywith GnuRadio is a complex process. Typically, three steps are involved:

• Understanding the physical layer of the technology of interest

• Creating the required signal processing blocks or use the ones provided withinthe GnuRadio package

• Creating the flow graph and tuning the blocks

Several limitations can arise during the implementation due to impossibility of thesoftware to always correctly reproduce the hardware tx/rx chain.

IEEE 802.11p has never been implemented using GnuRadio before the present work(neither the closest standard 802.11a). For this reason we decided to start the IEEE802.11p GnuRadio implementation from scratch. We created most of the signalprocessing blocks and reused some of the existing ones from the GnuRadio package.In the following, we describe the methodology adopted and the implementationdetails for each block.

4.1 Methodology adopted

Due to the complexity of working with the GnuRadio framework, we decided tofirst implement the standard compliant IEEE 802.11p transmitter using MATLAB.


4.1. METHODOLOGY ADOPTED

In fact MATLAB programming language is easy-to-use and versatile. We used thedetailed instructions of the encoding scheme given in the IEEE 802.11a standarddocument to create a reference-encoder in MATLAB. The corresponding chain isdepicted in Figure 4.1. Taking this intermediate step using MATLAB shortens theinitial debugging phase and speeds up the development of the baseband encoder.Note that the standard (see [27] annex G) also includes the baseband representationof one reference frame which enabled us to verify that the MATLAB code is indeedcorrect. The MATLAB script provides all the regimes supported by the standard.In the second phase of development we implemented the elements of the encod-ing chain in GnuRadio in a stepwise fashion. The rationale behind this approachis that any single block could be tested and debugged by comparing the behaviorof the corresponding MATLAB block. In this phase, it is crucial to understandthat the GnuRadio framework distinguishes between stream-based operation andblock-based operation. Adopting the purely block-based approach of our originalMATLAB code was not an option since it would have resulted in highly sub-optimumGnuRadio code in terms of latency of the encoding process. This is easy to under-stand when considering long frames (consisting of several hundred OFDM symbols).The third phase was dedicated to a final quality-check of the complete implemen-

Figure 4.1: IEEE 802.11p chain implemented in MATLAB

tation (baseband-encoder plus front-end) using over-the-air measurements. Usingsymbol-time settings in accordance with 11a and a carrier-frequency in the 2.4GHzISM band we were able to generate frames that were correctly received by a con-ventional 802.11g chip set. Ultimately, we were able to verify the compliance with


4.2. USRP2 TESTING/DEBUGGING

11p by conducting measurements using an early 802.11p industry-prototype as areceiver that is being used in the CVIS project. Details on the validation resultswill be given in Chapter 5.

4.2 USRP2 testing/debugging

The very first step is to verify that the USRP2 is able to transmit without distortionsthe signals generated with MATLAB. Part of this work is a mere quality-check of thehardware in use that could eventually generate unexpected non-linear effects. Dur-ing this first phase we were able to better assess some USRP2 functionalities, which,to the best of our knowledge, are not clearly described anywhere. As an example,we have discovered that the USRP2 in the FPGA swaps the real and imaginaryparts of the samples. Note that the chip set that we have used for the preliminarydebugging/tests was a 802.11a standard compliant. By simply doubling the inter-polation factor and changing the carrier frequency in the USRP2, the physical layerswitches from 802.11a to 802.11p standard. The correct reception at the chip set ofMATLAB-generated frames has proved the correctness of the code for all regimes.

4.3 GnuRadio OFDM and 802.11p: State of the

Art

We have already discussed about the existing GnuRadio code in section 3.3.4. Nowwe want to focus our attention to the state of the art in GnuRadio in the context ofOFDM standards. Currently, in the GnuRadio repository, there is already a codecapable of generating OFDM symbols. Figure 4.2 shows the available GnuRadioOFDM chain.

Figure 4.2: OFDM blocks implemented natively in GnuRadio core

As we can see, the frame generation consists only of a symbol mapping, ifft, cyclicprefix insertion and training sequence insertion. Now we analyze these blocks with


4.4. 802.11P: FROM DATA LINK LAYER TO PHYSICAL LAYER

a brief description about the main features of each of them:

• Symbols mapping: it creates the constellation symbols. It maps the payloadbits (SIGNAL+DATA) into symbols according to one of the available modu-lations (BPSK, QPSK, 16QAM or 64QAM). Note that this GnuRadio blockcannot change dynamically the modulation format, despite the fact that theDATA OFDM symbols exhibit likely a different modulation format with re-spect to the SIGNAL OFDM symbol.

• IFFT: it performs the ifft operation.

• Cyclic Prefix: it executes the cyclic prefix insertion.

• Scaling: it normalizes (by a simple multiplication) the average signal power.

• Training sequence: it gets as input a sequence from a Python static table andinsert it in front of each OFDM symbols. Note, in a real system case, thetraining sequence should be inserted only once before the first OFDM symbolof the frame.

As just described, the sequence chain showed in Figure 4.2 is a very simple OFDMgenerator. It performs few fundamental operations and is far from being 802.11p-a-gstandard compliant.

4.4 802.11p: From Data link layer to Physical

layer

The full IEEE 802.11p GnuRadio chain is showed in figure 4.3. We decided to im-plement some of the blocks in Python, instead of C++, due to their low processing-power requirements. More in particular, we used Python for all the blocks thatperform bit-operations (e.g. bit-shifts, bit-masks, etc.). The rest of the chain, fromsymbols mapping to the last block before the transmission, has been done entirelyin c++, due to tight real-time constraints. In the following subsections we describethe GnuRadio implementation of each block. For more details about the physicalimplementation and standard description, please refer to [1].

4.4.1 MAC and PLCP header

The first step in the transmitter chain is the encapsulation of the payload into theMAC and PLCP headers (see Chapter 2 for details). In figure 4.4 the format of the



Figure 4.3: IEEE 802.11p chain implemented in GnuRadio

PPDU, including the OFDM PLCP preamble, is showed. We recall that, in our case,the PLCP preamble is added from a static table and is here reported for the sakeof completeness. At this higher level, the frame assemblage has been performed byusing the Python programming language. The implementation details of this blockare confined in appendix C. More details about each single field depicted in Figure4.4 can be found in [27]. Note that, at this stage, tail and padding bits insertionis not a trivial task. The problem encountered is that the number of zeros to addis generally a fraction of byte. Since we can handle only bytes, we adopted thefollowing strategy: if the sum of tail bits and padding bits is a multiple of 8, thesmallest number of zero bits is additionally inserted in order to achieve an integernumber of bytes. Only during the encoding process these bits are finally removed.

4.4.2 CRC-32

The CRC-32 calculation has been conducted according to the algorithm in [28]. Thecode available in the GnuRadio repository did not produce a standard compliantCRC. Our standard compliant version of the CRC-32 code has been written in C++(see appendix B).



Figure 4.4: PLCP frame format and MPDU

4.4.3 Scrambler

The scrambling is performed in Python. The DATA field, composed of SERVICE,PSDU, tail and padding bits is XORed with the scrambler sequence, contained inthe Python script. The SIGNAL field is instead not scrambled. The implementationis in appendix C.

4.4.4 Convolutional encoder

The convolutional encoder was developed in Python as well. It uses the industrystandard polynomial generator g0 = 1338 and g1 = 1718 with rate R = 1/2. In figure4.5 the convolutional code generator is depicted. Note that the output B followsthe output A. The correct output sequence is then [A(1) B(1)], [A(2) B(2)], [A(3)B(3)] and so on. Appendix C contains the implementation details. Higher rates, foreach modulation, are obtained by means of the puncturing operation. As shown inAppendix C, after the convolution, some bits are periodically (according to a table)removed from the rate R = 1/2 codeword. Two puncturing tables allow for rates R= 3/4 and R = 2/3. Further details are contained in [27].



Figure 4.5: Convolutional encoder K = 7 block operation

4.4.5 Interleaver

The interleaver performs two consecutive permutations onto the coded bits of a singleOFDM block, containing a number NCBPS of bits that is modulation-dependent.The first one ensures that adjacent bits are mapped onto nonadjacent sub carriers.The second one ensures that adjacent coded bits are mapped alternately onto lessand more significant bits of the constellation. In this way, bursts of low-reliable bitsare avoided. Denote k = 0,1,........NCBPS - 1 the position index of the input codedbits, i the position index after the first permutation and j the position index afterthe second permutation. The first permutation works as follows:

i = (NCBPS/16) · (k mod 16) + floor(k/16).

The function floor denotes the largest integer not exceeding the argument. Thesecond permutation is defined by the rule:

j = s · floor(i/s) + (i + NCBPS − floor(16 · i/NCBPS)) mod s.

The value of s is determined by the number of coded bits per sub carriers NBPSC

s = max(NBPSC/2, 1).

The implementation details are available in Appendix C.



4.4.6 Symbols mapping

The symbols mapping block first divides the bits stream coming from the interleaverinto groups of NCBPS bits. In the standard 802.11p:

• NCBPS = 48 for BPSK modulation for rate 6 or 9 Mbit/s

• NCBPS = 96 for QPSK modulation for rate 12 or 18 Mbit/s

• NCBPS = 192 for 16-QAM modulation for rate 24 or 36 Mbit/s

• NCBPS = 288 for 64-QAM modulation for rate 48 or 54 Mbit/s

For each group, the corresponding bits are mapped into constellation symbols ofNBPSC bits:

• NBPSC = 1 for BPSK modulation

• NBPSC = 2 for QPSK modulation

• NBPSC = 4 for 16-QAM modulation

• NBPSC = 6 for 64-QAM modulation

The symbols are complex numbers representing BPSK, QPSK, 16-QAM or 64-QAMconstellation points. The symbols mapping available in the GnuRadio core repos-itory does not comply with the standard for two different reasons. First, the con-stellation mapping performed by the existent block is not the one required by thestandard. This problem has been isolated and solved by updating the existingPython code with the standard compliant symbol mapping. Second, the GnuRadioexisting block uses a fixed symbol constellation for all OFDM symbols. In the stan-dard, instead, the first OFDM symbol is always BPSK modulated. In fact, the firstsymbol (not considering the PLCP preamble, that it is conveniently inserted as veryfinal step of the encoding process according to our own design) corresponds to theSIGNAL field, which has to be always transmitted at the most conservative rate (6Mbit/s). The related C++ code is shown in Appendix B. In order to recognize thefirst symbol, our solution has been to set a counter of the streaming coded bits. Inthis way, we take the first 48 bits which correspond to the first OFDM symbol andmap them onto BPSK symbols. The remaining frame is modulated according to theselected regime.



4.4.7 Pilots insertion

For this block, the input item is 48 complex samples coming from the symbolsmapping processing block. Each input item is associated with one OFDM symbol.This block first associates to each complex sample a sub carrier position in theOFDM symbol. In particular, the standard assigns the 48 samples to the followingsub carriers: 1 to 6, 8 to 20, 22 to 26, -26 to -22, -20 to -8 and -6 to -1. Theremaining sub-carriers 7, 21, -21 and -7 are reserved to the pilot symbols. Figure4.6 clarifies the operation, where the input symbols X are indexed from 1 to 48.

Figure 4.6: Pilots insertion block operation

The four pilots in each OFDM symbol are necessary to allow for a robust coherentdetection. They are BPSK modulated by a pseudo-random binary sequence to pre-vent the generation of spectral lines. The polarity of the sub carriers is controlledby a sequence of 126 elements. For more details please refer to [27]. The implemen-tation of the pilots insertion block has been more challenging then for other blockslike the carrier permutation. In fact, blocks like carrier permutation, ifft, cyclic pre-fix addition do the same operation all the stream long. For instance the ifft blocktakes 64 samples in input and it always process these samples in the same way. Inthe pilots insertion instead the pilot polarity is not fixed. As described above, itchanges dynamically and depends on which OFDM symbol the block is processing.This means that a higher view on the position in the processed stream is necessary.To solve this problem, the solution has been using two counters. One inner counteris used with a local scope in the general work method and the other outer counter



is used with a global scope. The second counter is never reset during the frametransmission once it has been initialized. In this way, the outer counter combinedwith inner counter always keeps track of the current OFDM symbol position in theframe. Implementation details are available in Appendix B.

4.4.8 Carrier permutation

Figure 4.7: Carriers permutation block operation

This block receives 53 input samples from the pilot insertion block, permutes themand performs a zero-padding. Note that at this point of the chain the input ensembleexhibits 53 samples instead of 52 because a zero in the DC carrier position has beenalready added in the previous block. Figure 4.7 shows how this block works. Thecode,available in Appendix B, has been written in C++.

4.4.9 IFFT, cyclic prefix and scaling

We have already discussed about these three blocks in the section 4.2. In the 802.11pstandard, the number of points in the ifft is 64, while the cyclic prefix is 16 bits long.At the output of the cyclic prefix block we obtain 80 samples. The figure 4.8 depictsthe mentioned operations. The scaling block is necessary to fulfill the energy persymbol constraints.



Figure 4.8: Cyclic prefix block operation

4.4.10 Training sequence

The training sequence in the 802.11p standard, named PLCP preamble, allows forthe synchronization between transmitter and receiver at the OFDM symbol leveland the channel equalization. It is split into two different segments (the short andthe long preambles): the first one is the repetition of 10 short signals and has theduration of an OFDM symbol; the second one exhibits double duration and consistsof two equal OFDM symbols. More precisely, the short preamble is used for signaldetection, Automatic Gain Control (AGC), diversity selection, coarse frequency off-set estimation and fine timing synchronization. The long sequence,instead, is usedfor channel estimation and fine frequency offset estimation. The preamble is fixedand is added only once at the beginning of the frame. We take advantage fromthis situation by creating a static table in Python. This C++ block adds finallythe values given from the static table at the beginning of the frame. Note that thevalues stored in the Python script are the result of an off line processing through theoverall transmission chain of the values defined in the standard. Figure 4.9 showsan example of a 16-QAM modulated frame, generated with GnuRadio.

4.4.11 From floating point numbers to E.M. waves

We have already discussed about the Software Radio philosophy and the requiredhardware components. Here, we present how the stream of floating point numbersbecomes an electromagnetic wave through the air, as depicted in Figure 4.10.

The GnuRadio software deals with floating point numbers representing the base-band samples of signal to be transmitted. However, the Gigabit Ethernet requires



Figure 4.9: Example of complete 16-QAM frame generated in GnuRadio, payload100 bytes

Figure 4.10: Typical path followed from floating point number to E.M. wave

those sample to be represented as fixed point numbers. More precisely, the digitalformat is 16 bit I/Q Signed Integer. This conversion is crucial and must be takencarefully into account. In fact, the wrong input to this conversion can generatedistortion at the transmitter side. Figure 4.11 shows this operation.

As depicted, the conversion from the floating point number to the 16 bit I/Q signedinteger is linear for input values in the range (-1,+1). Elsewhere, the output satu-rates to -1 and 1 respectively for negative and positive input values. Therefore it isvery important to make sure that all samples (i.e. all floating point numbers) arein the range (-1,+1). A scaling block, that normalizes the numbers accordingly, isinserted before the transmission through the Gigabit Ethernet. Once converted the



Figure 4.11: Floating point to 16 bits Signed Integer linear transformation

stream of 16 bit I/Q Signed Integer numbers flows to the DSP motherboard. Thedigital signal is interpolated and transformed into the analog base-band signal.


CHAPTER 5. TESTING AND VALIDATION

Chapter 5

Testing and validation

This chapter presents the results of a preliminary measurement campaign that in-volves the deployed transmitter and a number of other devices. The main aim ofthis experiments is the assessment of the standard compliance of our gnuradio-based802.11p transmitter. A more comprehensive set of experiments will be presented in[3].

5.1 Testbed Description

We compiled and installed our code into a PC equipped with an Intel core 2 duoE8400 cpu, 4 GB of RAM, and an integrated Intel Gigabit Ethernet interface. Theoperating system environment was GNU/Linux (Ubuntu 8.10), with Python 2.5.2and the GnuRadio stable release 3.2.2. The Intel Gigabit Ethernet was connectedto a USRP2 equipped with the daughter board XCVR2450 and an antenna with5dBi gain.

At the receiver side we used a set of three hardware components (see Figure 5.1):

• a) An additional USRP2 connected to an independent host PC, used as spec-trum analyzer;

• b) A Ralink PCI card installed into a general purpose PC, used as 802.11a/greceiver.

• c) An experimental IEEE802.11p prototype deployed in the Cooperative Ve-hicle Infrastructure Systems (CVIS) project.


5.2. RESULTS

Figure 5.1: Radio testbed: Case a) USRP2 transmitter and USRP2 Spectrum An-alyzer. Case b) USRP2 and Ralink 802.11a receiver. Case c) USRP2 transmitterand CVIS 802.11p prototype.

5.2 Results

5.2.1 Spectral shape

The IEEE 802.11p standard includes four different spectrum masks labeled “ClassA”, “Class B”, “Class C”, and “Class D”. The details about these classes are avail-able in [1]. We used an additional USRP2 for analyzing the spectrum of the signalgenerated by our transmitter. Figure 5.2 shows that our transmitter is compliant

Figure 5.2: Transmitting spectrum and standard “Class A” and “Class B” maskscomparison


5.2. RESULTS

with the “Class A” and “Class B” spectrum masks. However, as it is shown inFigure 5.3, the signal spectrum presents two spurious peaks that exceed the limitsimposed by the “Class C” and “Class D” masks. We are currently investigatingwhether the two peaks are caused by a distortion of the receiver amplifiers or canbe mitigated by improving the transmitter source code.

Figure 5.3: Transmitting spectrum and standard “Class C” and “Class D” maskscomparison

5.2.2 IEEE 802.11a transmission

In the current draft version of the standard, the frame encoding procedure for IEEE802.11p differs from 11a and 11g only in two key aspects: the operating frequencyband is shifted to around 5.9GHz and the duration of OFDM symbols is doubledfrom 4 us to 8 us. Using symbol-time settings in accordance with 11a and a carrier-frequency in the 2.4GHz ISM band we were able to generate frames that were cor-rectly received by a conventional 802.11g chip set. This was achieved by settingan interpolation rate of 5 instead of 10. Figure 5.4 depicts the Frame Error Ratio(FER) for different frame lengths. The distance between transmitter and receiverwas kept constant to 3 meters yielding to a received power always greater than-80dBm. Clearly, the increased error probability of larger frames leads to higherFER.


5.2. RESULTS

Figure 5.4: FER for QPSK and 64-QAM modulation for different frame length

5.2.3 IEEE 802.11p transmission

In a final test we checked the standard compliance of the transmitter by usingthe IEEE 802.11p prototype from CVIS. Figure 5.5 shows the frame-error-ratioperformance over received-SNR for four different combinations of frame lengths andOFDM symbol-constellations. The channel setup (LOS, indoor) was kept constantand transmission-power-control at the USRP2 was used to realize specific averagereceived-SNR values. Each measurement-point corresponds to 104 frames sent witha rate of 200 frames/second. As we can see the BPSK modulation is the more robust

−5 0 5 10 15 200

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

SNR [dB]

Fra

me−

Err

or−

Rat

io

BPSK, R=0.7510 Bytes MSDU11 OFDM Symbols

BPSK, R=0.751500 Bytes MSDU342 OFDM symbols

64QAM, R=0.7510 Bytes MSDU3 OFDM symbols

64QAM, R=0.751500 Bytes MSDU58 OFDM symbols

Figure 5.5: FER vs received-SNR for BPSK 10 and 1500 bytes MSDU and for64-QAM 10and 1500 bytes MSDU

(i.e. FER near to zero) already with a very low Signal to Noise Ratio (less then10 dB), while the 64-QAM needs more then 22 dB in order to have the same FERvalues.


CHAPTER 6. CONCLUSIONS

Chapter 6

Conclusions

In this thesis we designed an IEEE 802.11p transmitter in open-source SoftwareDefined Radio. We focused on the physical layer implementation and we showedby means of different measurements that our gnuradio-based transmitter is able toreproduce correctly the PHY of 802.11a, 802.11g, and 802.11p transceiver.

Due to the current lack of commercial 802.11p chip sets, the research community hasstarted analyzing 802.11p link-layer performance by using simulation tools. How-ever, we believe that only real-world experiments can reliably evaluate the robust-ness of the standard in high-mobility scenarios. In this thesis we demonstrated thatthe high customizability of the GnuRadio platform makes it an attractive basis forinvestigating the real-world performance of upcoming draft protocols.

Note that the proposed transmitter implements only the physical layer functional-ities, i.e. it does not provide any MAC layer functions (except encapsulation intoframes). We are aware that the tight latency requirements of the carrier sensingscheme cannot be easily met by a full software radio transceiver on a general pur-pose pc. However we believe that moving some functionalities from the PC onto theUSRP2 FPGA will lead to a much faster operational reactivity. Regarding poten-tial future works, the first natural next step is the implementation of the receiverchain in MATLAB. This, together with the implementation of basic CSMA/CAfunctions, will place a milestone for the deployment of a fully interactive GnuRadioTx/Rx solution for IEEE 802.11a/g/p.


APPENDIX A. MATLAB CODE

Appendix A

MATLAB Code

clear all;

close all;

% Set ASCII message to send

message=’Here the massage to send’;

mac_body = reshape(dec2hex(unicode2native(message))’,

1,2*size(dec2hex(unicode2native(message)),1));

% Set modulation/coding mode

regime = 1;

% Set normalization factor in dB

gain_dB = 0; % make this negative if you want to modify signal-amplitude

% Set gap-time (in number of samples) to not violate DIFS if

% frame is transmitted repeatedly

gap_samples = 0;

% Set mac PDU:

mac_framectrl = ’0800’; % this is a data frame

mac_duration = ’0000’; % is calculated further down

mac_address1 = ’006008cd37a6’; % destination mac-address

mac_address2 = ’0020d6013cf1’; % source mac-address

mac_address3 = ’006008ad3baf’; % BSSID mac-address

mac_seqctrl = ’0000’; % 0 sequence and 0 fragment number

mac_crc = ’00000000’; % is calculated further down

% Optional fun stuff: disassociate STA from AP using this MPDU

% Set mac PDU:


% mac_framectrl = ’9000’; % MGMT disassociation frame

% mac_duration = ’0000’; % is calculated further down

% mac_address1 = ’0023127efe52’; % valid DST mac-address of STA

% mac_address2 = ’0018f8d2a29f’; % valid SRC mac-address of AP

% mac_address3 = ’0018f8d2a29f’; % valid BSSID mac-address of AP

% mac_seqctrl = ’0000’; % 0 sequence and 0 fragment number

% mac_crc = ’00000000’; % is calculated further dow

% mac_body = ’0100’;

% Moluation/coding parameters

p.Regime = regime; % One of 8 possible regimes

switch p.Regime % Regime-dependant parameters

case 1 % 3 Mbits/s *****MANDATORY*****

p.Modulation = ’BPSK’; % BPSK modulation

p.CodeRate = 1/2; % Coding rate 1/2 (unpunctured)

p.RateBits = [1 1 0 1];% RATE bits in the SIGNAL field

case 2 % 4.5 Mbits/s

p.Modulation = ’BPSK’; % BPSK modulation

p.CodeRate = 3/4; % Coding rate 3/4 (punctured)



p.Modulation = ’QPSK’; % QPSK modulation



case 4 % 9 Mbits/s

p.Modulation = ’QPSK’; % QPSK modulation




p.Modulation = ’16QAM’; % 16-QAM modulation



case 6 % 18 Mbits/s




case 7 % 24 Mbits/s




case 8 % 27 Mbits/s





otherwise

error([’Unknown regime ’ num2str(p.Regime)]);

end

switch p.Modulation % Coded bits per subcarrier

%depends on the modulation

case ’BPSK’ % BPSK has 1 bit per symbol

p.Nbpsc = 1; % Coded bits per subcarrier (BPSK)

p.Kmod = 1; % Normalization factor

case ’QPSK’ % QPSK has 2 bits per symbol

p.Nbpsc = 2; % Coded bits per subcarrier (QPSK)

p.Kmod = 1/sqrt(2); % Normalization factor

case ’16QAM’ % 16-QAM has 4 bits per symbol

p.Nbpsc = 4; % Coded bits per subcarrier (16-QAM)

p.Kmod = 1/sqrt(10);% Normalization factor

case ’64QAM’ % 64-QAM has 6 bits per symbol

p.Nbpsc = 6; % Coded bits per subcarrier (64-QAM)

p.Kmod = 1/sqrt(42);% Normalization factor

otherwise

error([’Unknown modulation ’ p.Modulation]);

end

p.nSubcarriers = 48; % Number of data subcarriers

p.nPilots = 4; % Number of pilot subcarriers

p.nPointsFFT = 64; % Number of points in the FFT/IFFT (power of 2)

p.nTrainingSymbols = 4; % Length of the training sequence

p.DeltaF = 10e6/p.nPointsFFT; % Subcarrier frequency spacing

p.Tfft = 1/p.DeltaF; % IFFT/FFT period

p.Tgi = p.Tfft/4; % Guard interval duration

p.Tsym = p.Tfft+p.Tgi; % Symbol interval

p.Tsamp = p.Tfft/p.nPointsFFT; % Sample time

p.nGuardSamples = p.Tgi/p.Tsamp; % Samples in the guard interval

p.nPreambleSym = 0; % Number of preamble OFDM symbols

p.Ncbps = p.nSubcarriers*p.Nbpsc; % Coded bits per OFDM symbol

p.Ndbps = p.Ncbps*p.CodeRate; % Data bits per OFDM symbol

p.DataRate = p.Ndbps/p.Tsym; % Data rate (3,4.5,6,9,12,18,24,27 Mbits/s)

% Assemble MPDU

packet = strcat(mac_framectrl,mac_duration,mac_address1,

mac_address2,mac_address3,mac_seqctrl,mac_body,mac_crc);

%--- Calculate duration bits ----------------------------------------

TxTime = 20 + 4 * ceil((16 + 4 * length(packet) + 6)/p.Ndbps) + 2


% The additional 2 is not in the standard!

mac_duration = dec2hex(TxTime,4);

%--- Update duration bits ----------------------------------------

packet = strcat(mac_framectrl,mac_duration,mac_address1,mac_address2,

mac_address3,mac_seqctrl,mac_body);

%--- Generate CRC and append it -------------------------------------

m = uint32(hex2dec(’ffffffff’));

crc_m = uint32(hex2dec(’edb88320’));

if exist(’crc32_table’) == 0

disp(’Creating crc32_table...’);

crc32_table = zeros(1,256,’uint32’);

for byte = 0:255

crc = byte;

for j = 1:8

if bitand(crc,1) == 1

mask = m;

else

mask = 0;

end

crc = bitxor(bitshift(crc,-1),bitand(crc_m, mask));

end

crc32_table(byte+1) = crc;

dec2hex(crc32_table(byte+1));

end

end

len = length(packet);

i = 1;

ff = uint32(hex2dec(’ff’));

crc = m;

while i < len

byte = uint32(hex2dec(packet(i:i+1)));

t_index = bitand(bitxor(crc, byte), ff) + 1;

crc = bitxor(bitshift(crc,-8), crc32_table(t_index));

i = i+2;

end

crc = bitxor(crc,m);

crc_bin = dec2bin(crc,32);

crc = fliplr(crc_bin);


crc=logical((sscanf(crc,’%1d’)).’);

% Change into transmit order and make logical

temp = ’’;

for i=1:length(packet)/2

first_nibble = dec2bin(hex2dec(packet(2*i)),4);

second_nibble = dec2bin(hex2dec(packet(2*i-1)),4);

for t = 1:4

first_nibble_rev(t) = first_nibble(5-t);

second_nibble_rev(t) = second_nibble(5-t);

end

temp = strcat(temp,first_nibble_rev,second_nibble_rev);

end

MPDUData = 0;

for i=1:length(temp)

MPDUData(i)=logical(str2num(temp(i)));

end

TxData = [MPDUData crc];

%--- Generate short training sequence -------------------------------

p.S = (1.472+1.472i)*...

[0,0,1,0,0,0,-1,0,0,0,1,0,0,0,-1,0,0,0,-1,0,0,0,1,0,0,0, ...

0, ... % DC subcarrier, also in PREAMBLE

0,0,0,-1,0,0,0,-1,0,0,0,1,0,0,0,1,0,0,0,1,0,0,0,1,0,0];

%--- OFDM modulation (IFFT) ----------------------------------------

X=zeros(p.nPointsFFT,1); % Empty input to the IFFT

% Map subcarriers accordingly

X(39:64) = p.S(1:26); % Map subcarriers -26 to -1

X(1) = p.S(27); % Map DC subcarrier (not really necessary)

X(2:27) = p.S(28:53); % Map subcarriers 1 to 26

% Inverse fft

x=sqrt(p.nPointsFFT)*ifft(X,p.nPointsFFT); % IFFT


short_preamble=[x;x;x(1:32)]; % Repeat periodically for 2.5 times

%--- Generate long training sequence -------------------------------

p.L = [1,1,-1,-1,1,1,-1,1,-1,1,1,1,1,1,1,-1,-1,1,1,-1,1,-1,1,1,1,1, ...

0, ... % DC subcarrier, also in PREAMBLE

1,-1,-1,1,1,-1,1,-1,1,-1,-1,-1,-1,-1,1,1,-1,-1,1,-1,1,-1,1,1,1,1];


X=zeros(p.nPointsFFT,1); % Empty input to the IFFT


X(39:64) = p.L(1:26); % Map subcarriers -26 to -1

X(1) = p.L(27); % Map DC subcarrier (not really necessary)

X(2:27) = p.L(28:53); % Map subcarriers 1 to 26

% Inverse fft


% Cyclic prefix using block-diagonal matrix T (note: double length!)

I=eye(2*p.nPointsFFT); % Identitity matrix used to construct T

T=[I(2*p.nPointsFFT-2*p.nGuardSamples+1:end,:);I];

% T is matrix for cyclic prefix insertion

long_preamble=T*[x;x];

%--- Generate Pilots -----------------------------------------------

p.Pseq = [... % Pilot sequence of 127 BPSK symbols

1,1,1,1, -1,-1,-1,1, -1,-1,-1,-1, 1,1,-1,1, -1,-1,1,1, -1,1,1,-1,...

1,1,1,1, 1,1,-1,1, 1,1,-1,1, 1,-1,-1,1, 1,1,-1,1, -1,-1,-1,1,...

-1,1,-1,-1, 1,-1,-1,1, 1,1,1,1, -1,-1,1,1, -1,-1,1,-1, 1,-1,1,1,...

-1,-1,-1,1, 1,-1,-1,-1, -1,1,-1,-1, 1,-1,1,1, 1,1,-1,1, -1,1,-1,1,...

-1,-1,-1,-1, -1,1,-1,1, 1,-1,1,-1, 1,1,1,-1, -1,1,-1,-1, -1,1,1,1,...

-1,-1,-1,-1, -1,-1,-1

];

% Calculate p.pilot, the pilot sequence adapted to the given frame length

p.DataSize = ceil(size(TxData,2)/8); % Payload size in bytes

p.nDataSym = ceil((p.DataSize*8+22)/p.Ndbps); % Number of data OFDM symbols

plen=p.nDataSym+1; % Desired length of pilot (=data+signal)

p.pilot1=zeros(1,plen); % Create the empty pilot vector

p.pilot2=zeros(1,plen);



l=size(p.Pseq,2); % Length of the provided pilot sequence

copies=ceil(plen/l); % Number of (partial) copies needed

for c=1:copies % Go through all copies

if(c<copies) % This is not the last copy


p.pilot1(1,(c-1)*l+1:c*l)=p.Pseq; % Paste the whole sequence

p.pilot2(1,(c-1)*l+1:c*l)=p.Pseq;

p.pilot3(1,(c-1)*l+1:c*l)=p.Pseq;

p.pilot4(1,(c-1)*l+1:c*l)=-p.Pseq;

else % This is the last (partial?) copy

p.pilot1(1,(c-1)*l+1:end)=... % Fill the end of the pilot vector...

p.Pseq(1:plen-(c-1)*l); % ... with a part of the sequence


p.Pseq(1:plen-(c-1)*l);


p.Pseq(1:plen-(c-1)*l);


-1*p.Pseq(1:plen-(c-1)*l);

end % if statement (last copy)

end % for loop (copies)

%--- Construct signal-bitstream ------------------------------------

signal=logical(zeros(1,24)); % Empty SIGNAL field

signal(1:4)=p.RateBits; % Insert the RATE bits

bytes=length(TxData)/8; % Length of PSDU in bytes

lenstr=dec2bin(bytes,12); % Convert to a binary (string!)

len=(sscanf(lenstr,’%1d’)).’; % Length vector

signal(6:17)=logical(fliplr(len)); % Write the length bits, LSB first!

signal(18)=mod(sum(signal(1:17)),2); % even parity bit

%--- Construct data-bitstream --------------------------------------

dlen=ceil((length(TxData)+22)/p.Ndbps)*p.Ndbps;

% Length of the DATA field, allocate 16 bits service + 6 bits tail

data=logical(zeros(1,dlen)); % Empty DATA field

data(17:16+length(TxData))=TxData; % Copy in the actual data

%--- Scramble data-bitstream ---------------------------------------

scrambling_seq =

[0 1 1 0 1 1 0 0 0 0 0 1 1 0 0 1 1 0 1 0 1 0 0 1 1 1 0 0 1 1 1 1,...

0 1 1 0 1 0 0 0 0 1 0 1 0 1 0 1 1 1 1 1 0 1 0 0 1 0 1 0 0 0 1 1,...

0 1 1 1 0 0 0 1 1 1 1 1 1 1 0 0 0 0 1 1 1 0 1 1 1 1 0 0 1 0 1 1,...

0 0 1 0 0 1 0 0 0 0 0 0 1 0 0 0 1 0 0 1 1 0 0 0 1 0 1 1 1 0 1’];

% Make copies of the short scramble-sequence and concatenate them

final_scrambling_seq = repmat(scrambling_seq,1,ceil(length(data)/127));

% Scramble the stuff

data_scrambled = xor(data,final_scrambling_seq(1:length(data)));

A = data_scrambled;

% Optional: turn off scrambling ------------------------------------

%data_scrambled = data;


% Insert the tail bits to make the conv-decoder at the receiver

% return to 0 state at last bit of the crc

data_scrambled(length(TxData)+17:length(TxData)+22) = logical([0 0 0 0 0 0]);

%--- Convolutional encoder -----------------------------------------

%--- Coding parameters ---------------------------------------------

p.K = 7; % Constraint length of the code

p.CodeGen = [133 171]; % Code generator for the convolutional encoder

p.Trellis = poly2trellis(p.K,p.CodeGen); % Encoder/decoder trellis

% Encode signal and data separately

signal_coded=convenc(signal,p.Trellis); % Encoding the SIGNAL field

data_coded=convenc(data_scrambled,p.Trellis); % Encoding the DATA field

switch p.CodeRate % Need to puncture if the rate is not 1/2

case 2/3

data_coded(4:4:end)=[]; % Remove every 4th bit

case 3/4

data_coded(4:6:end)=[];

data_coded(4:5:end)=[]; % Remove every 4th+5th bit

end

%--- Interleaver ---------------------------------------------------

%--- Signal field --------------------------------------------------

sin=reshape(signal_coded,48,[]); % Reshape into blocks of 48 bits

% First permutation

for k=0:47 % Go through all the bits

i=48/16*mod(k,16)+floor(k/16); % Calculate index

stemp(i+1,:)=sin(k+1,:); % Interleave

end % For loop (bits)

% Second permutation (not necessary as j=i for BPSK)

signal_interleaved=reshape(stemp,1,[]); % Just make into a long vector again

%--- Data field ----------------------------------------------------

din=reshape(data_coded,p.Ncbps,[]); % Reshape into blocks of Ncbps bits

% First permutation

for k=0:p.Ncbps-1 % Go through all the bits

i=p.Ncbps/16*mod(k,16)+floor(k/16); % Calculate new index

dtemp(i+1,:)=din(k+1,:); % Interleave


% Second permutation

s=max(p.Nbpsc/2,1); % Parameter used in index calculation below

for i=0:p.Ncbps-1 % Go through all the bits

j=s*floor(i/s)+mod(i+p.Ncbps-floor(16*i/p.Ncbps),s); % Calculate new index

dout(j+1,:)=dtemp(i+1,:); % Interleave



data_interleaved=reshape(dout,1,[]); % Make into a long vector again

%--- Symbol mapper -------------------------------------------------

%--- Signal field (always BPSK) ------------------------------------

signal_mapped=qammod(double(signal_interleaved),2); % Just direct BPSK mapping

%----Data field ----------------------------------------------------

s=reshape(data_interleaved,p.Nbpsc,[]); % Divide into symbols

d=zeros(1,size(s,2)); % Holder for decimal data values

for row=1:p.Nbpsc % Iterate over rows of s

d=d+s(row,:)... % d is a weighted sum of rows of s

*2^(p.Nbpsc-row); % Weights are decreasing powers of 2

end % for loop (rows of s)

data_mapped=conj(qammod(d,2^p.Nbpsc,0,’gray’))*p.Kmod; % Map on the IQ plane

%data_mapped=qammod(double(data_interleaved),2);

%--- Assemble the frame --------------------------------------------

frame=zeros(p.nSubcarriers+p.nPilots+1,(length(data_mapped)/p.nSubcarriers)+1);

% One extra column for SIGNAL OFDM-symbol

%--- Insert the data subcarriers -----------------------------------

% Concat SIGNAL and DATA

d=[signal_mapped.’ reshape(data_mapped,p.nSubcarriers,[])];

%d=reshape(data_mapped,p.nSubcarriers,[]);

frame(1:5,1:end) =d(1:5,:); % Subcarriers -26 to -22

frame(7:19,1:end) =d(6:18,:); % Subcarriers -20 to -8

frame(21:26,1:end)=d(19:24,:); % Subcarriers -6 to -1

frame(28:33,1:end)=d(25:30,:); % Subcarriers 1 to 6



%--- Insert the pilot subcarriers ----------------------------------

frame(6,1:end) =p.pilot1; % Subcarrier -21

frame(20,1:end)=p.pilot2; % Subcarrier -7

frame(34,1:end)=p.pilot3; % Subcarrier 7

frame(48,1:end)=p.pilot4; % Subcarrier 21



X=zeros(p.nPointsFFT,size(frame,2)); % Empty input to the IFFT

% Identitity matrix used to construct T

I=eye(p.nPointsFFT);

% Matrix for cyclic prefix insertion

T=[I(p.nPointsFFT-p.nGuardSamples+1:end,:);I];


X(39:64,:)=frame(1:26,:); % Map subcarriers -26 to -1

X(1,:) =frame(27,:); % Map DC subcarrier (not really necessary)

X(2:27,:) =frame(28:53,:); % Map subcarriers 1 to 26

% Inverse fft

%x=sqrt(p.nPointsFFT)*ifft(X,p.nPointsFFT); % IFFT


% Cyclic prefix using block-diagonal matrix T

Snd=T*x;

%--- Serialize -----------------------------------------------------

final = [reshape(Snd,1,size(Snd,1)*size(Snd,2))];

%--- Insert the long preamble sequence -----------------------------

final = [reshape(long_preamble,1,size(long_preamble,1)) final];

%--- Insert the short preamble sequences ---------------------------

final = [reshape(short_preamble,1,size(short_preamble,1)) final];

%--- Normalization -------------------------------------------------

normalization_factor = 10^(gain_dB/20)/max(abs(final));

final = normalization_factor*final;

%--- Optional: insert some gaps ------------------------------------

final = [zeros(1,gap_samples) final zeros(1,gap_samples)];

%--- Optional: plot the result- ------------------------------------

figure;

plot(abs(final),’r’);

%subplot(3,1,1);plot(abs(final),’r’);

%subplot(3,1,2);plot(unwrap(angle(final)),’r’);

%subplot(3,1,3);plot(abs(fftshift(fft(final))),’r’);

%--- Write to file - img parts first ---------------------

file_name=’packet.dat’;

fid = fopen(file_name,’w’);

new_save = reshape([imag(final) ; real(final)],1,2*length(final));

F = fwrite(fid,new_save,’float’);

fclose all;


APPENDIX B. C++ CODE

Appendix B

C++ code

In these examples we miss the less important part

header file, include stuff, and so on. More

specification about general_work, forecast

method in www.gnu.org/software/gnuradio/doc/howto-write-a-block.html

//////////////////////////////

CARRIER PERMUTATION

//////////////////////////////

ftw_cmap_cc_sptr

ftw_make_cmap_cc (int fft_size, int tones)

{

return ftw_cmap_cc_sptr (new ftw_cmap_cc (fft_size , tones));

}

static const int MIN_IN = 1; // mininum number of input streams

static const int MAX_IN = 1; // maximum number of input streams

static const int MIN_OUT = 1; // minimum number of output streams

static const int MAX_OUT = 1; // maximum number of output streams

/*

* The private constructor

*/

ftw_cmap_cc::ftw_cmap_cc (int fft_size, int tones)

// tones should be 48 subcarriers + 4 pilots + dc = 53

: gr_block ("cmap_cc",

gr_make_io_signature (MIN_IN, MAX_IN, tones * sizeof (gr_complex)),

gr_make_io_signature (MIN_OUT, MAX_OUT, fft_size * sizeof (gr_complex))),


d_fft_size(fft_size),

d_tones(tones)

{

}

/*

* Our virtual destructor.

*/

ftw_cmap_cc::~ftw_cmap_cc ()

{

}

int

ftw_cmap_cc::general_work (int noutput_items,

gr_vector_int &ninput_items,

gr_vector_const_void_star &input_items,

gr_vector_void_star &output_items)

{

const gr_complex *in = (const gr_complex *) input_items[0];

gr_complex *out = (gr_complex *) output_items[0];

int counter=0;

int i=0;

//gr_complex *app = new gr_complex(0);

/*

* Sanity check

*/

if(d_fft_size != 64)

{

throw std::invalid_argument("ftw_cmap_cc:

For IEEE 802.11p fft_length must be 64 ");

}

while(counter < noutput_items)

{

for (i = 0; i <= 26; i++)

{

out[i + (counter * d_fft_size)] = in[i+26 + (counter * d_tones )];

}


for (i = 27 ; i <= 37 ; i++)

{

out[i + (counter * d_fft_size)] = 0;

}

for (i = 38; i < d_fft_size ; i++)

{

out[i + (counter * d_fft_size)] = in[i-38 + (counter * d_tones)];

}

counter++;

}

counter++;

// Tell runtime system how many input items we consumed on

// each input stream.

consume_each (noutput_items);

// Tell runtime system how many output items we produced.

return noutput_items;

}

/////////////////////////////

PILOTS INSERTION

/////////////////////////////

ftw_pilot_cc_sptr

ftw_make_pilot_cc (int tones)

{

return ftw_pilot_cc_sptr (new ftw_pilot_cc (tones));

}

static const int MIN_IN = 1; // mininum number of input streams

static const int MAX_IN = 1; // maximum number of input streams

static const int MIN_OUT = 1; // minimum number of output streams

static const int MAX_OUT = 1; // maximum number of output streams

ftw_pilot_cc::ftw_pilot_cc (int tones)

: gr_block ("pilot_cc",

gr_make_io_signature (MIN_IN, MAX_IN, tones * sizeof (gr_complex)),

gr_make_io_signature (MIN_OUT, MAX_OUT, (5 + tones) * sizeof (gr_complex))),

d_tones(tones)

{

}


ftw_pilot_cc::~ftw_pilot_cc ()

{

}

int i=0, offset=0;

int

ftw_pilot_cc::general_work (int noutput_items,

gr_vector_int &ninput_items,



{

const gr_complex *in = (const gr_complex *) input_items[0];

gr_complex *out = (gr_complex *) output_items[0];

gr_complex polarity[127] = {1,1,1,1,-1,-1,-1,1,-1,-1,-1,-1,1,1,

-1,1,-1,-1,1,1,-1,1,1,-1,1,1,1,1, 1,1,-1,1,1,1,-1,1,1,-1,-1,1,1,1,-1,1,

-1,-1,-1,1,-1,1,-1,-1, 1,-1,-1,1, 1,1,1,1,-1,-1,1,1,-1,-1,1,-1, 1,-1,1,

1,-1,-1,-1,1, 1,-1,-1,-1,-1,1,-1,-1,1,-1,1,1, 1,1,-1,1,-1,1,-1,1,-1,-1,

-1,-1,-1,1,-1,1,1,-1,1,-1, 1,1,1,-1,-1,1,-1,-1,-1,1,1,1,-1,-1,-1,-1, -1,

-1,-1};

int count =0;

/*

* Sanity check

*/

if(d_tones != 48) {

throw std::invalid_argument("ftw_pilot_cc:

For IEEE 802.11p the subcarriers must be 48 \n");

}

while (count < noutput_items)

{

for(i = 0 ; i <= 4 ; i++){

// Subcarriers (-26 ---> -22)

out[i + ((count)*(d_tones + 5))] = in[i + ((count) * d_tones)];

}

// Pilot 1 (-21)

out[5 + ((count)*(d_tones + 5))] = polarity[(count+offset)%127];

for(i = 6 ; i <= 18; i++){

// Subcarriers (-20 ---> -8)

out[i + ((count)*(d_tones + 5))] = in[i-1 + ((count) * d_tones)];


}

// Pilot 2 (-7)


for(i = 20 ; i <= 25 ; i++){

// Subcarriers (-6 ---> -1)


}

out[26 + ((count)*(d_tones + 5))] = 0; // DC

for(i = 27 ; i <= 32 ; i++){

// Subcarriers (+1 ---> +6)


}

// Pilot 3 (+7)


for(i = 34 ; i <= 46 ; i++){

// Subcarriers (+8 ---> +20)


}

// Pilot 4 (+21)

out[47 + ((count)*(d_tones + 5))] = -(polarity[(count+offset)%127]);

for(i = 48 ; i <= 52; i++){

// Subcarriers (+22 ---> +26)


}

count++;

}

offset += count;

// Tell runtime system how many input items we consumed on

// each input stream.

consume_each (noutput_items);

// Tell runtime system how many output items we produced.

return noutput_items;

}

//////////////////////////


SYMBOLS MAPPING

//////////////////////////

Here we report only the work method

int

ftw_ofdm_mapper::work(int noutput_items,



{

gr_complex *out = (gr_complex *)output_items[0];

unsigned int i=0;

gr_complex proof;

float map_re, map_im;

unsigned char temp;

if(d_eof) {

return -1;

}

if(!d_msg) {

d_msg = d_msgq->delete_head(); // block, waiting for a message

d_msg_offset = 0;

d_bit_offset = 0;

d_pending_flag = 1; // new packet, write start of packet flag

if((d_msg->length() == 0) && (d_msg->type() == 1)) {

d_msg.reset();

return -1; // We’re done; no more messages coming.

}

}

char *out_flag = 0;

if(output_items.size() == 2)

out_flag = (char *) output_items[1];

// Build a single symbol:

// Initialize all bins to 0 to set unused carriers

memset(out, 0, d_occupied_carriers * sizeof(gr_complex));

bool FIRST_SYMBOL;

i = 0;

unsigned char bits = 0;

int test=0;


unsigned char *seed;

gr_complex constellation_bpsk[2]={-1 , 1};

while((d_msg_offset < d_msg->length()) && (i < d_subcarrier_map.size())) {

// need new data to process

if(d_msg_offset <=5){

d_nbits = 1;

FIRST_SYMBOL = 1;

}

else{

d_nbits = (unsigned long)ceil(log10(d_constellation.size()) / log10(2.0));

FIRST_SYMBOL = 0;

}

if(d_bit_offset == 0) {

d_msgbytes = d_msg->msg()[d_msg_offset];

#if DEBUG

printf("mod message byte: %x\n", d_msgbytes);

#endif

seed = &d_msgbytes;

test = *seed;

#if DEBUG

for (int k=0; k<8; ++k)

{

printf("%d ", (test >> 7) & 0x01);

test <<=1;

}

#endif

}

if(d_nresid > 0) {

// take the residual bits, fill out nbits with info from the new byte,

// and put them in the symbol

d_resid = (d_resid << d_nresid) |

((d_msgbytes & (0xf << (8-d_nresid))) >> (8-d_nresid));

bits = d_resid;

out[d_subcarrier_map[i]] = d_constellation[bits];

proof = out[d_subcarrier_map[i]];

#if DEBUG

map_re = proof.real();

map_im = proof.imag();


printf("%d",i);printf("-esima--> %f ", map_re);

printf("%f", map_im);printf("j");

printf("\n");

#endif

i++;

d_bit_offset += d_nresid;

d_nresid = 0;

d_resid = 0;

}

else {

if((8 - d_bit_offset) >= d_nbits) {

/*test to make sure we can fit nbits

take the nbits number of bits at a time

from the byte to add to the symbol */

temp = d_msgbytes;

bits = ((1 << d_nbits)-1) & (d_msgbytes >> ((8-d_nbits) - d_bit_offset));

d_msgbytes = temp;

#if DEBUG

printf("bits= %d\n",bits);

#endif

d_bit_offset += d_nbits;

if (FIRST_SYMBOL){

out[d_subcarrier_map[i]] = constellation_bpsk[bits];

}

else{

out[d_subcarrier_map[i]] = d_constellation[bits];

}

proof = out[d_subcarrier_map[i]];

map_re = proof.real();

map_im = proof.imag();

#if DEBUG

printf("%d",i);printf("-esima--> %f ", map_re);

printf("%f", map_im);printf("j");

printf("\n");

#endif

i++;

}

else { // if we can’t fit nbits, store them for the next

// saves d_nresid bits of this message where d_nresid < d_nbits

unsigned int extra = 8-d_bit_offset;


d_resid = ((1 << extra)-1) & (d_msgbytes);

d_bit_offset += extra;

d_nresid = d_nbits - extra;

}

}

if(d_bit_offset == 8) {

d_bit_offset = 0;

d_msg_offset++;

}

}

// Ran out of data to put in symbol

if (d_msg_offset == d_msg->length()) {

if(d_nresid > 0) {

d_resid |= 0x00;

bits = d_resid;

d_nresid = 0;

d_resid = 0;

}

while(i < d_subcarrier_map.size()) { // finish filling out the symbol

std::cout << "Warning: random stuff is going on" << std::endl;

out[d_subcarrier_map[i]] = d_constellation[randsym()];

i++;

}

if (d_msg->type() == 1){ // type == 1 sets EOF

d_eof = true;

}

d_msg.reset(); // finished packet, free message

assert(d_bit_offset == 0);

}

if (out_flag)

out_flag[0] = d_pending_flag;

d_pending_flag = 0;

return 1; // produced symbol

}


/////////////////////////////////

CRC-32 CALCULATION

/////////////////////////////////

unsigned int

update_crc32(unsigned int crc, const unsigned char *data, size_t len)

{

int i,j;

unsigned int byte, mask;

static unsigned int table[256];

/* Set up the table if necesary */

if (table[1] == 0){

for(byte = 0; byte <= 255; byte++){

crc = byte;

for (j = 7; j >= 0; j--){

mask = -(crc & 1);

crc = (crc >> 1) ^ (0xEDB88320 & mask);

}

table[byte] = crc;

}

}

/* Calculate the CRC32*/

i = 0;

crc = 0xFFFFFFFF;

for (i = 0; i < len; i++){

byte = data[i]; //Get next byte

crc = (crc >> 8) ^ table[(crc ^ byte) & 0xFF];

}

unsigned int crc_reversed;

crc_reversed = 0x00000000;

for (i=31; i >= 0; i--){

crc_reversed |= ((crc >> i) & 1) << 31-i;

}

return crc_reversed;

}


APPENDIX C. PYTHON CODE

Appendix C

Python code

/////////////////////////////////////////

INTERLEAVER

/////////////////////////////////////////

def interleaver (payload , regime):

length_payload = len(payload)

length_payload_bit = 8 * length_payload

info = get_info(payload, regime)

modulation = info["modulation"]

regime = info["regime"]

N_cbps = info["N_cbps"]

N_bpsc = info["N_bpsc"]

half_interleaved = first_permutation(payload,\

N_cbps, length_payload_bit)

interleaved = second_permutation(half_interleaved,\

N_cbps, N_bpsc, length_payload_bit)

return interleaved

def first_permutation(payload, N_cbps, length_payload_bit):

app = conv_packed_binary_string_to_1_0_string(payload)

app=list(app)

new = [’0’] * len(app)

if(N_cbps == 48): # Modulation "bpsk"

j=0

while(j < length_payload_bit/N_cbps):

for k in range (0, N_cbps):


i = (N_cbps/16) * (k%16) + int(math.floor(k/16))

new[i + (j*N_cbps)] = app[k + (j*N_cbps)]

j +=1

else: # other modulation ---> first 48 bits alone (signal field)

for k in range (0, 48):

i = (48/16) * (k%16) + int(math.floor(k/float(16)))

new[i] = app[k]

j = 0

while(j < (length_payload_bit - 48) / N_cbps):

for k in range (0, N_cbps):

i = (N_cbps/16) * (k%16) + int(math.floor(k/float(16)))

new[i + 48 + (j*N_cbps)] = app[k + 48 + (j*N_cbps)]

j +=1

new = "".join(new)

return conv_1_0_string_to_packed_binary_string(new)

def second_permutation(half_interleaved, N_cbps, N_bpsc, length_payload_bit):

app = conv_packed_binary_string_to_1_0_string(half_interleaved)

app=list(app)

new_temp = [’0’] * (len(app) - 48)

new = app[0:48] + new_temp

s = max(N_bpsc/2 , 1)

k=0

while (k < (length_payload_bit - 48)/N_cbps):

for i in range (0 , N_cbps):

j = (s * int(math.floor(i/s))) +\

(i + N_cbps - (int(math.floor(16*i/float(N_cbps))))) % s

new[j + 48 + (k*N_cbps)] = app[i + 48 + (k*N_cbps)]

k +=1

new = "".join(new)

return conv_1_0_string_to_packed_binary_string(new)


////////////////////////////////////////

CONVOLUTIONAL ENCODER

///////////////////////////////////////

def conv_encoder(pkt, Length, regime):

info = get_info(pkt, regime)



N_dbps = info["N_dbps"]

N_rate = info["rate"]

N_sym = info["N_sym"]

#We could have more then correct number we need

# See Tail and pad in my_make function

Real_num_of_bits = N_sym * N_cbps

app = conv_packed_binary_string_to_1_0_string(pkt)

app = list(app)

encoded = [’0’] * (2 * len(app))

g0 = 0x5b # Generator polynomial (133 base 8)

g1 = 0x79 # Generator polynomial (171 base 8)

outA = 0

outB = 0

register = 0

for i in range (0, len(app)):

if(app[i] == ’1’):

# Shift the status in the conv encoder

register = register >> 1

# push 1 in the first element in the register after the shift

register = register | 0x40

else:

register = register >> 1

modA = modB = 0

for k in range (0,8):

# Parity check (count the number of 1s)

modA += (((register & g0) >> k) & (0x01))

modB += (((register & g1) >> k) & (0x01))

outA = modA % 2 # Modulo 2 sum

outB = modB % 2

encoded[2 * i] = str(outA)

encoded[2 * i + 1] = str(outB)


# Puncturing operations-----------------------------------------------

if (regime == "1" or regime== "3" or regime == "5"):

print"real_num...= ",Real_num_of_bits+48

print"length encoded= ",len(encoded)

encoded = encoded[0:48 + Real_num_of_bits]

encoded = "".join(encoded)

return conv_1_0_string_to_packed_binary_string(encoded)

elif (regime == "2" or regime == "4" or regime == "6" or regime == "8"):

signal_coded = encoded[0:48]

data_coded = encoded[48:]

dinamic_offset = 0

new = data_coded[0:3]

while dinamic_offset + 9 < len(data_coded)-1 :

new = new + data_coded[5 + dinamic_offset : 9 + dinamic_offset]

dinamic_offset += 6

new.append(data_coded[5 + dinamic_offset])

new = new[0:Real_num_of_bits]

new = signal_coded + new

encoded = "".join(new)


elif (regime == "7"):

dinamic_offset = 0

signal_coded = encoded[0:48]

data_coded = encoded[48:]

new = data_coded[0:3]

while dinamic_offset + 4 < len(data_coded) -1 :

new = new + data_coded[4 + dinamic_offset : 7 + dinamic_offset]

dinamic_offset += 4

new = new[0:Real_num_of_bits]

new = signal_coded + new

encoded = "".join(new)

print"real_num...= ",Real_num_of_bits+48

print"length encoded= ",len(encoded)


else:

print"The inserted regime is unknown\n"

sys.exit(1)


///////////////////////////////////

SCRAMBLER

///////////////////////////////////

def scrambler(pkt, Length_data):

scrambling_seq = \

[0, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0, 1,\

0, 0, 1, 1, 1, 0, 0, 1, 1, 1, 1,\

0, 1, 1, 0, 1, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 1, 1, 1, 1, 1, 0,\

1, 0, 0, 1, 0, 1, 0, 0, 0, 1, 1,\

0, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, \

0, 1, 1, 1, 1, 0, 0, 1, 0, 1, 1,\

0, 0, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 0,\

0, 0, 1, 0, 1, 1, 1, 0, 1];

app = conv_packed_binary_string_to_1_0_string(pkt)

app = list(app)

zero_forcing_index = Length_data * 8

print"length data in scrambler= ",Length_data

scrambled = app[0:24]

# Start from 24 because signal field mustn’t be scrambled

for k in range (24 , len(app)):

scrambled.append(str(int(app[k])^(scrambling_seq[(k-24) % 127])))

# Force six bit to "0" in return to 0 state at last bit of the crc

for i in range (23 + zero_forcing_index +17 , \

23 + zero_forcing_index + 22 + 1):

scrambled[i] = ’0’

scrambled = "".join(scrambled)

return conv_1_0_string_to_packed_binary_string(scrambled) , Length_data

///////////////////////////////////

PLCP HEADER + FAKE MAC

//////////////////////////////////

def my_make(payload, regime):

#-------------- Adds Simple MAC address -------------------------

mac_framectrl = chr(0x08) + chr(0x00) # this is a data frame

mac_duration = chr(0x00) + chr(0x00) # is calculated further down

mac_address1 = chr(0x00) + chr(0x60) +\

chr(0x08) + chr(0xcd) + chr(0x37) + chr(0xa6) # destination mac-address

mac_address2 = chr(0x00) + chr(0x20) +\


chr(0xd6) + chr(0x01) + chr(0x3c) + chr(0xf1) # source mac-address

mac_address3 = chr(0x00) + chr(0x60) + \

chr(0x08) + chr(0xad) + chr(0x3b) + chr(0xaf) # BSSID mac-address

mac_seqctrl = chr(0x00) + chr(0x00) # 0 sequence and 0 fragment number

mac_crc = chr(0x00) + chr(0x00) +\

chr(0x00) + chr(0x00) # is calculated further down

#_______________________________________________________________________

info = get_info(payload, regime)

modulation = info["modulation"]

regime = info["regime"]



N_dbps = info["N_dbps"]

packet = info["packet"]

#------Time, Data and Padding Calculation---------------

N_sym = info["N_sym"]

Txtime = info["Txtime"]

print"txtime= ", Txtime

mac_duration = info["mac_duration"]

N_data = info["N_data"]

N_pad = info["N_pad"]

#----Sanity check ---------------------------------------

Length = len(packet)

MAXLEN = 0x642

if Length > MAXLEN:

raise ValueError, "len(payload) must be in [0, %d]" % (MAXLEN,)

#_____________________________________________________________________

#------Time, Data and Padding Calculation-----------------------------

print"Length packet in bit = ", len(packet) *8

print"N_padding bit= ", N_pad + 6

print"N_dbps= ",N_dbps

print"N_data = ",N_data

print"N_sym = ",N_sym

print"N_sym * N_dbps= ",N_sym * N_cbps

#____________________________________________________________________


#----------- Rate decision (4 bits)-----------------------------------

if (regime == "1"):

Rate = 0x0d


Rate = 0x0f


Rate = 0x05


Rate = 0x07


Rate = 0x09


Rate = 0x0b


Rate = 0x01


Rate = 0x03

else:

print "Unknown regime\n"

sys.exit(1)

#___________________________________________________________

#------------ Length must be LSB first ---------------------

app = 0

for i in range (0,12):

app = app | (((Length >> i) & 1) << (11 - i))

Length = app

#___________________________________________________________

#------------ Parity check ---------------------------------

parA = parB = 0

for k in range (0,12):

parA += ((Length >> k) & (0x01))

parB += ((Rate >> k) & (0x01))

P = (parA + parB) % 2

#___________________________________________________________

#-------------- Tail and padding ---------------------------

if ((N_pad + 6) % 8 == 0):


app = ’’

for i in range (0, (N_pad + 6)/8):

app += chr(0x00)

TAIL_and_PAD = app

else:

app = ’’

for i in range (0, (N_pad + 6)/8):

app += chr(0x00)

# we add one more byte because N_pad + 6 tail is not a

# multiple of 8. Then we delete the exeded bits in the conv encoder

TAIL_and_PAD = app + chr(0x00)

print"TAil and padd= ",len(TAIL_and_PAD)*8

#___________________________________________________________

Signal_tail = 0x0

Signal_field = 0x000

#-- Buidl signal field----------------------------------------------

"""

In order to have exactly 24 bit (i.e. 3 byte) we divide singal fied in 3 chr

"""

Signal_field = (Rate << 20) | (Length << 7) | Signal_tail | (P << 6)

chr1 = chr((Signal_field >> 16) & 0xff)

chr2 = chr((Signal_field >> 8) & 0xff)

chr3 = chr(Signal_field & 0xff)

SIGNAL_FIELD = chr1 + chr2 + chr3

#____________________________________________________________________

SERVICE = chr(0x00) + chr(0x00)

PLCP_HEADER = SIGNAL_FIELD + SERVICE

packet_for_crc = mac_framectrl +mac_duration + mac_address1 + mac_address2 + \

mac_address3 + mac_seqctrl + payload

# This packet is used for crc32 calculation

MPDU = make_MPDU (packet_for_crc)

MPDU_with_crc32 = gen_and_append_crc32(MPDU , packet_for_crc)

# N.B. The crc calculation has been done on payload


# but it is appended on the MPDU

Length = len(MPDU_with_crc32)

return PLCP_HEADER + MPDU_with_crc32 + TAIL_and_PAD , Length

def make_MPDU(payload):

app = conv_packed_binary_string_to_1_0_string(payload)

app=list(app)

mpdu = [’0’] * len(app)

j = 0

while (j < len(app)):

for i in range (0, 8):

mpdu[i+j] = app[7-i+j] # Change into transmit order

j += 8

mpdu = "".join(mpdu)

return conv_1_0_string_to_packed_binary_string(mpdu)


List of Abbreviations


ADC Analogue-to-Digital ConversionAGC Automatic Gain ControlAM Amplitude ModulationASIC Application Specific Integrated CircuitBE radio Back-EndCRC Cyclic Redundancy CheckCSMA/CD Carrier Sense Multiple Access network with Collision DetectionCVIS Cooperative Vehicle Infrastructure SystemsDAC Digital-to-Analogue ConversionDCF Distributed Coordination FunctionDIFS Distributed Inter Frame SpaceDSRC Dedicated Short Range CommunicationsDSSS Direct Sequence Spread SpectrumFDM Frequency Division MultiplexingFE radio Front-EndFER Frame Error RatioFPGA Field Programmable Gate ArraysGPP General Purpose ProcessorsHBF Half Band FilterICI Inter Carrier InterferenceIF Intermediate FrequencyITS Intelligent Transportation SystemsLNA Low Noise AmplifierMAC Medium Access ControlMPDU MAC Protocol Data UnitNAV Network Allocation VectorOFDM Ortogonal Frequency Division MultiplexingOSI Open System InterconnectionPCF Point Coordination FunctionPLCP Physical Layer Convergence Procedure



PCS Physical Carrier SensingPMD Physical Medium DependentPPDU PLCP Protocol Data UnitRTS Request To SendSDR Software-Defined RadioSIFS Short Inter Frame SpaceSSID Service Set IDentifierUSRP Universal Software Radio PeripheralUSRP Universal Software Radio PeripheralV2I Vehicle-to-InfrastructureV2V Vehicle-to-VehicleVII Vehicle Infrastructure IntegrationVCS Virtual Carrier SensingWAVE Wireless Access in a Vehicular EnvironmentWLAN Wireles Local Area Network


LIST OF FIGURES

List of Figures

2.1 The IEEE 802 family ............................................................... 7

2.2 The IEEE 802.11 physical and data link layers .............................. 7

2.3 DS PLCP frame format ............................................................ 8

2.4 Basic Access Scheme ................................................................ 10

2.5 Typical RTS/CTS sequence in a frame transmission ....................... 11

2.6 Typical 802.11 MAC frame format .............................................. 11

2.7 Traditional view of receiving signals in FDM................................. 14

2.8 OFDM Subcarriers spectrum ..................................................... 14

2.9 Guard time in OFDM transmission ............................................. 15

3.1 Ideal Software Defined Radio blocks diagram ................................ 18

3.2 Real Software Defined Radio blocks diagram................................. 19

3.3 Simplified scheme of the USRP2................................................. 20

3.4 USRP FPGA DDC ................................................................. 21

3.5 Typical graph representation ..................................................... 24

3.6 GnuRadio framework structure .................................................. 26

4.1 IEEE 802.11p chain implemented in MATLAB.............................. 32

4.2 OFDM blocks implemented natively in GnuRadio core.................... 33

4.3 IEEE 802.11p chain implemented in GnuRadio.............................. 35


LIST OF FIGURES

4.4 PLCP frame format and MPDU................................................. 36

4.5 Convolutional encoder K = 7 block operation................................ 37

4.6 Pilots insertion block operation .................................................. 39

4.7 Carriers permutation block operation .......................................... 40

4.8 Cyclic prefix block operation ..................................................... 41

4.9 Example of complete 16-QAM frame generated in GnuRadio, payload100 bytes ............................................................................... 42

4.10 Typical path followed from floating point number to E.M. wave ........ 42

4.11 Floating point to 16 bits Signed Integer linear transformation........... 43

5.1 Radio testbed: Case a) USRP2 transmitter and USRP2 SpectrumAnalyzer. Case b) USRP2 and Ralink 802.11a receiver. Case c)USRP2 transmitter and CVIS 802.11p prototype. .......................... 45

5.2 Transmitting spectrum and standard “Class A” and “Class B” maskscomparison ............................................................................ 45

5.3 Transmitting spectrum and standard “Class C” and “Class D” maskscomparison ............................................................................ 46

5.4 FER for QPSK and 64-QAM modulation for different frame length ... 47

5.5 FER vs received-SNR for BPSK 10 and 1500 bytes MSDU and for64-QAM 10and 1500 bytes MSDU .............................................. 47


BIBLIOGRAPHY

Bibliography

[1] IEEE. Draft amendment to wireless LAN medium access control (MAC) andphysical layer (PHY) specifications: Wireless access in vehicular environments.Technical report, IEEE P802.11ptm/D2.01, 2007.

[2] Gnuradio - The GNU Software Radio. http://www.gnuradio.org.

[3] P. Fuxjaeger, A. Costantini, D. Valerio, P. Castiglione, G. Zacheo, T. Zemen, F.Ricciato. To appear on 6th KarlsruheWorkshop on Software Radios. In IEEE802.11p Transmission Using GNURadio, Karlsruhe, Germany, March 2010.

[4] J. Mitola. The Software Radio. In IEEE National Telesystems Conference,Singapore, 1992.

[5] Eric Blossom. Gnu radio: Tools for exploring the radio frequency spectrum.Linux Journal, 2004, http://www.linuxjournal.com/article/7319.

[6] Ettus Research LLC. http://www.ettus.com.

[7] Gnuradio - The GNU Software Radio. http://gnuradio.org/trac/wiki/USRP2Schem.

[8] Andreas Mueller. DAB software receiver implementation. Technical report,Swiss Federal Institute of Technology Zurich, June 2008.

[9] GnuRadio Doxygen Documentation. http://gnuradio.org/doc/doxygen/inherits.html.

[10] Simplified Wrapper and Interface Generator. http://www.swig.org/.

[11] Dawei Shen. Tutorial 5: Getting Prepared for Python in GNU Radio by Readingthe FM Receiver Code Line by Line. , 2005.

[12] Eric Blossom - How to Write a GnuRadio Python Application Block.http://gnuradio.org/trac/wiki/Tutorials/WritePythonApplications.

[13] Eric Blossom - How to Write a Signal Processing Block.http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html.

[14] Gregory W Heckler. Exploring GPS with Software Defined Radio.http://www.gps-sdr.com.


BIBLIOGRAPHY

[15] Eric Blossom. Chaos Communication Congress. In I see Airplanes! How tobuild your own radar system, Berlin, December 2005.

[16] V. Pellegrini, G. Bacci, M. Luise. 5th KarlsruheWorkshop on Software Radios.In Soft-DVB, a Fully Software, GNURadio Based ETSI DVB-T Modulator,Karlsruhe, Germany, March 2008.

[17] WISER S.r.l Wireless System Engineering Research. Grides:. GSM-R SignalIntegrity Detection System, Livorno, Italy.

[18] BBN technology - Acert Savane Server. http://acert.ir.bbn.com/.

[19] GNUradio mailing list. http://lists.gnu.org/archive/html/discussgnuradio/.

[20] Hamed Firooz, Implementation of Full-Bandwidth 802.11b Receiver.http://span.ece.utah.edu/pmwiki/pmwiki.php?n=Main.80211bReceiver.

[21] Thomas Schmid, Tad Dreier, Mani B Srivastava. Software Radio Implementa-tion of Short-range Wireless Standards for Sensor Networking. SenSys 2006,2006.

[22] Networked and Embedded Systems Laboratory, UCLA, Zigbee sourcecode.http://acert.ir.bbn.com/projects/gr-ucla/.

[23] Stefan Knauth. Implementation of an IEEE 802.15.4 Transceiver with aSoftware-defined Radio setup. Technical report, Lucerne University of AppliedSciences.

[24] Dominic Spill. Implementation of the Bluetooth stack for software definedradio, with a view to sniffing and injecting packets. Technical report, UniversityCollege London, May 2007.

[25] Andrea Bittau Dominic Spill. Bluesniff, Evemeets Alice and Bluetooth. Ma,The first USENIX workshop on Offensive Technologies, August Boston 2007.

[26] GNU-Radio mailing list. Thread 802.11 and Bluetooth.http://lists.gnu.org/archive/html/discuss-gnuradio/2006-12/msg00089.html.

[27] Part11: Wireless LAN Medium Access Control (MAC) and PhysicalLayer (PHY) specifications. High-speed Physical Layer in the 5GHz Band.http://standards.ieee.org/getieee802/.

[28] CYCLIC REDUNDANCY CHECK. http://www.hackersdelight.org/crc.pdf.


802 11p_ivc

Documents