Simulinkmatlab 802..11P

UNIVERSITA SALENTO
DEL
Implementation of an IEEE 802.11p transmitter in open-source Software Dened Radio
Relatore: Fabio RICCIATO Laureando: Andrea COSTANTINI
A.A. 2008/2009
Acknowledgements
This thesis would have not been possible without the kind support, the trenchant critiques, the probing questions, and the remarkable patience of my thesis advisor FABIO RICCIATO. He gave me the great opportunity to study in the beautifoul city of Vienna in ftw. Here I have known fantastic people who will remain forever in my heart. I am grateful to Danilo Valerio for being so good to me. I shared with him most of my problems. He was beside me in every step of my work and he helped me to overcome 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 side by side with the signal processing guys. I would like to thank particularly PAOLO CASTIGLIONE and PAUL FUXJAEGER, who taught me the secrets of OFDM transmission and excellent working methods! Last but not least I would like to thank GIAMMARCO ZACHEO and ALESSANDRO DALCONZO, because they are just fantastic people and it was a pleasure to work and talk with them. Thanks everybody!
Universit` del Salento a
Ringraziamenti
Eccoci qua! Arrivati alla ne di questo lungo percorso di studio che sta per terminare con il conseguimento della laurea specialistica. Dopo tanti anni passati a studiare e sperare in un futuro migliore nalmente il primo traguardo della mia vita sta per essere raggiunto. Arrivato a questo punto sono, ovviamente, dobbligo i miei pi sentiti ringraziamenti a tutti coloro che mi sono stati vicini in questi anni. Vorrei cominciare (e non potrei fare altrimenti) ringraziando i miei cari GENITORI ai quali devo tutto quello che sono riuscito a fare di buono nella mia vita. Loro sono stati per me degli ottimi maestri di vita (e credo che continueranno ad esserlo per molti anni ancora). Mi hanno insegnato quali sono i veri valori della vita, mi hanno insegnato che bisogna sempre battersi per i principi nei quali crediamo e a non mollare mai di fronte alle dicolt e ai problemi che la vita ci mette davanti ogni giorno. Senza il conforto, laiuto, e il sostegno morale di loro due io credo che dicilmente sarei riuscito a raggiungere questo traguardo. Grazie PAPA, grazie MAMMA. 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 in questi anni di studio. Infatti con le loro litigate furibonde, i loro rumori molesti, e i loro inverosimili racconti, sono riusciti a movimentare ed alleviare le mie grigie e noiose giornate di studio. Grazie MARIA e grazie GIU. Un ringraziamento speciale va sicuramente a DANIELA, una ragazza veramente speciale che riuscita a conquistarmi con la sua gentilezza e il suo amore. La ringrazio di cuore per aver sopportato per tutti questi anni le mie lamentele e le mie scontentezze. La ringrazio anche per tutti gli utili consigli che mi ha dato durante il mio percorso di studi e per avermi sostenuto nei momenti pi dicili. Grazie DANI. Ringrazio tanto anche tutti gli ZII. Alcuni vicini e altri lontani, ma sempre tutti attenti e interessati al mio percorso di studi. Loro mi hanno sempre sostenuto e aiutato in ogni momento della vita. Grazie zio PIERO, zia ANNA, VECCHIA, zia TIZIANA 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 denire) i quali nel corso di questi ultimi anni sono diventati la mia seconda famiglia. Anche loro mi sono stati 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 delluniversit con i quali ho trascorso tanti anni anco a
II
anco a studiare, a fare esami e a progettare il nostro futuro. Insieme a loro ho superato tante dicolt che da solo non sarei mai e poi mai riuscito a superare. Grazie PIERO ANDRIULO, ALFONSO CARROZZO, ANDREA DONNO, DAVIDE SARACINO, GIUSEPPE COCCIOLO, PATRIZIO PRIMICERI, ANNACHIAVA SPAGNOLO, RINO, LINO, MARCELLO . e tutti coloro che ora non sto qui a scrivere perch sono veramente tanti. Come dicono gli inglesi, last but not least e cio ultimi ma non per questo meno importanti vorrei ringraziare tutti gli AMICI di una VITA (in particolare cucinu LUCIO amico fedele e sincero come nessun altro). Con loro ho condiviso tutte le pi belle esperienze della mia vita. Il loro sorriso e la loro amicizia vera sono stati fondamentali sia durante tutto il corso della mia vita universitaria sia nella vita quotidiana. Grazie CUCINU, EMANUELE, IVAN. GRAZIE A TUTTI!! Martano 2 gennaio 2010
III
A me e alla mia famiglia
IV
Abstract
Abstract
This work aims at providing a tool for the empirical assessment of the IEEE 802.11p performance. The main contribution is the implementation of a fully functional software-dened radio (SDR) 802.11p transmitter. We present the rapid-prototyping methodology that was used to implement an 802.11p frame-encoder within the opensource GNU Software Radio (GnuRadio) platform as well as a detailed overview of the technologies involved. Finally, we show some preliminary results that indicate the compliance of our transmitter with the physical layer requirements of the 802.11p standard. The developed code will be released under the GPL license on the comprehensive gnu radio archive network (CGRAN). We hope that the deployment of an SDR 802.11p transmitter will help the research community to overcome the limitations and inaccuracies of the simulation environments, paving the way towards the deployment of a complete 802.11p testbed for real-world performance assessment.
CONTENTS
Contents
1 Introduction 2 IEEE 802.11 basics 2.1 2.2 2.3 Overview ............................................................................... Physical layer ......................................................................... Medium Access ....................................................................... 2.3.1 2.3.2 2.4 2.5 Basic Access Scheme ...................................................... 4 6 6 7 9 9
Virtual Carrier Sensing ................................................... 10
Frame Format ........................................................................ 11 IEEE 802.11p ......................................................................... 13 2.5.1 2.5.2 The basic OFDM concepts............................................... 13 Comparison between 802.11a and 802.11p ........................... 15 17
3 Software Dened Radio 3.1 3.2
Introduction ........................................................................... 17 Universal Software Radio Peripheral............................................ 19 3.2.1 3.2.2 3.2.3 3.2.4 Motherboard ................................................................ 19 FPGA ......................................................................... 20 ADC-DAC ................................................................... 22 Daughter boards............................................................ 23
1
CONTENTS
3.3
GnuRadio .............................................................................. 23 3.3.1 3.3.2 3.3.3 3.3.4 Architecture ................................................................. 25 Brief Flow Graph Overview ............................................. 26 Signal processing blocks .................................................. 27 Existing implementations ................................................ 28 31
4 IEEE 802.11p Implementation 4.1 4.2 4.3 4.4
Methodology adopted............................................................... 31 USRP2 testing/debugging ......................................................... 33 GnuRadio OFDM and 802.11p: State of the Art ............................ 33 802.11p: From Data link layer to Physical layer ............................. 34 4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.4.6 4.4.7 4.4.8 4.4.9 MAC and PLCP header .................................................. 34 CRC-32 ....................................................................... 35 Scrambler..................................................................... 36 Convolutional encoder .................................................... 36 Interleaver .................................................................... 37 Symbols mapping .......................................................... 38 Pilots insertion .............................................................. 39 Carrier permutation ....................................................... 40 IFFT, cyclic prex and scaling ......................................... 40
4.4.10 Training sequence .......................................................... 41 4.4.11 From oating point numbers to E.M. waves ........................ 41 5 Testing and validation 5.1 5.2 44
Testbed Description ................................................................. 44 Results.................................................................................. 45
CONTENTS
5.2.1 5.2.2 5.2.3
Spectral shape .............................................................. 45 IEEE 802.11a transmission .............................................. 46 IEEE 802.11p transmission .............................................. 47 48 49 59 69 78 81 81
6 Conclusions A MATLAB Code B C++ code C Python code List of Abbreviations List of Figures References
CHAPTER 1. INTRODUCTION
Chapter 1 Introduction
In the last few years inter-vehicle communication has gained considerable interest in the research community. Vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication will play an important role in future automotive and trac management technologies. The nal goal is to improve passenger safety and reduce 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 new working group aimed at dening 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 amendment to the IEEE 802.11 standard to add wireless access in vehicular environments. It denes enhancements to IEEE 802.11 required to support Intelligent Transportation Systems (ITS) applications. This includes data exchange between high-speed vehicles and between the vehicles and the roadside infrastructure in the licensed ITS band of 5.9 GHz (in the US). The IEEE 802.11p is still in development and is part of the so-called Wireless Access for Vehicular Environment (WAVE) standard, which denes an architecture and a complementary standardized set of services and interfaces. Due to a lack of hardware implementations, most of the recent scientic works on V2V and V2I are based on simulations. However, the inaccuracy introduced by simplistic channel and mobility models makes simulation tools unreliable for the evaluation of wireless standards in high-mobility scenarios. In this thesis we developed a standard-compliant IEEE 802.11p transmitter by using an open-source Software Dened Radio (SDR) platform, i.e. GnuRadio [2]. The advantages of using a SDR solution instead of a full-hardware implementation is given by its exibility and its higher customizability.
The work presented in this thesis is part of a joint experimental activity carried out by the networking and signal processing groups at the Telecommunications Research Center Vienna (FTW) - a Competence Center for Excellent Technologies supported by the Austrian Government and the City of Vienna. In particular, the study has been supported by the FTW strategic projects N0 and I0. Part of the work was conducted in team. A workshop publication derived from the present work [3] will be presented at the 6th Karlsruhe workshop on Software Radios. This thesis contains six chapters and is organized as follows: Chapter 2 presents an overview of the IEEE 802.11 family of standards and explores the extensions of the 802.11p amendment. Chapter 3 presents the platform that has been used for implementing the transmitter. Both hardware and software parts are described in details, highlighting advantages and limitations of using SDR for testing wireless standards. Chapter 4 describes in details our GnuRadio 802.11p physical and data link layer implementation. Chapter 5 presents experimental results of our transmitter, validating its compliance 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). It denes design requirements for the MAC and PHY layer of WLAN transceivers. The original IEEE 802.11 specication was published on 1997 and provides a common MAC layer specication on top of three dierent PHY layers. In the following years, in order to improve performance and security for dierent applications, the IEEE published several amendments (e.g. 802.11a, 802.11g, 802.11n, etc) supporting other physical layers. The legacy IEEE 802.11 supported rates up to 2Mbps by using Frequency Hopping Spread Spectrum (FHSS), Direct Sequence Spread Spectrum (DSSS) and Infrared (IR). The IEEE 802.11a and IEEE 802.11g amendments added support for Orthogonal Frequency Division Multiplexing (OFDM) for bit rates up to 54Mbps. Picture 2.1 shows an overview of the 802.11 family in the context of the Open System Interconnection model (OSI). The 802.11 supports two dierent networking frameworks called respectively adhoc and infrastructure mode. In Ad-hoc mode, the wireless devices can directly communicate with each other in a peer-to-peer fashion without involving any central node (access point). In infrastructure mode, all the nodes communicate with a wireless access point. The latter can be cabled to the wired network in order to allow 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 dierent transmission techniques, the PHY layer is split into two generic components: the Physical Layer Convergence Protocol (PLCP), which denes 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 Medium Dependent (PMD) system, whose function denes the method of transmitting and receiving data through the wireless medium.
LLC sublayer
Datalink layer
MAC sublayer
PHY_SAP
PLCP sublayer
PMD_SAP
Physical layer
PMD 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 the MAC layer. The structure of the PLCP header is showed in gure 2.3. It contains the following elds:
2.2. PHYSICAL LAYER
Figure 2.3: DS PLCP frame format PLCP Preamble: It allows the synchronization between the transmitter and receiver stations. The modulation format is DBPSK and the rate is 1 Mbps. It is composed of a Sync eld and a Start Frame Delimiter eld: Sync: it carries 128 ones bits. Start Frame Delimiter: set to 0000 0101 1100 1111, it is utilized by the receiver to recover the start of the frame. Header: the PLCP header is placed after the preamble and contains some parameters of the physical transmission. It contains the following four elds: Signal: it delivers the information about the rate that shall be used by the 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 is least signicant bit rst (LSBF). CRC: it consists of 16 bits that are used to reveal with high reliability an incorrect header detection. The receiver veries the CRC before further frame processing. The dierent 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 contention free services. Special stations called Point Coordinators are used to ensure that the medium 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 station is transmitting. Particularly, DCF is based on carrier sense multiple access with collision avoidance (CSMA/CA). Two carrier sensing mechanisms are dened in the standard: Physical Carrier Sensing (PCS) and Virtual Carrier Sensing (VCS). PCS is mandatory while VCS is optional (it can be switched o by the users) and has been developed to mitigate the well-known hidden node problem. The channel is marked busy if either PCS or VCS 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 the status 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 Inter Frame Space (DIFS), the transmission of the frame can be initiated. The MAC indicates to the PLCP some of the parameters to include in the PLCP header and some physical setting (e.g. Antenna, Power Level, etc.). The PLCP then forwards the physical parameters to the PMD layer through dedicated PMD primitives, generates the PLCP header and issues a request to the PMD to start the transmission. The PHY entity immediately initiates data scrambling and transmission of the PLCP preamble followed by the transmission of the data. If PLCP indicates that the medium is busy, the station enters into a Contention Window and the transmission is deferred until the end of the ongoing transmission. A random interval, referred to as the back-o interval, is then selected and is used to initialize the back-o timer. Every time the medium is detected to be idle the back-o timer decreases. When the back-o timer reaches zero, the station initiates the transmission. To reduce the probability of collisions, after each unsuccessful transmission attempt the expected value of the random back-o interval is increased exponentially until a predetermined maximum is reached (exponential random backo). Immediate positive acknowledgments are employed to determine the successful reception of each data frame. The receiver checks the Cyclic Redundancy Check and after a time interval, called Short Inter Frame Space (SIFS), sends an acknowledgment 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 by the transmitter. This access method is often referred to as Basic Access and it is depicted in Figure 2.4.
SIFS DIFS Contention Window Source Contention Window Destination DIFS ACK DATA Frame
Figure 2.4: Basic Access Scheme
2.3.2
Virtual Carrier Sensing
The virtual carrier-sensing mechanism is achieved by distributing reservation information announcing the impending use of the medium. The exchange of RequestTo-Send (RTS) and Clear-To-Send (CTS) frames prior to the actual data frame is one means of distribution of this medium reservation information. When a node has a frame to send, it initiates the process by sending an RTS frame. This basically silences any stations that hear it. If the target station receives an RTS, it responds with a CTS. Like the RTS frame, the CTS frame silences stations in its transmission range. Once the RTS/CTS exchange is complete, the sending node can transmit its frames without worry of interference. The RTS and CTS frames contain a Duration/ID eld that denes the period of time that the medium is to be reserved to transmit the actual data frame and the returning ACK frame. At the end of the RTS/CTS exchange all stations within the reception range of either the originating node (which transmits the RTS) or the destination node (which transmits the CTS) save the information of the medium reservation by updating the so-called Network Allocation Vector (NAV) according to the Duration eld of the RTS/CTS frame. The NAV indicates the amount of time that elapses until the current transmission session is complete. Figure 2.5 depicts a frame transmission between two nodes using the RTS/CTS procedure. The RTS/CTS transmission procedure consumes a fair amount of capacity, especially because of the additional latency incurred before transmission can commence. As a result, it is used only in high-density environments and environments with signicant contention on transmission.
10
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 eld, which contains eleven subelds: Protocol: It is composed by two bits indicating which version of 802.11 MAC is 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 the distribution system. All frames in the infrastructure will have one of the distribution systems bits.
11
2.4. FRAME FORMAT
More fragment: This eld is set to 1 when the receiver has to expect another fragment of the frame. All non-fragmented frames have this eld set to 0. Retry: When a frame is retransmitted, this eld is set to 1 in order to aid the receiving station to delete the possible duplicate frame. Power Management: This eld is set to 1 when the transmitter is in powersaving mode, otherwise is set to 0. This power-save mode is only allowed at the nodes and it is forbidden for the access point, which perform a lot of important management operations. More data: To accommodate stations in power-saving mode, the access points may buer frames received from the distribution system. An access point sets this bit to indicate that at least one frame is available. WEP: Wired Equivalent Privacy is a encryption routine for wireless protection. When a frame has been processed by WEP, this eld is set to 1. Order: The frame and the fragments cam be sent in order (so-called strict ordering) and when this happens he order bit is set to 1. Duration/ID It is two bytes long and it has two dierent roles, depending on the type of frame being transmitted. In a situation of power-saving message this eld transports the transmitting 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 nd up to four eld called Address. Their use depend on the setting of the ToDS and FromDS in the frame control eld. In general the Address1 contains information address used for the receiver, Address2 contains information address about the transmitter, the Address3 contains information dependent on the FromDS setting, and the Address4 is utilized only when a wired distribution system is used. Sequence control It is a 16 bits eld used for defragmentation and for discarding duplicate frames if a retransmission occurs. The rst four bits indicate the fragmentation number and the other 12 bits indicate the sequence numbers.
12
2.5. IEEE 802.11P
Frame body It is the eld that carries the higher layer payload. It can transport maximum 2304 bytes. Actually the implementation can support payload up to 2312 bytes in order to arrange the WEP overhead. Frame Check Sequence This eld is often also called Cyclic Redundancy Check (CRC). It allows the station to check potential errors in the received frame. In particular the transmitting station calculates the FCS before transmitting its frame and put it into the header. Then at the receiver side the station calculates again the FCS of the frame. A dierence in the two FCSs indicates that the frame was corrupted during the transmission.
2.5
IEEE 802.11p
According to the ocial IEEE 802.11 Work Plan, the nal 802.11p amendment will be published in November 2010. The 802.11p specication denes: the functions and services of the WAVE-compliant stations; the WAVE signaling technique and the interface between the physical and MAC 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 discrete multi-tone modulation, is the modulation technique adopted in 802.11p. In order to highlight the basic concepts and the advantages of this technique we should recall the basic Frequency Division Multiplexing (FDM). In traditional FDM systems, see gure 2.7, the signal is modulated independently per each sub-band through a time-domain multiplication with the sub-carrier signal (the cosine and the sine with frequency at the center of the corresponding sub-band). At the receiver, a lters bank allows for the mitigation of the inter-carrier interference (ICI). By increasing the guard interval between the sub-bands, the complexity of the lters is reduced, at the cost of a decrease in spectral eciency.
13
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 (see Figure 2.8). This statement is actually true only if the channel has a negligible Doppler spread compared to the bandwidth of each sub-band. This condition is normally fullled in real-world scenarios. The main steps of the OFDM modulation
Figure 2.8: OFDM Subcarriers spectrum are the following: rst, the code symbols are mapped onto the discrete frequency domain (each symbol is associated to a sub-carrier); second, the discrete inverse Fourier transform (IFT) of the mapped symbols is performed; third, the whole ensemble (OFDM symbol) is over-sampled and modulated by the the carrier signal. At the receiver, the demodulated signal is transformed back to the discrete frequency domain. The equivalent base-band channel in the frequency domain is memoryless (diagonal), provided that the channel has been cyclically convoluted with the OFDM
14
2.5. IEEE 802.11P
symbol in the time domain. In order to articially induce a cyclic convolution between the OFDM symbol and the channel, the cyclic prex, containing the tail of the OFDM symbol, is added before each OFDM symbol. If the cyclic prex is longer then the channel delay spread, each OFDM symbol experiences only its own interference in the discrete time domain, which emulates a cyclic convolution between the signal and the the channel. Hence, the equalization of the channel at the receiver side results easier in the frequency domain. The orthogonality of the sub-bands is again paid by a decrease in spectral eciency due to the cyclic prex insertion (that acts practically as a guard time interval as depicted in Figure 2.9). However, compared to a traditional FDM system, the trade-o between complexity and eciency is greatly improved.
Figure 2.9: Guard time in OFDM transmission Another advantageous characteristic of OFDM is that the payload is spread across a high number of carriers. In fact the spectral notches (deep fade) caused by the multipath propagation aect only a small number of sparsely distributed sub-carriers. Traditional forward error correcting (FEC) codes, like convolutional codes are able to exploit this frequency diversity and to correctly reconstruct the transmitted information.
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, in order to underline the dierences between the two standards. In the current draft version of the standard, the frame encoding procedure for IEEE 802.11p diers from 11a only in two key aspects: the operating frequency band is shifted to around 5.9GHz and the duration of OFDM symbols is doubled from 4s
15
2.5. IEEE 802.11P
Parameter Sample rate Chip duration Number of t points Number of sub carriers Number of data sub carriers Number of pilot sub carriers OFDM symbol period Cyclic prex FFT Symbol period Modulation scheme Coding scheme Puncturing Available data rate
1 2
802.11 a 20 MHz 50 ns 64 52 + DC 52 4 TSymbols = 80 chips = 4 s 16 chips = 0.8 s 64 chips = 3.2 s BPSK-QPSK-16QAM-64QAM industry convolutional
3 4
802.11 p 10 MHz 100 ns 64 52 + DC 52 4 8 s 1.6 s 6.4 s BPSK-QPSK-16QAM-64QAM

1 2 3 4
optional puncturing
or
2 3
or
2 3
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 relative dierence to 8s. The rationale behind these modications is the following: rst, using a dedicated part of the spectrum reduces interference with legacy systems, second, doubling the symbol-time also means doubling the cyclic-prex-duration - a modication that helps to decrease the OFDM inter-symbol-interference (ISI) when operated in outdoor channels. The detailed guide about the dierence between 802.11a and 11p is available in [1].
16
CHAPTER 3. SOFTWARE DEFINED RADIO
Chapter 3 Software Dened Radio

3.1 Introduction
The term Software Dened Radio was coined in 1991 by Joseph Mitola, who published the rst paper on the topic in 1992 [4]. The basic idea behind the term Software Dened Radio is of a radio communication system where components that have typically been implemented in hardware (e.g. lters, modulator, ampliers, detectors. etc.) are instead implemented using some software on a personal computer or other embedded devices. So, more in general, we dene an SDR as a radio platform that uses software techniques on digitized radio signals. Therefore, at a certain stage in the receiving chain the signal should be digitized and passed to the software domain. By using SDR, engineers try to move the software domain as close as possible to the antenna in order to guarantee a higher exibility. In addition to that, 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 point of view, we can divide a SDR system into two subsystems: the hardware-dened subsystem and the software-dened subsystem. The separation between hardware and software subsystems is not xed. The decision of what should be implemented in software and what in hardware depends on the performance requirements of each particular implementation. Ideally, an SDR could consist of an antenna, an ADC, and a software-dened subsystem as depicted in gure 3.1. Realizing such a device would require that each of the three following conditions are met: The antenna should be capable to operate at the frequency of all radio signals of interest The ADC and the DAC should have a sampling rate greater than two times
17
3.1. INTRODUCTION
Antenna
ADC
Receive signal path Antenna
Software Subsystem
DAC
Transmit signal path
Software Subsystem
Figure 3.1: Ideal Software Dened Radio blocks diagram the frequency of the signals of interest and for this reason a very high sampling rate to support wide signal bandwidths The software subsystem should have enough processing power to handle the signal processing of all radio signals of interest In practice ADCs and DACs are not fast enough to process a large portion of the spectrum and antennas are designed for specic frequency bands. As a result, ideal SDR are realized only for particularly simple technologies (e.g. AM radio). In a typical SDR the hardware-dened subsystem consists of a wide-band Radio FE that takes a portion of spectrum and shifts it to the IF prior to digitization (see gure 3.2). The software-dened subsystem receives the digital wide-band signal, sends it to a set of digital down converters to isolate the required carrier, and proceeds with the demodulation. Further ltering is also done in the software domain. The designing goal of SDR remains to make the FE as general as possible and act on the software subsystem for the implementation of new functionalities. The software-dened subsystem can also be composed by a combination of programmable devices, provided that the connection between them is fast enough to transfer DSP data. There are several SDR solutions available on the market. In this thesis we opted for an open-source SDR platform that combines GnuRadio (as software-dened subsystem) and the Universal Software Radio Peripheral (as hardware-dened subsystem).
18
3.2. UNIVERSAL SOFTWARE RADIO PERIPHERAL
Hardware based subsystem Antenna
Software based subsystem
Radio Front End

Receive signal path Antenna
ADC
Programmable device(s) (e.g. FPGA, GPP)
Radio Front End
DAC
Management Software
Transmit signal path
Figure 3.2: Real Software Dened Radio blocks diagram
3.2
Universal Software Radio Peripheral
The Universal Software Radio Peripheral (USRP) was designed within the GnuRadio project [2] and is currently produced by Ettus Research [6]. As a consequence, it perfectly ts with the GnuRadio framework. In this thesis we used the USRP version 2 (in the following simply referred to as USRP2). This version overcomes the limitations of the USRP1 in terms of bandwidth and processing power. The USRP2 contains a motherboard with four plugs (for the Radio Front Ends) and a Gigabit Ethernet controller (for the connection to the host PC). The USRP hardware design is 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
19
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 simplied scheme of the USRP2 is depicted in gure 3.3.
Figure 3.3: Simplied 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 general purpose computer. All these components work with a 100MHz master clock. Now let 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 bandwidth in order to obtain a sustainable ow trough the Gigabit Ethernet, e.g. signal proUniversit` del Salento a
20
cessing, interpolation, decimation, ltering, etc. Two other important operations made inside the FPGA are the Digital Down Conversion (DDC) and the Digital Up Conversion (DUC). Digital Down Converter Figure 3.4 depicts the Digital Down Conversion performed in the FPGA. The complex 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.
Sampling rate Fs
4 Stage CIC Filter

