FPGA, Na Qual É Instanciado Um Microprocessador E Periféricos

Departamento de Universidade de Aveiro Electrónica, Telecomunicações e Informática 2012

João Tiago Implementação do Controlo de Acesso ao Meio Bartolomeu Pio para IEEE 802.11p

Implementation of IEEE 802.11p Medium Access Control

Departamento de Universidade de Aveiro Electrónica, Telecomunicações e Informática 2012

João Tiago Implementação do Controlo de Acesso ao Meio Bartolomeu Pio para IEEE 802.11p

Implementation of IEEE 802.11p Medium Access Control

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Elec- trónica e de Telecomunicações, realizada sob a orientação cientíﬁca do Pro- fessor Doutor Arnaldo Silva Rodrigues de Oliveira (Orientador), Professor do Departamento de Electrónica, Telecomunicações e Informática da Uni- versidade de Aveiro e do Professor Doutor Joaquim José de Castro Fer- reira (Co-orientador), Professor Adjunto da Escola Superior de Tecnologia e Gestão de Águeda – Universidade de Aveiro. o júri / the jury presidente / president Prof. Doutor João Nuno Pimentel da Silva Matos Professor Associado da Universidade de Aveiro vogais / examiners committee Prof. Doutor Arnaldo Silva Rodrigues de Oliveira Professor Auxiliar da Universidade de Aveiro (Orientador)

Prof. Doutor Joaquim José de Castro Ferreira Professor Adjunto da Escola Superior de Tecnologia e Gestão de Águeda – Univer- sidade de Aveiro (Coorientador)

Prof. Doutor Valter Filipe Miranda Castelão da Silva Professor Adjunto da Escola Superior de Tecnologia e Gestão de Águeda – Univer- sidade de Aveiro agradecimentos / Antes de mais queria agradecer aos meus pais, que durante todo o meu acknowledgements percurso académico sempre me apoiaram em tudo o que necessitei. Foram eles os principais motivadores por detrás da minha decisão de escrever esta dissertação. Agradeço ao Professor Arnaldo Oliveira e o Professor Joaquim Ferreira, que me acompanharam e orientaram durante este longo percurso e sem os quais não teria sido possível completar o trabalho aqui apresentado. De igual importância foram os meus colegas de projecto, Nelson Cardoso e Manuel Ventura, cujo trabalho foi uma importante contribuição para esta dissertação. Quero também deixar uma nota de apreço à minha namorada, que me acompanhou durante a escrita do documento, ajudando no processo de revisão ﬁnal.

Resumo À medida que os avanços na tecnologia vão surgindo, as comunicações sem fios são cada vez mais omnipresentes. Os progressos nesta área fizeram com que recentemente se tenha começado a explorar as comunicações entre veículos móveis, de forma a proporcionar uma viagem mais confortável e segura aos passageiros. No entanto este tipo de comunicação tem características muito específicas, distintas das já familiares redes sem fios estáticas, exigindo outros modos de funcionamento. Posto isto, há a necessidade de desenvolver um conjunto de normas que supram essas necessidades específicas, não abrangidas pelas normas já existentes, que permitam a diferentes equipamentos comunicarem e falarem a mesma linguagem. Com este intuito, a norma IEEE 802.11p foi proposta como uma adenda à já estabelecida norma IEEE 802.11, de forma a providenciar serviço numa rede com baixos tempos de conectividade e alta mobilidade. Nesta dissertação discute-se a especificação, implementação e validação da camada Upper MAC de uma plataforma de comunicação que pretende implementar a norma 802.11p, com capacidade de estabelecer comuni- cações sem fios entre veículos de uma forma standardizada. Fisicamente a plataforma consiste num equipamento RF com antena e uma FPGA, na qual é instanciado um microprocessador e periféricos. Conceptualmente a plataforma consiste nas duas camadas mais baixas do modelo OSI de co- municações, PHY e MAC, sendo que a camada MAC se encontra dividida em Upper MAC de software e Lower MAC de hardware. A Upper MAC foi desenvolvida em C compilado para ser executado num microprocessador instanciado na FPGA. A Upper MAC é responsável pelas operações atribuídas pela norma à camada MAC que apresentam um maior nível de complexidade de implementação e que não têm exigências em re- lação à operação em tempo real. A Upper MAC foi implementada e testada na FPGA com sucesso, cumprindo com a maioria dos requisitos exigidos pela norma.

Abstract With current technological progress, wireless communications are becoming more pervasive. The developments in this area have caused a recent interest in communications between fast moving vehicles, in order to aid in a safer and confortable voyage. This type of communication has very specific characteristics, different from the already familiar static wireless networks, imposing distinct modes of operation. A set of standards that can comply with such specific needs must be developed, to allow different equipments to establish and maintain communications in a stable and organized manner. An amendment to the IEEE 802.11 wireless standard, called IEEE 802.11p, was written to provide communications in a network with low connectivity times and high mobility. This dissertation discusses the specification, implementation and validation of the Upper MAC layer of a communications platform that complies with 802.11p. Physically, the platform consists of an RF front-end with antenna and a FPGA, in which a microprocessor and its peripherals are instantiated. Conceptually the platform contains the two lower layers of the OSI communications model, PHY and MAC. The MAC layer is further divided into a software Upper MAC and a hardware Lower MAC The Upper MAC was developed in C compiled to be executed in the microprocessor instantiated in the FPGA. The Upper MAC is responsible for the MAC layer functionalities, defined by the standard, that require a higher level of complexity in the implementation and which don’t have real time operation requirements. The Upper MAC was implemented and validated with success, complying with most requisits defined in the standard.

Contents

Contents i

List of Figures iii

List of Tables v

List of Acronyms vii

1 Introduction 1 1.1 Scope ...... 1 1.2 Motivation ...... 3 1.3 Objectives ...... 4 1.4 Organization of the Document ...... 5

2 Applications, Standards and Projects 7 2.1 Introduction ...... 7 2.2 Applications ...... 7 2.2.1 Safety ...... 7 2.2.2 Traﬃc Management ...... 8 2.2.3 Commercial ...... 8 2.3 Standards ...... 8 2.4 MAC layer development projects ...... 10

3 Specification of the Upper MAC Layer 15 3.1 Introduction ...... 15 3.2 Functional Specification ...... 16 3.2.1 Interface With the LLC ...... 17 3.2.2 MAC Address Management ...... 18 3.2.3 Frame Assembling ...... 18 3.2.4 Frame Processing ...... 19 3.2.5 Positive Acknowledgment ...... 20 3.2.6 Medium Access Mechanism ...... 20 3.3 Timing Specification ...... 21

4 Implementation of the Upper MAC Layer 25 4.1 Introduction ...... 25 4.2 Software Architecture ...... 26

i 4.2.1 Main Cycle ...... 26 4.2.2 Reception From the LLC ...... 26 4.2.3 End of frame transmission to the PHY ...... 27 4.2.4 Reception from the PHY ...... 27 4.2.5 Countdown expiration ...... 28 4.3 Layer Interfaces ...... 33 4.3.1 MAC-LLC Interface ...... 33 4.3.2 UMAC/LMAC Interface ...... 34 4.4 Development Platform ...... 35 4.4.1 Hardware Kit ...... 35 4.4.2 Development Tools ...... 38 4.5 Project Structure ...... 38 4.6 Project Compilation and Execution ...... 41

5 Validation 43 5.1 Introduction ...... 43 5.2 Functional Validation ...... 43 5.2.1 Frame Format ...... 43 5.2.2 Frame Sequence Exchanges ...... 45 5.3 Timing Validation ...... 46 5.3.1 SIFS ...... 47 5.3.2 Virtual Carrier Sense ...... 50 5.3.3 Physical Carrier Sense ...... 50

6 Conclusion and Future Work 53 6.1 Final Remarks and Conclusions ...... 53 6.1.1 Functional Behavior ...... 53 6.1.2 Timing Behavior ...... 53 6.2 Future work ...... 55 6.2.1 Solving issues ...... 55 6.2.2 Adding Further Functionalities ...... 56

Bibliography 57

A UMAC/LMAC programming model 61 A.1 Macros Available ...... 61

B Over the Air Update 69 B.1 Overview ...... 69 B.2 Features ...... 69 B.3 Architecture and Implementation ...... 70

ii List of Figures

1.1 Example of a Vehicular Network with Vehicle-to-Vehicle (V2V) and Vehicle-to- Infrastructure (V2I) communication...... 2

2.1 The Wireless Access in Vehicular Environments (WAVE) layer stack and the standards their Institute of Electrical and Electronics Engineers (IEEE) ruling standards. 10 2.2 Hardware/software architecture of the OpenMAC platform...... 12

3.1 Block architecture of the 802.11p wireless communications device...... 15 3.2 Logical Link Control (LLC) - Medium Access Control (MAC) interface, with the diﬀerent primitives exchanged between the two layers and their respective directions and parameters...... 17 3.3 Data exchange at the LLC-MAC interface, for transmission and reception. . . . . 19 3.4 General format of MAC frames...... 20 3.5 Exchange of data between two stations, including Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) and positive acknowledgment...... 21 3.6 Timing relations between the diﬀerent Interframe Space (IFS) values...... 22

4.1 Detailed architecture of the MAC layer of the 802.11p communications platform. 26 4.2 Upper MAC (UMAC)’s main software cycle. Interrupt routines are named and labeled by numbers...... 27 4.3 Interrupt service routine for the llc_rx_interrupt...... 29 4.4 Interrupt service routine for the phy_tx_end_interrupt...... 30 4.5 Interrupt service routine for the phy_rx_interrupt...... 31 4.6 Interrupt service routine for the countdown_interrupt...... 32 4.7 Usage of the escape byte to signal the start and end flag ...... 33 4.8 Frame format for the codification of the LLC-MAC data exchange primitives . . . 34 4.9 Trenz Spartan-3E Field-Programmable Gate Array (FPGA) Industrial Micromodule. 37 4.10 802.11p communications platform motherboard, with the FPGA, Radio Frequency (RF) module (analogue Physical (PHY)) and General Packet Radio Service (GPRS) modem...... 37 4.11 Software project tree view...... 40 4.12 Compile and execution flow for the Xilinx EDK...... 41 4.13 Linker script generation window...... 42 4.14 Joint Test Action Group (JTAG) programmer cable for the FPGA...... 42

5.1 Setup for the validation test on frame format...... 44 5.2 Sniﬀer capture of four data frames...... 45

iii 5.3 Setup for the validation test of frame sequence exchanges...... 46 5.4 Terminal outputs of the two stations exchanging the frame sequences...... 47 5.5 Contributing layer times for the SIFS. Times are not to scale...... 48 5.6 Measured PHY transmission delay. Channel 1 represents the Lower MAC (LMAC) request and Channel 2 is the baseband signal...... 48 5.7 Experiment procedure with two stations. The medium idle interval is increased with each iteration of the experiment...... 51

B.1 Over the air upgrade system architecture added to the 802.11p platform. . . . . 70

iv List of Tables

2.1 Comparison of the existing MAC layer development projects...... 12

3.1 LLC-MAC interface data exchange primitives and their respective parameters. . . 18 3.2 Values of the diﬀerent IFS values and slot time for the Orthogonal Frequency- Division Multiplexing (OFDM) PHY with a channel spacing of 10 MHz, as deﬁned in 802.11 ...... 23

4.1 Encoding of the type and subtype frame ﬁelds...... 34

5.1 Results for the MAC process time component of Short Interframe Space (SIFS) on the second stage development platform...... 49 5.2 Results for the MAC process time component of SIFS on the third stage development platform...... 49 5.3 Results for the Virtual Carrier Sense tests...... 50 5.4 Average packet transmission success rates for the diﬀerent idle intervals...... 52

6.1 Standard deﬁned times versus obtained results for the SIFS validation tests. . . . 54

v vi List of Acronyms

AP Access Point

ACK Acknowledgment

ARM Advanced RISC Machine

BB Baseband

B2B Board-to-Board

BSP Board Support Package

CSMA/CA Carrier Sense Multiple Access with Collision Avoidance

CTS Clear-to-Send

CCH Control Channel

CICAS Cooperative Intersection Collision Avoidance Systems

COOPERS CO-OPerative SystEms for Intelligent Road Safety

DLL Data Link Layer

DIFS DCF Interframe Space

DSRC Dedicated Short Range Communications

DSP Digital Signal Processor

DCF Distributed Coordination Function

DDR Double Data Rate

ETC Electronic Toll Collection

FPGA Field-Programmable Gate Array

FCS Frame Check Sequence

FM Frequency Modulation

GPRS General Packet Radio Service

GPIO General Purpose Input Output

vii GPS Global Positioning System

GSM Global System for Mobile Communications

HEADWAY Highway Environment ADvanced WArning sYstem

IEEE Institute of Electrical and Electronics Engineers

ISE Integrated Software Environment

ITS Intelligent Transportation Systems

IFS Interframe Space

IP Internet Protocol

JTAG Joint Test Action Group

LLC Logical Link Control

LMAC Lower MAC

MAC Medium Access Control

MDD Microprocessor Driver Deﬁnition

MLD Microprocessor Library Deﬁnition

MSS Microprocessor Software Speciﬁcation

NAV Network Allocation Vector

NIC Network Interface Controller

OBU On Board Unit

OSI Open Systems Interconnection

OFDM Orthogonal Frequency-Division Multiplexing

PC Personal Computer

PCMCIA Personal Computer Memory Card International Association

PHY Physical

PSDRAM Pseudo Static RAM

RF Radio Frequency

RFID Radio Frequency Identiﬁcation

RAM Random Access Memory

RSSI Receive Signal Strength Indicator

RS232 Recommended Standard 232

viii RTS Request-to-Send

RSU Road Side Unit

SPI Serial Peripheral Interface

SCH Service Channel

SIFS Short Interframe Space

SDK Software Development Kit

SDRAM Synchronous Dynamic Random-Access Memory

UWB Ultra High Band

USDOT United States Department of Transportation

USB Universal Serial Bus

UMAC Upper MAC

VICS Vehicle Information and Communication System

V2I Vehicle-to-Infrastructure

V2V Vehicle-to-Vehicle

VHDL VHSIC Hardware Description Language

WSMP WAVE Short Message Protocol

WAVE Wireless Access in Vehicular Environments

