Jun.-Prof. Dr.-Ing.

Christoph Sommer
Cooperative Mobile Systems – CCS Labs

Cooperative Mobile Systems [CMS]

Evaluation with R & Flooding project

Tobias Hardes
10.05.2019 - 09.06.2019

1 Introduction

In this lab we’ll implement a flooding algorithm. We prepared a skeleton code, which is available on the
course website: http://www.ccs-labs.org/teaching/cms/2019s/SimpleFlooding.tar.gz
You can import the code in the same way as in the previous lab. All tasks in this lab will be discussed after
the deadline. For this, we will ask at least one student to show results (plots, videos, running simulations,
...) on the projector. In any case, please prepare a PDF / PowerPoint presentation to give answers to the
questions in the next lab. Your presentation should take about 10 minutes.

Attention
Make sure to submit in groups of exactly two (no single submission and no groups of more than two
students.)

2 Flooding

Task 1
Start the simulation and observe the behavior. In a terminal, start the daemona by executing:
<your-dir>/veins$ ./sumo-launchd.py -vv
The daemon needs to be running all the time. You can minimize the terminal for now.
a
http://veins.car2x.org/documentation/sumo-launchd/

The network is a Manhattan Grid with random traffic, random vehicle distributions, and building dimensions
gathered from Manhattan, New York. For better insight of the behavior you can inspect the code of the
MySimpleFlooding.cc application.
From the detour-Project you got a first impression about possible problems when message propagation is
implemented. In the next lecture you’ll get some ideas for techniques in terms of information dissemination
in networks. During this lab, we want to improve the SimpleFlooding project.
An RSU is placed in the center of the network and it is transmitting only once after a variable time x with
0 s ≤ x ≤ 1 s. This transmission is the initial step in the simulation. The packet might be received by a first
car in the network and then the propagation in the network starts. The skeleton code also contains some
basic statements to collect statistics you can use for your later evaluation.

Page 1 of 4
 Task 2
What are possible strategies to implement flooding for the given network?
Think of measurements which can be done in order to quantify the robustness and the speed of your
implementation.
Prepare your ideas until 22 May. We’ll meet in room FU.511 to talk about them.

You’re allowed to change the FloodingMessage and the SimpleFlooding code to improve the message distribu-
tion in the network. Do not change the network, the RSU logic or configurations given in the omnetpp.ini
file. Consider the following steps and tasks:

Task 3
• Run your implementation with the provided network and verify that your flooding is an improve-
ment.
• Collect data about how many nodes received the message, dissemination delay (due do packet
loss) and so on. The skeleton code contains almost everything you need for a basic evaluation.
• Make sure to show the improvement of your implementation by comparing your results to the
initial skeleton.
• We prepared a script which converts the *.vec and *.sca files into .csv files. The file can be found
in simulation/analysis/eval.sh.

Mandatory Task

• Describe the flooding logic you’re using. In addition to a textual description, you can also include
diagrams. If you do so, make sure that they are easy to understand.
• Record data to measure the efficiency, robustness and speed of your dissemination.
• Describe the metrics you use and how they are calculated.
– Robustness (15 points)
– Protocol speed (15 points)
– Efficiency (20 points)
Use max. 160 words for each description.
• Create suitable plots for each of the three metrics depending on the amount of vehicles in your
network (number of vehicles on x-axis):
– Robustness (15 points)
– Protocol speed (15 points)
– Efficiency (20 points)
Explain your choice for each metric with max. 160 words each. You can choose any type of plot
we showed in the CMS lecture.
• Please upload a single PDF in PANDA including headings for the different questions.

CMS Lab – Evaluation with R & Flooding project Page 2 of 4

3 Collecting Global Statistics

The skeleton used a global variable to count the nodes that received a packet. Global variables aren’t very
good for use in the model, because there is no reset statement when OMNeT++ rebuilds a network and
other disadvantages. This may produce surprising results. Second, they prevent you from parallelizing the
simulation. When using parallel simulation, each partition of the model runs in a separate process, having
their own copies of global variables. This is usually not what you want.
It is possible to circumvent this problem by using the initialize and finish methods. However, a more
suitable method is to introduce a global module for statistics.

Task 4
Change the code such that the value for overallReachedNodes is collected by a global module.

4 Tips and tricks

• The skeleton code has an issue that you already know from the detour project.
• You can enable the SUMO-GUI to visually inspect the cars in the network. For this you need to add a
parameter to the sumo-launchd:

1 ./sumo-launchd.py -vv -c sumo-gui

• In order to speed up your simulation, we recommend to run it on the command line without the GUI.
Have a look to the OMNeT++ manual to see how this is done.
• The number of simulation runs is set to 10. For testing, you can change this to a lower value in the
omnetpp.ini:

omnetpp.ini

1 repeat = 10

• In order to change the number of vehicles in the network you can change the numVehicles parameter
in the omnetpp.ini file:

omnetpp.ini

1 *.vehicleInserter.numVehicles = 150

• The skeleton code contains statements which are not ready to use. Check if they are really correct and
implemented in a correct way.
• All nodes in the OMNeT++ simulation GUI are colored. Initial they are red, but they can turn to green
and get a small additional icon:
– Red: Nothing received

CMS Lab – Evaluation with R & Flooding project Page 3 of 4

 Figure 1: Usage of colors in the simulator.

– Green: Message received

– Green with icon: Message received and sent again
figure 1 shows an example.
• The global module can be implemented as a cSimpleModule.
• The global module doesn’t need any channels. Simple C++ techniques are enough.
• Examples of global modules are the ConnectionManager or the AnnotationManager you already know
from the first lab assignment.
• You can find several scripts in <your-dir>/SimpleFlooding/simulations/analysis. Those scripts
are nicer to use than the Scavetool. The doEval.sh shows an example call.

Contact

• Tobias Hardes: http://www.ccs-labs.org/~hardes/

• CMS Website: http://www.ccs-labs.org/teaching/cms/2019s/

CMS Lab – Evaluation with R & Flooding project Page 4 of 4