From Nsnam
Revision as of 21:45, 28 July 2013 by Vedranm (Talk | contribs) (Fix midterm report wiki link)

Jump to: navigation, search


  • Project Name: Implementation of WAVE 1609.4/802.11p
  • Student: Junling Bu
  • Mentor: Guillaume Remy, Tom Henderson, Daniel Lertpratchya
  • Abstract: Since WAVE communication standards have been published, there exist many relevant implementations including prototypes, products, and simulations. However the implementation varies significantly, some of them even based on old draft standards. Besides that, ns-3 has no complete WAVE module yet. So this project will implement WAVE 1609.4/802.11p in mac layer for ns-3, with complete testsuits, examples, helpers and documents.
  • Code: Because of access restrictions from China, the code repository of this project cannot host on ns-3 code server with ssh command connected to. For now, an easy solution is to host the code on github website (mainly under src/wave directory).Code repository.
  • Midterm report: GSOC2013WAVE MAC/MidTermReport
  • About me: I am a second year Master student from China, and now is researching on vehicular network communication.


Vehicluar Networks and VANET simulations

Vehicular networks called VANETs are an important area of research in the field of Intelligent Transportation Systems (ITS). A wide range of safety and infotainment systems have been envisioned using this technology. Cooperative active safety systems, urban traffic control and the study of the inherent communication protocols are currently drawing great research interest [8-9]. The protocol stacks dedicated for VANET include WAVE from US IEEE, C2C-CC from Europe and CALM from ISO. Note that: this project is mainly focus on MAC layer of WAVE architecure described in section 2.2 and 2.3.
VANET simulations are the most practicable methodology to study vehicular networks. First, it is the only viable solution to evaluate applications in large-scale scenarios with thousands of vehicles. Second, it allows for the control of parameters that are usually unavailable in real experiments such as traffic lights algorithms. Third, it provides a cost-effective solution for trying new applications or simulating accidents [8]. The challenge of VANET simulations mainly includes network simulation, vehicular mobility, channel model and large-scale simulation [11].

IEEE Std 802.11p-2010 [1]

802.11p is an amendment of the IEEE standard 802.11, specifying extensions to 802.11a, adapting it to VANET communications in the 5.9 GHz band, fitting the VANET requirements of high mobility and short-duration communications. This specification includes: functions and services required by stations to operate correctly and to exchange messages without joining a BSS; signaling techniques and interface functions used by stations to communicate outside the context of a BSS.

IEEE Std 1609.4-2010 [4]

1609.4 means multi-channel operations, providing enhancements to IEEE 802.11 MAC to support WAVE operations, namely number and type of channels, channel routing and coordination, QoS mechanisms and node synchronization. 75MHz channel spacing is divided into one CCH (control channel) and six SCHs (service channels). Based on GPS time information or 802.11p Timing Advertisement frame, wireless devices synchronously switch between CCHI (control channel interval) and SCHI (service channel interval)。


Architecture of the implementation of 1609.4/802.11p in ns-3

Implement 802.11p mac in ns-3

The OCB mac mode named OcbWifiMac will be defined(Outside the context of a BSS), which is like ad-hoc rather than AP and station. According to the discussion among ns-3 developers [2-3],OcbWifiMac will inherit from RegularWifiMac class, which is very similar to AdhocWifiMac. The OcbWifiMac will overwrite some unsuitable functions to only log warn message, overwrite some functions to operate in OCB mode, and also provider some specific functions defined only in 802.11p. Moreover, OcbWifiMac will also set some arguments like default EDCA value.

Implement 1609.4 mac extension in ns-3

Since 1609.4 has already been implemented in some other simulations[5-6], this project will adopt some ideas from these papers as well as take the discussion among ns-3 developers[2-3] as the guideline for implementing. A subclass inheriting from NetDevice named WaveNetDevice will be defined, composed of (a) OcbWifiMac mac defined in 802.11p, (b) WaveNetDevice mac extension dealing with functions of 1609.4 management and data plane,(c) subcomponents in 1609.4 including ChannelCoordinator, ChannelManager, SchChannelScheduler and VSARepeater.

Development methodology

  • First,based on ns-3 manual and model documents, abstract high basic classes, define common functions, and also add ns-3 features including Log and Attributes;
  • Then, develop real working subclass inheriting from base class.
  • After that, write test suits and examples, find bug, and check whether they work well;
  • Last, complete manual documents about how to implement and how to use.

And the most important point is that it’s an iterative process like Extreme Programming. Because this is a light project, we can develop simple functions, work well, then go back to develop a little more complex and accurate.

Testing approach

When programming codes, test codes meanwhile. And testing approach is mainly based on log functions, examples and test suits. According to the Test part of ns-3 manual, it includes:

a) Unit test, each layer's important functions and classes will be tested independently.
b) Integrated test, integrating multiple classes will be tested.
c) System test, examples will be used to test WAVE implementation.