WAN Wireless Area Network

XPS Xilinx Platform Studio

ix x Chapter 1

Introduction

1.1 Scope

The number of motorized vehicles that populate roads all around the globe has risen steadily in the last few decades, from the so called developed countries to the developing ones, with a steeper rise being witnessed in the latter [1]. This increase in density is directly responsible for most of the traffic problems that many countries are facing today, mainly related to road safety and traffic congestion, but it also presents an opportunity for the creation of a mobile and flexible network. Using the vehicles themselves as a medium for the propagation of information, an inter-vehicle communication platform can be achieved, in what is currently referred to as a mobile or vehicular network [2, 3]. The mobile units of a vehicular network are the equivalent to nodes in a traditional wireless network, and can function as the source, destination or router of information. Communication between these nodes can be point-to-point, point-to-multipoint or broadcast, depending on the current application’s requirements [4]. Besides the ad-hoc implementation of a network consisting of neighboring vehicles joining up and establishing Vehicle-to-Vehicle (V2V) communication, there is also the possibility of a more traditional wireless network setup, with base stations along the route of the vehicles in Vehicle-to-Infrastructure (V2I) communication that work as access points and manage the flow of information, as well as portals to external Wireless Area Networks (WANs) [5], as is pictured in figure 1.1. Devices operating inside vehicles are called On Board Units (OBUs), while devices operating on the side of the road are Road Side Units (RSUs), and have different requirements and mode of operation. There are currently a multitude of identified applications for vehicular networks, including road safety, traffic management, entertainment and commercial applications. All these applications have different requirements which must be covered, so vehicular networks must be flexible, in order to be able to accommodate diversified applications [3, 4, 5]. In regards to safety and traffic management applications, the network requirements include low latency in information exchange, the need to disseminate it efficiently, high reliability of delivery without data corruption and a certain degree of data security. Applications related to entertainment and information must have the capability of delivering high quantities of information. In these applications delivery latency does not assume such a critical aspect as in safety and traffic management applications. Applications with commercial objectives require high security of the transferred information, since they involve electronic payments, with a throughput of data that is

1 Figure 1.1: Example of a Vehicular Network with V2V and V2I communication. not unsubstantial [4]. This varied array of applications and their requirements, means that a vehicular network must have great flexibility in terms of throughput versus latency, as well as highly secure data exchange, owing to the life threatening implications that some of the applications have on their users. To accommodate this, protocols ruling these real-time communication systems must be very reliable and timely. Contructing a communications device of this type can be approached in several ways. Focusing on developing the upper layers of the Open Systems Interconnection (OSI) model while relying on third party hardware for the lower layers, will inevitably carry a cost, in terms of overhead and communication speed. On the other hand, development of adequate lower level layers, mainly the Medium Access Control (MAC) layer, should guarantee the necessary real-time requirements of such a system [3]. Originally, the WiFi standards family (Institute of Electrical and Electronics Engineers (IEEE) 802.11) were not aimed at fulfilling the specific requirements of vehicular networks, so efforts were made to draft a new standard that would support these requirements. In 2004, the first version of the new amendment 802.11p was drafted and by 2012 it had reached its finalized version. Parallel to this standard, the Intelligent Transportation Systems (ITS) program of the United States Department of Transportation (USDOT) developed the Wireless Access in Vehicular Environments (WAVE) family of standards (1609.X), of which 1609.4 is of a particular interest as it defines the operation of 802.11p stations in multi-channel environment. These standards and their characteristics will be further discussed in section 2.3.

2 1.2 Motivation

The work presented in this dissertation is included in the Highway Environment ADvanced WArning sYstem (HEADWAY) project [6], which aims to build a communications platform compliant with the 802.11p standard and the 1609 sub-standards, for implementation of a vehicular network with several possible applications. The platform is built from scratch, with the development of all the OSI layers, from the Physical (PHY) up to the application, the work being divided between the various members of the project group. The technology on which the different layers are implemented is the Xilinx family of Field-Programmable Gate Arrays (FPGAs), namely the Spartan 3 and, more recently, Spartan 6 models. Several other projects have decided on a different approach to the development of a 802.11p compliant platform, by extending or tweaking the functionalities on top of equipment compliant with the 802.11a/g family, so that it provides the same services and functionalities as the WAVE standards. That approach has obvious advantages in terms of developing time, since the bulk of the work is done by a third party, but the core of the device is still a black box to which the developers have no access. Such system is therefore monolithic and hard to adapt when a change to the functionalities is required. The build from scratch approach followed by the HEADWAY project implies a much higher workload, yet it provides the developers with deep knowledge of the core functioning of the device, which in turns allows great flexibility when any kind of change or expansion is required. Development from the bottom-up also allows for a modular system, with each layer being self contained and communicating with the adjacent layers through interfaces clearly defined in the standard, both at architectural and behavioral levels. In turn, this leads to the possibility of any layer of a HEADWAY device to be integrated into any third party device that is compliant with the standard. Full knowledge and access to the core of the MAC layer allows a high grade of control over its architecture and behavior, more easily reaching the demands imposed by the standard. In a vehicular network scenario, situations of high traffic are to be expected, and failure to deliver critical data related to safety applications is unacceptable. A deterministic MAC layer capable of supporting real-time communications is a desirable feature. The proposed solution in this dissertation is the development of a MAC layer from scratch implemented in a FPGA, to be later expanded to support real-time communications. The solution, is a hybrid of hardware and software, where time-critical operations are implemented in hardware and non-time critical operations in software. This dissertation will address the MAC layer, more specifically the Upper MAC (UMAC) sublayer, being a work in cooperation with another student whose work was focused on the Lower MAC (LMAC). Both works are complementary to each other; the LMAC will be explained in sufficient detail in this document for the understanding of the UMAC. For a full understanding of how the LMAC works, refer to [7].

3 1.3 Objectives

In the context of the HEADWAY project, the objectives of the work, discussed in this dissertation, are:

• Full specification of the MAC layer; Identification and definition of all the functions and services a 802.11p MAC layer must provide in a communication system; how these should be implemented and the minimum accepted performance values required for the system to be compliant to the norm. Also a structural definition of the MAC layer, how and where its functions should be allocated, as well as the reasons behind this allocation based on the resources available and their capabilities.

• Implementation of a functional MAC layer (focusing on the UMAC sublayer), that provides the basic functionalities and services, and which is self contained, in the sense that its communication with the upper and lower layers (PHY and Logical Link Control (LLC)) is compliant with the standard, enabling a black box development. The platform for this implementation is the Xilinx family of FPGAs, where both the MAC layer and the digital PHY (not within the scope of this document) will be located.

• Validation of the functionalities previously identified in the specification phase. Confirmation of the logical behavior of the MAC layer as well as evaluation of its performance, mainly in terms of packet loss rate, propagation, delay times and throughput.

• Implementation of a General Packet Radio Service (GPRS) based, over-the-air update system with the ability to update remotely the contents of the FPGA (both MAC and PHY layers).

• Deﬁnition of the next steps in the development process, namely which functionalities are more important and which avenue of development will yield results faster.

4 1.4 Organization of the Document

Besides this introduction, this document includes the following chapters:

• Chapter 2 - Applications, Standards and Projects - This chapter contains a survey of existing applications for vehicular networks. The most recent protocols that rule medium access in vehicular communications is also presented, as well as a report on existing MAC layer development projects.

• Chapter 3 - Speciﬁcation of the Upper MAC Layer - In this chapter, the speciﬁcation required of the MAC layer is discussed. The general architecture of the system is described and the reasons for the architectural choices are explained. It is also explained what should be the behaviour of the MAC layer in terms of functionality and time demands.

• Chapter 4 - Implementation of the Upper MAC Layer - In this chapter the implementation of the Upper MAC will be presented. The implementation aspects of the layer include the structure of the software, the layer interfaces, as well as the development platform used to implement the UMAC.

• Chapter 5 - Validation - In this chapter a validation and evaluation of the behavior of the UMAC is described. Both functional and timing behaviors are evaluated.

• Chapter 6 - Conclusion and Future Work - In this chapter the results obtained from the validation are discussed. There is a discussion about the objectives proposed and which of them were achieved. Issues and non compliances are examined and solutions are proposed, allowing for planning of future work.

The following appendixes are also included in this document:

• Appendix A - UMAC/LMAC programming model macros - The set of software macros used by the UMAC to access the control and status registers of the LMAC.

• Appendix B - Over the Air Update - Description of the auxiliary system for remote upgrade of both software and hardware of the communications platform.

5 6 Chapter 2

Applications, Standards and Projects

2.1 Introduction

In this chapter an overview of the diﬀerent applications of vehicular networks will be presented. Following that, the existing standards that regulate vehicular communications will be discussed, namely what diﬀerenciates them from existing wireless technology standards and what are their advantages. Finally a survey of existing MAC layer projects, wether for vehicular communications or not, will be presented.

2.2 Applications

Vehicular communications have a wide range of possible applications, but can generally be divided into three categories: Safety, Traﬃc Management and Commercial applications. Each application within a category shares the same requirements as the other members of its type and these speciﬁcities can vary greatly.

2.2.1 Safety

Safety is the most evident application type and the main drive behind the investigation into vehicular networks, due to the health implications to road users. It is aimed at reducing the number of traﬃc accidents, by providing a fast and reliable method of sharing information about hazardous situations or positional data between the vehicles present in the same road as well as infrastructure. Several projects focusing on safety applications have been active in the last few years. The SAFESPOT project [8] implements a safety distance warning system, to help prevent accidents. The project aims to achieve this by combining several sources of information in a vehicle network, namely Global Positioning System (GPS) positioning data, Ultra High Band (UWB) round-trip time and image identiﬁcation of road features, and using a cooperative algorithm to detect critical situations. The vehicles then share between themselves the relevant information they have obtained from all the sources. Another institution also working in safety applications is the USDOT ITS division. One of their projects, the Cooperative Intersection Collision Avoidance Systems (CICAS) [9], aims to aid drivers negotiating intersections by providing them updated information about the behavior of other vehicles in the intersection. CICAS uses both OBUs and RSUs to collect data through a

7 diversity of sensors, followed by communication between the units through Dedicated Short Range Communications (DSRC). An European Commission funded project, CO-OPerative SystEms for Intelligent Road Safety (COOPERS) [10], aims to provide vehicles with real-time, local context aware, safety information, distributed through an installed infrastructure. The project claims that V2I is necessary because only the infrastructure can provide strategic traffic information in real-time. V2V is left a second line role, simply as a means of conveying information collected by each vehicle, which function as floating sensors on the road. Its aim of increasing safety is better achieved in areas of dense traffic, where accidents might occur more frequently. COOPERS is also used to improve traffic flow, by collecting data about the position of vehicles and guiding users through the most efficient route.

2.2.2 Traﬃc Management

Heavy traffic in big cities is a problem with no easy solution, and is responsible for delays, high fuel consumption and health issues related with pollution and accidents. The natural consequence is a push towards development of projects aimed at improving traffic flow. The SafeTrip 21 [11], also developed by the USDOT’s ITS division, aims to provide drivers with assistance in choosing the safest and fastest route to their destination, by collecting information from several sources, computing a route and delivering it to the OBUs. In Japan, the Vehicle Information and Communication System (VICS) [12], as the name indi- cates, is an information and communication system that delivers real-time road traffic information about congestion and regulation to the drivers. This provides them with assistance for safe driving and what the best routes are, indirectly increasing efficiency in road management. The cars receive messages through the Frequency Modulation (FM) band and 2.5 GHz radio.

2.2.3 Commercial

The most widely implemented commercial application for Vehicular Networks is the tolling in highways. In Japan the Electronic Toll Collection (ETC) [13], is a project started in 1993 with the purpose of developing a common Electronic Toll Collection system, able to process payments and keep track of highway usage. The system is common to every vehicle nationwide and operates in the 5.8 GHz radio band. Via Verde [14] is the Portuguese wireless tolling system. It functions in the 5.8 GHz radio band, just like the Japanese ETC, but the speciﬁcations are distinct regarding modulation and data rate, among others. It allows users of the transponders to also purchase fuel and pay parking fees electronically. Other countries have developed systems for tolling, but they share the same premise and implementation with the ones already mentioned.

2.3 Standards

Vehicular networks require speciﬁc standards to address their demands, since the IEEE WiFi (802.11) family standards are primarly directed towards providing wireless internet access in a relatively small area of a few meters indoors and up to several hundred meters outdoors. This is not suitable for a situation where vehicles are travelling in a low density road and need to report

8 an event to the closest vehicle, which may very well be further away than the 250 meters range. Other limitations of traditional WiFi include the low data rate when terminals are moving at high speed and the inability to guarantee the small and bounded delays required by safety applications [15]. This lack of a suitable standard to supplement the demanding requisites of vehicular networks, not supported by native 802.11 WiFi [16], led IEEE to form a new task group in 2004, to create an amendment to the existing standard, 802.11p [17] and the 1609.4 standard [18]. The amendment is responsible for the regulation of communications in WAVE and the standard defines the operation of the MAC layer in a multi channel mode. 802.11p is based in 802.11, sharing some of its core concepts, simplifying several aspects of the main standard and adding new services to both the MAC and PHY layers. 802.11p brings enhancements to WiFi, defining the working frequency in the band of 5.9 GHz (5.85-5.925 GHz) and extending the 802.11 MAC to provide short latency (between 50 and 100 milliseconds), ranges until 1000 meters and operation at speeds up to 200 km/h [19]. The process of joining a network was one of the standard features that was simplified in 802.11p [20]. The main factor behind this was the dynamic nature of these networks and the required shorter latency time between data production and delivery. A complicated and relatively slow process of authentication and association is thus unpractical, but this reduction makes it difficult to identify network members within useful time. This leads to the next relevant difference in 802.11p when compared with native 802.11, which is the exclusive communication in broadcast mode and all that this entails [20]. The USDOT pursued interest in the concept of vehicular communications, so while accompa- nying the progress of the 802.11p standards, the WAVE family of standards was conceived.

• 1609.0 - Describes the WAVE architecture and services necessary for multi-channel DSRC/WAVE devices to communicate in a vehicular environment [21].

• 1609.1 - Speciﬁes the services and interfaces of the WAVE Resource Manager application.It describes the data and management services oﬀered within the WAVE architecture .[21]

