Standards in VANET simulations using DSRC/WAVE under ns-3

VANET and DSRC

As a researcher, if you search the Internet for previous implementations related to VANET simulations using DSRC/WAVE you will see a lot of previously published works related to VANET/DSRC. But understanding them and doing genuine research or project on VANET within the scope and standards of DSRC is not a simple thing.

To understand this, first, we have to understand what is the original scope and standards of DSRC/WAVE. As far as I know, no open-source simulator including ns-2, ns-3 and Omnet++ is having a fully functional or complete DSRC protocol stack compatible with RFCs and White Papers of DSRC. Further, there are more than one standard to implement (such as European and US VANET standards)

VANET Simulation Support

From the perspective of open source simulator,

Omnet++ has limited support for doing VANET simulations using ‘Veins‘
As far as I know, under ns-2, Ali J Ghandour’s implementation of wave tool for ns2[1] contains a primitive implementation of 802.11p and DSRC. It is a genuine effort towards the implementation of DSCR protocol stack – but it only has limited minimum functionality.
The authors of ns-3’s WAVE module also cite Ali J Ghandour’s implementation as well as ‘Veins’ in their publication. In their paper[2], the authors present the model of the WAVE protocol stack and clearly mentioned that they only implemented up to the MAC Sublayer Extension (IEEE1609.4)

Limitations

So as per the above diagram, they only implemented some functionalities (from bottom to up) in the following three layers

IEEE202.11p
IEEE802.11p MAC Sublayer and
MAC Sublayer Extension (IEEE1609.4)

So, what they implemented is not a complete DSRC protocol stack as per the RFCs and White papers, and they also mentioned it in their publications.

So, it is obvious that Ali J Ghandour [1] or Junling Bu and others[2] definitely have not implemented any sophisticated routing algorithms for VANET. Because, basically, under VANET/DSRC standards, the safety messages will be transmitted only using “one hop” broadcast messages. And even such broadcasts may be repeated by the neighbouring nodes to pass the message to other nodes if needed.

So, no other “sophisticated” rouging is in the design of basic DSRC safety messaging. So What they implemented is only some basic “Safety Messaging” and “Non-Safety Messaging” functionalities of DSRC.

Of course, we can simulate a genuine VANET V2V scenario using these basic “Safety Messaging” and “Non-Safety Messaging” functionalities.

In [1] and [2] the original authors only demonstrated one-hop safety messaging and did some evaluation on MAC layer aspects of it. The graph in right is one of such output from [2] and the graphs at the bottom are the results from [1].

Misunderstanding(?)

But if you see the literature, you may see a lot of people are using this incomplete DSRC protocol stack to route packets in the “MANET” way using conventional routing MANET routing protocols such as AODV, DSDV etc., on this primitive stack. Of course, such protocols may be used in the future design of DSRC.

But, for the simple safety message decimation in V2V scenarios, using such complex proactive and reactive routing protocols are not advised and it is not as per the standards of DSRC.

One of the major confusion which leads students and scholar is an example script that is available under ns-3/Wave extension.

It is “vanet-routing-compare.cc“.

About “vanet-routing-compare.cc“.

In fact, that script was written by Scott E. Carpenter[3]. The following comments are at the top of that script.

* This example program allows one to run vehicular ad hoc
* network (VANET) simulation scenarios in ns-3 to assess
* performance by evaluating different 802.11p MAC/PHY
* characteristics, propagation loss models (e.g. Friss,
* Two-Ray Ground, or ITU R-P.1411), and application traffic
* (e.g. Basic Safety Message) and/or routing traffic (e.g.
* DSDV, AODV, OLSR, or DSR) under either a synthetic highway
* scenario (i.e. a random waypoint mobility model) or by
* playing back mobility trace files (i.e. ns-2 movement files).

In their paper[3], they mentioned the following :

“We develop a simulation script for ns-3 that we execute for several realistic VANET scenarios and compare routing throughput, end-to-end delay, and safety message packet delivery ratio (PDR) to assess routing protocol performance of AODV, DSDV, OLSR, and DSR. “

(But they never show any results with AODV, DSDV, OLSR, and DSR in that paper Because their research is not about contributing anything on routing protocols – it is about contributing something else at different layer of protocol stack -so, they didn’t even use any routing aspects from that example script- See the right side graphs from[3] – it is not measuring any routing aspects)

So, in this script “vanet-routing-compare.cc“., it is sending “Safety Messages” in a V2V scenario using Multi-hop proactive and reactive routing protocols, which is not at all the original scope of DSRC standard of safety messaging. (so it is only for some demonstration purpose ?). Please, someone, explain this to me (through ns-3 user group or e-mail) if I am wrong.

