Nsnam - User contributions [en]

GSOC2013WAVE MAC

2013-10-02T05:30:31Z

Junling: /* Plan and Weekly Progress */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report: [[GSOC2013WAVE MAC/MidTermReport]]
* Final report: [[GSOC2013WAVE MAC/FinalReport]]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.

= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: completed]
July 15 – July 28: implement SchChannelScheduler
a) complete SchChannelScheduler
b) support continuous access, extended access, and immediate access. (not support alternating access yet)
* mid-term report [status: completed]
July 29 - August 2:submit source files including ocb-wifi-mac.h/.cc, wave-net-device.h/.cc, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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: completed]
August 3 – August 11: implement ChannelCoordinator
a) modify some implementation code according to comments from ns-3 developer
b) implement ChannelCoordinator
c) complete a test cast about channel coordination
d) add expire-time-tag to support control the packet's lifetime.
*Week 8 [status: completed]
August 12 – August 18: implement ChannelManager
My initial proposal that use 7 mac entities and single phy entity to support channel alternating access seems not easy,
instead I try to implement ns3::WaveEdcaTxopN inheriting from ns3::EdcaxopN which uses multiple internal queues instead of single queue, when channel switches,
the current queue will not be flushed and just switch to another queue for next channel.
a) define WaveEdcaTxopN to support alternating access
b) implement ChannelManager which contains channel information and state.
* Week 9/10 [status: completed]
August 19 – September1: implement VSARepeater
a) implement VSA transmission method and receive callback of WaveNetDevice.
b) complete VsaRepeater to support send VSAs repeatedly.
c) finish an example to show usage.
* Week 11 [status: completed]
September 2 – September 8: complete documents, useful helpers
a) update documents
b) complete wave-multiple-channel to model a VANET environment to show the impact of WAVE 1609.4
* Week 12 [status: completed]
September 9 – September 15: complete some WAVE examples, system test.
a) update WAVE examples
b) System test has not been completed which will be done in the future.
* Final [status: completed]
September 16 – September 23: scrub code, and improve documentation.
a) update documentation and doxygen
b) divide my implementation into three patches

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC/FinalReport

2013-10-02T05:23:00Z

Junling:

Abstract:
This is the final set deliverables of the ns-3 GSoC 2013 project, named
WAVE. The patch set is mainly divided to three patches and based on the
current ns-3-dev.

The first patch was about removing deprecated 802.11p code in the wifi
module, and fixing some wifi bugs. It has already been merged to
ns-3-dev after review by Daniel and Tom (changesets 10200-10204).

The second patch [1] contains the base implementation of the IEEE
802.11p standard. This patch contains documentation, the new NetDevice
model, a simple example, a test suite, and helpers. Besides that, this
patch also made some slight modifications to the wifi module.

The model in this patch implements:
a) a high MAC class named OcbWifiMac
b) vendor specific frames operation, including management header, send
and receive operations
c) a new tag called HigherDataTxVectorTag, and a subclass WaveMacLow
inheriting from MacLow, that supports higher layer control Tx parameters.

The test suite tests association times with different high Mac
modes. The example is to show how to create and use 802.11p device.

The third patch [2] is about the implementation of the 1609.4 standard,
where most of the WAVE functionality resides. This patch contains
documentation, models, three simple examples, a test suite, and helpers.
Besides that, this patch also needs additional modifications to the
wifi module. The model provides service via a new WaveNetDevice
inheriting from WifiNetDevice, in which the main work is done by several
internal classes.

The four classes are ChannelManager, VsaRepeater, ChannelScheduler and
ChannelCoordinator. ChannelManager stores the WAVE channel information.
VsaRepeater sends VSAs repeatedly and stores VSA tx parameters.
ChannelCoordinator coordinates channel interval operation including
control channel (CCH) intervals, service channel (SCH) intervals, and
Guard intervals. ChannelScheduler is to assign channel access with four
mechanisms. Besides that, a new tag ExpireTimeTag is used to support
control lifetime of packets, and a subclass WaveMacQueue inheriting from
WifiMacQueue is used to support AlternatingAccess channel access
mechanism. An example named MultipleChannelExperiment models the
multiple channel environment. The test suite tests implemented methods
and features. However, an item for future work is to include more test
cases.

[1] https://codereview.appspot.com/13880043/

[2] https://codereview.appspot.com/14013044/

[3] https://github.com/linlinjava/ns-3-dev-git

[4] https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC

GSOC2013WAVE MAC

2013-10-02T05:21:59Z

Junling: /* Project */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report: [[GSOC2013WAVE MAC/MidTermReport]]
* Final report: [[GSOC2013WAVE MAC/FinalReport]]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.

= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: completed]
July 15 – July 28: implement SchChannelScheduler
a) complete SchChannelScheduler
b) support continuous access, extended access, and immediate access. (not support alternating access yet)
* mid-term report [status: ]
July 29 - August 2:submit source files including ocb-wifi-mac.h/.cc, wave-net-device.h/.cc, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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: completed]
August 3 – August 11: implement ChannelCoordinator
a) modify some implementation code according to comments from ns-3 developer
b) implement ChannelCoordinator
c) complete a test cast about channel coordination
d) add expire-time-tag to support control the packet's lifetime.
*Week 8 [status: completed]
August 12 – August 18: implement ChannelManager
My initial proposal that use 7 mac entities and single phy entity to support channel alternating access seems not easy,
instead I try to implement ns3::WaveEdcaTxopN inheriting from ns3::EdcaxopN which uses multiple internal queues instead of single queue, when channel switches,
the current queue will not be flushed and just switch to another queue for next channel.
a) define WaveEdcaTxopN to support alternating access
b) implement ChannelManager which contains channel information and state.
* Week 9/10 [status: completed]
August 19 – September1: implement VSARepeater
a) implement VSA transmission method and receive callback of WaveNetDevice.
b) complete VsaRepeater to support send VSAs repeatedly.
c) finish an example to show usage.
* Week 11 [status: completed]
September 2 – September 8: complete documents, useful helpers
a) update documents
b) complete wave-multiple-channel to model a VANET environment to show the impact of WAVE 1609.4
* Week 12 [status: ]
September 9 – September 15: complete some WAVE examples, system test.
* Final [status: ]
September 16 – September 23: scrub code, and improve documentation.

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC/FinalReport

2013-10-02T05:20:50Z

Junling: Created page with "Abstract: This is the final set deliverables of the ns-3 GSoC 2013 project, named WAVE. The patch set is mainly divided to three patches and based on the current ns-3-dev. T..."

Abstract:
This is the final set deliverables of the ns-3 GSoC 2013 project, named
WAVE. The patch set is mainly divided to three patches and based on the
current ns-3-dev.

The first patch was about removing deprecated 802.11p code in the wifi
module, and fixing some wifi bugs. It has already been merged to
ns-3-dev after review by Daniel and Tom (changesets 10200-10204).

The second patch [1] contains the base implementation of the IEEE
802.11p standard. This patch contains documentation, the new NetDevice
model, a simple example, a test suite, and helpers. Besides that, this
patch also made some slight modifications to the wifi module.

The model in this patch implements:
a) a high MAC class named OcbWifiMac
b) vendor specific frames operation, including management header, send
and receive operations
c) a new tag called HigherDataTxVectorTag, and a subclass WaveMacLow
inheriting from MacLow, that supports higher layer control Tx parameters.

The test suite tests association times with different high Mac
modes. The example is to show how to create and use 802.11p device.

The third patch [2] is about the implementation of the 1609.4 standard,
where most of the WAVE functionality resides. This patch contains
documentation, models, three simple examples, a test suite, and helpers.
Besides that, this patch also needs additional modifications to the
wifi module. The model provides service via a new WaveNetDevice
inheriting from WifiNetDevice, in which the main work is done by several
internal classes.

The four classes are ChannelManager, VsaRepeater, ChannelScheduler and
ChannelCoordinator. ChannelManager stores the WAVE channel information.
VsaRepeater sends VSAs repeatedly and stores VSA tx parameters.
ChannelCoordinator coordinates channel interval operation including
control channel (CCH) intervals, service channel (SCH) intervals, and
Guard intervals. ChannelScheduler is to assign channel access with four
mechanisms. Besides that, a new tag ExpireTimeTag is used to support
control lifetime of packets, and a subclass WaveMacQueue inheriting from
WifiMacQueue is used to support AlternatingAccess channel access
mechanism. An example named MultipleChannelExperiment models the
multiple channel environment. The test suite tests implemented methods
and features. However, an item for future work is to include more test
cases.

[1] https://codereview.appspot.com/13880043/
[2] http://codereview.appspot.com/14013044/
[3] https://github.com/linlinjava/ns-3-dev-git
[4] https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC

GSOC2013WAVE MAC

2013-10-02T05:19:13Z

Junling: /* Project */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report: [[GSOC2013WAVE MAC/MidTermReport]]
* Final report:
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.

= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: completed]
July 15 – July 28: implement SchChannelScheduler
a) complete SchChannelScheduler
b) support continuous access, extended access, and immediate access. (not support alternating access yet)
* mid-term report [status: ]
July 29 - August 2:submit source files including ocb-wifi-mac.h/.cc, wave-net-device.h/.cc, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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: completed]
August 3 – August 11: implement ChannelCoordinator
a) modify some implementation code according to comments from ns-3 developer
b) implement ChannelCoordinator
c) complete a test cast about channel coordination
d) add expire-time-tag to support control the packet's lifetime.
*Week 8 [status: completed]
August 12 – August 18: implement ChannelManager
My initial proposal that use 7 mac entities and single phy entity to support channel alternating access seems not easy,
instead I try to implement ns3::WaveEdcaTxopN inheriting from ns3::EdcaxopN which uses multiple internal queues instead of single queue, when channel switches,
the current queue will not be flushed and just switch to another queue for next channel.
a) define WaveEdcaTxopN to support alternating access
b) implement ChannelManager which contains channel information and state.
* Week 9/10 [status: completed]
August 19 – September1: implement VSARepeater
a) implement VSA transmission method and receive callback of WaveNetDevice.
b) complete VsaRepeater to support send VSAs repeatedly.
c) finish an example to show usage.
* Week 11 [status: completed]
September 2 – September 8: complete documents, useful helpers
a) update documents
b) complete wave-multiple-channel to model a VANET environment to show the impact of WAVE 1609.4
* Week 12 [status: ]
September 9 – September 15: complete some WAVE examples, system test.
* Final [status: ]
September 16 – September 23: scrub code, and improve documentation.

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-09-09T13:19:16Z