• 1609.2 - Security Services for Applications and Management Messages deﬁnes secure message formats and processing. [21]

• 1609.3 - Networking Services defines network and transport layer services. It is responsible for the definition of the Network layer and introduces the alternative to the Internet Protocol (IP), the WAVE Short Message Protocol (WSMP). WSMP is a simpler protocol than IP and was developed to be transmitted in single hop exchanges, due to its bandwidth efficiency. IP is used for multi-hop exchanges, which take advantage of its routing capabilities.

• 1609.4 - Extends the management plane of 802.11 for operation in a multi-channel environment. With it, a system with one or more radios can switch between diﬀerent radio channels in a synchronized fashion with the other devices in the same network, guaranteeing that all devices are communicating in the same channel [20].

• 1609.11 - Deﬁnes the services and secure message formats necessary to support secure electronic payments.[21]

Figure 2.1 shows the WAVE layer organization and the corresponding standards.

9 WAVE was developed with the guidance of the USDOT, and consequently took the United States frequency spectrum into consideration when allocating its working frequencies. The reality in Europe is diﬀerent, but despite this, the European Commission allocated part of the 5.9 GHz band for priority road safety applications, with the objective of ensuring compatibility with the USA even if the allocated frequencies were not exactly the same [22].

WAVE stack

1609.1 Upper Layers

Transport Network and UDP 1609.3 Transport WSMP Network IPv6 1609.2 WAVE Security 802.2 LLC Services 1609.4

WAVE MAC (incl. channel coordination)

802.11/p

PHY

Figure 2.1: The WAVE layer stack and the standards their IEEE ruling standards.

2.4 MAC layer development projects

Several approaches to the implementation of a MAC layer for 802.11 family of standards, can be found in the existing literature. One concept which can be found in [23, 24, 25, 26], is the adaptation of the device drivers of the system’s Network Interface Controller (NIC), adding or changing the desired functionalities of the MAC layer at the software level. More speciﬁcally, in [24] the wireless driver of a Linux distribution is edited to provide channel routing and access, channel switching and coordination, priority messages and scheduling. In [27] Manfrin, R., et al. developed a communications platform that consists of four components, namely an Radio Frequency (RF) transciever, a Baseband (BB) processor, a Digital Signal Processor (DSP) and an Advanced RISC Machine (ARM) processor. The ARM and DSP are integrated in a single dual-core Texas Instruments chip. The ARM supports the upper layers, from the network layer up, the DSP handles the Data Link Layer (DLL) and MAC layer functionalities, while the BB processor and RF transciever support the PHY layer functionalities. The MAC layer contained in the DSP is available for programming in ANSI C, but there is no access to any of the hardware. In [28], the software development approach was taken even further, with the digital transmission chain, both MAC and digital PHY, being developed in an open source Software Development Kit (SDK) for software deﬁned radio called GNURadio [29]. This SDK provides the transmission

10 chain blocks needed to encode an Orthogonal Frequency-Division Multiplexing (OFDM) frame and the resulting BB samples are then fed to a RF digital-to-analog converter, which transmits it to the air medium. Their validation focuses only on frame format and power spectrum issues and does not go into any detail about timing issues, which raises the question if a system so reliant in software is able to comply with the strict timing demands of the standard. On the other hand, having access to the entirety of the transmission chain, makes the 802.11p GNURadio project highly flexible. These approaches are advantageous in terms of the reduced development time that a software solution entails. The programming languages used to develop software drivers are easy to master and the debugging process is simpler due to the debugging tools available and the reduced time of compilation. As a trade-off, there is a loss of flexibility, as the NIC hardware effectively is a black box to the developer. The development is limited to the high level, non time critical functions of the MAC layer, accessible through the software driver, and is unable to do any modifications to the PHY or time critical sections of the MAC. If the objective is to develop a deterministic MAC layer, the non deterministic characteristics of software implemented functionalities, are undesirable. Hardware oriented implementations can be found in [30, 31, 32]. The approach taken in these projects explores not only the development of high level functions through software, but also delves into the development of the lower level functionalities of both the MAC and PHY layer through hardware. The process of designing, implementing and debugging a hardware solution is more cumbersome in terms of time as well as in complexity. Knowledge of hardware description languages and the development tools is harder to obtain than common software programming languages, but it allows for an in-depth control of the time critical functionalities of a communication system. In [30, 31] Hunter, C., et al. built a wireless communication test platform with a mixture of custom hardware and software. The PHY layer is implemented in a Xilinx FPGA and the MAC layer runs on the PowerPC instantiated in the same FPGA. It is not completelly clear if there are any MAC functionalities that are implemented in hardware, but the implementation is aimed at providing full flexibility in the development process. This approach is very similar to the one described in this dissertation, but it does not provide any coverage of 802.11p. A recent implementation of a FPGA based MAC layer for 802.11 called OpenMAC is presented in [32]. This implementation, while not aimed at 802.11p, follows the same hybrid approach to the distribution of layers and functionalities as our own project. It also implements the PHY and MAC in a Xilinx Virtex-5 FPGA, and further divides the MAC into hardware MAC and software MAC. Both PHY and hardware MAC are implemented in VHSIC Hardware Description Language (VHDL), while software MAC is written in C++ running in a PowerPC processor in the FPGA. The architecture of the OpenMAC platform can be seen in figure 2.2 The rationale for the separation between hardware and software MAC is the need to guarantee several time critical functions in the hardware MAC, while allowing an easier and faster development in the software MAC of non-time critical functions. The project presented in [32] is directed towards 802.11 families in general, with no special attention given to the specificities of 802.11p. The PHY layer of this project was developed for compliance with 802.11p in mind, and can move towards a solution that allows for multi channel operation, as specified in 1609.4. The separation between Control Channels (CCHs) and Service Channels (SCHs), allows for the existence of a channel dedicated to high priority exchanges of information, the CCH. Such a channel, where control and management information is guaranteed to reach the destination swiftly, can provide an important resource to achieve determinism in the communications. Other devices exist for which detailed information on the implementation is not known. The

11 Figure 2.2: Hardware/software architecture of the OpenMAC platform. (Image taken from [32])

Arada Systems project Locomate [33] is a commercial device compliant with 802.11p and 1609.4 and they provide equipments for both OBUs and RSUs. The implementation of the several layers of the communications platform is not revealed, but they base their device on the Atheros Wireless chipset AR5414, which according to the datasheet supports 802.11a/b/g only. The Locomate project probably alters the functionalities of the chipset, to comply to both 802.11p and 1609.4, by means of changing the device drivers of the chipset, much the same way as the DRIVE-IN project previously mentioned. Table 2.1 shows a comprehensive comparison of the MAC development projects discussed previously, with the different projects being classified by the implementation of the MAC layer, the degree of flexibility in assigning functionalities these implementations allow and if they intend to comply to 802.11p.

Project MAC implementation Flexibility 802.11p Cooperative Network [23] driver-level software Low No DRIVE-IN [24] driver-level software Low Yes UM Platform [25] driver-level software Low No SoftMAC [26] driver-level software Low No CalRadio 1 [27] low-level software Medium No 802.11p GNURadio [28] high-level software High Yes WARP [30, 31] low-level software High No OpenMAC [32] low-level software and hardware High No Locomate [33] N/A N/A Yes

Table 2.1: Comparison of the existing MAC layer development projects.

The survey of the state of the art in regards to MAC layer development projects, shows that software, hybrid and hardware solutions exist, each with different degrees of flexibility and complexity. Although solutions that comply with 802.11p exist, they lack flexibility as they are based in closed, third-party chipsets, with developers not having access to the core functionalities of both the PHY and MAC layers. Solutions totally based in software allow access to all the levels and layers of the communication platforms, but they lack the real time capabilities of hardware solutions. Finally, solutions that are based in both hardware and software benefit from the best of two worlds, but none has been developed specifically for 802.11p. This is the gap that the project

12 discussed in this dissertation intends to ﬁll. In the next chapter, the speciﬁcation of the UMAC will be presented.

13 14 Chapter 3

Speciﬁcation of the Upper MAC Layer

3.1 Introduction

In this chapter, the specification required of the MAC layer will be discussed. The architecture of the system will be described and the reasons for the architectural choices will be explained. It will also be explained what should be the functional and timing specifications of the MAC layer. The different functionalities of the MAC layer are divided into time critical and non-time critical functions. The different requirements of these functionalities require the MAC layer to be divided in two sublayers with different characteristics, the Upper MAC and the Lower MAC. The focus of this dissertation is the UMAC, but it is important to understand that both sublayers were designed and implemented in cooperation, taking into attention each other’s specifications and needs. This means that some functionalities of the MAC are indissoluble, being shared by UMAC and LMAC. The motivation for the division of the MAC into sublayers was that some functionalities of the MAC layer demand a high degree of precision and predictability in terms of timing, while others do not. To achieve the real-time demands of such functionalities, their implementation must be done in hardware instead of software, but this brings added costs in terms of development time and complexity. A software solution is faster to implement and is perfectly able to perform the functionalities that do not have a real-time component. So the sublayer architecture provides a tradeoff between complexity of the implementation and the guarantee of determinism where real-time operation is needed. Figure 3.1 shows the block architecture of the communications platform. As previously mentioned, it consists of a MAC layer (subdivided into the UMAC and LMAC), digital PHY and RF module. The UMAC, LMAC and digital PHY reside in the FPGA, while the RF module is external.

External PC FPGA

LLC-MAC UMAC Interface software Digital PHY LLC RF module LMAC MAC-PHY (hardware) hardware Interface

Figure 3.1: Block architecture of the 802.11p wireless communications device.

15 The layers above the MAC, starting with the LLC are external to the platform, and interface with the UMAC through a serial interface. The system was built using a modular approach, meaning that each layer sees the other as a black box, effectively making development independent. The connection between each module follows the specifications defined in 802.11p, as is the case of the LLC-MAC and MAC-PHY interface.

3.2 Functional Speciﬁcation

As mentioned in section 3.1, the functionalities of the MAC layer are divided by the two sublayers. The UMAC handles the functions which are non-time critical but require more processing power. It is also responsible for communication with the upper layers of the OSI model of the communication platform. The LMAC is given the time critical functions, which require a lighter load in terms of processing. The following functionalities are handled by the UMAC:

• Interface with the LLC - Transmission and reception from the LLC, following the standard;

• MAC address management - Identiﬁcation of each device by means of a MAC address that is unique and permanent to each networking component (as opposed to IP addresses of the Network layer);

• Frame assembling - In order to transmitting data, the MAC must assemble a frame where the data will be contained;

• Frame processing - Receiving frames from the LMAC and process them.

• Replying to the originator of frames received by the station, when such is required. Examples are the positive acknowledgment and the Request-to-Send (RTS)/Clear-to-Send (CTS) pair;

• Medium Access mechanism - Virtual carrier sense part of the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) medium access mechanism;

• Controlling the behavior of the LMAC layer, through a set of control and status registers provided by the latter.

The LMAC is in turn responsible for:

• Management of the memory banks where frames shall be kept, both for transmission and reception;

• Interfacing with the PHY, following the standard;

• Receiving frames from the PHY;

• Transmit frames to the PHY;

• Maintain the system timers. These are used for timestamping of outbound frames as well as in the medium access control mechanism.

• Perform the physical carrier sense part of the CSMA/CA of the medium access mechanism.

16 • Error checking capability. The LMAC must verify the Frame Check Sequence (FCS) ﬁeld of arriving frames and detect errors. It must also calculate and append the FCS ﬁeld to outbound frames.

3.2.1 Interface With the LLC

The UMAC handles all interactions with the LLC through means of a set of primitives defined in 802.11 [16, section 5.2.1]. There are several primitives defined for different purposes, namely management operations and data transfer between the layers. In this device only the latter have been implemented, because the management plane of the MAC layer has not been developed. Figure 3.2 shows the data exchange primitives that are implemented. For a detailed explanation of what are the parameters of each primitive and their function, refer to table 3.1 and [16, section 5.2]. The distinction between MA-UNITDATA and MA-UNITDATAX relates to the network protocol packet being exchanged (WSMP or IP, respectively, as seen in figure 2.1). For the kind of network intended for this project, only WSMP is to be implemented, since the ad hoc network being implemented does not require or allow any routing.

LLC n t n t o s i o s t m i s e t s r r s e a i r u r f a e u c t e i q e c n t i q t e d e o e d e r e n . c r i m n . . . m i m X a . A A a r X a A r A r T T a A a T a T p A A T

p p A A

D D t n A D D s T o T m D i I I T r T e t I i I T f N N u a I N N n c q U U i N - o - U e U d - - U A A C - R n A I A A M M M M M

MAC

Figure 3.2: LLC - MAC interface, with the diﬀerent primitives exchanged between the two layers and their respective directions and parameters.

Transmission

When the LLC wishes to transmit a frame to the MAC layer, it must generate a MA- UNITDATAX.request primitive, with all the parameters described in table 3.1, and send it to the UMAC. The MAC layer buﬀers the data, processes it and attempts transmission. The result is then reported to the LLC through the generation of a MA-UNITDATAX-STATUS.indication

17 Parameters source address destination address routing information transmission status data provided priority priority reception status provided service class service class MA-UNITDATAX.request x x x x x x MA-UNITDATAX.indication x x x x x MA-UNITDATAX-STATUS.indication x x x x x x

Table 3.1: LLC-MAC interface data exchange primitives and their respective parameters. primitive, whose parameters include the Transmission Status, a descriptor of the success state of the transmission.

Reception

When the MAC receives a frame from the PHY and wishes to relay it to the LLC, it must generate a MA-UNITDATAX.indication with the adequate parameters and transmit it to the LLC. This can only occur if the MAC layer has already validated the format of the frame, checked it for errors and accepted the destination MAC address as the one of the station. Both reception and transmission are represented in ﬁgure 3.3.

3.2.2 MAC Address Management

The UMAC is responsible for the identification of the station in terms of MAC address. This address is hardcoded, permanent and unique to the station. It must be capable of distinguishing the origin of frames from their address fields, as well as discerning the different networks within range.

3.2.3 Frame Assembling