Most of the students and scholars spend their effort to route “safety message” packets using proactive and reactive routing protocols by following this script which is not at all the original scope and design of DSRC (as per its current standards). So, I believe, instead of spending their efforts on other important (and unimplemented) aspects of DSRC, most of them spend their efforts in the wrong direction.

My question is: Is the most popular VANET example script “vanet-routing-compare.cc” doing things within the original scope and standards of DSRC?

Of course, in the future one may invent an efficient routing algorithm to route a “safety message” packet under a V2V scenario within the limitations of DSRC standards – But, I can understand that, at present, one can not definitely do it with the present MANET routing protocols such as AODV, DSR, OLSR and DSDV.

Update (22-11-2021) :

The original author of the script “vanet-routing-compare.cc” Mr. Scott Carpenter, PhD Provided an Authentic answer to the above question. He spent much of his time outlining the correct directions of VANET routing research using that script – Thank you Dr. Scott Carpenter.

I hereby present the information he generously shared with me over email. I hope that this information will be useful to a lot of students and scholars who are trying to do research and VANET and particularly on VANET-routing.

Mr. Pandian,

I read with interest your comments on the ns-3 script that I authored some time ago, vanet-routing-compare.cc. I understand and agree with your premise that using it for VANET routing research requires quite a bit of additional attention to details, and that you provide some of those excellent thoughts and guidance to potential researchers. However, I feel that there is some possible missing background as to the scripts development and usages that have led to misunderstandings among researchers. Allow me an opportunity to attempt a better and more detailed explanation of the script’s evolution and purpose to hopefully clear up some of those misrepresentations that I may have inadvertently caused. But, also please understand that my comments that follow are based on mainly my memories of work on that script, and I have stepped away from continued research and maintenance of it for quite some time now.

The script initially evolved from the (at that time) much more familiar script, manet-routing-compare.cc, as advised to me by the ns-3 community. The goal at the time was to provide a working example that shifted away from the “manet” view of the world, and into a way to explore “vanet” scenarios. I was advised to start by copying a well-known working example (e.g., manet script –> vanet script) instead of just creating a new script from scratch, which would be harder to explain to the ns-3 research community.

I believe the work that you ended up citing in your comments as [3] was the result of that initial work. However, that work was merely a two-page proposal to the ns-3 community with a poster presentation, and it was not reviewed, nor “published” in the traditional sense. For example, that citation was not an accepted full-length paper on the ns-3 workshop. (Actually, it was as the start of my PhD research, and was a part of a class project, with the main goal to get an “A” in the class. Mission accomplished!). Following that presentation and with comments from peers and my advisor, work continued on expanding and correcting that script, resulting in a work that was peer-reviewed and published the following year [5]:

[5] An obstacle model implementation for evaluating radio shadowing with ns-3[https://dl.acm.org/doi/abs/10.1145/2756509.2756512]

Minor point, but I would prefer that [5] be referenced over what you have used and have listed as [3].

The script documents that it “draws from several ns-3 examples” (including the manet-routing example) and that if allows “many parameters to be modified”. The intend of this script was to support research using ns-3, and was not necessarily meant to precisely model the full-stack of DSRC, as you have correctly discovered.

One of the parameters in the script allows routing to be completely disabled (when setting m_protocol == 0). This was the primarily way that I personally used the script in my continuing research. However, I understand how others would use the script to evaluate different routing protocols and their potential usefulness in VANET topologies. Perhaps this point needs to be stressed more to potential researchers. That is, 1) it is okay to disable routing altogether when using the script, for a somewhat more realistic approach to using it to mimic a VANET scenario using ns-3, and 2) otherwise enabling ANY of the supported routing protocols is meant to provide a means to “test” the effects of routing in a VANET, but, as you correctly point out, this is not a part of existing standards.

Regardless, I assert that the question as to whether or not a VANET should support multi-hop routing is still an interesting and unsettled question, and so the means to help researchers in that regard may be helpful. As having formerly served as a member of the SAE J2735 DSRC Tech Cmte that authors and amends those DSRC standards, I can assure you that interesting research does in fact guide the standards and their revisions. That being said, it is still the current case that multi-hop routing does not appear in current standards (at least as of the time that I ended my research in the area). An alternate approach to VANET routing using geoaddressing is described in [6].