Junling: /* Plan and Weekly Progress */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git 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.

= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: completed]
July 15 – July 28: implement SchChannelScheduler
a) complete SchChannelScheduler
b) support continuous access, extended access, and immediate access. (not support alternating access yet)
* mid-term report [status: ]
July 29 - August 2:submit source files including ocb-wifi-mac.h/.cc, wave-net-device.h/.cc, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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: completed]
August 3 – August 11: implement ChannelCoordinator
a) modify some implementation code according to comments from ns-3 developer
b) implement ChannelCoordinator
c) complete a test cast about channel coordination
d) add expire-time-tag to support control the packet's lifetime.
*Week 8 [status: completed]
August 12 – August 18: implement ChannelManager
My initial proposal that use 7 mac entities and single phy entity to support channel alternating access seems not easy,
instead I try to implement ns3::WaveEdcaTxopN inheriting from ns3::EdcaxopN which uses multiple internal queues instead of single queue, when channel switches,
the current queue will not be flushed and just switch to another queue for next channel.
a) define WaveEdcaTxopN to support alternating access
b) implement ChannelManager which contains channel information and state.
* Week 9/10 [status: completed]
August 19 – September1: implement VSARepeater
a) implement VSA transmission method and receive callback of WaveNetDevice.
b) complete VsaRepeater to support send VSAs repeatedly.
c) finish an example to show usage.
* Week 11 [status: completed]
September 2 – September 8: complete documents, useful helpers
a) update documents
b) complete wave-multiple-channel to model a VANET environment to show the impact of WAVE 1609.4
* Week 12 [status: ]
September 9 – September 15: complete some WAVE examples, system test.
* Final [status: ]
September 16 – September 23: scrub code, and improve documentation.

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-09-09T13:05:01Z

Junling: /* Plan and Weekly Progress */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git 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.

= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: completed]
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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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: completed]
August 3 – August 11: implement ChannelCoordinator
a) modify some implementation code according to comments from ns-3 developer
b) implement ChannelCoordinator
c) complete a test cast about channel coordination c) add expire-time-tag to support control the packet's lifetime.
*Week 8 [status: completed]
August 12 – August 18: implement ChannelManager
a) My initial proposal that use 7 mac entities and single phy entity to support channel alternating access seems not easy,
instead I try to implement ns3::WaveEdcaTxopN inheriting from ns3::EdcaxopN which uses multiple internal queues instead of single queue, when channel switches,
the current queue will not be flushed and just switch to another queue for next channel.
b) implement ChannelManager which contains channel information and state.
* Week 9/10 [status: completed]
August 19 – September1: implement VSARepeater
a) implement VSA transmission method and receive callback of WaveNetDevice. b) complete VsaRepeater to support send VSAs repeatedly.
b) finish an example to show usage.
* Week 11 [status: completed]
September 2 – September 8: complete documents, useful helpers
a) update documents
b) complete wave-multiple-channel to model a VANET environment to show the impact of WAVE 1609.4
* Week 12 [status: ]
September 9 – September 15: complete some WAVE examples, system test.
* Final [status: ]
September 16 – September 23: scrub code, and improve documentation.

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-09-09T13:03:14Z

Junling: /* Plan and Weekly Progress */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git 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.

= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: completed]
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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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: completed]
August 3 – August 11: implement ChannelCoordinator
a) modify some implementation code according to comments from ns-3 developer
b) implement ChannelCoordinator
c) complete a test cast about channel coordination c) add expire-time-tag to support control the packet's lifetime.
*Week 8 [status: completed]
August 12 – August 18: implement ChannelManager
a) My initial proposal that use 7 mac entities and single phy entity to support channel alternating access seems not easy, instead I try to implement ns3::WaveEdcaTxopN inheriting from ns3::EdcaxopN which uses multiple internal queues instead of single queue, when channel switches, the current queue will not be flushed and just switch to another queue for next channel. b) implement ChannelManager which contains channel information and state.
* Week 9/10 [status: completed]
August 19 – September1: implement VSARepeater
a) implement VSA transmission method and receive callback of WaveNetDevice. b) complete VsaRepeater to support send VSAs repeatedly.
c) finish an example to show usage.
* Week 11 [status: completed]
September 2 – September 8: complete documents, useful helpers
a) update documents
b) complete wave-multiple-channel to model a VANET environment to show the impact of WAVE 1609.4
* Week 12 [status: ]
September 9 – September 15: complete some WAVE examples, system test.
* Final [status: ]
September 16 – September 23: scrub code, and improve documentation.

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC/MidTermReport

2013-08-01T16:10:31Z

Junling: /* Helpers */

