We have validate MMHC and assess its performance over the Path Reconfiguration Scenario depicted in the figure below. The goal is to verify if and to what extent the exploitation of the Path Mobility (PM) parameter allows the Routing Manager (RM) component to proactively trigger path modifications before path disruptions, thus achieving relevantly shorter connectivity interruptions than for reactive path management.
The ns-2 tested scenario includes one sender and 2 gateways:
the path to Gateway2 is reliable, since all nodes in the path are still, but provides a limited bandwidth;
the path to Gateway1 is greatly unreliable, since Gateway1 and the two intermediary nodes frequently leave the cooperating network, so disrupting connectivity; anyway, this shorter path when available supports wider bandwidth.
The reported results refer to the case of mobile nodes starting from the position in the figure below and staying there for 15s. Then, they start moving forth and back along 30m-long trajectories away from their position at 4m/s, with a 5s pause each time they reaches their starting position.
Path Reconfiguration Scenario
At simulation start-up, the sender exploits the left path (both paths have high PM and the left path is preferred because shorter). Then, once the nodes on the left path have started moving, the sender behavior changes depending on whether exploiting PM. If not, the sender reactively switches to the right path only after left path breaks. With PM, instead, the sender proactively selects the right path few seconds after the nodes start moving, largely in advance with respect to actual path disruption. When the mobile nodes return back to right, the sender exploits the left path again (to better remark how PM affects connectivity, handover length is set to 0s in these simulations).
The table below reports average performance results over a set of 100 runs of 110s-long simulations. The sender starts transmitting data after 10s and stops after 100s (bitrate is 0.7Mb/s). PM exploitation relevantly enhances the continuity of selected MMHC paths, by improving user experience when accessing continuous services, such as VoIP. In addition, notwithstanding the left path would allow greater maximum throughput, the continuity ensured by the right path increases the percentage of data packets correctly received by gateways (Efficacy), while keeping almost constant the percentage of packets correctly transmitted (Efficiency), and greatly reducing the number of Normalized Path Reconfigurations. That stems from two primary factors. On the one hand, the proactive behavior based on PM allows MMHC to reconfigure paths before their potential disruption, thus reducing the intervals with no paths to gateway. On the other hand, PM exploitation permits to early discard paths estimated as insufficiently reliable, thus reducing unnecessary runtime reconfigurations.
|PM||Efficacy (%)||Efficiency (%)||Normalized Path
To better clarify how MMHC behaves, the figure below presents the throughput of Gateway1 (continuous) and Gateway2 (dashed) whether not exploiting (left) or exploiting (right) the PM indicator; in any case, it is worth noting that Gateway1 is used. The main difference is that, with PM awareness, MMHC proactively triggers a path reconfiguration whenever the intermediate node starts moving; that avoids the short service interruptions of the reactive approach (compare left and right graphs at about 20s, 40s, 60s, and 80s). Given the coarse-grained approximations introduced by MMHC, of course it is possible that a few path reconfigurations are not triggered correctly or timely, e.g., right figure for t = 20s. Let us finally point out that, in our current MMHC implementation, PM threshold setting pushes for the exploitation of reliable paths; by modifying that threshold, e.g., because of specific application requirements, it is possible to dynamically tune MMHC for higher priority of ET/APE instead of path reliability.
Throughput of the two gateways without (left) or with (right) PM