MAC frames sent by a station can be originated in the upper layers or in the MAC layer itself. Data frames, (more exactly the payload of data frames) are originated in the upper layers, sent to the UMAC, through the primitives defined in the previous point, which then encapsulates them with the adequate fields and sends them to the LMAC, and consequently the PHY, for transmission. Control and management frames are originated in the UMAC sublayer, with exceptions being when the upper layers initiate a management request. These types of frames are important for the efficient functioning of the network, like the RTS/CTS pair and Acknowledgment (ACK) frames, and are invisible to the upper layers. The UMAC is responsible for the encapsulation or the complete assembly of these frames for transmission. Figure 3.4 shows the general format of the MAC frame, with the MAC header, the frame body and the FCS (whose calculation is performed by the LMAC). For further information on the fields present in the different types of frames, refer to [16, section 8.3].

18 LLC MAC

Transmission LLC wants to send data

MA-UNITDATAX.request

MAC buffers data to be sent

MAC attempts to send data to PHY

MA-UNITDATAX-STATUS.indication STATUS values: Successful Undeliverable

Reception

MAC received valid frame from PHY

MA-UNITDATAX.indication

Figure 3.3: Data exchange at the LLC-MAC interface, for transmission and reception.

3.2.4 Frame Processing

The capacity to build frames for transmission implies the ability to recognize and process them when they arrive to the station. The UMAC is responsible for discerning what type of frame has arrived from the medium, read all the ﬁelds and take appropriate action. Actions undertaken,

19 Octets: 2 2 6 6 6 2 6 2 0-23124 4 Frame Sequence QoS Frame Duration Address 1 Address 2 Address 3 Address 4 FCS Control Control Control Body

MAC Header

Figure 3.4: General format of MAC frames. range from forwarding of the frame payload to the upper layers, to replying to the source station with the appropriate frame.

3.2.5 Positive Acknowledgment

In native 802.11, each data frame with an individual destination address (unicast) must be positively acknowledged, with the destination station sending an ACK frame back to the source. Positive acknowledgement of frames is an important characteristic of 802.11 that allows a station to detect any failures of delivery of data frames. Without it, it is virtually impossible for the station to know if the data arrived to the destination. In 802.11p, with the introduction of transmission outside the context of a network, broadcast is the norm when exchanging data [20], making it impossible to provide positive acknowledgment. The station must be able to work with the rules of 802.11 and have an alternative mode where it follows the speciﬁcations of 802.11p.

3.2.6 Medium Access Mechanism

This is one of the functionalities that is shared between UMAC and LMAC, and for an understanding of how it works, several aspects of the LMAC’s role must be described. In 802.11 and its extensions, the fundamental MAC medium access method is CSMA/CA. In this access method, when a node wants to transmit any data, it first has to listen to the channel to determine if any other nodes are occupying it (within the wireless medium range). Providing it does not sense any carriers in the channel, the node can start relaying the data to the medium. On the other hand, if it detects a busy channel, the node has to defer access until the medium is free once more. As soon as this happens the node waits a fixed minimum time, followed by a random period called backoff, before trying again. The backoff period is composed by time slots of fixed size and is defined by equation 3.1.

BackoffP eriod = RandomInteger × SlotT ime (3.1) In this device, the backoﬀ is calculated by the UMAC and supplied to the LMAC every time the former requests the transmission of a frame. The sensing of the medium is performed both through physical and virtual methods. If any of the methods detects a busy medium, the station shall defer access.

Physical Carrier Sense

The PHY layer provides the physical carrier sense method through the Receive Signal Strength Indicator (RSSI) from the RF transceiver, which is in turn used by the LMAC to control access to the medium. Solely sensing the medium with the physical method has its ﬂaws, as it does not cover situations like the hidden node problem. In this problem, node A can see and communicate with two nodes B and C for they are within range, but B cannot see C and vice versa because they

20 are not within range of each other [34]. By default, 802.11 suﬀers from this, but it is an optional feature of the standard to use the virtual carrier sense method, discussed in subsection 3.2.6.

Virtual Carrier Sense

The virtual carrier sense method is implemented with the help of the RTS/CTS frame exchange to reduce frame collisions resulting from the hidden node problem. In this mode of operation, any node wishing to transmit must first send a RTS frame and wait for a CTS frame to be sent back by the destination node. Any other member of the network that senses either a RTS or CTS frame, will refrain from accessing the medium, thus solving the hidden node problem. Each RTS or CTS frame contains a field with the value of the expected duration for the data transaction that will follow (based on the frame size, fragmentation and data rate currently being used). If the data frame is not directed to the station, this duration value is used to update the Network Allocation Vector (NAV), deferring access for the duration of the transaction. The UMAC is responsible for the implementation of both the RTS/CTS exchange, as well as upkeep of the NAV value, effectively implementing the virtual carrier sense method of the medium access protocol. Figure 3.5 shows a successful exchange of data between two stations and what happens in other stations, within communications range but not involved in the exchange. The process starts with the source sending a RTS frame to the destination station, which also reaches other stations not involved which update their NAV according to the duration field contained in the RTS frame, deferring access to the medium. The destination station replies with a CTS frame allowing the source station to begin transmission. At the same time, other stations that may have not received the RTS, update their NAV according to the duration field contained in the CTS frame and also defer from accessing the medium. The data is then sent by the source to the destination station, which promptly answers with an ACK frame. By now, other stations which want to access the medium have exhausted their NAV and have detected the medium idle. After waiting the backoff period, they attempt accessing the medium again.

Source RTS Data

Destination SIFS CTS SIFS SIFS ACK

Other NAV (RTS) DIFS Contention Window

NAV (CTS)

Defer access Backoff after defer

Figure 3.5: Exchange of data between two stations, including CSMA/CA and positive acknowledgment.

3.3 Timing Speciﬁcation

The 802.11 standard deﬁnes that the time interval between frames, not accounting for fragmentation, is called the Interframe Space (IFS) [16]. There are several IFS, depending on the

21 nature of the two frames it is separating. Short Interframe Space (SIFS) is the shortest interval between frames, and occurs in between frames that are logically connected to each other (their sequence is expected). The Example of this is the time between a RTS/CTS pair, between a data frame and its corresponding acknowledgment and between fragments of a same data packet. The first two examples are present in figure 3.5. It is defined in [16, section 9.2.10] as a function of several processing and delay times of the MAC and PHY layers according to equation 3.2.

SIF Stime = RxRF Delay + RxP LCP Delay (3.2) +MACP rocessingDelay + RxT xT urnaroundT ime

The definitions for these members are found in [16, section 10.4.3.2] and can be roughly trans- lated into the reception delay of the PHY added to the MAC processing time and the transmission delay on the PHY. When two frames are not logically connected (for example two data frames sent by different stations) the IFS is variable, depending on the coordination function that is being used. The simplest coordination function that a network can use is the Distributed Coordination Function (DCF), which relies on every station to contribute to the management of access to the medium in an equal way. The IFS for the DCF is the DCF Interframe Space (DIFS) [16]. Since the network for which this communication platform is intended, does not have an infrastructure that can act as Access Points (APs), the chosen function is the DCF. Figure 3.6, shows how DIFS is dependent of SIFS. In [16, section 9.3.7] it is defined by equation 3.3.

DIFS

First SIFS Slot Time Slot Time backoff Slot

Medium Busy

Time

Figure 3.6: Timing relations between the diﬀerent IFS values.

DIF Stime = SIF Stime + (2ÖSlotT ime) (3.3)

DIFSTime and SIFSTime correspond to the SIFS and the DIFS, respectively, while SlotTime is the time of each slot of the backoff period. Knowing the relation between these values is not enough, and it is necessary to know what absolute values are expected for each interval. 802.11 defines the required values for all the IFS values as well as SlotTime, depending on the type of PHY of the communications system as well as the channel spacing. The system discussed in this dissertation works with an OFDM PHY with 10 MHz channel spacing, whose IFS and Slot Time values are defined by [16, section 18.4.4] as can be seen in table 3.2. When the medium is idle for the minimum DIFS time, the MAC should start decrementing the backoff time slots in a discreet manner, meaning that only a full slot and not a fraction of it, can be decremented at a time. This means that only if 13 µs have passed after the end of the DIFS, shall there be a decrement in the backoff counter.

22 Characteristic Value SlotTime 13µs SIFSTime 32µs DIFSTime 58µs

Table 3.2: Values of the diﬀerent IFS values and slot time for the OFDM PHY with a channel spacing of 10 MHz, as deﬁned in [16, section 18.4.4]

Taking into account the CSMA/CA protocol methodology and the deﬁned IFS for the OFDM PHY with 10 MHz channel spacing, the minimum radio silence interval that is required for a station to access the medium is:

Minimum ∆t = aDIF ST ime + aSlotT ime = 71µs (3.4) With both functional and timing speciﬁcations known, the implementation of the requirements and functionalities explained in this chapter will be presented.

23 24 Chapter 4

Implementation of the Upper MAC Layer

4.1 Introduction

In this chapter, the details of UMAC implementation will be discussed. Some of the features of the LMAC will also be alluded, but for an in-depth view of the LMAC’s implementation, refer to [7, chapter 4]. As mentioned in section 3.1, both the UMAC and LMAC are located in a FPGA. The UMAC is software in C language and runs on a microprocessor instantiated in the FPGA, while the LMAC is modeled in VHDL and present in the FPGA as a hardware module. Figure 4.1 shows a detailed view of the architecture of the MAC layer inside the FPGA board. The system is composed of:

• A microprocessor running at 50 MHz, where the UMAC runs;

• A Double Data Rate (DDR) Synchronous Dynamic Random-Access Memory (SDRAM), used by the microprocessor during code execution. This SDRAM is a physical circuit, not instantiated as block Random Access Memorys (RAMs) in the FPGA;

• The LMAC, with a set of registers for communication with the UMAC, as well as memory buﬀers to hold arriving and exiting frames;

• An interrupt controller, required due to the microprocessor only having one interrupt en- trance;

• A 32 bit wide bus used to interface the microprocessor with all its peripherals, including the LMAC;

• A system clock;

• A serial interface Recommended Standard 232 (RS232) for communication with the external Personal Computer (PC) where the LLC resides;

• An interface with the digital PHY, located within the FPGA; for further details refer to [7].

25 MAC LMAC Interrupt lines Lower MAC Serial Interrupt interrupt Controller (hardware) e

c µP interrupt line a f r

e Memory t

n Microblaze µP LLC-MAC i

interface a i r e

S Upper MAC (software) Registers

MAC-PHY interface

Figure 4.1: Detailed architecture of the MAC layer of the 802.11p communications platform.

4.2 Software Architecture

As communications can often be infrequent, it makes no sense to have a system polling the events that may occur in the system, so the operation of the UMAC layer is interrupt driven. The microprocessor can only handle one interrupt, since it only has one interrupt input. It is possible to increase the capacity for interrupt handling with the help of the interrupt controller, which keeps a table of several interrupt signals and communicates which interrupt has been activated. This allows for the LMAC to signal the UMAC of diﬀerent events and handle them accordingly, as well as having another interrupt for the serial port in the LLC-MAC interface.

4.2.1 Main Cycle

The UMAC’s general behavior revolves around the handling of the diﬀerent interrupts that occur during the communication events, avoiding all the disadvantages of a polling algorithm. Figure 4.2 shows the main cycle of the UMAC, where each sub cycle of interrupt servicing routines is labeled by numbers.

4.2.2 Reception From the LLC

The llc_rx_interrupt handler is triggered when the UMAC detects bytes at the LLC-MAC interface serial port. After validation of the primitive, the UMAC encapsulates the data received from the LLC to forward it to the LMAC and to request transmission, after calculating the backoﬀ. This request is only performed in the virtual carrier sense is not in a defer access state. The UMAC then reports the result of the transmission to the LLC. Successful transmission triggers the phy_tx_end_interrupt handler, represented by box number 2 in ﬁgure 4.3.

26 System Start Load MAC address initialization Initialize stat counters Initialize buffers

System Idle

Interruption detected

LMAC finished LMAC received Bytes arrived on frame transmission valid frame system countdown LLC-MAC interface to the PHY from PHY finished

countdown_interru llc_rx_interrupt phy_tx_end_int phy_rx_interrupt pt handler handler handler handler

1 2 3 4

Figure 4.2: UMAC’s main software cycle. Interrupt routines are named and labeled by numbers.

4.2.3 End of frame transmission to the PHY

The phy_tx_end_interrupt handler is triggered when the LMAC reports to the UMAC that the transmission of a frame to the PHY layer has finished. Depending on the type and destination address of the frame, the UMAC will then activate the ACK timeout, which is the countdown that the station will wait for the ACK reply from the destination station. If the frame was originated in the LLC, the UMAC will reply with the correct primitive to the LLC (this is the part that overlaps with figure 4.3). This sequence of steps is represented in figure 4.4.

4.2.4 Reception from the PHY

The phy_rx_interrupt handler is triggered when the LMAC signals the UMAC that a frame has arrived from the PHY layer and has passed the FCS veriﬁcation. After extracting the header, the UMAC identiﬁes the destination of the frame and if it is not destined to this MAC, the virtual carrier sense mechanism is activated and the interrupt routine

27 is exited. With a destination consistent with the MAC’s own identity, the UMAC proceeds to branch, depending on the type and subtype of the frame received:

• Management frame – Not yet implemented. Exits routine.

• Control frame:

– ACK – Stops ACK timeout. It will not repeat the transmission of the data frame that originated the ACK countdown. – RTS – First frame of a RTS/CTS handshake mechanism, to which the UMAC replies with a CTS allowing the source station to begin transmission and preventing other stations that were not within the CTS’s range to access the medium. – CTS – Second frame of a RTS/CTS handshake mechanism. The UMAC must verify if it had sent an RTS to the source station. In case the answer is affirmative, the UMAC will calculate the backoff and request transmission to the LMAC. The program flow then overlaps with figure 4.4.

• Data Frame – Broadcasted frames will simply be forwarded to the LLC with the right primitive, while unicast frames will be answered with the corresponding ACK frame and then forwarded to the LLC. This sequence of steps is represented in ﬁgure 4.5.

4.2.5 Countdown expiration

The countdown_interrupt handler is triggered when the LMAC signals that a countdown initiated by the UMAC has been completed. The UMAC must recognize what type of countdown was activated:

