Supporting VoIP traffic data loads

In a final set of experiments, we investigate the issue of delivering sessions with VoIP level data rates. In 6.2.2, we saw that both algorithms have trouble when data rates go up to VoIP levels: AntHocNet drops to a delivery ratio of 67% and a delay of 0.19s, while AODV has a delivery of 63% and a delay of 0.1s. Jitter is for both algorithms around 0.15s. To support good quality VoIP, a delivery ratio of 90% is needed, and end-to-end delay should not exceed 0.15s (see [189]).

Jitter is normally considered in conjunction with delay, as applications deal with jitter by keeping packets in buffer for a short time before delivering them; jitter can therefore be added to delay to count towards the delay limit [189]. Using this approach, we can see that both in terms of delivery ratio and delay, the standards needed to deliver good quality VoIP conversations are not met by either of the algorithms. Here, we investigate this in more detail.

We do tests varying the number of data sessions from 1 to 10. All sessions are bi-directional and send 25packets/s. The results are show in figure 6.9.

When few sessions are started, we can see that AntHocNet manages to reach the formulated VoIP requirements both in terms of delivery ratio and delay (when delay and jitter are added together). AODV on the other hand falls short on both requirements. Then, when the number of sessions is increased, also AntHocNet fails to reach the VoIP requirements.

These reported results are averages over all the started communication ses-sions though. In order to get a more precise view, we investigate for each scenario how many of the individual sessions reach the cited requirements. In figure 6.10, we show this number (a) as a fraction of the total number of started sessions, and (b) in absolute terms. We can see that using AntHocNet, at least a few of the sessions can obtain VoIP quality. When only one session is started, it almost always gets the required quality (in 90% of the cases, as shown in figure 6.10a).

Then, as more sessions are started, the fraction of them that receive VoIP qual-ity decreases. However, in absolute terms, the total number of sessions that receive the required quality grows up to almost 2.5 when 4 sessions are started, and then remains more or less stable. Finally, when more than 7 sessions are started, the absolute number also decreases. When 10 sessions are started, on average about only 1 receives VoIP quality. This is because too many sessions are interfering with each other. For AODV, the number of sessions receiving the required service quality always remains low.

The results show that using AntHocNet it is in principle possible to support VoIP in the given urban scenario. However, not all sessions can get the required levels of service, and when too many sessions are started, all of them suffer.

This indicates that it might be useful to refuse some sessions to start (e.g., sessions that would likely not receive the required quality anyway, because they need paths that go through highly congested or poorly connected parts of the network) in order to be able to deliver a good service to other sessions. This points to the importance of the use of admission control or some other system for Quality-of-Service support in resource limited urban MANETs: if only sessions that are likely to get the levels of service they need are allowed to start, less

0.6

Figure 6.9: Results for AntHocNet and AODV with VoIP level data rates (25packets/s) and varying numbers of data sessions in the urban scenario. We report (a) delivery ratio, (b) average end-to-end delay, (c) average delay jitter, (d) overhead in number of packets, and (e) overhead in number of bytes.

bandwidth is wasted. For existing work on admission control in AHWMNs, see e.g. [81].

0

Fraction of sessions reaching VoIP requirements

Number of data sessions

Number of sessions reaching VoIP requirements

Number of data sessions AntHocNet

AODV

(a) (b)

Figure 6.10: Sessions reaching VoIP quality requirements in terms of delivery ratio, delay and jitter: (a) as a fraction of the total number of started sessions and (b) in absolute numbers.

6.3 Conclusion

In this chapter, we have studied the behavior of AntHocNet in an urban scenario.

First, we have given a detailed description of how we obtained a good and efficient simulation of the working of an AHWMN in an urban environment.

Then, we have presented results of a set of experiments in which we compared the performance of AntHocNet and AODV in this setup.

