Problems with WaveBsmHelper

[Ricardo Filho]

Hi,

I was trying to simulate the BSM mechanism, and I found this error message: 

'build' finished successfully (2.200s)

terminate called after throwing an instance of 'std::out_of_range'

  what():  vector::_M_range_check

I also tried run it under debuggers (dbg and valgrind), but I can't find the error source. The code (bsm.cc) and debuggers messages are attached.

 I appreciate any help.

Ricardo Filho

[Konstantinos]

Hi Ricardo,

Please provide the mobility file you used as well.

[Ricardo Filho]

Sorry, I forgot that. It's attached.

[Konstantinos]

Hi,

Using backtrace command in GDB, you would get this 

#9  0x000000010178b297 in std::__1::vector<int, std::__1::allocator<int> >::at (this=0x1017f17d8, __n=1) at vector:1467

#10 0x00000001017886a6 in ns3::BsmApplication::GenerateWaveTraffic (this=0x1045c2de0, socket=<value temporarily unavailable, due to optimizations>, pktSize=200, pktCount=1990, pktInterval=<value temporarily unavailable, due to optimizations>, sendingNodeId=1) at ../src/wave/model/bsm-application.cc:241

If you then look closely your code you can see that you install the applications before setting up the interfaces. I would recommend to follow a more bottom-up approach when writting your scenarios. First create the nodes, then place them where you want to be (ie install mobility), then install net devices, after that the protocol stack/interfaces and last you install the applications. That ensures that the nodes are ready to start the applications.

Regards,

K.

[Tommaso Pecorella]

Hi,

unfortunately things are not that simple. The problem is that BsmHelper is all but obvious and it have some quirks that should have been ironed out before its inclusion in ns-3. Sadly, sometimes something pass through the reviews without being noticed.

The applications needs an explicit setup of a static vector in BsmHelper, and you didn't set it up.

Check the function

void VanetRoutingExperiment::CourseChange

in the file src/wave/examples/vanet-routing-compare.cc

You should do more or less the same. When a node change its position, you must update the vector accordingly.

Counterintuitive ? Yes.

Could be made better ? Yes, we're open to patches.

Cheers,

T.

[Scott Carpenter]

A couple of points to add:

1. Yes, BsmHelper is not (yet) ideal, and could benefit from some documentation and/or maybe API changes.  The original intend was to couple that with the VANET BSM generation application.  So, using it outside of the framework of the VANET script will require some more thought / work to make it "stand alone". 

Part of what BsmStats and helper are trying to work-around are:

2.  The well-discussed "FlowMonitor does not work with broadcast packets."  The VANET application is broadcasting from every node a Basic Safety Message (BSM) 10 times per second.  While FlowMonitor does not work with broadcast packets, there remains a need to capture some statistics for those packets.  BsmStats is intended to allow someone to set up a "range" of distances and then track the PDR, i.e., the percent of expected packets that are actually received within the set of user-provided ranges (i.e., distances from the transmitter).  I guess I would favor / suggest a refactoring to more generally support a stand-alone mechanism to capture statistics for broadcast packets.

3.  Node in a VANET need to "start" and "stop" moving.  I think this has also been discussed in the forum, but as of yet there is not an implementation to generically support starting and stopping nodes. Playing back a mobility file in the vanet-routing-compare script simulates cars (nodes) moving.  But, not all nodes are initially "started".  Some of them may actually sit idle for some part of the simulation (e.g., until the "driver" turns the key to start the car and finally gets the vehicle underway).  Thus, when playing back a mobility file, it is (currently) left up to the user to specify when nodes are actually considered to "start" moving.  Similarly, there is an issue when vehicles reach their destination (but the simulation is NOT yet completed), then such vehicles should be thought of as "the car reached the destination.  User turned off the key, so the node should stop transmitting packets.  This, again, is not necessarily "normal" in an ns-3 script, which is why the static vector as mentioned in the prior post needs to be controlled by the user - i.e., to indicate when nodes are moving, or stopped, as corresponds with the user's mobility playback file.  Ultimately, I would hope this part could be refactored to support StartNode() StopNode() concepts.

-Scott

[Ricardo Filho]

Thank you all for your answers, I did some changes on the code: I believe that now the code follows the bottom-up approach, and I added the CourseChange method.

 Any error is reported. But I think that BSM are not sent. The PDR  are reset for all ranges.

And Tommaso, what does mean update the vector accordingly?

Sorry for this late message.