• NAV – The countdown of the virtual carrier sense method has reached zero, so the UMAC checks if any frames are queued for transmission. In case there are, the UMAC will calculate the backoﬀ and requests transmission to the LMAC. With the successful transmission of this frame and depending on the type of destination being unicast, the station will activate the ACK timeout. This could lead the software ﬂow to the next branch of this routine.

• ACK timeout – The unicast frame previously transmitted by the UMAC was not replied with an ACK frame, for which a retransmission is necessary. The UMAC will first verify if the transmission retry limit for the frame has been reached. If that is the case, the slot with the original frame will be cleared and if the frame came from the LLC, that layer will be informed of the failure. In case the limit has not been reached, the software flows into the first branch here described, by re-requesting the transmission of the frame to the LMAC.

The sequence of steps here described are represented in ﬁgure 4.6.

28 llc_rx_interrupt handler

Valid primitive? NO

YES

Clear serial port Encapsulate frame buffers

Is NAV YES counting down?

Wait for NAV NO countdown to finish

Request LMAC transmission to PHY

Wait for timeout or phy_tx_end_int handler

Frame transmitted?

NO 2 YES

Generate MA- Generate MA- UNITDATAX- UNITDATAX- STATUS STATUS (failure) (success)

Figure 4.3: Interrupt service routine for the llc_rx_interrupt.

29 phy_tx_end_int handler

Was frame a YES broadcast?

Clear frame slot Was frame data or NO and update stats management? (successful transmitted frames)

YES

Activate ACK timeout

Was frame originated in the LLC?

YES

Generate MA- UNITDATAX- STATUS (success)

Figure 4.4: Interrupt service routine for the phy_tx_end_interrupt.

30 phy_rx_interrupt handler

Header extraction

Frame is NO directed to this station?

YES

Data frame Control Frame Management Frame

Unicast frame? ACK RTS CTS Not implemented Update NAV

NO Answer Stop ACK Was a CTS NO YES timeout with CTS expected?

YES Answer with ACK Request Transmission of Data frame to LMAC

Generate MA- UNITDATAX. indication 2 Wait for phy_tx_end_int handler

Activate ACK timeout

Figure 4.5: Interrupt service routine for the phy_rx_interrupt.

31 countdown_interrupt handler

Countdown type

NAV ACK timeout

Is there a Update failed frame queued NO transmission stats for Tx?

YES

Request maximum number Transmission of NO of retries reached? frame to LMAC

2 YES Wait for phy_tx_end_int handler Clear frame slot

2 Frame is NO broadcast? Was frame originated in LLC?

Activate ACK Generate MA- YES timeout UNITDATAX- STATUS (failure) NO

Figure 4.6: Interrupt service routine for the countdown_interrupt.

32 4.3 Layer Interfaces

As represented in figure 3.1, the UMAC has interfaces with the LLC and the LMAC. The interface with the LLC is defined by the 802.11 standard, while the interface with the LMAC is defined in-house, since the division of the MAC layer into its two sublayers was an implementation decision not defined in the standards.

4.3.1 MAC-LLC Interface

The interface between the UMAC and the LLC was implemented as a serial RS232 port working with a baud rate of 115200 bps. On the MAC side, it is a Xilinx Uartlite module instantiated in the FPGA, connected to a physical DB9 connector on the 802.11p platform’s motherboard. On the LLC side it is a RS232 port in the PC that houses the LLC. Transmitting a stream of bytes through a serial connection that only has TX and RX signals raises the issue of distinguishing when a frame starts and when it ends. To overcome that problem, a set of flag bytes used to delimit the start and end of a frame were specified. Since the contents of each frame can include any byte value, to distinguish these flags from normal bytes of data, byte stuffing was implemented. A byte value was defined as an escape character and it must precede a byte whenever one of the following situations arise:

• A start or end ﬂag appears in the data. This can be seen in ﬁgure 4.7.

• The escape character itself appears in the data.

Byte stuﬃng introduzes some overhead, but it guarantees that the frames delimitations will be properly identiﬁed.

octets 1 1 X 1 1

Escape Start Escape End frame byte Flag byte Flag

Figure 4.7: Usage of the escape byte to signal the start and end ﬂag

The interface as specified in subsection 3.2.1, requires the exchange of standard defined primitives and their parameters, which are listed in table 3.1. Figure 4.8 shows the structure of the frame, which consists of the following fields:

• Start bytes - These two bytes identify the beggining of a frame; they are the escape byte and the start ﬂag.

• Type and a subtype - They represent what kind of primitive is being exchanged.

• The body of the primitive - These are the parameters of the primitive.

• End bytes - These two bytes identify the end of a frame; they are the escape byte and the end ﬂag.

The type and subtype ﬁelds codify what primitive is being transmitted and they are deﬁned in table 4.1. Because future work might lead to the implementation of further primitives covered by the standard, some values are reserved for future expansion.

33 2 1 1 X 2

Start Bytes Type Subtype Primitive End Bytes

6 6 1 1 X

Service REQUEST Source address Destination address Priority Data Class

6 6 1 1 1 X

Service RX INDICATION Source address Destination address Priority Data Class status

6 6 1 1 1 Provided Provided CONFIRM Source address Destination address Service TX status Priority Class

Figure 4.8: Frame format for the codiﬁcation of the LLC-MAC data exchange primitives

Type value Type name Subtype Value Subtype name 0x00 request 0x00 MA-UNITDATA 0x01 conﬁrm 0x02 indication 0x00 request 0x01 MA-UNITDATAX 0x01 conﬁrm 0x02 indication 0x02-0x1A Reserved

Table 4.1: Encoding of the type and subtype frame ﬁelds.

4.3.2 UMAC/LMAC Interface

Communication between the UMAC and the LMAC is achieved through a set of control and status registers, visible in ﬁgure 4.1, to which both the LMAC and the UMAC have access. Control registers allow the UMAC to request actions to the LMAC and control certain aspects of it. Through these registers, the UMAC is able to:

• Request a memory slot, to build a frame for transmission;

• Release a memory slot, previously requested;

• Order the transmission of a frame contained in a slot, by transmitting it to the PHY;

• Cancel a pending transmission;

• Adjust the value of the system clock;

• Change the dividing factor of the system clock, eﬀectively accelerating or delaying its ca- dence;

• Enabling periodic interrupts, activated by the system timer.

34 Status registers are provided by the LMAC, so that the UMAC can monitor several aspects of the system, more speciﬁcally: • Obtain the transmission status of a frame;

• Get the slot number of the last transmitted frame to the PHY;

• Verify the state of the memory (how many slots are free and how many are occupied);

• Get size and position information about a frame in a speciﬁc slot;

• Read the timestamp of a frame contained in a speciﬁc slot;

• Get the slot number of the ﬁrst frame received from the PHY;

• Obtain the current value of the system clock; Besides these sets of registers, the UMAC is also able to read and write into the memory slots reserved by the LMAC for MAC frames. The implementation of these registers is the scope of the dissertation focusing on the LMAC (refer to [7]), so it will not be discussed in this document. On the side of the UMAC, the registers are accessible to both reading and writing directly on the memory. To simplify the programming and the readability of the code, a set of programming macros which mask the access to the memory addresses were implemented. Their names, parameters and a short description of respective functions is in Annex A.

4.4 Development Platform

The development platform for this project consists of a hardware kit, containing the FPGA and its peripherals, and a set of software development tools, provided by the FPGA manufacturer. The code is written and compiled in the development tools and then loaded onto the FPGA where it is executed.

4.4.1 Hardware Kit

The development of the MAC layer lasted a period of several months, during which the progress of work generated an increase in memory requirements, which led to the upgrade of the FPGA development board. There were three upgrade stages:

• First stage development board: Nexys-2 500 from Digilent, containing a Spartan 3E-500 FPGA. This was the preliminar stage of the development process, where the PHY layer was still not present, being emulated by a serial connection.

• Second stage development board: Trenz Spartan-3E FPGA Industrial Micromodule, containing a Spartan 3E-1600 FPGA. Most of the development was done during this stage. UMAC, LMAC and PHY were present, although the UMAC software had to be run from the external RAM due to lack of resources in the FPGA.

• Third stage development board: Trenz Spartan-6 FPGA Industrial Micromodule, containing a Xilinx Spartan-6 XC6SLX45 FPGA. This was the ﬁnal upgrade. It held enough resources to instantiate the block RAMs that held the UMAC software.

35 The first board was a Nexys-2 500 from Digilent, which held a Spartan 3E-500 FPGA, as well as an Intel Strataflash memory and a Micron Pseudo Static RAM (PSDRAM). During the progression of the MAC layer’s development, this board proved to be insufficient to hold LMAC, UMAC and PHY. Despite several attempts to solve the problem by saving the software in the flash memory and at execution time, loading it in bulk into the SDRAM, this solution proved to be unpractical due to the long uploading times of the UMAC into the system. The second development board was the Trenz Spartan-3E FPGA Industrial Micromodule, seen in figure 4.9. This development board contains a Xilinx Spartan-3E XC3S1600E FPGA, 32 Mbit Serial Peripheral Interface (SPI) Flash memory, a 512 Mbit DDR SDRAM and a multitude of General Purpose Input Outputs (GPIOs). This FPGA has approximately triple amount of resources of the Spartan 3E-500, although it still belongs to the same family of products. In figure 4.9 it is visible that this development board has some degree of miniaturization and does not supply in an easily accessible way, all the interfaces present in the board. The I/Os are provided through two high density Board-to-Board (B2B) connectors, visible in the underside of the board and are used to connect to the motherboard developed for the 802.11p communications platform, which also contains the RF module (analogue PHY) and the GPRS modem, as seen in figure 4.10. As work developed, PHY and MAC layer functionalities were progressively added to the system, forcing the UMAC software to be run from the external RAM provided in the Trenz micromodule, instead of having it in block RAMs instantiated in the FPGA itself. The limitations of this FPGA were apparent, so a more powerful FPGA with more resources, was needed. The third development board adopted was the Trenz Spartan-6 FPGA Industrial Micromodule, containing a Xilinx Spartan-6 XC6SLX45 FPGA. This board was developed by Trenz to be pin compatible with the Spartan-3E model, simplifying the upgrade. The Spartan-6 FPGA has four times the resources of the Spartan-3E 1600, allowing for the UMAC software to be run from instantiated block RAMs. All of these platforms had FPGAs manufactured by Xilinx, making the software for the micro- processors compatible, with little need for any alterations. More information on the GPRS modem and its purpose can be found in Annex B.

36 Top side Under side

FPGA Two B2B connectors

DDR Flash SDRAM Memory

Figure 4.9: Trenz Spartan-3E FPGA Industrial Micromodule.

GPRS Module (w/ GPS)

RF Module r e y a L

P P A

k r

o Trenz Spartan w

t 3E FPGA e

N Industrial Micromodule

Figure 4.10: 802.11p communications platform motherboard, with the FPGA, RF module (analogue PHY) and GPRS modem.

37 4.4.2 Development Tools

Both development boards come with a set of development tools provided by Xilinx, which allow and facilitate the development of both hardware and software. The Xilinx Platform Studio (XPS) was used for the set up of the communications system that resides in the FPGA, including the microprocessor, the interrupt controller, the LMAC and any other hardware modules. It allows for a streamlined arrangement and connection of all the VHDL modules developed in-house, or provided in existent libraries. When the system is set up, the XPS generates the bitstream to be loaded on to the FPGA. The Xilinx SDK was the programming environment used to develop the UMAC. It facilitates syntax recognition, compilation, organization and debugging of the software in C that runs in the microprocessor. It also allows for programming of the Flash memory present in the development board. The Xilinx Integrated Software Environment (ISE) Project Navigator was the platform used to develop the VHDL modules, namely the LMAC and Digital PHY. These are then available as connectable blocks which can be attached to the system in the XPS environment.

4.5 Project Structure

The software project has the structure seen in ﬁgure 4.11. The main cycle of the UMAC layer is in the ﬁle upper_mac.c. The elements seen in the tree structure are the following:

• headway_bsp - This is the Board Support Package (BSP) for the hardware provided by the FPGA manufacturer. It is a set of drivers with which the programmer can access the functionalities of the hardware blocks made by Xilinx, such as the microprocessor or the interrupt controller.

• hw_platform_0 - It is the synthetised hardware, comprising the user and provided cores as assembled in the XPS. They are the basis for the system where the software will execute.

• UMAC_2.1 is the folder with the software containing the UMAC. It has several subfolders:

– Binaries – Includes - C Include ﬁles for basic operations (printing, memory manipulation, simple math functions) – Debug - Contains the executables as compiled in Debug mode. – Release - Contains the executables as compiled in Release mode. – src - Folder with the source code for the UMAC. ∗ 802MLME.c/h - Database that contains several important characteristics of the MAC layer, like the MAC address, communications statistics as well as behavioral control variables. ∗ 802PLME.c/h - Database that contains several important characteristics of the PHY layer, like the physical characteristics of the PHY. ∗ debug_tools.c/h - Printing tools, for faster debug. ∗ llc_frame_processing.c/h - Contains the functions that deal with the processing of frames exchanged between MAC and LLC, including encapsulation and decoding.

38 ∗ llc_rx.c/h - Functions that deal with the reception of data from the LLC, in a raw data perspective (interrupts and handlers). ∗ lower_mac.h - Set of macros that perform the operations on the LMAC, as described in subsection 4.3.2. ∗ mac_types.h - Commonly used types in the UMAC, namely mac address struc- tures, and waiting queues. ∗ NET_mac_types.h - Constants mainly related to LLC primitives sizes and also the sizes of each ﬁeld. ∗ phy_rx.c/h - Functions that deal with the reception of data from the PHY. In- cludes interrupt handlers as well as frame decoding and processing. ∗ phy_tx.c/h - Functions that deal with the transmission of frames to the PHY, including clean up routines and communication with the LMAC ∗ tools.c/h - Byte inversion tools, for correct construction of MAC frame ﬁelds. Also contains MAC address construction tools. ∗ upper_mac.c/h - Contains the main body of the UMAC software. ∗ lscript.ld - script for the linkage stage.

39 Figure 4.11: Software project tree view.

40 4.6 Project Compilation and Execution

Since the project to be loaded into the FPGA is composed of hardware and software components, these must be combined before loading. Figure 4.12 shows the compile, link and combining stages of the process.

Hardware Flow Software Flow