[6] SafeRelay: Improving safety in the time-constrained VANET with geoaddresing [https://ieeexplore.ieee.org/abstract/document/7991899]

Another parameter of the script, the “BSM packet size”, is completely configurable, and from this I think we can see that this script does not implement the DSRC message set and so does not handle specific processing of messages. Again, those areas are up to the individual researcher to consider and address.

Although I found the fidelity of the ns-3 wireless models and the discrete event simulator to be well ahead of other simulators (at the time of my research), one of the most interesting outcomes of my VANET research was that none of them handle well the effects of obstacles. Consider that most models rely on some random bit-error rate (BER) model, that is implemented using some random variable that assumes i.i.d. properties. As such, any BSM packet ends up being equally likely to be missed as any other packet. While this is often appropriate in static wireless configuration scenarios, this is generally not the case in dynamic environment that a VANET presents, where many obstacles (i.e., trucks, tunnels, trees, metal road signs, hills, etc.) present a very harsh wireless environment where packet loss becomes not independent of other packets, but conditionally dependent upon them. That is to say, once a truck comes between two VANET-enable vehicles, then communications will be poor until that truck moves out of the way. These results are described in [7]

[7] BUR-GEN: A Bursty Packet Generator for Vehicular Communication Channels [https://ieeexplore.ieee.org/abstract/document/8444721]

That you for commenting on the vanet-routing-compare.cc script. I agree that researchers that make use of it should fully understand the DSRC stack and its limitations, and how they have been reflected within ns-3. Furthermore, the use of ns-3 as a research tool to explore areas that are and are not currently defined in existing standards is quite useful. The places where the ns-3 simulator lacks completeness serve as opportunities for researchers to extend and correct the ns-3 implementation by contributing corrections and new models.

Happy to provide more background on my memories of the script, if it would be in any way helpful.

Best,
Scott Carpenter, PhD

After, reading his elaborate answer, I can now say the following :

While learning ns-3, one can certainly use the example script “vanet-routing-compare.cc” and start to realize the difference between MANET and VANET and do some elementary class projects or assignments on VANET routing, and try to prove that existing MANET routing protocols will not be suitable under a VANET scenario.
One can use the script “vanet-routing-compare.cc” for testing and improving VANET features such as “Safety Messaging”, MAC layer or other layer aspects of DSRC, only after completely disabling the routing functionality by setting the parameter m_protocol == 0. By doing so, one can do good research work using this script.
Of course, one can certainly do a state of the art research work on “VANET routing” using the example script “vanet-routing-compare.cc”– but for that, (according to my understanding,) they should try to incorporate a VANET routing layer functionality in the existing DSRC stack and may try to experiment with existing routing protocols on that new stack. And of course, one may try to contribute an innovative, state of the art VANET routing protocol that will work on their new routing-capable DSRC stack. (I think, up to date, no one did this on ns-3 – I mean (a) a multihop, routing-capable DSRC stack and (b)an innovative VANET routing protocol that will work on that new multihop, routing-capable DSRC stack)
So, the research and contributions on multihop, routing-capable DSRC are still open.
Further, research and contributions on multihop VANET routing protocol are also still open.

Update:

“ms-van3t” [4] is an excellent Multi-Stack VANET Framework is a set of modules developed for ns-3. Those who what to contribute something in the routing layer of VANET may try to incorporate it with this model.

You may find a procedure for installing ms-van3t under chroot jail” at the following link:

Installing ms-van3t – A Multi-Stack VANET Framework for ns-3

This module can be used to build and simulate ETSI-compliant VANET (V2X) applications using SUMO and ns-3[4].

The most interesting aspect of this module is: It can interact with SUMO from an ns-3 simulation using the standard “TraCI” interface(“Traffic Control Interface”) of SUMO. So that, it is possible to create VANET nodes dynamically by reading the events of SUMO configuration file during the run of the ns-3 simulation. Even the simulated traffic aspects and the simulated SUMO vehicles can be controlled from the running ns-3 simulation.

It may be a good choice for simulating realistic VANET scenarios by coping with VANET/DSRC standards.

The following ns-3-TraCI-SUMO integration output may show its elegance.

Features of ms-van3t

ms-van3t currently supports two stacks/communication technologies for V2I/V2N:

802.11p, communicating, for instance, with a Road-Side Unit
LTE, for V2N communications

The ms-van3t team confirms the existence of the following features in this ns-3 extension.

802.11p, LTE and C-V2X access technology models
Emulation mode through fd-net-devices
Possibility of removing SUMO from the loop and using real GPS trace to manage mobility
A couple of applications to showcase and explain how to use the framework in V2I and V2V scenarios

Further, they outlined some of the possibilities of integrating existing modules of ns3 with their extension.

I think ms-van3t will have a good future in the ns3-VANET world.

Now I hope that, finally, Malinverno[4] and his team is doing a good job on ms-van3t to fulfil all the standards of a typical DSRC protocol stack and make ns-3 a fully VANET compliant simulator.