As a setting for our urban scenario experiments, we used an area of 1561 × 997m²in the center of the Swiss town of Lugano. We modeled node mobility in this area using an adaptation of RWP in which node movements were limited to the streets and open spaces in the town. Urban radio propagation was modeled using a preprocessing step, in which the network surface area was discretized and signal strengths between each of the discrete points was calculated off-line using a raytracing approach. Finally, network data traffic was modeled using bidirec-tional point-to-point data sessions with varying data rates that could represent the typical data load generated by different types of interactive communication applications. We used the QualNet discrete event network simulator, and used the same network protocols as in the open space experiments of the previous chapter.

In the results section, we first investigated general network properties of the AHWMN in the urban environment. We observed that compared to open space scenarios, nodes typically have less neighbors, network connectivity is less good, paths are longer, and the network change rate is higher. Then, we discussed the results of a number of tests in which we compared the performance of AntHocNet to that of AODV. In the first tests, we studied the effect of increasing data rates. We observed that AntHocNet could outperform AODV for most data rates, but noticed that it had more difficulties with the highest data rate. Next, we investigated what happened when the number of data sessions was increased.

We saw that AntHocNet could each time outperform AODV, and that it was

AODV that had large difficulties when the number of sessions became high.

Then, we did tests with increasing number of nodes. Both algorithms had more difficulties in networks with more nodes. AntHocNet outperformed AODV when low and medium data rates were used, but had more difficulties at the highest data rate. After that, we also investigated what happened with increasing node speeds. We found that increasing the node speed had a relatively small negative effect on the performance of both algorithms. Finally, we considered whether it would at all be possible to deliver the level of service needed to support VoIP conversations in the given scenario. Our conclusion is that using AntHocNet, it is in principle possible, if at least a mechanism is applied to control which sessions are allowed to start.

Chapter 7

Towards the

implementation of adaptive routing in AHWMNs

Most existing work on the development of routing algorithms for AHWMNs is carried out in simulation, rather than in real deployment studies. This is also the case for the work that has been presented in this thesis. An important fac-tor that influences the choice for simulation as a research tool is that building an AHWMN testbed is expensive and requires a substantial effort, in which many technological issues need to be resolved. Simulation is often the only real option for researchers who want to investigate a specific aspect of AHWMNs such as routing. Moreover, simulation also gives other advantages, such as the ease with which different and large test scenarios can be investigated, and the possibility to easily repeat previous tests. Nevertheless, since a few years there is a growing awareness in the AHWMN research community that simulation ex-periments have their limitations [54,117,124,260]. The main concern is that the abstractions and simplifications used in simulation studies can have a significant impact on the network behavior, so that observed results can diverge from what can be expected in reality. Consequently, researchers are increasingly interested in the use of real world testbeds to support research in AHWMNs. Several such testbeds have been set up, such as the Roofnet experiment of MIT [30] and the Magnets project of DTL [148].

In the current chapter, we describe work that we have done regarding the implementation of adaptive routing in AHWMNs. We have developed a system, called MagAntA¹, that is aimed at supporting adaptive routing in Linux based AHWMNs. MagAntA runs as a daemon in user space. It is written in C, and possesses a modular structure, which makes it easy to adapt and extend with

1The name MagAntA is derived from the Magnets testbed set up at DTL, the color magenta of the DTL logo, and the ants that formed the initial inspiration for the adaptive routing algorithms we study.

new algorithms.

In what follows, we first describe related work on AHWMN testbeds and the implementation of AHWMN routing algorithms. Then, we describe our MagAntA routing system. Finally, we discuss how MagAntA integrates with the network protocol stack in the Linux kernel. The material described in this chapter was based on work carried out during an internship at DTL. It has been presented in [101].

7.1 On the deployment of AHWMNs

Here, we provide a general discussion on the deployment of AHWMNs. We first discuss existing AHWMN testbeds. In particular, we give details about the Magnets testbed of DTL, in order to give a concrete example of the kind of networks that MagAntA was developed for. Then, we discuss the implemen-tation of AHWMN routing algorithms. We first describe in general the kind of issues that need to be addressed when implementing a routing algorithm for AHWMNs. Then, we discuss existing implementations that have appeared in the literature.