== Abstract ==
My midterm code is composed of 2 patches in Rietveld issues 11685043[1] and 11480044 [2]. The first is to remove previous 802.11p-related code in src/wifi. then implement WAVE 802.11p MAC defined by IEEE 802.11p-2010 in src/wave, the second is partial implementation of WAVE 1609.4 MAC defined by IEEE 1609.4-2010 in src/wave.

To run examples, the command is ./waf --run wave-simple-device (or wave-simple-ocb or wave-simple-vsa. To run test suites, the command is ./test.py -s wave (or ocb). Besides that, users can read wave.rst document and wiki page[4].

For more information, The [https://github.com/linlinjava/ns-3-dev-git code] is hosted on github website, and the main [https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC WAVE MAC wiki page] is recommended. This midterm page will introduce what has been implemented until now, how the code is implemented, what are uncertain, and what are out of scope).

== 802.11p Implementation ==
The patch of 802.11p implementation removes previous 802.11p-related code in
src/wifi, which was based on an old and unsuitable 1609.4-2006 standard and only
partially implemented, then adds the MAC portion of the 802.11p-2010 standard,
that allows stations to send data packets directly.

The main features are 1) provide outside the context of a Bss (OCB) mode of
high MAC defined in the standard, 2) use specific EDCA parameters, 3) provide
vendor specific action frames and allow users to send management information over VSAs. Further study is needed to verify that this implementation of 802.11p is accurate and can undertake a large number of nodes.

== partial 1609.4 Implementation ==
The patch of 1609.4 implementation is to complete 1609.4-2010 standard based on 802.11p to deal
with multiple channels operation for vehicular environment. It would build on
the previous patch[1].The implemented features are 1) provide a NetDevice with special APIs, 2) allowusers to route different packets by different ways, 3) define standard channel coordination mechanism, user can inherit to overwrite for optimization research,4) provide two simple channel access assignment mechanisms.Because of time limit of this midterm review, some important features are notfinished, including 1) the support of VSAs frame in multiple channels environment, 2) the most important channel access assignment named AlternatingAccess. Besides that, some details not defined in the standard will need more consideration and tests.

== Helpers ==
In wave module, the helpers include QosWaveMacHelper, NqosWaveHelper, Wifi80211pHelper and WaveHelper. NqosWaveMacHelper and NqosWaveMacHelper are used to create MAC entities of WAVE. Wifi80211pHelper is used to create 802.11p devices that follow the 802.11p-2010 standard. WaveHelper is used to create WAVE devices that follow the 802.11p-2010 and 1609.4-2010 standards which are the MAC and PHY layers of the WAVE architecture.
The relation of them is described as below.

WifiHelper ----------use----------> WifiMacHelper
^ ^ ^ ^
| | | |
| | inherit inherit
| | | |
| | QosWifiMacHelper NqosWifiMacHelper
| | ^ ^
| | | |
inherit inherit inherit inherit
| | | |
WaveHelper Wifi80211pHelper QosWaveMacHelper NqosWaveHelper

Although Wifi80211Helper can use any subclasses inheriting from WifiMacHelper, we force user shall use subclasses inheriting from QosWaveMacHelper or NqosWaveHelper.

Although WaveHelper can use any subclasses inheriting from WifiMacHelper, we force user shall use subclasses inheriting from QosWaveMacHelper. NqosWaveHelper is also not permitted, because 1609.4 standard requires the support for priority.

== Open issues ==
Because some details are not define in the standard, the implementation is partially based on my personal knowledge. Some of the code needs modification or refactoring.
(1) WaveNetDevice inherits from NetDevice rather than WifiNetDevice which causes duplicated code.
(2) 802.11p device supports 802.11a with 10MHz or 20MHz. But wave devices do not support 802.11a 20MHz.
(3) The immediate access defined in 1609.4 is implemented simply, not considering channel guard interval.
(4) The current test suite is not extensive enough, which should be refactored.
== Next Goal ==
Besides some code that is not implemented well described in open issues, there are some important features are not implement yet which will be finished after midterm.
(1) implement vsa-repeater class.
(2) add support for transmit parameter control.
(3) support AlternatingAccess.
(4) complete some examples to show performance.
== References ==
[1] https://codereview.appspot.com/11685043/

[2] https://codereview.appspot.com/11480044/

[3] https://github.com/linlinjava/ns-3-dev-git

[4] https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC

GSOC2013WAVE MAC/MidTermReport

2013-08-01T16:08:23Z

Junling: /* Helpers */

== Abstract ==
My midterm code is composed of 2 patches in Rietveld issues 11685043[1] and 11480044 [2]. The first is to remove previous 802.11p-related code in src/wifi. then implement WAVE 802.11p MAC defined by IEEE 802.11p-2010 in src/wave, the second is partial implementation of WAVE 1609.4 MAC defined by IEEE 1609.4-2010 in src/wave.