From ADC
31 Tap HBF
Cos( i)
4 Stage CIC Filter Sin( i)
31 Tap HBF
NCO
Decimators (division by N)
Base band 16-bit I/Q data with bandwidth Fs/N
Figure 3.4: USRP FPGA DDC After that, the signal goes through a 4 stage Cascaded Integrator-Comb (CIC) lters for a decimation by a factor N. In this way, the data rate can be adapted to ow in the Gigabit Ethernet and for a subsequent software computing in the host computer. The decimator can be treated as a low pass lter followed by a down sampler. If we suppose a decimation factor of N, the low pass lter remove the band out the range [-Fs/N, Fs/N], and then the down sampler de-spread the spectrum from [-Fs, Fs] to [-Fs/N, Fs/N]. In the end, in order to obtain the best spectral shaping possible and to reject the out of band signals there is a 31 taps Half Band Filter (HBF). Regarding the bandwidth, we can sustain 1 Gb/s = 128MB/s across the GigaEthernet. All samples sent over the GigaEthernet interface are in 16-bit signed integers in IQ format, i.e. 16-bit I and 16-bit Q data (complex) which means 4 bytes per complex sample. This means that we can send 128MBps / 4Byte
21
= 32Mega complex samples per sec across the GigaEthernet. Recalling that ADCs sampling rate is 100Msample per second, then we can immediately nd the minimum decimation factor as 100Msamples per second / 32M samples per second = 3.123 better 4. Since complex processing was used, this provides a maximum eective total spectral bandwidth of 32MHz by Nyquist criteria. Of course we can select much narrower ranges by increasing the decimation factor. In any case the decimation factor must be in the range [4, 512]. The standard FPGA conguration implements 2 complete digital down converters (DDC). Also there is an image with 4 DDCs but without half-band lters, so this allows 1, 2 or 4 separate RX channels. Note that when there are multiple channels (up to 4), the channels are interleaved. For example, with 4 channels, the sequence sent over the Ethernet would be I0 Q0 I1 Q1 I2 Q2 I3 Q3 I0 Q0 I1 Q1, ...etc. In multiple RX channels (1,2, or 4) , all input channels 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 we send 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 nally send it through the DAC. The only transmit signal processing blocks in the FPGA are the CIC interpolators. These CIC are an optimized class of nite impulse response lters combined with interpolators or decimators. The CIC outputs can be routed to any of the 4 CODEC inputs. In multiple TX channels (1 or 2) all output channels must be the same data rate (i.e. same interpolation ratio). Note that we could have dierent Tx and RX rate.
3.2.3
ADC-DAC
The DAC chip used in the USRP2 motherboard is the AD9777 16-bit. The maximum input data rate is 160 M samples per second (no interpolation) while the maximum DAC update rate is 400 M samples per second (8x interpolation). This chip presents a selectable interpolation rate (2x/4x/8x) and a complex modulator that can mix at Fs/2, Fs/4 or Fs/8. All conguration are accomplished through a 3 or 4-wire SPI interface. The ADC chip used in the USRP2 motherboard is the LTC2284. This is a 14-bit 105 Msps (but used in the USRP2 at 100Msamples per second), low power dual 3V A/D converter designed for digitizing high frequency, wide dynamic range signals.
22
3.3. GNURADIO
3.2.4
Daughter boards
A daughter board represents the core of the analog process. Usually it encompasses a RF lter to discard the out band components, a LNA (Low Noise Amplier), a mixer to move the signal from the RF frequency to IF Frequency, an IF lter, and an IF amplier. The structure is pretty similar to a typical Etherodyne receiver. The daughter board together with the motherboard let us use the USRP2 as a complete RF transceiver system. Several daughter boards are available in [6]. Usually, a single daughter board can be either a receiver or a transmitter. Recently, a few transceiver daughter boards have been released. We have chosen the XCVR-2450 daughter board, which is a transceiver board operating at 2.4-2.5 GHz and 4.9-5.9 GHz. Therefore, it is suitable for the IEEE 802.11 family of standards. The main features 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 softwaredened radios. The GnuRadio project was founded by Eric Blossom. The goal of GnuRadio is to bring the code as close to the antenna as possible, and therefore turn hardware problems into software problems [5]. It supports natively Linux, and packages are precompiled for the major Linux distributions. A port to Windows has been also developed, but it provides limited functionalities. Initially, it was mainly used by radio amateur enthusiasts, but it gained increase interest from the research world, in an attempt to stay away from closed source rmwares/drivers, and low level of customizability of commercial chips.
23
3.3. GNURADIO
In GnuRadio, a transceiver is represented by a graph, where the vertices are signal processing blocks and the edges represent the data ow between them. In other words, the design of a radio transceiver with GnuRadio is similar to what is done in the hardware design, where physical RF components are connected to each other to create a hardware radio. Figure 3.5 depicts a simple example of a gnuradio ow graph. Any graph must have at least a signal source block (in the example the Signal Generator and the Noise generator) and a signal sink block (in the example the USRP2 Sink). Additionally, the ow graph usually contains intermediate signal processing blocks (in the example the Adder block).
Figure 3.5: Typical graph representation The GnuRadio package provides several building blocks for signal and information processing, as well as the framework to control the data ow between them. An incomplete list of the functions provided by GnuRadio is divided in the following functional blocks [8]: Mathematical operations (log, add, multiply, .. . ) Interleaving, delay blocks, . . . FFT blocks Interpolation and decimation Filters (FIR, Innite Impulse Response (IIR), . . . )
24
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 various signal 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 le) Graphical sinks (Oscilloscope, FFT, Waterfall, . . . ) User Datagram Protocol (UDP) source and sink Unfortunately, it is very hard to nd documentation about the blocks provided by GnuRadio. In order to understand the hundreds of implemented blocks, the only practicable way is to look at the source code and the documents generated by doxygen [9].
3.3.1
Architecture
Figure 3.6 depicts the general GnuRadio framework structure. Python is used to create high level graphs. The signal processing blocks that are included in the graphs are programmed in C++. SWIG 1 is then used to interface the two programming languages (e.g. making C++ functions available to python). Information about SWIG can be found in [10]. This approach allows to combine the eciency of C++ coding with the simplicity of Python. With reference to gure 3.5, the blocks (vertices), such as the signal generator, the noise generator, the adder, and the USRP sink are written in C++ and they represent the body of the graph. The edge i.e. the connection between the blocks are
1
SWIG is an acronym for Simplied Wrapper and Interface Generator 25
3.3. GNURADIO
Figure 3.6: GnuRadio framework structure written in Python and represent an high level view of the graph. In other words all the signal processing operations, the critical operations and the real time operations are written in a lower level language (C++), while the logical interconnections between them are written in a higher level language (Python).
3.3.2
Brief Flow Graph Overview
Creating a GnuRadio ow graph in Python does not require full knowledge of the C++ code in each block. The concept is similar to the OSI reference model. Signal processing blocks use the services oered by the hardware, and provide services to the python code through the SWIG interface. In GnuRadio each block is characterized by attributes that indicate the number of input and output ports, and the type of data that it can process. Clearly, a source block has only outgoing ports, a sink block has only incoming ports, and a processing block can have multiple incoming and outgoing ports. Signal processing blocks can be either synchronous or asynchronous. As far as regards the data format, the blocks process usually complex oats, but other data formats are also possible (oat, short, and chars). From the python point of view, GnuRadio provides a data ow 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
26
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 is that all parameters and logical connections must be consistent. This abstraction is implemented in the top block class. Let us suppose that we want to use the USRP2 as receiver. In this case we want that the signals received and processed (digitized) by the USRP2 ow through the Gigabit Ethernet towards the host computer and are further processed by GnuRadio. In this case, the USRP2 is the signal source of our ow graph. Vice versa in a situation where the USRP2 acts as transmitter, the signal is rst generated and processed by the GnuRadio ow graph, and nally ow to the USRP2 sink. To create an application, we should derive our own class either from the class top 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 the application requires a GUI or not). This can only be done in Python. Support for pure C++ applications, which may sometimes be preferable (e.g. for embedded systems), is under development. Once our blocks have been instantiated, they can be connected with the connect method of the main class in Python (i.e. the class which is derived from top block that represents the ow graph). This is the analog of drawing edges in the graph as in gure 3.5. To get a runnable graph, all ports of each block must be connected. Then signal processing can be started with the start method of the ow 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 manages the blocks and the ow of samples between them, assisted by some important methods that are dened in the c++ code of the blocks. The forecast() method can be used by the programmer to tell the scheduler how many input samples a block requires to produce a given number of output samples. The general work and work methods are used for the actual signal processing steps. These functions are called by the scheduler and are given a certain number of input samples (which is not xed, but can be modied by the programmer). After processing the samples, they write the output into the memory and return the number of processed input samples and produced output samples. GnuRadio also takes care of buering the data. While signal processing blocks usually process samples as fast as they come in (or as fast as the CPU allows), some signal sources and sinks require a constant sample rate (e.g. the audio sink). In this case, it is the programmers responsibility to make sure, that data is processed
27
3.3. GNURADIO
fast enough. If a source delivers more samples than the application can process, then some buer will eventually overow, and samples are lost (this is called an overrun). If the sample rate at the input of a sink is too low on the other hand, the buer 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 between the USRP2 and the PC) is too slow, or if data streams with dierent xed sample rates are connected without appropriate interpolation or decimation. Obviously, it is crucial 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 for reproducing simple applications, such as real-time capture and display of analog TV stations, transmission and reception of FM signals, transmission of dial tones to the sound card, etc. However, several groups around the world implemented new modules, reproducing a variety of widely used technologies. Unfortunately, to the best of our knowledge there is no on line listing directory that groups all the available implementations. Extensive research is required in order to identify what has been already implemented and with which limitations. We list here some of the existing GnuRadio implementations, that use either the USRP or the USRP2 board. A complete GPS receiver has been implemented in [14]. It uses the DBSRX daughter-board for receiving GPS signals, and contains interfaces to the Google Earth 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 been presented in [16], which is capable of receiving (and playing) DVB-T signals. Wiser SRL [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 the wireless technology implemented in this thesis, we elaborate more on them in the following subsections. IEEE 802.11 There have been several attempts to reproduce the IEEE 802.11 standard with GnuRadio. All these implementations are designed for use with USRP1. The latter uses a USB connection instead of the Gigabit Ethernet, therefore it is exposed to the USB 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 bits samples (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
28
3.3. GNURADIO
avoid this bottleneck. A rst well-known implementation has been developed within the 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 being passed 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 a successful reception of IEEE 802.11 data at 1Mbps (DBPSK). More information can be gathered by looking at the available source code. Hamed Firooz [20] proposed another implementation. In its architecture, despreading operation is performed in the FPGA prior to the USB, rather than in the host CPU. In this way, the data to be transfered through the USB connection is considerably 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 signal before 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, the IEEE 802.11 demodulator and Physical Layer Convergence Protocol (PLCP) from the ADROIT project is used for decoding the frame. Details on the implementation and 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 designed for sensor networks. It is meant to work in dierent frequency bands, although the 2.4 GHz ISM band is the most widely used. The latter is divided in 16 channels spaced 5 MHz apart from each other. The radios use direct-sequence spread spectrum 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 GHz band. One bit at the source is encoded in 4 source symbols, which are in turn coded into 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 nally a channel symbol rate of 1Msymbols/s. A complete implementation of the IEEE 802.15.4 PHY/MAC layer has been presented in [21]. The code is open and freely available at [22]. However the authors measured Round Trip Times (RTT) three to six times larger than conventional radio chips. They found that this is due to the impossibility of the current implementation to reach a RX-TX turnaround time of 12 symbol periods (192 s) as mandated by the standard. Another implementation has been presented in [23]. The source code however is not publicly available.
29
3.3. GNURADIO
Bluetooth At a glance it could seem that the low power and data rate characteristics of Bluetooth make it easy to be implemented in the USRP/GnuRadio. A more accurate analysis reveals that this is not always true. Bluetooth communications use frequencies from 2402 MHz to 2480 MHz. One bluetooth channel is 1 MHz wide resulting in a total of 79 channels. The data is modulated using Gaussian Frequency Shift Keying (GFSK) with a symbol rate of 1 MSamples/s. GFSK is not explicitly implemented 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 the symbol rate does not pose any problem in the USRP. However Bluetooth uses a technique known as Frequency Hopping Spread Spectrum (FH-SS). A communication does not take place on a single channel (as in IEEE 802.11) but hops between dierent channels. In bluetooth the channel changes every 625 s, and the hopping sequence is calculated from the clock and the MAC address of the master device (exchanged during the pairing procedure). Therefore, tuning the USRP on one channel would allow us to retrieve only sporadic packets from a communication. For a USRP to decode an entire bluetooth communication one needs to monitor the entire bluetooth 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 a tune command is issued. This means that roughly the rst third of a transmission slot will be missed as the radio tunes to the frequency. Some tests on a bluetooth implementation has been performed by Dominic Spill [24], who proposes the use of 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 next channel). In [25] the problem is avoided by forcing the communication to a single channel. The most explicative words on the issue are probably given in [26], a thread on the GnuRadio mailing list.
30
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 prototype is an attractive basis for conducting empirical measurements for assessing the link performance of the IEEE 802.11p standard. Implementing a wireless technology with 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 within the GnuRadio package Creating the ow graph and tuning the blocks Several limitations can arise during the implementation due to impossibility of the software 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 IEEE 802.11p GnuRadio implementation from scratch. We created most of the signal processing blocks and reused some of the existing ones from the GnuRadio package. In the following, we describe the methodology adopted and the implementation details for each block.
4.1
Methodology adopted
Due to the complexity of working with the GnuRadio framework, we decided to rst implement the standard compliant IEEE 802.11p transmitter using MATLAB.
31
4.1. METHODOLOGY ADOPTED
In fact MATLAB programming language is easy-to-use and versatile. We used the detailed instructions of the encoding scheme given in the IEEE 802.11a standard document to create a reference-encoder in MATLAB. The corresponding chain is depicted in Figure 4.1. Taking this intermediate step using MATLAB shortens the initial debugging phase and speeds up the development of the baseband encoder. Note that the standard (see [27] annex G) also includes the baseband representation of one reference frame which enabled us to verify that the MATLAB code is indeed correct. The MATLAB script provides all the regimes supported by the standard. In the second phase of development we implemented the elements of the encoding chain in GnuRadio in a stepwise fashion. The rationale behind this approach is that any single block could be tested and debugged by comparing the behavior of the corresponding MATLAB block. In this phase, it is crucial to understand that the GnuRadio framework distinguishes between stream-based operation and block-based operation. Adopting the purely block-based approach of our original MATLAB code was not an option since it would have resulted in highly sub-optimum GnuRadio code in terms of latency of the encoding process. This is easy to understand when considering long frames (consisting of several hundred OFDM symbols). The third phase was dedicated to a nal 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. 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 correctly received by a conventional 802.11g chip set. Ultimately, we were able to verify the compliance with
32
4.2. USRP2 TESTING/DEBUGGING
11p by conducting measurements using an early 802.11p industry-prototype as a receiver that is being used in the CVIS project. Details on the validation results will be given in Chapter 5.
4.2
USRP2 testing/debugging
The very rst step is to verify that the USRP2 is able to transmit without distortions the signals generated with MATLAB. Part of this work is a mere quality-check of the hardware in use that could eventually generate unexpected non-linear eects. During this rst 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 imaginary parts of the samples. Note that the chip set that we have used for the preliminary debugging/tests was a 802.11a standard compliant. By simply doubling the interpolation factor and changing the carrier frequency in the USRP2, the physical layer switches from 802.11a to 802.11p standard. The correct reception at the chip set of MATLAB-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. Now we want to focus our attention to the state of the art in GnuRadio in the context of OFDM standards. Currently, in the GnuRadio repository, there is already a code capable of generating OFDM symbols. Figure 4.2 shows the available GnuRadio OFDM chain.
Figure 4.2: OFDM blocks implemented natively in GnuRadio core As we can see, the frame generation consists only of a symbol mapping, it, cyclic prex insertion and training sequence insertion. Now we analyze these blocks with
33
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 payload bits (SIGNAL+DATA) into symbols according to one of the available modulations (BPSK, QPSK, 16QAM or 64QAM). Note that this GnuRadio block cannot change dynamically the modulation format, despite the fact that the DATA OFDM symbols exhibit likely a dierent modulation format with respect to the SIGNAL OFDM symbol. IFFT: it performs the it operation. Cyclic Prex: it executes the cyclic prex 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 and insert it in front of each OFDM symbols. Note, in a real system case, the training sequence should be inserted only once before the rst OFDM symbol of the frame. As just described, the sequence chain showed in Figure 4.2 is a very simple OFDM generator. It performs few fundamental operations and is far from being 802.11p-a-g standard compliant.
4.4
802.11p: From Data link layer to Physical layer
The full IEEE 802.11p GnuRadio chain is showed in gure 4.3. We decided to implement some of the blocks in Python, instead of C++, due to their low processingpower requirements. More in particular, we used Python for all the blocks that perform bit-operations (e.g. bit-shifts, bit-masks, etc.). The rest of the chain, from symbols mapping to the last block before the transmission, has been done entirely in c++, due to tight real-time constraints. In the following subsections we describe the GnuRadio implementation of each block. For more details about the physical implementation and standard description, please refer to [1].
4.4.1
MAC and PLCP header
The rst step in the transmitter chain is the encapsulation of the payload into the MAC and PLCP headers (see Chapter 2 for details). In gure 4.4 the format of the
34
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 sake of completeness. At this higher level, the frame assemblage has been performed by using the Python programming language. The implementation details of this block are conned in appendix C. More details about each single eld depicted in Figure 4.4 can be found in [27]. Note that, at this stage, tail and padding bits insertion is not a trivial task. The problem encountered is that the number of zeros to add is generally a fraction of byte. Since we can handle only bytes, we adopted the following strategy: if the sum of tail bits and padding bits is a multiple of 8, the smallest number of zero bits is additionally inserted in order to achieve an integer number of bytes. Only during the encoding process these bits are nally removed.
4.4.2
CRC-32
The CRC-32 calculation has been conducted according to the algorithm in [28]. The code available in the GnuRadio repository did not produce a standard compliant CRC. Our standard compliant version of the CRC-32 code has been written in C++ (see appendix B).
35
Figure 4.4: PLCP frame format and MPDU
4.4.3
Scrambler
The scrambling is performed in Python. The DATA eld, composed of SERVICE, PSDU, tail and padding bits is XORed with the scrambler sequence, contained in the Python script. The SIGNAL eld is instead not scrambled. The implementation is in appendix C.
4.4.4
Convolutional encoder
The convolutional encoder was developed in Python as well. It uses the industry standard polynomial generator g0 = 1338 and g1 = 1718 with rate R = 1/2. In gure 4.5 the convolutional code generator is depicted. Note that the output B follows the 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, for each modulation, are obtained by means of the puncturing operation. As shown in Appendix 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].
36
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 single OFDM block, containing a number NCBP S of bits that is modulation-dependent. The rst one ensures that adjacent bits are mapped onto nonadjacent sub carriers. The second one ensures that adjacent coded bits are mapped alternately onto less and more signicant bits of the constellation. In this way, bursts of low-reliable bits are avoided. Denote k = 0,1,........NCBP S - 1 the position index of the input coded bits, i the position index after the rst permutation and j the position index after the second permutation. The rst permutation works as follows: i = (NCBP S /16) (k mod 16) + oor(k/16). The function oor denotes the largest integer not exceeding the argument. The second permutation is dened by the rule: j = s oor(i/s) + (i + NCBP S oor(16 i/NCBP S )) mod s. The value of s is determined by the number of coded bits per sub carriers NBP SC s = max(NBP SC /2, 1). The implementation details are available in Appendix C.
37
4.4.6
Symbols mapping
The symbols mapping block rst divides the bits stream coming from the interleaver into groups of NCBP S bits. In the standard 802.11p: NCBP S = 48 for BPSK modulation for rate 6 or 9 Mbit/s NCBP S = 96 for QPSK modulation for rate 12 or 18 Mbit/s NCBP S = 192 for 16-QAM modulation for rate 24 or 36 Mbit/s NCBP S = 288 for 64-QAM modulation for rate 48 or 54 Mbit/s For each group, the corresponding bits are mapped into constellation symbols of NBP SC bits: NBP SC = 1 for BPSK modulation NBP SC = 2 for QPSK modulation NBP SC = 4 for 16-QAM modulation NBP SC = 6 for 64-QAM modulation The symbols are complex numbers representing BPSK, QPSK, 16-QAM or 64-QAM constellation points. The symbols mapping available in the GnuRadio core repository does not comply with the standard for two dierent reasons. First, the constellation mapping performed by the existent block is not the one required by the standard. This problem has been isolated and solved by updating the existing Python code with the standard compliant symbol mapping. Second, the GnuRadio existing block uses a xed symbol constellation for all OFDM symbols. In the standard, instead, the rst OFDM symbol is always BPSK modulated. In fact, the rst symbol (not considering the PLCP preamble, that it is conveniently inserted as very nal step of the encoding process according to our own design) corresponds to the SIGNAL eld, which has to be always transmitted at the most conservative rate (6 Mbit/s). The related C++ code is shown in Appendix B. In order to recognize the rst symbol, our solution has been to set a counter of the streaming coded bits. In this way, we take the rst 48 bits which correspond to the rst OFDM symbol and map them onto BPSK symbols. The remaining frame is modulated according to the selected regime.
38
4.4.7
Pilots insertion
For this block, the input item is 48 complex samples coming from the symbols mapping processing block. Each input item is associated with one OFDM symbol. This block rst associates to each complex sample a sub carrier position in the OFDM symbol. In particular, the standard assigns the 48 samples to the following sub carriers: 1 to 6, 8 to 20, 22 to 26, -26 to -22, -20 to -8 and -6 to -1. The remaining sub-carriers 7, 21, -21 and -7 are reserved to the pilot symbols. Figure 4.6 claries 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 coherent detection. They are BPSK modulated by a pseudo-random binary sequence to prevent the generation of spectral lines. The polarity of the sub carriers is controlled by a sequence of 126 elements. For more details please refer to [27]. The implementation of the pilots insertion block has been more challenging then for other blocks like the carrier permutation. In fact, blocks like carrier permutation, it, cyclic prex addition do the same operation all the stream long. For instance the it block takes 64 samples in input and it always process these samples in the same way. In the pilots insertion instead the pilot polarity is not xed. As described above, it changes 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 counter is used with a local scope in the general work method and the other outer counter
39
is used with a global scope. The second counter is never reset during the frame transmission once it has been initialized. In this way, the outer counter combined with inner counter always keeps track of the current OFDM symbol position in the frame. 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 them and performs a zero-padding. Note that at this point of the chain the input ensemble exhibits 53 samples instead of 52 because a zero in the DC carrier position has been already added in the previous block. Figure 4.7 shows how this block works. The code,available in Appendix B, has been written in C++.
4.4.9
IFFT, cyclic prex and scaling
We have already discussed about these three blocks in the section 4.2. In the 802.11p standard, the number of points in the it is 64, while the cyclic prex is 16 bits long. At the output of the cyclic prex block we obtain 80 samples. The gure 4.8 depicts the mentioned operations. The scaling block is necessary to fulll the energy per symbol constraints.
40
Figure 4.8: Cyclic prex block operation
4.4.10
Training sequence
The training sequence in the 802.11p standard, named PLCP preamble, allows for the synchronization between transmitter and receiver at the OFDM symbol level and the channel equalization. It is split into two dierent segments (the short and the long preambles): the rst one is the repetition of 10 short signals and has the duration of an OFDM symbol; the second one exhibits double duration and consists of two equal OFDM symbols. More precisely, the short preamble is used for signal detection, Automatic Gain Control (AGC), diversity selection, coarse frequency oset estimation and ne timing synchronization. The long sequence,instead, is used for channel estimation and ne frequency oset estimation. The preamble is xed and is added only once at the beginning of the frame. We take advantage from this situation by creating a static table in Python. This C++ block adds nally the values given from the static table at the beginning of the frame. Note that the values stored in the Python script are the result of an o line processing through the overall transmission chain of the values dened in the standard. Figure 4.9 shows an example of a 16-QAM modulated frame, generated with GnuRadio.
4.4.11
From oating point numbers to E.M. waves
We have already discussed about the Software Radio philosophy and the required hardware components. Here, we present how the stream of oating point numbers becomes an electromagnetic wave through the air, as depicted in Figure 4.10. The GnuRadio software deals with oating point numbers representing the baseband samples of signal to be transmitted. However, the Gigabit Ethernet requires
41
Figure 4.9: Example of complete 16-QAM frame generated in GnuRadio, payload 100 bytes
Figure 4.10: Typical path followed from oating point number to E.M. wave those sample to be represented as xed point numbers. More precisely, the digital format is 16 bit I/Q Signed Integer. This conversion is crucial and must be taken carefully into account. In fact, the wrong input to this conversion can generate distortion at the transmitter side. Figure 4.11 shows this operation. As depicted, the conversion from the oating point number to the 16 bit I/Q signed integer is linear for input values in the range (-1,+1). Elsewhere, the output saturates to -1 and 1 respectively for negative and positive input values. Therefore it is very important to make sure that all samples (i.e. all oating point numbers) are in the range (-1,+1). A scaling block, that normalizes the numbers accordingly, is inserted before the transmission through the Gigabit Ethernet. Once converted the
42
Figure 4.11: Floating point to 16 bits Signed Integer linear transformation stream of 16 bit I/Q Signed Integer numbers ows to the DSP motherboard. The digital signal is interpolated and transformed into the analog base-band signal.
43
CHAPTER 5. TESTING AND VALIDATION
Chapter 5 Testing and validation

