Version 1.5.1rc2 is the direct ancestor to which our changes are added. During the composing of the thesis, the number for the new version is not determined yet. For simplicity, in this thesis, we call it version 1.5.2. However it could be different from its actual version number in the project repository.
To ensure the differences of experiment results are only caused by the changes of scenarios without the interference by possible implementation changes, we conducted experiments on both version 1.5.2 and version 1.5.1rc2 with the default scenario. We expected acceptable differences between their results. In software engineering, it is called system testing because it involves all components of the software. And we actually found a critical bug during this step which will be discussed later in this section. 10-4 10-3 10-2 10-1 100 100 101 102 103 104 105 P[X>x] Time [s] CCDF of contact duration v1.5.1rc2 v1.5.2 10-2 10-1 100 100 101 102 103 104 105 106 P[X>x] Time [s] CCDF of inter-contact time v1.5.1rc2 v1.5.2
Figure 18: Comparing CCDF of contact duration and inter-contact time between version 1.5.1rc2 and 1.5.2
As one might think by using the same seeds for random number generating, the results should be exactly the same. Thus, there should be no need to plot graphs for those metrics. Using some file compare utility, for instance diff, on the resulted reports will do the work. However, in fact, the implementation changes are not required to have the same number of random number requests nor to keep the requests in the same order. For example, in OfficeActivityMovement class, to
support multistory feature, it has to request an extra random number for randomly determine the floor it belongs to even it only has one floor. As a result, the numbers in resulted reports are different. Figure18shows theCCDFof contact durations and inter-contact times for version 1.5.1rc2 and 1.5.2. We can see the lines are almost overlapping all the time.
0 2000 4000 6000 8000 10000
Mon 0 8 16 Tue 0 8 16 Wed 0 8 16 Thu 0 8 16 Fri 0 8 16 Sat 0 8 16 Sun 0 8 16
Hourly activity
Time [h]
Hourly activity with same scenario
151rc2 160
Figure 19: Comparing hourly activity between version 1.5.1rc2 and 1.5.2 The run chart in Figure 19shows how the hourly activity level varies for a whole 7-day week. There are two peaks each day. The duration between two peaks is roughly 8 hours which correlates to the working hours set in the scenario. Except the first 16 hours on Monday, the timing of activity level variation of the two version match quite well. During the first 16 hours of the simulation, version 1.5.2 apparently has much more contacts happened than version 1.5.1rc2. This is because the bug we mentioned in the beginning of this section. With this bug, the movement warmup feature does not work.
The movement warmup feature lets nodes start to move before the zero sim- ulation time, so that when simulation starts, the mobility model has reached a stationary state. This is done by setting the initial simulation time with a negative value, making location updates start from that negative value, and keeping network status updates and message events heppen only after the zero simulation time. The initial simulation time is used to generate the time of the first location update for each nodes. For example, if the update interval is 0.1 second, and the inital simu- lation time is -1000 second, then the time of the first location update will happen at -999.9 second. However, in version 1.5.1rc2, when generating the time of first location update, the initial simulation time is not set to the negative value yet, and still with the default zero value. Thus no node will update its location before the zero simulation time. Which further means the movement warmup feature does not
work at all. In version 1.5.2, we fixed this bug by setting the initial simulation time before generating the time of first location update.
As movement warmup feature does not work in version 1.5.1rc2, all the WDM
nodes start to wake up at home only after the zero simulation time. While in version 1.5.2, at the zero simulation time, there are WDMnodes that are already woke up and on the bus to office. That explains why there are more contacts heppened in the first 16 hours.
101 102 103 101 102 103 104 Unique encounters Total encounters version 151rc2 101 102 103 101 102 103 104 Unique encounters Total encounters version 160 1 1.5 2 2.5 3 3.5 4
Figure 20: Total encounters vs unique encounters
In Figure 20, the two scatter diagrams depict the heterogeneity of the mobility patterns in the simulation. We can see the distribution pattern of the dots in version 1.5.2 is compliant with the pattern in version 1.5.1rc2. Addionally, for version 1.5.2, benefited from an improvement on reporting module, the dots can be painted in different colours to distinguish their movement model.
From the diagram of version 1.5.2, we can tell there are four types of nodes:
WDMnodes with car(in blue), WDMnodes without car(in red), public transporta- tion vehicles(in green) and SPMBM nodes(in orange). As WDM nodes with car move fast and always along the shortest path, they normally take less time on the road. That means their unique and total encounters are both smaller than those of WDM nodes without car. However because of the distribution of home and office location, and the different size of districts they live in, the differences between with car and without car are blurred. Public transportation vehicles are almost always moving, so they have larger total encounters than travelers, around 10000. However their locality are largely affected by their routes, like how long the route is and how many districts it across. SPMBMnodes for sure are the ones in the right top corner. That is because they are almost always moving and can move towards any where on the road network.
Figure 21shows no significant difference on the network metrics between version 1.51rc and 1.5.2. 10000 15000 20000 25000 30000 35000 40000 45000 50000 v1.5.1rc2 v1.5.2 Latency 40560 38773 0 2 4 6 8 10 v1.5.1rc2 v1.5.2 HopCount 7.17 7.19 0 0.2 0.4 0.6 0.8 1 v1.5.1rc2 v1.5.2 Delivery ratio 0.8688 0.8696
Figure 21: Message statistics
Based on the experiment results of the two versions of implementation, we con- sider the variations and differences are acceptable, and verified that the implemen- tation changes introduced by version 1.5.2 works correctly one existing features.