To run examples, the command is ./waf --run wave-simple-device (or wave-simple-ocb or wave-simple-vsa. To run test suites, the command is ./test.py -s wave (or ocb). Besides that, users can read wave.rst document and wiki page[4].

For more information, The [https://github.com/linlinjava/ns-3-dev-git code] is hosted on github website, and the main [https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC WAVE MAC wiki page] is recommended. This midterm page will introduce what has been implemented until now, how the code is implemented, what are uncertain, and what are out of scope).

== 802.11p Implementation ==
The patch of 802.11p implementation removes previous 802.11p-related code in
src/wifi, which was based on an old and unsuitable 1609.4-2006 standard and only
partially implemented, then adds the MAC portion of the 802.11p-2010 standard,
that allows stations to send data packets directly.

The main features are 1) provide outside the context of a Bss (OCB) mode of
high MAC defined in the standard, 2) use specific EDCA parameters, 3) provide
vendor specific action frames and allow users to send management information over VSAs. Further study is needed to verify that this implementation of 802.11p is accurate and can undertake a large number of nodes.

== partial 1609.4 Implementation ==
The patch of 1609.4 implementation is to complete 1609.4-2010 standard based on 802.11p to deal
with multiple channels operation for vehicular environment. It would build on
the previous patch[1].The implemented features are 1) provide a NetDevice with special APIs, 2) allowusers to route different packets by different ways, 3) define standard channel coordination mechanism, user can inherit to overwrite for optimization research,4) provide two simple channel access assignment mechanisms.Because of time limit of this midterm review, some important features are notfinished, including 1) the support of VSAs frame in multiple channels environment, 2) the most important channel access assignment named AlternatingAccess. Besides that, some details not defined in the standard will need more consideration and tests.

== Helpers ==
In wave module, the helpers include QosWaveMacHelper, NqosWaveHelper, Wifi80211pHelper and WaveHelper. NqosWaveMacHelper and NqosWaveMacHelper are used to create MAC entities of WAVE. Wifi80211pHelper is used to create 802.11p devices that follow the 802.11p-2010 standard. WaveHelper is used to create WAVE devices that follow the 802.11p-2010 and 1609.4-2010 standards which are the MAC and PHY layers of the WAVE architecture.
The relation of them is described as below.

WifiHelper ----------use---------> WifiMacHelper
^ ^ ^ ^
| | | |
| | inherit inherit
| | | |
| | QosWifiMacHelper NqosWifiMacHelper
| | ^ ^
inherit| | |
| inherit inherit inherit
| | | |
| Wifi80211pHelper QosWaveMacHelper NqosWaveHelper
WaveHelper

Although Wifi80211Helper can use any subclasses inheriting from WifiMacHelper, we force user shall use subclasses inheriting from QosWaveMacHelper or NqosWaveHelper.

Although WaveHelper can use any subclasses inheriting from WifiMacHelper, we force user shall use subclasses inheriting from QosWaveMacHelper. NqosWaveHelper is also not permitted, because 1609.4 standard requires the support for priority.

== Open issues ==
Because some details are not define in the standard, the implementation is partially based on my personal knowledge. Some of the code needs modification or refactoring.
(1) WaveNetDevice inherits from NetDevice rather than WifiNetDevice which causes duplicated code.
(2) 802.11p device supports 802.11a with 10MHz or 20MHz. But wave devices do not support 802.11a 20MHz.
(3) The immediate access defined in 1609.4 is implemented simply, not considering channel guard interval.
(4) The current test suite is not extensive enough, which should be refactored.
== Next Goal ==
Besides some code that is not implemented well described in open issues, there are some important features are not implement yet which will be finished after midterm.
(1) implement vsa-repeater class.
(2) add support for transmit parameter control.
(3) support AlternatingAccess.
(4) complete some examples to show performance.
== References ==
[1] https://codereview.appspot.com/11685043/

[2] https://codereview.appspot.com/11480044/

[3] https://github.com/linlinjava/ns-3-dev-git

[4] https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC

GSOC2013WAVE MAC/MidTermReport

2013-08-01T16:07:27Z

Junling:

== Abstract ==
My midterm code is composed of 2 patches in Rietveld issues 11685043[1] and 11480044 [2]. The first is to remove previous 802.11p-related code in src/wifi. then implement WAVE 802.11p MAC defined by IEEE 802.11p-2010 in src/wave, the second is partial implementation of WAVE 1609.4 MAC defined by IEEE 1609.4-2010 in src/wave.

To run examples, the command is ./waf --run wave-simple-device (or wave-simple-ocb or wave-simple-vsa. To run test suites, the command is ./test.py -s wave (or ocb). Besides that, users can read wave.rst document and wiki page[4].

For more information, The [https://github.com/linlinjava/ns-3-dev-git code] is hosted on github website, and the main [https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC WAVE MAC wiki page] is recommended. This midterm page will introduce what has been implemented until now, how the code is implemented, what are uncertain, and what are out of scope).

== 802.11p Implementation ==
The patch of 802.11p implementation removes previous 802.11p-related code in
src/wifi, which was based on an old and unsuitable 1609.4-2006 standard and only
partially implemented, then adds the MAC portion of the 802.11p-2010 standard,
that allows stations to send data packets directly.

The main features are 1) provide outside the context of a Bss (OCB) mode of
high MAC defined in the standard, 2) use specific EDCA parameters, 3) provide
vendor specific action frames and allow users to send management information over VSAs. Further study is needed to verify that this implementation of 802.11p is accurate and can undertake a large number of nodes.