This chapter presents the results of a preliminary measurement campaign that involves the deployed transmitter and a number of other devices. The main aim of this experiments is the assessment of the standard compliance of our gnuradio-based 802.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 duo E8400 cpu, 4 GB of RAM, and an integrated Intel Gigabit Ethernet interface. The operating system environment was GNU/Linux (Ubuntu 8.10), with Python 2.5.2 and the GnuRadio stable release 3.2.2. The Intel Gigabit Ethernet was connected to a USRP2 equipped with the daughter board XCVR2450 and an antenna with 5dBi 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 spectrum analyzer; b) A Ralink PCI card installed into a general purpose PC, used as 802.11a/g receiver. c) An experimental IEEE802.11p prototype deployed in the Cooperative Vehicle Infrastructure Systems (CVIS) project.
44
5.2. RESULTS
Figure 5.1: Radio testbed: Case a) USRP2 transmitter and USRP2 Spectrum Analyzer. Case b) USRP2 and Ralink 802.11a receiver. Case c) USRP2 transmitter and CVIS 802.11p prototype.
5.2
5.2.1
Results
Spectral shape
The IEEE 802.11p standard includes four dierent spectrum masks labeled Class A, Class B, Class C, and Class D. The details about these classes are available in [1]. We used an additional USRP2 for analyzing the spectrum of the signal generated by our transmitter. Figure 5.2 shows that our transmitter is compliant
Figure 5.2: Transmitting spectrum and standard Class A and Class B masks comparison
45
5.2. RESULTS
with the Class A and Class B spectrum masks. However, as it is shown in Figure 5.3, the signal spectrum presents two spurious peaks that exceed the limits imposed by the Class C and Class D masks. We are currently investigating whether the two peaks are caused by a distortion of the receiver ampliers or can be mitigated by improving the transmitter source code.
Figure 5.3: Transmitting spectrum and standard Class C and Class D masks comparison
5.2.2
IEEE 802.11a transmission
In the current draft version of the standard, the frame encoding procedure for IEEE 802.11p diers from 11a and 11g only in two key aspects: the operating frequency band is shifted to around 5.9GHz and the duration of OFDM symbols is doubled from 4 us to 8 us. Using symbol-time settings in accordance with 11a and a carrierfrequency in the 2.4GHz ISM band we were able to generate frames that were correctly received by a conventional 802.11g chip set. This was achieved by setting an interpolation rate of 5 instead of 10. Figure 5.4 depicts the Frame Error Ratio (FER) for dierent frame lengths. The distance between transmitter and receiver was kept constant to 3 meters yielding to a received power always greater than -80dBm. Clearly, the increased error probability of larger frames leads to higher FER.
46
5.2. RESULTS
Figure 5.4: FER for QPSK and 64-QAM modulation for dierent frame length
5.2.3
IEEE 802.11p transmission
In a nal test we checked the standard compliance of the transmitter by using the IEEE 802.11p prototype from CVIS. Figure 5.5 shows the frame-error-ratio performance over received-SNR for four dierent combinations of frame lengths and OFDM symbol-constellations. The channel setup (LOS, indoor) was kept constant and transmission-power-control at the USRP2 was used to realize specic average received-SNR values. Each measurement-point corresponds to 104 frames sent with a rate of 200 frames/second. As we can see the BPSK modulation is the more robust
1 0.9 0.8 FrameErrorRatio 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 5 BPSK, R=0.75 10 Bytes MSDU 11 OFDM Symbols BPSK, R=0.75 1500 Bytes MSDU 342 OFDM symbols 64QAM, R=0.75 10 Bytes MSDU 3 OFDM symbols 64QAM, R=0.75 1500 Bytes MSDU 58 OFDM symbols 0 5 10 SNR [dB] 15 20
Figure 5.5: FER vs received-SNR for BPSK 10 and 1500 bytes MSDU and for 64-QAM 10and 1500 bytes MSDU (i.e. FER near to zero) already with a very low Signal to Noise Ratio (less then 10 dB), while the 64-QAM needs more then 22 dB in order to have the same FER values.
47
CHAPTER 6. CONCLUSIONS
Chapter 6 Conclusions
In this thesis we designed an IEEE 802.11p transmitter in open-source Software Dened Radio. We focused on the physical layer implementation and we showed by means of dierent measurements that our gnuradio-based transmitter is able to reproduce 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 has started analyzing 802.11p link-layer performance by using simulation tools. However, we believe that only real-world experiments can reliably evaluate the robustness of the standard in high-mobility scenarios. In this thesis we demonstrated that the high customizability of the GnuRadio platform makes it an attractive basis for investigating the real-world performance of upcoming draft protocols. Note that the proposed transmitter implements only the physical layer functionalities, i.e. it does not provide any MAC layer functions (except encapsulation into frames). We are aware that the tight latency requirements of the carrier sensing scheme cannot be easily met by a full software radio transceiver on a general purpose pc. However we believe that moving some functionalities from the PC onto the USRP2 FPGA will lead to a much faster operational reactivity. Regarding potential future works, the rst natural next step is the implementation of the receiver chain in MATLAB. This, together with the implementation of basic CSMA/CA functions, will place a milestone for the deployment of a fully interactive GnuRadio Tx/Rx solution for IEEE 802.11a/g/p.
48
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 = mac_duration = mac_address1 = mac_address2 = mac_address3 = mac_seqctrl = mac_crc =
0800; 0000; 006008cd37a6; 0020d6013cf1; 006008ad3baf; 0000; 00000000;
% % % % % % %
this is a data frame is calculated further down destination mac-address source mac-address BSSID mac-address 0 sequence and 0 fragment number is calculated further down
% Optional fun stuff: disassociate STA from AP using this MPDU % Set mac PDU:
49
% % % % % % % %
mac_framectrl mac_duration mac_address1 mac_address2 mac_address3 mac_seqctrl mac_crc mac_body
= = = = = = = =
9000; 0000; 0023127efe52; 0018f8d2a29f; 0018f8d2a29f; 0000; 00000000; 0100;
% % % % % % %
MGMT disassociation frame is calculated further down valid DST mac-address of STA valid SRC mac-address of AP valid BSSID mac-address of AP 0 sequence and 0 fragment number is calculated further dow
% Moluation/coding p.Regime = switch p.Regime case 1 p.Modulation = p.CodeRate = p.RateBits = case 2 p.Modulation = p.CodeRate = p.RateBits = case 3 p.Modulation = p.CodeRate = p.RateBits = case 4 p.Modulation = p.CodeRate = p.RateBits = case 5 p.Modulation = p.CodeRate = p.RateBits = case 6 p.Modulation = p.CodeRate = p.RateBits = case 7 p.Modulation = p.CodeRate = p.RateBits = case 8 p.Modulation = p.CodeRate =
parameters regime; % One of 8 possible regimes % Regime-dependant parameters % 3 Mbits/s *****MANDATORY***** BPSK; % BPSK modulation 1/2; % Coding rate 1/2 (unpunctured) [1 1 0 1];% RATE bits in the SIGNAL field % 4.5 Mbits/s BPSK; % BPSK modulation 3/4; % Coding rate 3/4 (punctured) [1 1 1 1];% RATE bits in the SIGNAL field % 6 Mbits/s *****MANDATORY***** QPSK; % QPSK modulation 1/2; % Coding rate 1/2 (unpunctured) [0 1 0 1];% RATE bits in the SIGNAL field % 9 Mbits/s QPSK; % QPSK modulation 3/4; % Coding rate 3/4 (punctured) [0 1 1 1];% RATE bits in the SIGNAL field % 12 Mbits/s *****MANDATORY***** 16QAM; % 16-QAM modulation 1/2; % Coding rate 1/2 (unpunctured) [1 0 0 1];% RATE bits in the SIGNAL field % 18 Mbits/s 16QAM; % 16-QAM modulation 3/4; % Coding rate 3/4 (punctured) [1 0 1 1];% RATE bits in the SIGNAL field % 24 Mbits/s 64QAM; % 64-QAM modulation 2/3; % Coding rate 2/3 (punctured) [0 0 0 1];% RATE bits in the SIGNAL field % 27 Mbits/s 64QAM; % 64-QAM modulation 3/4; % Coding rate 3/4 (punctured)
50
p.RateBits = [0 0 1 1];% RATE bits in the SIGNAL field 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
51
% 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);
52
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
53
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]; %--- OFDM modulation (IFFT) ---------------------------------------X=zeros(p.nPointsFFT,1); % Empty input to the IFFT % Map subcarriers accordingly 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 x=sqrt(p.nPointsFFT)*ifft(X,p.nPointsFFT); % IFFT % 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); p.pilot3=zeros(1,plen); p.pilot4=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
54
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.pilot2(1,(c-1)*l+1:end)=... % Fill the end of the pilot vector... p.Pseq(1:plen-(c-1)*l); p.pilot3(1,(c-1)*l+1:end)=... % Fill the end of the pilot vector... p.Pseq(1:plen-(c-1)*l); p.pilot4(1,(c-1)*l+1:end)=... % Fill the end of the pilot vector... -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;
55
% 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 end % For loop (bits) % 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
56
end % For loop (bits) 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 frame(35:47,1:end)=d(31:43,:); % Subcarriers 8 to 20 frame(49:53,1:end)=d(44:48,:); % Subcarriers 22 to 26 %--- 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 %--- OFDM modulation (IFFT) ---------------------------------------Universit` del Salento a
57
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]; % Map subcarriers accordingly 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 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;
58
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 static static static
const const const const
int int int int
MIN_IN = 1; // mininum number of input streams MAX_IN = 1; // maximum number of input streams MIN_OUT = 1; // minimum number of output streams 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))),
59
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 )]; }
60
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) { }
61
ftw_pilot_cc::~ftw_pilot_cc () { } int i=0, offset=0; int ftw_pilot_cc::general_work (int gr_vector_int gr_vector_const_void_star gr_vector_void_star { const gr_complex *in = (const gr_complex *out = (gr_complex
noutput_items, &ninput_items, &input_items, &output_items) gr_complex *) input_items[0]; *) 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)];
62
} // Pilot 2 (-7) out[19 + ((count)*(d_tones + 5))] =
polarity[(count+offset)%127];
for(i = 20 ; i <= 25 ; i++){ // Subcarriers (-6 ---> -1) out[i + ((count)*(d_tones + 5))] = in[i-2 + ((count) * d_tones)]; } out[26 + ((count)*(d_tones + 5))] = 0; // DC for(i = 27 ; i <= 32 ; i++){ // Subcarriers (+1 ---> +6) out[i + ((count)*(d_tones + 5))] = in[i-3 + ((count) * d_tones)]; } // Pilot 3 (+7) out[33 + ((count)*(d_tones + 5))] = polarity[(count+offset)%127]; for(i = 34 ; i <= 46 ; i++){ // Subcarriers (+8 ---> +20) out[i + ((count)*(d_tones + 5))] = in[i-4 + ((count) * d_tones)]; } // Pilot 4 (+21) out[47 + ((count)*(d_tones + 5))] = -(polarity[(count+offset)%127]); for(i = 48 ; i <= 52; i++){ // Subcarriers (+22 ---> +26) out[i + ((count)*(d_tones + 5))] = in[i-5 + ((count) * d_tones)]; } 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; } //////////////////////////
63
SYMBOLS MAPPING ////////////////////////// Here we report only the work method int ftw_ofdm_mapper::work(int noutput_items, gr_vector_const_void_star &input_items, gr_vector_void_star &output_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; // Were 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;
64
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();
65
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 cant 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;
66
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
67
///////////////////////////////// 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; }
68
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):
69
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)
70
//////////////////////////////////////// CONVOLUTIONAL ENCODER /////////////////////////////////////// def conv_encoder(pkt, Length, regime): info = get_info(pkt, regime) N_cbps = info["N_cbps"] N_bpsc = info["N_bpsc"] 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 = outB = encoded[2 * encoded[2 * modA % modB % i] = i + 1] 2 # Modulo 2 sum 2 str(outA) = str(outB)
71
# 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) return conv_1_0_string_to_packed_binary_string(encoded) 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) return conv_1_0_string_to_packed_binary_string(encoded) else: print"The inserted regime is unknown\n" sys.exit(1)
72
/////////////////////////////////// SCRAMBLER /////////////////////////////////// def scrambler(pkt, Length_data): scrambling_seq = \ [0, 1, 1, 0, 1, 1, 0, 0, 0, 0, 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, 1, 0, 0, 1, 0, 1, 0, 0, 0, 1, 1,\ 0, 1, 1, 1, 0, 0, 0, 1, 1, 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, 0, 0, 1, 0, 1, 1, 1, 0, 1];
1, 0, 0, 1, 1, 0, 1, 0, 1,\ 0, 1, 0, 1, 1, 1, 1, 1, 0,\ 1, 1, 0, 0, 0, 0, 1, 1, 1, \ 1, 0, 0, 0, 1, 0, 0, 1, 1, 0,\
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 mustnt 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) +\
73
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_cbps = info["N_cbps"] N_bpsc = info["N_bpsc"] 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 #____________________________________________________________________
74
#----------- Rate decision (4 bits)----------------------------------if (regime == "1"): Rate = 0x0d elif (regime == "2"): Rate = 0x0f elif (regime == "3"): Rate = 0x05 elif (regime == "4"): Rate = 0x07 elif (regime == "5"): Rate = 0x09 elif (regime == "6"): Rate = 0x0b elif (regime == "7"): Rate = 0x01 elif (regime == "8"): 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):

75
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_address3 + mac_seqctrl + payload # This packet is used for crc32 calculation MPDU = make_MPDU (packet_for_crc)
mac_address1 + mac_address2 + \
MPDU_with_crc32 = gen_and_append_crc32(MPDU , packet_for_crc) # N.B. The crc calculation has been done on payload
76
# 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)
77
List of Abbreviations
ADC AGC AM ASIC BE CRC CSMA/CD CVIS DAC DCF DIFS DSRC DSSS FDM FE FER FPGA GPP HBF ICI IF ITS LNA MAC MPDU NAV OFDM OSI PCF PLCP Analogue-to-Digital Conversion Automatic Gain Control Amplitude Modulation Application Specic Integrated Circuit radio Back-End Cyclic Redundancy Check Carrier Sense Multiple Access network with Collision Detection Cooperative Vehicle Infrastructure Systems Digital-to-Analogue Conversion Distributed Coordination Function Distributed Inter Frame Space Dedicated Short Range Communications Direct Sequence Spread Spectrum Frequency Division Multiplexing radio Front-End Frame Error Ratio Field Programmable Gate Arrays General Purpose Processors Half Band Filter Inter Carrier Interference Intermediate Frequency Intelligent Transportation Systems Low Noise Amplier Medium Access Control MAC Protocol Data Unit Network Allocation Vector Ortogonal Frequency Division Multiplexing Open System Interconnection Point Coordination Function Physical Layer Convergence Procedure
78
PCS PMD PPDU RTS SDR SIFS SSID USRP USRP V2I V2V VII VCS WAVE WLAN
Physical Carrier Sensing Physical Medium Dependent PLCP Protocol Data Unit Request To Send Software-Dened Radio Short Inter Frame Space Service Set IDentier Universal Software Radio Peripheral Universal Software Radio Peripheral Vehicle-to-Infrastructure Vehicle-to-Vehicle Vehicle Infrastructure Integration Virtual Carrier Sensing Wireless Access in a Vehicular Environment Wireles Local Area Network
79
LIST OF FIGURES
List of Figures
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 The IEEE 802 family ............................................................... The IEEE 802.11 physical and data link layers .............................. DS PLCP frame format ............................................................ 7 7 8
Basic Access Scheme ................................................................ 10 Typical RTS/CTS sequence in a frame transmission ....................... 11 Typical 802.11 MAC frame format .............................................. 11 Traditional view of receiving signals in FDM................................. 14 OFDM Subcarriers spectrum ..................................................... 14 Guard time in OFDM transmission ............................................. 15 Ideal Software Dened Radio blocks diagram ................................ 18 Real Software Dened Radio blocks diagram ................................. 19 Simplied scheme of the USRP2 ................................................. 20 USRP FPGA DDC ................................................................. 21 Typical graph representation ..................................................... 24 GnuRadio framework structure .................................................. 26 IEEE 802.11p chain implemented in MATLAB .............................. 32 OFDM blocks implemented natively in GnuRadio core.................... 33 IEEE 802.11p chain implemented in GnuRadio.............................. 35
80
LIST OF FIGURES
4.4 4.5 4.6 4.7 4.8 4.9
PLCP frame format and MPDU ................................................. 36 Convolutional encoder K = 7 block operation................................ 37 Pilots insertion block operation .................................................. 39 Carriers permutation block operation .......................................... 40 Cyclic prex block operation ..................................................... 41 Example of complete 16-QAM frame generated in GnuRadio, payload 100 bytes ............................................................................... 42
4.10 Typical path followed from oating 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 Spectrum Analyzer. Case b) USRP2 and Ralink 802.11a receiver. Case c) USRP2 transmitter and CVIS 802.11p prototype. .......................... 45 Transmitting spectrum and standard Class A and Class B masks comparison ............................................................................ 45 Transmitting spectrum and standard Class C and Class D masks comparison ............................................................................ 46 FER for QPSK and 64-QAM modulation for dierent frame length ... 47 FER vs received-SNR for BPSK 10 and 1500 bytes MSDU and for 64-QAM 10and 1500 bytes MSDU .............................................. 47
5.2 5.3 5.4 5.5
81
BIBLIOGRAPHY
Bibliography
[1] IEEE. Draft amendment to wireless LAN medium access control (MAC) and physical layer (PHY) specications: 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 IEEE 802.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] Simplied Wrapper and Interface Generator. http://www.swig.org/. [11] Dawei Shen. Tutorial 5: Getting Prepared for Python in GNU Radio by Reading the 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 Dened Radio. http://www.gps-sdr.com.
82
BIBLIOGRAPHY
[15] Eric Blossom. Chaos Communication Congress. In I see Airplanes! How to build 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 Signal Integrity 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 Implementation 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 a Software-dened Radio setup. Technical report, Lucerne University of Applied Sciences. [24] Dominic Spill. Implementation of the Bluetooth stack for software dened radio, with a view to sning and injecting packets. Technical report, University College London, May 2007. [25] Andrea Bittau Dominic Spill. Bluesni, Evemeets Alice and Bluetooth. Ma, The rst USENIX workshop on Oensive 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 Physical Layer (PHY) specications. High-speed Physical Layer in the 5GHz Band. http://standards.ieee.org/getieee802/. [28] CYCLIC REDUNDANCY CHECK. http://www.hackersdelight.org/crc.pdf.
83

Simulinkmatlab 802..11P

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Simulinkmatlab 802..11P

Caricato da

Copyright:

Formati disponibili

UNIVERSITA SALENTO

Implementation of an IEEE 802.11p transmitter in open-source Software Dened Radio

Relatore: Fabio RICCIATO Laureando: Andrea COSTANTINI

Universit` del Salento a