According to the ns-3 architecture, deliverables are in a new module named WAVE, including Model, Doc, Helper, Binding, Test, and Examples.

  • Model mainly contains : a) implementations of 802.11p, including ocb-wifi-mac.h/.cc; b) implementations of 1609.4, including wave-net-device.h/.cc, vsa-repeater.h/.cc, sch-channel-scheduler.h/.cc, channel-manager.h/.cc, channel-coordinator.h/.cc,vendor-specific-frame.h/.cc.
  • Doc contains design ideas, implementation details, and manual. Helper contains nice helpers to simplify operation, including wave-helper.h/.cc.
  • Test contains some test suits, including,
  • Examples contain useful examples, including simple-wave-example.c, and simple-802.11p-example.c.

Plan and Weekly Progress

Based on the GSoC 2013 timeline, there are totally 12 weeks. The following is the plan of this project (Implementation not only means source codes, but also contains relevant test suits, examples and documents):

  • Community bonding period [status: completed]

Before June 17: learn Python, ns-3 coding style, read relevant ns-3 codes,talk with mentors about implementation details.

  • Week 1/2 [status: completed]

June 17 – June 30: implement OcbWifiMac.

 a) remove deprecated 802.11p code from wifi module.
 b) complete a management frame header named VendorSpecificActionHeader.
 c) complete wifi-80211p-helper
 d) declare and implement OcbWifiMac class.
 e) finish two examples and one test suit.
  • Week 3/4 [status: completed]

June 1 – July 14: implement WaveNetDevice

 a) define initial ChannelCoordinator, ChannelManager and ChannelScheduler which are used in WaveNetDevice
 b) define WifiNetDevice that has specific methods to deal with multiple channel operation.
 c) refactor helpers and implement WaveHelper
 d) finish a simple example to send WSMP packets.
  • Week 5/6 [status: ]

July 15 – July 28: implement SchChannelScheduler

  • mid-term report [status: ]

July 29 - August 2:submit source files including ocb-wifi-mac.h/.cc, wave-net-device.h/.cc,, And submit a document about partial technical details and usage for VANET researchers and a relatively simple introduction of WAVE for other users

  • Week 7 [status: ]

August 3 – August 11: implement ChannelCoordinator

  • Week 8 [status: ]

August 12 – August 18: implement ChannelManager

  • Week 9/10 [status: ]

August 19 – September1: implement VSARepeater

  • Week 11 [status: ]

September 2 – September 8: complete documents, useful helpers

  • Week 12 [status: ]

September 9 – September 15: complete some WAVE examples, system test.

  • Final [status: ]

September 16 – September 23: scrub code, and improve documentation.


How to use wifi80211p device ?

This model defines some wifi-like helpers: NqosWaveMacHelper, QosWaveMacHelper, Wifi80211pHelper and WaveHelper. NqosWaveMacHelper and QosWaveMacHelper deal with OcbWifiMac configuration that are similar to NqosWifiMacHelper and QosWifiMacHelper. Wifi80211pHelper is used to create a WifiNetDevice that combines one OcbWifiMac and one WifiPhy, which is a conceptual 802.11p wifi netdevice. WifiHelper is used to create WaveNetDevice that combines multiple OcbWifiMacs and one WifiPhy to deal with multiple channel operation, which is a conceptual WAVE device (although now still miss 1609.3 standards).


#include "ns3/wave.h"
NodeContainer nodes;
NetDeviceContainer devices;
nodes.Create (2);
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
wifiPhy.SetChannel (wifiChannel.Create ());
NqosWaveMacHelper wifi80211pMac = NqosWaveMacHelper::Default();
Wifi80211pHelper wifi80211p = Wifi80211pHelper::Default ();
devices = wifi80211p.Install (wifiPhy, wifi80211pMac, nodes);

see wave/examples/

How to use wave device ?

Users can use WaveHelper to create a WaveNetDevice. Then before send or receive packets, we should assign channel access by StartSch method, then we can call SendX to send WSMP packets or call StartVsa to send VSA frames, and before send IP-based packets, we also need call RegisterTxProfile to indicate which channel to send, then we can call Send method. Usage:

see wave/examples/

How to use VSA frame to send management information ?

Normally the up layer can send packets in different protocols via 802.11 data frame, like ipv4 and ipv6. However, actually wifi know nothing about these differences, because this work has been done with LlcSnapHeader with protocol field. So if up layer wants to send different management informations over 802.11 management frame (of course nobody can prevent someone just wants to send management information over 802.11 data frame), how can we do? The 802.11 and 802.11p can allow the up layer send different information over Vendor Specific Action management frame by using different OrganizationIdentifier fields (now only support 3 and 5 bytes according to the standard) to identify differences.

If you want to use 802.11p device to send VSAs.Usage:

0. refer to 5.1, already has some Nodes and WifiNetdevices
1. define an OrganizationIdentifier
   uint8_t oi_bytes[5] = {0x00, 0x50, 0xC2, 0x4A, 0x40};
   OrganizationIdentifier oi(oi_bytes,5);
2. define a Callback for the defined OrganizationIdentifier
   VscCallback vsccall = MakeCallback (&VsaExample::GetWsaAndOi, this);
3. OcbWifiMac regists this identifier and function
   Ptr<WifiNetDevice> device1 = DynamicCast<WifiNetDevice>(nodes.Get (i)->GetDevice (0));
   Ptr<OcbWifiMac> ocb1 = DynamicCast<OcbWifiMac>(device->GetMac ());
   ocb1->AddReceiveVscCallback (oi, vsccall);