== partial 1609.4 Implementation ==
The patch of 1609.4 implementation is to complete 1609.4-2010 standard based on 802.11p to deal
with multiple channels operation for vehicular environment. It would build on
the previous patch[1].The implemented features are 1) provide a NetDevice with special APIs, 2) allowusers to route different packets by different ways, 3) define standard channel coordination mechanism, user can inherit to overwrite for optimization research,4) provide two simple channel access assignment mechanisms.Because of time limit of this midterm review, some important features are notfinished, including 1) the support of VSAs frame in multiple channels environment, 2) the most important channel access assignment named AlternatingAccess. Besides that, some details not defined in the standard will need more consideration and tests.

== Helpers ==
In wave module, the helpers include QosWaveMacHelper, NqosWaveHelper, Wifi80211pHelper and WaveHelper. NqosWaveMacHelper and NqosWaveMacHelper are used to create MAC entities of WAVE. Wifi80211pHelper is used to create 802.11p devices that follow the 802.11p-2010 standard. WaveHelper is used to create WAVE devices that follow the 802.11p-2010 and 1609.4-2010 standards which are the MAC and PHY layers of the WAVE architecture.
The relation of them is described as below.

WifiHelper ----------use---------> WifiMacHelper
^ ^ ^ ^
| | | |
| | inherit inherit
| | | |
| | QosWifiMacHelper NqosWifiMacHelper
| | ^ ^
inherit| | |
| inherit inherit inherit
| | | |
| Wifi80211pHelper QosWaveMacHelper NqosWaveHelper
WaveHelper

Although Wifi80211Helper can use any subclasses inheriting from WifiMacHelper, we force user shall use subclasses inheriting from QosWaveMacHelper or NqosWaveHelper.

Although WaveHelper can use any subclasses inheriting from WifiMacHelper, we force user shall use subclasses inheriting from QosWaveMacHelper. NqosWaveHelper is also not permitted, because 1609.4 standard requires the support for priority.

== Open issues ==
Because some details are not define in the standard, the implementation is partially based on my personal knowledge. Some of the code needs modification or refactoring.
(1) WaveNetDevice inherits from NetDevice rather than WifiNetDevice which causes duplicated code.
(2) 802.11p device supports 802.11a with 10MHz or 20MHz. But wave devices do not support 802.11a 20MHz.
(3) The immediate access defined in 1609.4 is implemented simply, not considering channel guard interval.
(4) The current test suite is not extensive enough, which should be refactored.
== Next Goal ==
Besides some code that is not implemented well described in open issues, there are some important features are not implement yet which will be finished after midterm.
(1) implement vsa-repeater class.
(2) add support for transmit parameter control.
(3) support AlternatingAccess.
(4) complete some examples to show performance.
== References ==
[1] https://codereview.appspot.com/11685043/

[2] https://codereview.appspot.com/11480044/

[3] https://github.com/linlinjava/ns-3-dev-git

[4] https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC

GSOC2013WAVE MAC/MidTermReport

2013-08-01T15:38:17Z

Junling:

== Abstract ==
My midterm code is composed of 2 patches in Rietveld issues 11685043[1] and 11480044 [2]. The first is to remove previous 802.11p-related code in src/wifi. then implement WAVE 802.11p MAC defined by IEEE 802.11p-2010 in src/wave, the second is partial implementation of WAVE 1609.4 MAC defined by IEEE 1609.4-2010 in src/wave.

To run examples, the command is ./waf --run wave-simple-device (or wave-simple-ocb or wave-simple-vsa. To run test suites, the command is ./test.py -s wave (or ocb). Besides that, users can read wave.rst document and wiki page[4].

For more information, The [https://github.com/linlinjava/ns-3-dev-git code] is hosted on github website, and the main [https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC WAVE MAC wiki page] is recommended. This midterm page will introduce what has been implemented until now, how the code is implemented, what are uncertain, and what are out of scope).

== 802.11p Implementation ==
The patch of 802.11p implementation removes previous 802.11p-related code in
src/wifi, which was based on an old and unsuitable 1609.4-2006 standard and only
partially implemented, then adds the MAC portion of the 802.11p-2010 standard,
that allows stations to send data packets directly.

The main features are 1) provide outside the context of a Bss (OCB) mode of
high MAC defined in the standard, 2) use specific EDCA parameters, 3) provide
vendor specific action frames and allow users to send management information over VSAs. Further study is needed to verify that this implementation of 802.11p is accurate and can undertake a large number of nodes.

== partial 1609.4 Implementation ==
The patch of 1609.4 implementation is to complete 1609.4-2010 standard based on 802.11p to deal
with multiple channels operation for vehicular environment. It would build on
the previous patch[1].The implemented features are 1) provide a NetDevice with special APIs, 2) allowusers to route different packets by different ways, 3) define standard channel coordination mechanism, user can inherit to overwrite for optimization research,4) provide two simple channel access assignment mechanisms.Because of time limit of this midterm review, some important features are notfinished, including 1) the support of VSAs frame in multiple channels environment, 2) the most important channel access assignment named AlternatingAccess. Besides that, some details not defined in the standard will need more consideration and tests.

