Universidade de Aveiro Departamento deElectrónica, Telecomunicações e Informática 2012
João Tiago
Bartolomeu Pio
Implementação do Controlo de Acesso ao Meio
para IEEE 802.11p
Implementation of IEEE 802.11p Medium Access
Control
Universidade de Aveiro Departamento deElectrónica, Telecomunicações e Informática 2012
João Tiago
Bartolomeu Pio
Implementação do Controlo de Acesso ao Meio
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ífica do Pro-fessor Doutor Arnaldo Silva Rodrigues de Oliveira (Orientador), ProPro-fessor 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 / acknowledgements
Antes de mais queria agradecer aos meus pais, que durante todo o meu 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 final.
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 commu-nications 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 mi-croprocessor 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 Traffic 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.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
List of Figures
1.1 Example of a Vehicular Network with Vehicle (V2V) and
Vehicle-to-Infrastructure (V2I) communication. . . 2
2.1 The Wireless Access in Vehicular Environments (WAVE) layer stack and the stan-dards their Institute of Electrical and Electronics Engineers (IEEE) ruling stanstan-dards. 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 different 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 different 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.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
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 different IFS values and slot time for the Orthogonal
Frequency-Division Multiplexing (OFDM) PHY with a channel spacing of 10 MHz, as defined in 802.11 . . . 23 4.1 Encoding of the type and subtype frame fields. . . 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
develop-ment platform. . . 49 5.3 Results for the Virtual Carrier Sense tests. . . 50 5.4 Average packet transmission success rates for the different idle intervals. . . 52 6.1 Standard defined times versus obtained results for the SIFS validation tests. . . . 54
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
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 Definition MLD Microprocessor Library Definition MSS Microprocessor Software Specification 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
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
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 entertain-ment 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
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.
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 com-pliant 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 develop-ment 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].
1.3
Objectives
In the context of the HEADWAY project, the objectives of the work, discussed in this disser-tation, 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). • Definition of the next steps in the development process, namely which functionalities are
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 - Specification of the Upper MAC Layer - In this chapter, the specification 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 implemen-tation of the Upper MAC will be presented. The implemenimplemen-tation 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.
Chapter 2
Applications, Standards and Projects
2.1
Introduction
In this chapter an overview of the different applications of vehicular networks will be presented. Following that, the existing standards that regulate vehicular communications will be discussed, namely what differenciates 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, Traffic Management and Commercial applications. Each application within a category shares the same requirements as the other members of its type and these specificities 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 traffic 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 identification 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
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 Traffic 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 specifications 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.
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 - Specifies the services and interfaces of the WAVE Resource Manager application.It describes the data and management services offered within the WAVE architecture .[21] • 1609.2 - Security Services for Applications and Management Messages defines secure
mes-sage 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
environ-ment. With it, a system with one or more radios can switch between different 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 - Defines the services and secure message formats necessary to support secure electronic payments.[21]
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 different, 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 MAC (incl. channel coordination)
PHY LLC WAVE Security Services Network and Transport WSMP 1609.3 1609.4 802.11/p 1609.2 802.2 Upper Layers 1609.1 WAVE stack Transport UDP Network IPv6
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 specifically, 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 compo-nents, 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
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 lan-guages, 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 develop-ment 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.
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.
discussed in this dissertation intends to fill.
Chapter 3
Specification 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 men-tioned, 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 RF module FPGA Digital PHY (hardware) LLC UMAC software LLC-MAC Interface MAC-PHY Interface LMAC hardware
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 Specification
As mentioned in section 3.1, the functionalities of the MAC layer are divided by the two sub-layers. 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 - Identification 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;
• Error checking capability. The LMAC must verify the Frame Check Sequence (FCS) field of arriving frames and detect errors. It must also calculate and append the FCS field 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.
MAC LLC M A -U N IT D A T A .r e q u e s t R e q u e s t p a ra m e te rs M A -U N IT D A T A .c o n fi rm In d ic a ti o n p a ra m e te rs C o n fi rm p a ra m e te rs M A -U N IT D A T A X .r e q u e s t M A -U N IT D A T A .i n d ic a ti o n M A -U N IT D A T A X .i n d ic a ti o n
Figure 3.2: LLC - MAC interface, with the different 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 buffers the data, processes it and attempts transmission. The result is then reported to the LLC through the generation of a MA-UNITDATAX-STATUS.indication
Parameters source address destination address routing info rma tion transmission status data provided prio rit y prio rit y 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 figure 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.
Reception
Transmission
LLC
MAC
MA-UNITDATAX.request LLC wants to send dataMAC buffers data to be sent
MAC attempts to send data to PHY
MA-UNITDATAX-STATUS.indication
STATUS values:
Successful Undeliverable
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 fields and take appropriate action. Actions undertaken,
Frame
Control Address 3 Address 4
Frame
Body FCS
2 2 6 6 6 2 6 2 0-23124 4
Duration Address 1 Address 2 Sequence Control
QoS Control
Octets:
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 specifications 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 under-standing 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.
Backof f P eriod = RandomInteger × SlotT ime (3.1)
In this device, the backoff 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.
are not within range of each other [34]. By default, 802.11 suffers 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 Data ACK Destination Other RTS CTS NAV (RTS) NAV (CTS)
Defer access Backoff after defer Contention Window DIFS
SIFS SIFS SIFS
Figure 3.5: Exchange of data between two stations, including CSMA/CA and positive acknowledgment.
3.3
Timing Specification
The 802.11 standard defines that the time interval between frames, not accounting for frag-mentation, is called the Interframe Space (IFS) [16]. There are several IFS, depending on the
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
+M ACP rocessingDelay + RxT xT urnaroundT ime (3.2) 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.
Medium Busy
Time
SIFS Slot Time Slot Time
DIFS
First backoff Slot
Figure 3.6: Timing relations between the different 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
Characteristic Value SlotTime 13µs SIFSTime 32µs DIFSTime 58µs
Table 3.2: Values of the different IFS values and slot time for the OFDM PHY with a channel spacing of 10 MHz, as defined in [16, section 18.4.4]
Taking into account the CSMA/CA protocol methodology and the defined 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 specifications known, the implementation of the requirements and functionalities explained in this chapter will be presented.
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 buffers 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;
MAC Microblaze µP Upper MAC (software) Lower MAC (hardware) µP interrupt line Interrupt Controller
LMAC Interrupt lines
Memory Registers MAC-PHY interface S e ri a l in te rf a c e LLC-MAC interface Serial interrupt
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 different 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 different 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.
System initialization Start System Idle Interruption detected llc_rx_interrupt handler phy_rx_interrupt handler phy_tx_end_int handler LMAC finished frame transmission to the PHY LMAC received valid frame from PHY Bytes arrived on LLC-MAC interface countdown_interru pt handler system countdown finished
Load MAC address Initialize stat counters Initialize buffers
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 verification.
After extracting the header, the UMAC identifies 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
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 figure 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 backoff 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 flow 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.
1
llc_rx_interrupt handler Valid primitive? Encapsulate frame Request LMAC transmission to PHYWait for timeout or
phy_tx_end_int handler YES Frame transmitted? Generate MA- UNITDATAX-STATUS (success) Generate MA- UNITDATAX-STATUS (failure) YES NO
Clear serial port buffers NO
2
Is NAV counting down? NOWait for NAV countdown to
finish YES
2
phy_tx_end_int handler NO Was frame a broadcast?Clear frame slot and update stats
(successful transmitted frames) Was frame data or
management? NO YES Was frame originated in the LLC? Generate MA- UNITDATAX-STATUS (success) Activate ACK timeout YES YES
3 phy_rx_interrupt handler Generate MA-UNITDATAX. indication Header extraction Frame is directed to this station? NO Management Frame Control Frame Data frame YES Unicast frame? Answer with ACK YES NO Not implemented CTS RTS
ACK Update NAV
Stop ACK timeout Answer with CTS Request Transmission of Data frame to LMAC Activate ACK timeout Wait for phy_tx_end_int handler 2 Was a CTS expected? YES NO
4
countdown_interrupt handler Countdown type NAV Is there a frame queued for Tx? YES YES Request Transmission of frame to LMAC Frame is broadcast? NO Activate ACK timeout NO2
Wait for phy_tx_end_int handler Update failed transmission stats ACK timeout maximum number of retries reached? NOClear frame slot YES Was frame originated in LLC? NO Generate MA- UNITDATAX-STATUS (failure)
2
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 flag appears in the data. This can be seen in figure 4.7. • The escape character itself appears in the data.
Byte stuffing introduzes some overhead, but it guarantees that the frames delimitations will be properly identified. frame Start Flag Escape byte X 1 1 End Flag Escape byte 1 1 octets
Figure 4.7: Usage of the escape byte to signal the start and end flag
The interface as specified in subsection 3.2.1, requires the exchange of standard defined prim-itives 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 flag.
• 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 flag.
The type and subtype fields codify what primitive is being transmitted and they are defined 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.
Primitive Subtype Type X 1 1 Start Bytes 2 End Bytes 2 Source address 6 Destination address 6 REQUEST Service Class Priority 1 1 Data X INDICATION CONFIRM Source address 6 Destination address 6 Service Class Priority 1 1 Data X Source address 6 Destination address 6 Provided Service Class Provided Priority 1 1 RX status 1 TX status 1
Figure 4.8: Frame format for the codification of the LLC-MAC data exchange primitives Type value Type name Subtype Value Subtype name
0x00 request 0x00 MA-UNITDATA 0x01 confirm 0x02 indication 0x00 request 0x01 MA-UNITDATAX 0x01 confirm 0x02 indication 0x02-0x1A Reserved
Table 4.1: Encoding of the type and subtype frame fields.
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 figure 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;