Source Code (C Code) MSS File System.mss

FPGA Compile Driver MDD Programming Files (system.bit LibGen Object Files Library MLD Files

Link Libraries

Data2Mem Executable (.elf)

Download.bit Hardware

Figure 4.12: Compile and execution ﬂow for the Xilinx EDK.

The C source code is compiled much like in a normal C program, where the SDK uses the gcc compiler to create the object files. Next is the linker stage, where the SDK LibGen gathers the Microprocessor Software Specification (MSS), Microprocessor Driver Definition (MDD) and Microprocessor Library Definition (MLD) files and links them with the object files. The MSS file defines the drivers associated with peripherals, standard input/output devices, interrupt handler routines, and other related software features. The MDD file contains directives for customizing software drivers; the MLD file contains directives for customizing software libraries, generating the BSP for the operating system. The result of the linkage is an executable file .elf which is then combined with the hardware files synthetised in the XPS into the bitstream download.bit that will be loaded into the FPGA. The SDK provides the user with a linker script generator, which results in the lscript.ld file. This file defines where the software will be run from. The possibilities are any of the memories

41 instantiated in the FPGA or the external RAM. Figure 4.13 shows the window where the linker script settings are deﬁned. In this particular example, the code is placed in a block RAM instantiated in the FPGA with a heap and a stack of 1 KBytes, but several other options can be seen on the left column, such as the external RAM and even the Flash memory.

Figure 4.13: Linker script generation window.

In the SDK, the user can order the programming of the FPGA, as well as the execution of the .elf file, through a Joint Test Action Group (JTAG) programmer cable, of which an example can be seen in figure 4.14. One end is connected to the Universal Serial Bus (USB) port of the computer running the SDK and the other to the programming port of the communications platform, seen in figure 4.10 directly adjacent to the top left of the FPGA micromodule. The JTAG is vital during the development stages, for control and interaction with the device, not only to program the FPGA as well as providing a debug channel connected to the SDK. When the development stage finishes, the JTAG cable is no longer necessary, as any communications between the communications platform and the applications is done through the serial interface.

Figure 4.14: JTAG programmer cable for the FPGA.

This completes the description of how the UMAC was implemented. The next chapter will describe the validation process and the evaluation of the UMAC performance.

42 Chapter 5

Validation

5.1 Introduction

In this chapter the UMAC will be validated, to evaluate if its behavior ﬁts with the demands of the standard it proposes to comply with. The validation of the platform has been divided into two diﬀerent categories and subcategories:

• Functional validation - The logical behavior of the UMAC.

– Frame format - Correct construction and decoding of MAC frames. – Frame sequence exchanges - Dialog between stations follows the 802.11 standard.

• Timing validation - The timing behavior of the UMAC.

– SIFS - Complies with the demanded SIFS – Virtual Carrier Sense - NAV is obeyed. – Physical Carrier Sense - The Physical Carrier Sense is respected.

The tests used to validate these aspects of the communications platform, were only made starting from the second stage of the development platform (Spartan-3E 1600), which are indicated in subsection 4.4.1. Most tests described in this chapter were made during this stage, but during the writing of this dissertation the third stage of the development board was introduced (Spartan- 6). This allowed for a comparison with the previous stage’s results. Mentioned in each test is the development platform which was used to obtain the results.

5.2 Functional Validation

In the functional validation, the operation of the MAC layer at the logical level is evaluated. The testing procedure will verify if the MAC layer follows the correct behavior according to its current state.

5.2.1 Frame Format

During transmission, there is an assessment of the construction of the frames and the cor- rectness of their format, as well as the error check FCS. In reception the decoding of the FCS,

43 extraction and interpretation of the MAC header must yield a correct result, as well as the corresponding behavior that follows. To be noted is the fact that FCS validation enters the scope of the LMAC, but it is an important part of the frame validation process that cannot be tested separately from the rest.

Setup

To test the validity of the format of frames, an independent device must be able to receive and correctly identify frames broadcasted by the device developed in this project. Such a device should be able to work in the 5.9 GHz DSRC band and comply to the 802.11p standard in relation to the PHY characteristics. A third party 5.9 GHz DSRC sniffer device certified by the OmniAir Consortium [35], developed by Sirit Inc. [36], was purchased for this purpose. Sirit is a company specialized in the designing and manufacturing of Radio Frequency Identification (RFID) technology for applications related with vehicle networks. The OmniAir Consortium is the leading The OmniAir Consortium is an entity whose goal is to enable connected vehicle interoperability. The Sirit DSRC sniffer is a purely listening device, meaning that it is only able to receive frames and present them in a readable fashion. It is unable to reply or produce frames of its own, so it is not adequate for the testing of expected frame sequences or any timing issues. It is connected to a laptop through a Personal Computer Memory Card International Association (PCMCIA) slot and comes with software for display and recording of frames captured. The testing setup for the validation of the format of the frames transmitted, consisted of the 802.11p communications platform containing the second stage development board discussed in this document and a laptop with the Sirit sniffer. Figure 5.1 shows a schematic of the setup.

Broadcast of MAC frames

802.11p communications Sirit DSRC Sniffer platform

Figure 5.1: Setup for the validation test on frame format.

Tests and Results

The test performed was the broadcast of the following types of frames, four times each:

• Data;

44 • ACK;

• CTS;

• RTS;

In figure 5.2 there is a screenshot of the capture done in this test. In it the sniffer was able to catch the data frames without problem, but there was no capture of any of the other frames. The fact that the data frames were captured inherently validates the FCS calculation and the way the frame fields are assembled. After some tweaking with the experiment, it was concluded that the sniffer had a bug that prevents it from capturing frames that have a shorter length than the general format, as is the case of ACK, CTS and RTS. By transmitting wrongly formatted ACK, CTS and RTS frames (with more fields that the standard defines for them) the sniffer was able to capture them, confirming the buggy behavior already admitted by the manufacturer in an email exchange.

Figure 5.2: Sniﬀer capture of four data frames.

5.2.2 Frame Sequence Exchanges

The UMAC must behave as the 802.11 standard dictates, when it comes to the sequence of frames expected to be exchanged between several communicating stations

45 Setup

As previously mentioned, the sniffer is a listening device, with no ability to generate his own frames, effectively preventing it from being able to do an exchange of frames with other stations. It is therefore necessary to use a method of validation of frame sequence exchanges that does not require the sniffer. With the frame formats and the FCS calculation validated, two 802.11p communications platform with the second stage development board developed in this project are enough to validate the frame sequence exchanges, as depicted in figure 5.3.

Exchange of MAC frames

802.11p 802.11p communications communications platform platform

Figure 5.3: Setup for the validation test of frame sequence exchanges.

Tests and Results

The frame sequences to be tested were the ones necessary to implement the positive acknowledgment of unicast transmission of data frames, as well as the exchange used to implement the virtual Carrier Sense mechanism. The two sequences are:

• RTS frame, replied with CTS frame;

• Data frame, replied with ACK frame;

All sequences were exchanged has expected, with unicast data frames always getting a positive acknowledgment, and RTS receiving a CTS in response. Figure 5.4 shows a representation of the two stations and their terminal outputs during this test.

5.3 Timing Validation

For the timing validation, the duration of the execution of the diﬀerent frame exchanges, as well as the times involved in the medium access protocol (CSMA/CA), were tested. The standard deﬁnes a set of values that a 802.11p compliant MAC layer must follow, which have already been presented in section 3.3. The validation of the timing characteristics requires involvement of the

46 Station 1 Station 2

Terminal output: Terminal output:

START START This is the test application for station This is the test application for station 00:D5:B3:00:00:40 00:D5:B3:00:00:80 Sending Request To Send frame to 00:D5:B3:00:00:80 Received Request To Send frame from Clear To Send received from 00:D5:B3:00:00:80 00:D5:B3:00:00:40 Data transmission allowed. Sending data frame to Sending Clear To Send frame to 00:D5:B3:00:00:40 00:D5:B3:00:00:80 Received Data frame from 00:D5:B3:00:00:40 Frame sent. Starting ACK timeout. Data frame destination is this station. ACK received from 00:D5:B3:00:00:80 Sending ACK to 00:D5:B3:00:00:40 ACK timeout stopped.

Figure 5.4: Terminal outputs of the two stations exchanging the frame sequences.

LMAC layer, since the set of values deﬁned by the standard are for operation of the MAC layer as a whole. Consequently, parts of this validation involve entering the scope of [7] for testing purposes.

5.3.1 SIFS

The SIFS is an important validation aspect, since it is the shortest reaction interval a station must be able to comply with.

Setup

The setup for this test is the same as the one represented in ﬁgure 5.3. This test was then repeated with the third stage of the development board.

Tests and Results

To obtain the SIFS, it is necessary to measure the time between the arrival of the last byte of a Data frame at the radio interface and the transmission to the medium of the first byte of the corresponding ACK response, as is represented in figure 3.5. SIFS will be the difference between these two values. It is not possible to measure SIFS solely in the MAC layer, since the delay imposed by the PHY on the reception of the Data frame and on the transmission of the ACK frame must also be taken into account for the SIFS. So for a true value of SIFS, the difference between the arrival and transmission must be measured on the MAC and then added to the PHY delays, as represented in figure 5.5. In the development of the LMAC, the registration of the MAC process time was taken in mind, so it provides (solely for testing purposes and not described in Annex A) several registers

47 Station 1 Data

SIFS Station 2 PHY RX delay MAC process time PHY TX delay ACK

Figure 5.5: Contributing layer times for the SIFS. Times are not to scale. accessible by the UMAC where the relevant time values are kept. The PHY delays for the second stage development board were obtained as followed:

• Reception delay measurements were simulated as the diﬀerence between the instants of arrival of the last symbol and of the delivery of the last byte at the PHY-LMAC interface. The value measured was approximately 15 µs.

• Transmission delay was measured with an oscilloscope, as the difference between the instants of request for transmission by the LMAC and of the conversion of the first byte in to baseband. This measurement is seen in figure 5.6 to be 10.6 µs.

Figure 5.6: Measured PHY transmission delay. Channel 1 represents the LMAC request and Channel 2 is the baseband signal.

The PHY delays for the third stage development board were measured in the same way and yelded the same results.

48 The experiment consisted in the transmission by Station 1 of ten data frames, which in turn are received and replied with ACK frames by Station 2. The time values are registered in Station 2 and consist of the number of microseconds since the station was activated until the instant being measured. Results for the second stage development board are visible in table 5.1, while for the third stage development board are in table 5.2.

Test # Time of last Data Time of ﬁrst ACK MAC process time(mus) byte received (hex µs) byte sent (hex µs) 1 0x0000000000167C23 0x0000000000167D19 246 2 0x00000000001B0B5D 0x00000000001B0C53 246 3 0x0000000000223A98 0x0000000000223B8F 247 4 0x0000000000228E28 0x0000000000228F1E 246 5 0x000000000027806E 0x0000000000278164 246 6 0x00000000003C7EF1 0x00000000003C7FE7 246 7 0x00000000003FF853 0x00000000003FF949 246 8 0x0000000000529CCF 0x0000000000529DC6 247 9 0x00000000007DBE30 0x00000000007DBF27 247 10 0x0000000000B48D1A 0x0000000000B48E10 246 Average 246,3

Table 5.1: Results for the MAC process time component of SIFS on the second stage development platform.

Test # Time of last Data Time of ﬁrst ACK MAC process time(mus) byte received (hex µs) byte sent (hex µs) 1 0x0000000000321423 0x0000000000321459 54 2 0x0000000000350343 0x0000000000350378 53 3 0x0000000000394A12 0x0000000000394A48 54 4 0x0000000000441E16 0x0000000000441E4C 54 5 0x000000000049007F 0x00000000004900B5 54 6 0x00000000004DAEF3 0x00000000004DAF29 54 7 0x00000000004FF828 0x00000000004FF85D 53 8 0x000000000052AB4F 0x000000000052AB85 54 9 0x00000000006F2340 0x00000000006F2366 54 10 0x0000000000728D44 0x0000000000728D7A 54 Average 53,8

Table 5.2: Results for the MAC process time component of SIFS on the third stage development platform.

SIFS can now be calculated with the values obtained, as described in equation 5.1 for the second stage development platform and equation 5.2 for the third stage development platform.

SIFS = P HY RXdelay + MACprocesstime + P HY T Xdelay u 272µs (5.1)

SIFS = P HY RXdelay + MACprocesstime + P HY T Xdelay u 79µs (5.2)

49 5.3.2 Virtual Carrier Sense

The Virtual Carrier Sense, as part of the CSMA/CA mechanism, is an important part of the medium access control of a station.

Setup

The setup for this validation test is the same as the one represented in ﬁgure 5.3, with both platforms containing the second stage development board.

Tests and Results

The virtual carrier sense relies on the correct implementation of the NAV timer, so it is necessary to verify if the NAV mechanism is causing the station to defer access to the medium in the right instant and for the right duration. As in the previous test the LMAC provides information to the UMAC about the following instants:

• Arrival of the last byte of a frame.

• Expiration of the NAV countdown.

By measuring the time difference between the arrival of a frame not directed to the station and the time when the NAV countdown ends, it is possible to verify how long the station deferred access to the medium. Comparison of this value with the one contained in the Duration field of the frame received, yields the difference to the expected value. The experiment consisted of Station 1 transmitting a set of frames, not directed at Station 2 (to activate the virtual carrier sense method) with progressively increasing Duration fields. The time values are registered in Station 2 and consist of the number of microseconds since the station was activated until the instant being measured. Results can be seen in table 5.3.

Frame duration Time of last Time of NAV NAV deferral Diﬀerence ﬁeld Data byte expiration time (µs) to expected received (hex µs) (hex µs) time (µs) 255 0x0004A3064 0x0004A3252 494 239 2047 0x0002AACE3 0x0002AB5D1 2286 239 4095 0x0003D3229 0x0003D4317 4334 239 8191 0x0023B27A3 0x0023B4891 8430 239 16383 0x000586167 0x00058A254 16621 238 32767 0x0006C2EE0 0x0006CAFCE 33006 239 65535 0x000307876 0x000317964 65774 239

Table 5.3: Results for the Virtual Carrier Sense tests.

5.3.3 Physical Carrier Sense

The validation test covered in this sub-chapter has a particularity as an important part of them encompass the scope of the LMAC. The physical carrier sense method is almost completely implemented in the LMAC, except for the backoﬀ calculation which is done by the UMAC. Although

50 this would mean that it would fall under the scope of [7], not only was it implemented after the completion of that dissertation but it is also needed to validate the global CSMA/CA mechanism. As previously mentioned, the CSMA/CA mechanism has two carrier sense methods, physical and virtual, with each method falling under the responsibility of a diﬀerent MAC sublayer.

Setup

The setup for this validation test is the same as the one represented in ﬁgure 5.3, although the behavior of each station is not the same as in the previous tests. Both platforms contain the second stage development board.

Tests and Results

To evaluate how the physical carrier sense method performs, a test was developed to ﬁnd the shortest idle interval in which the station manages to gain access to the medium. As explained in section 3.3, the minimum idle interval the station needs to be able to access the medium is 71 µs. To verify if the station can comply to this value, the medium must be occupied in a predictable manner, with precise control over the lengths of the idle intervals. The experiment consists of two devices performing diﬀerent roles:

• Station 2 has a working MAC layer that follows the CSMA/CA protocol with physical carrier sense to access the medium. Virtual Carrier Sense is deactivated for this experiment.

• Station 1 is a repeating device that does not respect the rules of medium access, and whose only purpose is to occupy the wireless medium in a cyclic manner, with alternating intervals of transmission followed by periods of idleness.

With Station 1 occupying the medium as represented in ﬁgure 5.7, Station 2 attempts to transmit 50 data frames, while complying with the CSMA/CA protocol with physical carrier sense. The experience times out after 30 seconds and the amount of frames that Station 2 was able to transmit (by being able to access the medium) is veriﬁed. The experiment is repeated ten times and the average of packets transmitted is calculated. The period of silence from Station 1 is then increased, and consequently the medium idle interval and the experiment is done again. This is repeated until Station 2 succeeds in transmitting all the 50 frames.

Station 1 transmission transmission transmission (medium occupier)

Medium Medium Medium busy Medium busy Time idle idle

Station Station Station 2 Station defers attemps Station defers attemps Station defers (transmitter) access access access access access

Time

Figure 5.7: Experiment procedure with two stations. The medium idle interval is increased with each iteration of the experiment.

51 Since Station 1 does not comply with any medium access rules, nothing prevents it from interfering with the transmission of frames of Station 2 after the latter has already gained medium access, which rules out the usage of the Sniffer as means of confirming transmission by Station 2. It is important to note that the Sniffer wouldn’t have been suitable to measure the successful transmissions even if Station 1 respected the medium access rules, since it was discovered that it is unable to record more than a few frames per second. Results of this experiment are represented in table 5.4. Until the 75 µs interval mark, Station 2 has very low success in transmitting the 50 frames in the allotted time. From this value onward, the transmission rate is 100%. With these functional and timing results, it is possible to move on to the next chapter, where conclusions will be drawn and future work will be proposed.

Idle interval (µs) 49 53 55 59 62 67 70 72 72,5 73 75 80 Average transmission 0 0 0 0 0 0 0 0,4 1,2 1,2 100 100 rate (%)

Table 5.4: Average packet transmission success rates for the diﬀerent idle intervals.

52 Chapter 6

Conclusion and Future Work

6.1 Final Remarks and Conclusions

The speciﬁcation and development of a functional UMAC, as part of a larger communications platform capable of exchanging messages with others like it was achieved. In terms of logical behavior, the UMAC proved to be compliant with the standard, being able to encode and decode 802.11 frames, as well as establishing the correct frame exchanges with other equipments. Timing aspects were not ﬂawless, and although the medium access mechanism does not seem to be in danger of allowing too many collisions, the UMAC simply does not perform as fast as desired. The issues raised can have several solutions. In this chapter the conclusions and future work will be discussed in detail.

6.1.1 Functional Behavior

The functional validation of the UMAC was successful, as the following points were proved:

• The construction of frames with the correct format, as conﬁrmed by the third party sniﬀer, despite the limitations of this device.

• The exchange of frames, with the expected sequences being exchanged between two stations.

• Station addressing and recognition of distinct addresses.

It can be concluded that the UMAC performs as expected when it comes to logical behavior and the format of communications.

6.1.2 Timing Behavior

Timing validation of the UMAC, was not so successful as the functional validation. In order to present the conclusions in a logic manner, the successful timing validation of the physical carrier sense will be discussed ﬁrst.

Physical Carrier Sense

The physical carrier sense mechanism was successfully validated. The standard deﬁnes a 71 µs window of no communications as the minimum required for a station to access the medium.

53 Tests have shown that this implementation can access the medium after approximately 75 µs, which entails a 4 µs error, or approximately 5%. The implementation follows the standard and it is my belief that no alterations have to be done to this speciﬁc aspect of it.

SIFS

Results varied greatly between the second and third stage development boards. At approximately 272 µs, the SIFS time for the platform with the Spartan-3E 1600 was an order of magnitude higher than the 32 µs specified by the standard. The results for the SIFS time on the Spartan-6 were approximately 79 µs, almost three times what the standard specifies. The SIFS time is a contribution of several times resultant of delays and processing times of the PHY and MAC layers, as explained in section 3.3 and subsection 5.3.1. The standard defines values for the MAC processing and PHY transmission delay components, but leaves the reception delay of the PHY implementation dependent as long as the SIFS value respects the expected 32 µs, as can be seen in table 6.1. This means that it is safe to say that in the tests performed, the MAC processing delay was the biggest contributor to the SIFS not complying with the standard.

Deﬁned by the standard (µs) Obtained (µs) RxRFDelay (PHY) Implementation dependent 15 µs RxPLCPDelay (PHY) Implementation dependent MACProcessingDelay (MAC) 2 247 RxTxTurnaroundTime (PHY) 2 10 SIFS (Spartan 3E-1600) 32 272 SIFS (Spartan 6E) 32 79

Table 6.1: Standard deﬁned times versus obtained results for the SIFS validation tests.

It is clear that the implementation of the UMAC cannot comply with the times required by the standard and so the reasons for it must be found in order to present a solution. It is my opinion that the speed of execution of instructions running in the microprocessor is unacceptably slow. On the Spartan-3E 1600 a small conﬁrmation test using the LMAC timer functions provided to the UMAC, showed that each C instruction has an average duration of 4 µs. C, being a middle to high level language can have a wide amplitude of duration for each instruction, but the 4 µs average is too large to be ignored as a statistical oddity. This means that all the UMAC functionalities are prone to be too slow to follow the standard’s speciﬁcations and so the sublayer must be responsible for the functionalities that don’t have any time criticality.

Virtual Carrier Sense

Virtual carrier sense validation showed the same timing problems as before. Test values varied in a great degree from the expected results, but always with the same error of 239 µs. These results seem to point to the same problem discussed in 7.2.2. The whole process of virtual carrier sense is divided between both sublayers, and by analyzing the results of the two previous validations, it is inferred that the UMAC is causing the 239 µs delay. The fact that the NAV value measured is always proportional to the Duration ﬁeld value, but with a constant absolute error, also points in this direction, since the amount of instructions executed by the UMAC for each frame is always the same. Due to lack of time, results for this parameter were not obtained with the Spartan-6.

54 6.2 Future work

With functional validation successful, work must be oriented towards the resolution of the several timing problems found. In order to achieve inter-operability with other devices, it is imperious to comply with the standard timing demands. By solving these issues related to standard compliance, the implementation of further features in the communication platform can be proposed.

6.2.1 Solving issues

The main conclusion obtained from the results is that the UMAC is the element of the communication platform with more negative inﬂuence in the timing issues. Several solutions to this problem can be presented.

Microprocessor Working Frequency

The microprocessor currently works at 50 MHz, but has the ability to work in frequencies up to 100 MHz. The duration of instructions could go down to as much as half of the current duration, although this could not be the case since the system works with some level of caching. This gain would not be enough to solve the problem, since the error being introduced is higher than just 100%, but it could be a ﬁrst step into the improvement of performance.

Migration of Functionalities to the LMAC

Migration of all functionalities that are time critical to the LMAC, could solve the timing issues. The validations done in [7] as well as the physical carrier validation show that the LMAC is able to comply with the demands of 802.11, so it would be fair to conclude that it could handle the functionalities currently implemented in the UMAC while complying to the standard. This would be a work heavy solution, since development of VHDL is a slow process and would bring the whole project several steps back. Also, the reason for the existence of the UMAC would have to change, since most of the functionalities currently implemented have an inﬂuence in the timing issues of the station. The UMAC would have to be relegated to functions of management of the station’s database, which has not been explored as of the writing of this dissertation.

Upgrade of the MAC Development Board

As discussed in subsection 4.4.1, the Spartan-3E 1600 development board used for this project has limitations. The FPGA does not have enough capacity to instantiate block RAMs in it, so the has to use the DDR SDRAM provided as a physical circuit and accessible through a XCL bus. This induces delays in the execution of code kept in the external RAM memory that could be increased by having the block RAMs in the FPGA. The amount of time gained is hard to deﬁne and wouldn’t consist of more than mere speculations, but the fact that it would improve performance is undeniable. With the upgrade of the development board to a Spartan-6 FPGA the whole project could be instantiated and still leave space for the block RAMs. Results show a great improve in the MAC processing time component of the SIFS, which conﬁrms that the communication with the external RAM was contributing greatly to the delay observed.

55 With these results in mind, it is reasonable to assume that further upgrade of the development board, could lead to an increase in performance. Nevertheless, the solutions proposed in subsection 6.2.1 and subsection 6.2.1 should not be neglected.

6.2.2 Adding Further Functionalities

The functionalities implemented in this project in terms of the MAC layer basically implement a 802.11 platform (although the PHY is already 802.11p compliant), since the 802.11p features are not present yet. These functionalities, like multi-channel coordination and Time Synchronization frames, are strongly dependent of the timing behavior of the platform and so have to be postponed until the timing issues indentiﬁed have been resolved. Their implementation opens several avenues of work and is the ﬁnal goal in implementing a fully compliant 802.11p communication platform.

56 Bibliography

[1] Dragos Serban. Concerning fact: World vehicle count tops 1 billion. http://www.autoevolution.com/news/ concerning-fact-world-vehicle-count-tops-1-billion-38106.html, August 2011. [2] Gregory S. Bickel. Inter/intra-vehicle wireless communication. http://www1.cse.wustl. edu/~jain/cse574-06/ftp/vehicular_wireless/, August 2011. [3] G. Karagiannis, O. Altintas, E. Ekici, G. Heijenk, B. Jarupan, K. Lin, and T. Weil. Vehicular networking: A survey and tutorial on requirements, architectures, challenges, standards and solutions. Communications Surveys Tutorials, IEEE, 13(4):584 –616, quarter 2011. [4] T.L. Willke, P. Tientrakool, and N.F. Maxemchuk. A survey of inter-vehicle communication protocols and their applications. Communications Surveys Tutorials, IEEE, 11(2):3 –20, quarter 2009. [5] R. Uzcategui and G. Acosta-Marum. Wave: A tutorial. Communications Magazine, IEEE, 47(5):126 –133, may 2009. [6] Headway project. www.brisainovacao.pt/en/innovation/projects/headway, June 2012. [7] Manuel Ventura. Co-projecto em fpga da mac ieee 802.11p para comunicações veiculares, 2011. [8] R. Schubert, M. Schlingelhof, H. Cramer, and G. Wanielik. Accurate positioning for vehicular safety applications - the safespot approach. In Vehicular Technology Conference, 2007. VTC2007-Spring. IEEE 65th, pages 2506 –2510, april 2007. [9] Cooperative intersection collision avoidance systems (cicas). http://www.its.dot.gov/ cicas/index.htm, June 2012. [10] Coopers project. http://www.coopers-ip.eu/index.php?id=36, June 2012. [11] Safetrip 21. http://www.rita.dot.gov/publications/horizons/2008_05_06/html/ introducing_safe_trip_21.html, June 2012. [12] Vehicle information and communication system (vics). http://www.vics.or.jp/english/ vics/index.html, June 2012. [13] Organization for road system enhancement. http://www.orse.or.jp/english/, June 2012.

57 [14] Via verde. http://www.viaverde.pt/Website/, June 2012.

[15] J. Ott and D. Kutscher. Drive-thru internet: Ieee 802.11b for "automobile" users. In INFO- COM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communica- tions Societies, volume 1, pages 4 vol. (xxxv+2866), march 2004.

[16] Ieee standard for information technology - telecommunications and information exchange between systems - local and metropolitan area networks - speciﬁc requirements - part 11: Wireless lan medium access control (mac) and physical layer (phy) speciﬁcations. IEEE Std 802.11-2007 (Revision of IEEE Std 802.11-1999), pages 1 –1076, 12 2007.

[17] Ieee standard for information technology– local and metropolitan area networks– speciﬁc requirements– part 11: Wireless lan medium access control (mac) and physical layer (phy) speciﬁcations amendment 6: Wireless access in vehicular environments. IEEE Std 802.11p- 2010 (Amendment to IEEE Std 802.11-2007 as amended by IEEE Std 802.11k-2008, IEEE Std 802.11r-2008, IEEE Std 802.11y-2008, IEEE Std 802.11n-2009, and IEEE Std 802.11w- 2009), pages 1 –51, 15 2010.

[18] Ieee standard for wireless access in vehicular environments (wave)–multi-channel operation. IEEE Std 1609.4-2010 (Revision of IEEE Std 1609.4-2006), pages 1 –89, 7 2011.

[19] W. Fisher. Development of dsrc/wave standards. http:// www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved= 0CB0QFjAA&url=https%3A%2F%2Fmentor.ieee.org%2F802.11%2Fdcn%2F07% 2F11-07-2045-00-000p-development-of-dsrc-wave-standards.doc&ei= Wwn6ToayIsfOswbY8_2gDA&usg=AFQjCNGFZoxl49mzJZv1r_eAbpNnsqJiLA, August 2007.

[20] J.B. Kenney. Dedicated short-range communications (dsrc) standards in the united states. Proceedings of the IEEE, 99(7):1162 –1182, july 2011.

[21] Its standards fact sheets. www.standards.its.dot.gov, 2008.

[22] Cars that talk: Commission earmarks single radio frequency for road safety and traﬃc management. europa.eu/rapid/press-release_IP-08-1240_en.htm?locale=en, 2008.

[23] T. Korakis, M. Knox, E. Erkip, and S. Panwar. Cooperative network implementation using open-source platforms. Communications Magazine, IEEE, 47(2):134 –141, february 2009.

[24] C. Ameixieira, J. Matos, R. Moreira, A. Cardote, A. Oliveira, and S. Sargento. An ieee 802.11p/wave implementation with synchronous channel switching for seamless dual-channel access (poster). In Vehicular Networking Conference (VNC), 2011 IEEE, pages 214 –221, nov. 2011.

[25] A. Ganz, A. Savvides, and Z. Ganz. Media access control development platform for wireless lans. In Electronics, Circuits and Systems, 1999. Proceedings of ICECS ’99. The 6th IEEE International Conference on, volume 1, pages 105 –108 vol.1, 1999.

[26] Michael Neufeld, Jeﬀ Fiﬁeld, Christian Doerr, Anmol Sheth, and Dirk Grunwald. SoftMAC - Flexible Wireless Research Platform. In HotNets-IV, November 2005.

58 [27] R. Manfrin, A. Zanella, and M. Zorzi. Functional and performance analysis of calradio 1 platform. In Network Computing and Applications, 2009. NCA 2009. Eighth IEEE International Symposium on, pages 300 –305, july 2009.

[28] A. Costantini D. Valerio P. Castiglione G. Zacheo T. Zemen F. Ricciato Fuxjäger, P. Ieee 802.11p transmission using gnuradio. In 6th Karlsruhe Workshop on Software Radios, pages 83 – 86, march 2010.

[29] Gnuradio. http://gnuradio.org/redmine/projects/gnuradio/wiki, September 2012.

[30] K. Amiri, Yang Sun, P. Murphy, C. Hunter, J.R. Cavallaro, and A. Sabharwal. Warp, a uniﬁed wireless network testbed for education and research. In Microelectronic Systems Education, 2007. MSE ’07. IEEE International Conference on, pages 53 –54, june 2007.

[31] C. Hunter, J. Camp, P. Murphy, A. Sabharwal, and C. Dick. A ﬂexible framework for wireless medium access protocols. In Signals, Systems and Computers, 2006. ACSSC ’06. Fortieth Asilomar Conference on, pages 2046 –2050, 29 2006-nov. 1 2006.

[32] F. Vázquez Gallego, J. Alonso-Zarate, C. Liss, and C. Verikoukis. Openmac: A new reconﬁg- urable experimental platform for energy-eﬃcient medium access control protocols. Science, Measurement Technology, IET, 6(3):139 –148, may 2012.

[33] Arada Systems. Locomate project white paper.

[34] Li Bin Jiang and Soung Chang Liew. Hidden-node removal and its application in cellular wiﬁ networks. Vehicular Technology, IEEE Transactions on, 56(5):2641 –2654, sept. 2007.

[35] Omniair consortium - interoperability through collaboration. http://www.omniair.org/, July 2012.

[36] Sirit inc. website. http://www.sirit.com/, July 2012.

59 60 Appendix A

UMAC/LMAC programming model

A.1 Macros Available

In this appendix there is a description of the C macros that allow a simpliﬁed communication with the LMAC, permitting for complex operations that involve writing to several addresses of memory to be accessed through a single line of code. Besides their name and function, there is an explanation of what each parameter is.

LMAC_TX_FRAME(BaseAddress, SlotID, BACKOFF); Role: Order the transmission of a frame to the PHY layer. Input parameters:

• BaseAddress – Base address of the registers. • SlotID – Slot ID where the frame to be transmitted is being held. • BACKOFF - Number of slots equivalent to the backoﬀ value, in case access to the medium is not instantaneous. Returns: N/A

LMAC_TX_CANCEL(BaseAddress); Role: Cancel any currently undergoing transmissions of frames to the PHY layer. Input parameters:

• BaseAddress – Base address of the registers. Returns: N/A

61 LMAC_LAST_TX_SLOT(BaseAddress); Role: Request the slot ID of the last transmitted frame. Input parameters:

• BaseAddress – Base address of the registers.

Returns: Slot ID where the last transmitted frame is held.

LMAC_GET_TX_STATUS(BaseAddress); Role: Read the LMAC’s transmission status. Input parameters:

• BaseAddress – Base address of the registers.

Returns: State of the TXR ﬂag of register 0 STATUS.

LMAC_GET_MEM_STATUS(BaseAddress); Role: Obtain the memory occupation status. Input parameters:

• BaseAddress – Base address of the registers.

Returns: Content of register 6 MEMSTA.

LMAC_REQ_SLOT(BaseAddress, SlotID, isValid); Role: Request a memory slot to the LMAC. Input parameters:

• BaseAddress – Base address of the registers.

Returns:

62 • SlotID - Slot ID allocated by the LMAC. • isValid - ’1’ if allocation is successful, ’0’ if otherwise.

LMAC_CLEAR_SLOT(BaseAddress, SlotID); Role: Order the liberation of a memory slot to the LMAC. Input parameters:

• BaseAddress – Base address of the registers. • SlotID – Slot ID the UMAC intends to liberate.

Returns: N/A

LMAC_GET_FIRST_RX_FRAME_ID(BaseAddress, SlotID, isValid, isLast); Role: Get the slot ID where the ﬁrst received frame from the PHY is held. Input parameters:

• BaseAddress – Base address of the registers.

Returns:

• SlotID - Slot ID of the ﬁrst frame received from the PHY. If no frame has been received, returns ‘0’ and the value of ‘isValid’ is ‘0’ too. • isValid - ’1’ in case there is at least one frame received in the PHY layer and ’0’ otherwise. • isLast - ’1’ if there is ONLY one frame received in the PHY.

LMAC_LOAD_COUNTDOWN(BaseAddress, value); Role: Load a value in the countdown timer and activate it. Input parameters:

• BaseAddress – Base address of the registers. • Value – Value to load in the timer, in microseconds.

Returns: N/A

63 LMAC_STOP_GET_COUNTDOWN(BaseAddress, value);

Role: Stop the countdown timer and obtain its current value. Input parameters:

• BaseAddress – Base address of the registers. • Value – Value of the timer, the momemnt it was stopped.

Returns: N/A

LMAC_SET_TIMER(BaseAddress, ﬂags, prescaler);

Role: Timer settings. It is possible to load the timer with a starting oﬀset and alter the clock division factor, to increase or decrease clock cadency. Input parameters:

• BaseAddress – Base address of the registers. • ﬂags – Flags which control the operation being executed. Flag format is: {Set Timer Load Value |Set Prescaler Counter}. • prescaler – Clock division factor. To be applied when Set prescaler counter is ’1’.

Returns: N/A

LMAC_ENABLE_TIMER_INT (BaseAddress, ﬂags);

Role: Timer settings and interrupts. It is possible to activate the timer and the periodical interrupt each second associated with it. Input parameters:

• BaseAddress – Base address of the registers. • ﬂags – Flags which control the operation being executed. Flag format is: {Enable Periodic Sec Interrupt |Enable Counter}.

Returns: N/A

64 LMAC_LOAD_TIMER_COUNTER_HI(BaseAddress, tmrCounter);

Role: Loads the 32 most signiﬁcant bits of the timer with the value of tmrCounter.

Input parameters:

• BaseAddress – Base address of the registers. • tmrCounter – 32 bits value to load onto the timer.

Returns: N/A

LMAC_LOAD_TIMER_COUNTER_LO(BaseAddress, tmrCounter);

Role: Loads the 32 least signiﬁcant bits of the timer with the value of tmrCounter.

Input parameters:

• BaseAddress – Base address of the registers. • tmrCounter – 32 bits value to load onto the timer.

Returns: N/A

LMAC_GET_TIMER_VAL_HI(BaseAddress);

Role: Obtains the 32 most signiﬁcant bits of the timer.

Input parameters:

• BaseAddress – Base address of the registers.

Returns: The 32 most signiﬁcant bits of the timer.

65 LMAC_GET_TIMER_VAL_LO(BaseAddress);

Role: Obtains the 32 least signiﬁcant bits of the timer.

Input parameters:

• BaseAddress – Base address of the registers.

Returns: The 32 least signiﬁcant bits of the timer.

LMAC_GET_FRAME_INFO(BaseAddress, SlotID);

Role: Reads information about the frame contained in the memory slot deﬁned by SlotID.

Input parameters:

• BaseAddress – Base address of the registers. • SlotID – Slot ID of the frame.

Returns: The content of the register with the frame information.

LMAC_SET_FRAME_INFO(BaseAddress, SlotID, data);

Role: Writes information about the frame in slot number SlotID.

Input parameters:

• BaseAddress – Base address of the registers. • SlotID – Slot ID of the frame. • data – 32 bits value to load into the frame information register.

Returns: N/A

66 LMAC_GET_FRAME_TS_HI(BaseAddress, SlotID);

Role: Reads the 32 most signiﬁcant bits of the arrival timestamp of the frame contained in SlotID. Input parameters:

• BaseAddress – Base address of the registers. • SlotID – Slot ID of the frame.

Returns: The 32 most signiﬁcant bits of the arrival timestamp of the frame.

LMAC_GET_FRAME_TS_LO(BaseAddress, SlotID);

Role: Reads the 32 least signiﬁcant bits of the arrival timestamp of the frame contained in SlotID. Input parameters:

• BaseAddress – Base address of the registers. • SlotID – Slot ID of the frame.

Returns: The 32 least signiﬁcant bits of the arrival timestamp of the frame.

LMAC_WORD_WRITE_FRAME(MemBaseAddress, SlotID, DataWord, WordOﬀset);

Role: Writes a four byte word in a memory position deﬁned by SlotID and WordOﬀset. Input parameters:

• MemBaseAddress – Base address of the memory slots. • SlotID – Slot ID of the frame. • DataWord – Word to be written. • WordOﬀset – Oﬀset in WORDS, in relation to the beggining of the slot, where the word is to be written.

Returns: N/A

67 LMAC_BYTE_WRITE_FRAME(MemBaseAddress, SlotID, DataByte, ByteOffset); Role: Writes a byte in a memory position defined by SlotID and ByteOffset. Input parameters:

• MemBaseAddress – Base address of the memory slots. • SlotID – Slot ID of the frame. • DataByte – Byte to be written. • ByteOﬀset – Oﬀset in BYTES, in relation to the beggining of the slot, where the byte is to be written.

Returns: N/A

LMAC_WORD_READ_FRAME(MemBaseAddress, SlotID, WordOffset); Role: Reads a four byte word from a memory position defined by SlotID and WordOffset. Input parameters:

• MemBaseAddress – Base address of the memory slots. • SlotID – Slot ID of the frame. • WordOﬀset – Oﬀset in WORDS, in relation to the beggining of the slot, from where the word is to be read.

Returns: The four byte word that was read from the memory. .

LMAC_BYTE_READ_FRAME(MemBaseAddress, SlotID, ByteOffset); Role: Reads a byte from a memory position defined by SlotID and ByteOffset. Input parameters:

• MemBaseAddress – Base address of the memory slots. • SlotID – Slot ID of the frame. • ByteOﬀset – Oﬀset in BYTES, in relation to the beggining of the slot, from where the byte is to be read.

Returns: The byte that was read from the memory. .

68 Appendix B

Over the Air Update

B.1 Overview

As seen in ﬁgure 3.1, the MAC layer and the digital PHY of the communication device reside in a FPGA board. The reprogrammable nature of the FPGA presents the opportunity for the development of a system with the capability of upgrading the hardware and software of the communications device in a remote fashion. Having to displace the vehicle/equipment to a speciﬁc location in order to provide an upgrade is undesirable both for the user and the service provider. The over the air update solves this issue by providing a way of upgrading every device equipped with it, on the spot. This releases the user from having to be concerned about the upgrade of the device as well as allowing the network manager to have a great degree of control over the units of the network. The upgrade technology must have the right coverage characteristics to be able to upgrade the mobile units of the network wherever they are. It must also have a high enough datarate to complete the upgrade process within a useful time frame. The choice of a GPRS modem to provide the upgrade medium was based on these considerations.

B.2 Features

The upgrade system provides the following features:

• Upgrade of the hardware/software of the 802.11p communications device, wherever it is located, provided it is covered by the Global System for Mobile Communications (GSM) network in that area;

• Deletion/replacement of the same hardware/software, subject to the same conditions of the previous point;

• Monitoring of the status of the equipment (functional, non-functional, erased, etc);

• Remote jumpstart of the device, to solve a deadlock situation;

• Remotely deactivating a device.

The system is added to the main 802.11p platform through a standardized interface, so it is ﬂexible enough to allow for the upgrade of the GPRS modem itself. These upgrades might include

69 units with GPS localization, for example, useful for both the upgrading system and the 802.11p communications device.

B.3 Architecture and Implementation

The architecture of the over the air upgrade system adds two components to the main 802.11p platform:

• A GSM/GPRS modem;

• A data switch matrix;

Figure B.1: Over the air upgrade system architecture added to the 802.11p platform.

The GSM/GPRS module is responsible for the communication with the exterior of the HEADWAY platform. It is through this module that short message alerts are received, operation confirmation messages are sent, and the transfer of data and files (the FPGA memory images and the module software itself) is done. This module communicates with the rest of the system through SPI (for the transfer of data) and GPIO pins (for control operations). The GPIO pins function as a control of the Switch Data Matrix’s operation. Its purpose is to prevent master conflicts when accessing the SPI bus (since both the FPGA and the GPRS module act as masters). The GPIO pins (controlled by the GSM module) define who accesses the SPI as master at any given time (in order to access yet another module, the Flash memory). The FPGA module, already part of the 802.11p system itself, is what contains the main functionalities of the communications platform. Its program is loaded from its adjacent Flash

70 memory, through the same SPI bus that the GPRS module uses. Every time there’s a software update, the GPRS module downloads the upgraded file to this Flash memory, and subsequently the file is loaded into the FPGA. Of note is the fact that not only the FPGA’s software (and by consequence, the 802.11p system) can be upgraded through the over-the-air upgrade system, but also the GPRS module’s software can be updated as well. At any time, a short message can be sent to the GPRS module to query its status and that of the system, as well as giving specific orders (stopping or rebooting the system).