== Open issues ==
Because some details are not define in the standard, the implementation is partially based on my personal knowledge. Some of the code needs modification or refactoring.
(1) WaveNetDevice inherits from NetDevice rather than WifiNetDevice which causes duplicated code.
(2) 802.11p device supports 802.11a with 10MHz or 20MHz. But wave devices do not support 802.11a 20MHz.
(3) The immediate access defined in 1609.4 is implemented simply, not considering channel guard interval.
(4) The current test suite is not extensive enough, which should be refactored.
== Next Goal ==
Besides some code that is not implemented well described in open issues, there are some important features are not implement yet which will be finished after midterm.
(1) implement vsa-repeater class.
(2) add support for transmit parameter control.
(3) support AlternatingAccess.
(4) complete some examples to show performance.
== References ==
[1] https://codereview.appspot.com/11685043/

[2] https://codereview.appspot.com/11480044/

[3] https://github.com/linlinjava/ns-3-dev-git

[4] https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC

GSOC2013WAVE MAC/MidTermReport

2013-08-01T15:21:13Z

Junling:

GSOC2013WAVE MAC/MidTermReport

2013-07-23T12:02:33Z

Junling: /* partial 1609.4 Implementation */

GSOC2013WAVE MAC/MidTermReport

2013-07-23T12:02:05Z

Junling: /* partial 1609.4 Implementation */

GSOC2013WAVE MAC/MidTermReport

2013-07-23T12:01:21Z

Junling: /* 802.11p Implementation */

GSOC2013WAVE MAC/MidTermReport

2013-07-23T11:55:37Z

Junling: /* Abstract */

GSOC2013WAVE MAC/MidTermReport

2013-07-23T11:54:47Z

Junling: /* Abstract */

GSOC2013WAVE MAC/MidTermReport

2013-07-23T11:53:03Z

Junling: /* 1609.4 Implementation */

GSOC2013WAVE MAC/MidTermReport

2013-07-23T11:51:34Z

Junling: Created page with "== Abstract == My midterm code is composed of 2 patches in Rietveld issues 11685043[1] and 11480044 [2]. The first is to remove previous 802.11p-related code in src/wifi. then..."

GSOC2013WAVE MAC

2013-07-22T14:02:26Z

Junling: /* How to use VSA frame to send management information ? */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-22T14:01:16Z

Junling: /* Usage */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== 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).

Usage:
#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/wave-simple-ocb.cc

== 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/wave-simple-device.cc

== 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 standards) 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-22T13:50:47Z

Junling: /* How to use VSA frame to send management information ? */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== 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).

Usage:
If users only want a 802.11p device, use code below.
#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/wave-simple-ocb.cc

== 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 standards) 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-22T13:49:37Z

Junling: /* How to use VSA frame to send management information ? */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== 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).

Usage:
If users only want a 802.11p device, use code below.
#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/wave-simple-ocb.cc

== 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 standards) 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/wave-simple-vsa.cc

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

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-22T13:43:04Z

Junling: /* Why here are two kinds of NetDevice */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== 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).

Usage:
If users only want a 802.11p device, use code below.
#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/wave-simple-ocb.cc

== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-22T13:34:31Z

Junling: /* Issues */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== 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).

Usage:
If users only want a 802.11p device, use code below.
#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/wave-simple-ocb.cc

== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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 could be used in an ITS-G5 implementation (the European standard).

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-22T12:16:11Z

Junling: /* Usage */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== 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).

Usage:
If users only want a 802.11p device, use code below.
#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/wave-simple-ocb.cc

== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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.

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-15T04:34:48Z

Junling: /* Plan and Weekly Progress */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== How to use OcbWifiMac ? ==
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).

Usage:
If users only want a 802.11p device, use code below.
#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/wave-simple-ocb.cc

== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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.

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-12T03:05:14Z

Junling: /* How to use OcbWifiMac ? */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: ]
June 1 – July 14: implement WaveNetDevice
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== How to use OcbWifiMac ? ==
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).

Usage:
If users only want a 802.11p device, use code below.
#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/wave-simple-ocb.cc

== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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.

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-07-12T03:04:04Z

Junling: /* How to use OcbWifiMac ? */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: ]
June 1 – July 14: implement WaveNetDevice
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== How to use OcbWifiMac ? ==
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).
If users only want a 802.11p device, use code below.
Usage:
#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/wave-simple-ocb.cc

== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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.

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-06-29T13:54:47Z

Junling: /* Vehicluar Networks and VANET simulations */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: ]
June 1 – July 14: implement WaveNetDevice
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== How to use OcbWifiMac ? ==
This model defines some wifi-like helpers: NqosWifi80211pMacHelper, QosWifi80211pMacHelper and Wifi80211pHelper.so write codes like WifiHelper.
Usage:
#include "ns/wave.h"
NodeContainer nodes;
NetDeviceContainer devices;
nodes.Create (2);
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
wifiPhy.SetChannel (wifiChannel.Create ());
NqosWifi80211pMacHelper wifi80211pMac = NqosWifi80211pMacHelper::Default();
Wifi80211pHelper wifi80211p = Wifi80211pHelper::Default ();
devices = wifi80211p.Install (wifiPhy, wifi80211pMac, nodes);
see wave/examples/wave-simple-ocb.cc
== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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.

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-06-29T13:03:02Z