4. now you can send management packet over VSA frame
   Ptr<Packet> vsc = Create<Packet> ();
   ocb2->SendVsc (vsc, Mac48Address::GetBroadcast (), m_16093oi);
5. then registered callback in other devices will be called.

see wave/examples/

If you want to use wave device to send VSAs under multi-channel environment.Usage:


Is this model going to involve vehicular mobility of some sort

Vehicular network involves not only communication protocol, but also communication environment including vehicular mobility and propagation models. Because of specific features of the latters than normal MANET, the protocols need to change. The MAC layer model in this project just adopts MAC changes to vehicular environment. However this model not involves any vehicular mobility with time limit.Users can use any mobility model in ns-3, but should know these models are not real vehicular mobility. More work is need.

Is your model going to use different propagation models

Refer to the first issue, some more realistic propagation models for vehicualr environment are suggested and welcome. And some existed propagation models in ns-3 are also suitable. Normally users can use Friis,Two-Ray Ground and Nakagami model [7].

What specifically is different about your mac other than wildcard BSSID

are there any vehicular application models to drive the code

About vehicular application models, I only know SAE J2375 depend on WAVE architecture is application message set in US; CAM and DENM in Europe is between network and application layer but is very close to application model. The BSM in J2375 and CAM is alert messages that every vehicle node will sent periodicity about its status information to cooperate with others. Fow now, here is no plan to develop a vehicular application model. But to drive WAVE MAC layer code, a simple application model will be tried to develop.

Any previous code you think you can leverage

This project will provide two netdevice. First is normal 802.11p netdevice which uses new implemented OcbWifiMac, this is very useful for those people who only want to simulate route protocols or up protocols for vehicular environment and do not need whole WAVE architecture. For any previous code, my suggestion is to use Wifi80211phelper with little modification or just set ad-hoc mode with 802.11a 10MHz (this is enough to simulate main characteristic of 802.11p). The second netdevice is 1609.4 netdevice which providers some methods to deal with multi-channel operation. This is part of whole WAVE architecture and provides service for up 1609.3 standards.

Why here are two kinds of NetDevice

In wave module, actually here are two device, one is 802.11p device which is the object of WifiNetDevice class, another is wave device which is the object of WaveNetDevice class. An "802.11p Net Device" is one that just runs the 802.11p extensions (channel frequency = 802.11a 5.9GHz, channel width = 10MHz, single instance of OcbWifiMac, and specific EDCA parameters). A "WAVE Net Device" is one that implements also 1609.1-4 standards based on 802.11p, and now we are focusing only on 1609.4 modeling aspects (multi channel). The reason to provide a 802.11p device is that considering the fact many researchers are interested in route protocol or other aspects on vehicular environment of single channel, so they need no multi-channel operation and WAVE architectures. Besides that, the European standard could use 802.11p device in an modified ITS-G5 implementation (maybe named ITSG5NetDevice).


Thanks for all comments from Guillaume Rémy, Lalith Suresh, Tommaso Pecorella, and Tom Henderson.


  • [1] IEEE Std 802.11p. IEEE Standard for Information Technology-Telecommunications and Information Exchange Between Systems-Local and Metropolitan Area Networks-Specific Requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless Access in Vehicular Environments, 2010.
  • [2] ns-3.Bug 945 - Revise how we provide support for vehicular communications. [Online]. Available:
  • [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available:
  • [4] IEEE Std 1609.4-2010. IEEE Standard for Wireless Access in Vehicular Environments (WAVE) - Multi-Channel Operation, 2010.
  • [5] Chen Qi, Daniel Jiang, and Luca Delgrossi. "IEEE 1609.4 DSRC multi-channel operations and its implications on vehicle safety communications."Vehicular Networking Conference (VNC), 2009 IEEE. IEEE, 2009.
  • [6] Ghandour, Ali J., et al. "Modeling and simulation of WAVE1609.4-based multi-channel vehicular ad hoc networks." Proceedings of the 5th International ICST Conference on Simulation Tools and Techniques. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering), 2012.
  • [7] Benin, Joseph, Michael Nowatkowski, and Henry Owen. "Vehicular Network simulation propagation loss model parameter standardization in ns-3 and beyond." Southeastcon, 2012 Proceedings of IEEE. IEEE, 2012.
  • [8] Fernandes, Ricardo, Fausto Vieira, and Michel Ferreira. "VNS: An integrated framework for vehicular networks simulation." Vehicular Networking Conference (VNC), 2012 IEEE. IEEE, 2012.
  • [9] Karagiannis, Georgios, et al. "Vehicular networking: A survey and tutorial on requirements, architectures, challenges, standards and solutions."Communications Surveys & Tutorials, IEEE 13.4 (2011): 584-616.
  • [10] Stanica, Razvan, Emmanuel Chaput, and André-Luc Beylot. "Simulation of vehicular ad-hoc networks: Challenges, review of tools and recommendations." Computer Networks 55.14 (2011): 3179-3188