Universit` del Salento a

A me e alla mia famiglia

Universit` del Salento a

Universit` del Salento a

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

3 Software Dened Radio 3.1 3.2

Universit` del Salento a

4 IEEE 802.11p Implementation 4.1 4.2 4.3 4.4

Testbed Description ................................................................. 44 Results.................................................................................. 45

Universit` del Salento a

5.2.1 5.2.2 5.2.3

Universit` del Salento a

Universit` del Salento a

Universit` del Salento a

CHAPTER 2. IEEE 802.11 BASICS

Chapter 2 IEEE 802.11 basics

Universit` del Salento a

2.2. PHYSICAL LAYER

Figure 2.1: The IEEE 802 family

Universit` del Salento a

2.2. PHYSICAL LAYER

2.3. MEDIUM ACCESS

Basic Access Scheme

2.3. MEDIUM ACCESS

Figure 2.4: Basic Access Scheme

Virtual Carrier Sensing

Universit` del Salento a

2.4. FRAME FORMAT

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

Figure 2.6: Typical 802.11 MAC frame format

2.4. FRAME FORMAT

2.5. IEEE 802.11P

The basic OFDM concepts

2.5. IEEE 802.11P

2.5. IEEE 802.11P

Comparison between 802.11a and 802.11p

2.5. IEEE 802.11P

802.11 p 10 MHz 100 ns 64 52 + DC 52 4 8 s 1.6 s 6.4 s BPSK-QPSK-16QAM-64QAM

Universit` del Salento a

CHAPTER 3. SOFTWARE DEFINED RADIO

Chapter 3 Software Dened Radio

Universit` del Salento a

3.2. UNIVERSAL SOFTWARE RADIO PERIPHERAL

Hardware based subsystem Antenna

Software based subsystem

Radio Front End

Programmable device(s) (e.g. FPGA, GPP)

Radio Front End

Transmit signal path

Figure 3.2: Real Software Dened Radio blocks diagram

Universal Software Radio Peripheral

3.2. UNIVERSAL SOFTWARE RADIO PERIPHERAL

3.2. UNIVERSAL SOFTWARE RADIO PERIPHERAL

4 Stage CIC Filter

4 Stage CIC Filter Sin( i)

Base band 16-bit I/Q data with bandwidth Fs/N

3.2. UNIVERSAL SOFTWARE RADIO PERIPHERAL

Universit` del Salento a

Universit` del Salento a

noutput_items, &ninput_items, &input_items, &output_items) gr_complex ) input_items[0]; ) output_items[0];