Junling: /* Plan and Weekly Progress */

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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 includes 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: ]
June 1 – July 14: implement WaveNetDevice
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== How to use OcbWifiMac ? ==
This model defines some wifi-like helpers: NqosWifi80211pMacHelper, QosWifi80211pMacHelper and Wifi80211pHelper.so write codes like WifiHelper.
Usage:
#include "ns/wave.h"
NodeContainer nodes;
NetDeviceContainer devices;
nodes.Create (2);
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
wifiPhy.SetChannel (wifiChannel.Create ());
NqosWifi80211pMacHelper wifi80211pMac = NqosWifi80211pMacHelper::Default();
Wifi80211pHelper wifi80211p = Wifi80211pHelper::Default ();
devices = wifi80211p.Install (wifiPhy, wifi80211pMac, nodes);
see wave/examples/wave-simple-ocb.cc
== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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.

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-06-29T13:01:02Z

Junling:

= Project =
* Project Name: Implementation of WAVE 1609.4/802.11p
* Student: [mailto:linlinjavaer@gmail.com Junling Bu]
* Mentor: [mailto:guillaume.remy@ieee.org Guillaume Remy], [mailto:tomh@tomh.org Tom Henderson], [mailto:nikkipui@gmail.com 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).[https://github.com/linlinjava/ns-3-dev-git Code repository].
* Midterm report:[https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport https://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC/MidTermReport]
* About me: I am a second year Master student from China, and now is researching on vehicular network communication.
= Introduction =
== 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 includes 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)。

= Approach =
[[File:Architecture_of_the_implementation_of_1609.4_and_802.11p.jpg|

300px|thumb|right|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.
== Deliverables ==
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 ocb-wifi-mac-test-suit.cc, wave-net-device-test-suit.cc.
* 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: underway]
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 OcbWifiMac class and implement most method.
* Week 3/4 [status: ]
June 1 – July 14: implement WaveNetDevice
* 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, ocb-wifi-mac-test-suit.cc, simple-802.11p-example.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.

= Usage =
== How to use OcbWifiMac ? ==
This model defines some wifi-like helpers: NqosWifi80211pMacHelper, QosWifi80211pMacHelper and Wifi80211pHelper.so write codes like WifiHelper.
Usage:
#include "ns/wave.h"
NodeContainer nodes;
NetDeviceContainer devices;
nodes.Create (2);
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
wifiPhy.SetChannel (wifiChannel.Create ());
NqosWifi80211pMacHelper wifi80211pMac = NqosWifi80211pMacHelper::Default();
Wifi80211pHelper wifi80211p = Wifi80211pHelper::Default ();
devices = wifi80211p.Install (wifiPhy, wifi80211pMac, nodes);
see wave/examples/wave-simple-ocb.cc
== 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 standards) to identify differences.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/wave-simple-vsa.cc

= Issues =
== 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.

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

= References =

* [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: https://www.nsnam.org/bugzilla/show_bug.cgi?id=978.
* [3] ns-3.Bug 978 - Consolidate Wi-Fi MAC high functionality. [Online].Available: http://www.nsnam.org/bugzilla/show_bug.cgi?id=978#c16.
* [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

GSOC2013WAVE MAC

2013-06-27T13:55:35Z

Junling: /* Vehicluar Networks and VANET simulations */

GSOC2013WAVE MAC

2013-06-27T13:54:03Z

Junling: /* Vehicluar Networks and VANET simulations */

GSOC2013WAVE MAC

2013-06-27T13:50:22Z

Junling: /* Vehicluar Networks and VANET simulations */

GSOC2013WAVE MAC

2013-06-27T13:44:14Z

Junling: /* References */

GSOC2013WAVE MAC

2013-06-27T13:43:29Z

Junling: /* Vehicluar Networks and VANET simulations */

GSOC2013WAVE MAC

2013-06-27T13:26:57Z

Junling: /* Vehicluar Networks and VANET simulations */

GSOC2013WAVE MAC

2013-06-27T13:23:56Z

Junling: /* References */

GSOC2013WAVE MAC

2013-06-27T13:11:25Z

Junling: /* Introduction */

GSOC2013WAVE MAC

2013-06-27T13:05:49Z

Junling: /* References */

GSOC2013WAVE MAC

2013-06-27T13:04:11Z

Junling: /* Introduction */

GSOC2013WAVE MAC

2013-06-26T09:03:24Z

Junling: /* any previous code you think you can leverage */

GSOC2013WAVE MAC

2013-06-26T08:41:59Z

Junling: /* are there any vehicular application models to drive the code */

GSOC2013WAVE MAC

2013-06-24T06:29:00Z

Junling: /* is your model going to use different propagation models */

GSOC2013WAVE MAC

2013-06-24T03:07:11Z

Junling: /* is your model going to use different propagation models */

GSOC2013WAVE MAC

2013-06-24T03:04:03Z

Junling:

GSOC2013WAVE MAC

2013-06-24T03:02:33Z

Junling: /* is your model going to use different propagation models */

GSOC2013WAVE MAC

2013-06-24T02:48:53Z

Junling: /* is this model going to involve vehicular mobility of some sort */