We have tested our MMHC middleware in different wireless environments, with changing sets of mobile nodes getting/offering connectivity via Bluetooth and IEEE 802.11. The primary goal was to quantitatively evaluate the connection establishment performance and the overhead/delay introduced by our MMHC middleware. The reported results concentrate on channel establishment, path update responsiveness, and path selection; they are average values over hundreds of experiment repetitions over a typical MMHC environment (see figure below). In practically useful self-organizing networks, the number of hops is limited as well as the number of collaborating clients at each topology level; the reported results have been measured by exploiting Linux-based nodes equipped with IEEE 802.11 PROWireless/Orinoco Gold cards and Mopogo Bluetooth 1.2 dongles (the MMHC prototype is also available for MS Windows XP/Vista and includes modules for several interfaces, such as IEEE 802.11 Orinoco Gold cards and all MS-BluetoothAPI-compliant dongles).
For the sake of simplicity and rapid presentation, let us consider the initial case of three IEEE 802.11 nodes, A (still) and B (moving) that offer connectivity, and C that requires connectivity. At test-bed startup, CM at C estimates EEA and EEB and to consequently select A because of reliability, mainly due to the long time for the needed construction of the time series of RSSI samples. To have a concise evaluation of CM performance when performing new channels, we report as indicator the time needed to update the set of available channels when a new connector becomes reachable. In the case of a new Wi-Fi/Bluetooth connector arrival, e.g., node A and C, CM spends 5.137/22.808s to configure the new channel, due to 3.041/14.370s to discover the connector, 0.039/0.116s to evaluate its suitability, 0.022/3.430s to connect to it via association/PAN connection, and 2.035/3.292s to complete the needed IP configuration via DHCP. The main performance differences between the two interface types have been exhibited for connector discovery and connection: Bluetooth inquiries and PAN connections are slower than IEEE 802.11 scans and associations; the longer IEEE 802.11 discovery phase is mainly due to the time needed to set up the ad hoc mode, which is of infrequent usage and not optimized in several Wi-Fi cards. In addition to interface types, the reported performance indicators have demonstrated to highly depend on card model and driver implementations. For instance, in our testbed the IEEE 802.11 ad hoc throughput is much higher for Orinoco Gold than for our PROWireless 3945ABG interfaces (about 6 times) because the latter only support ad hoc transmission at 1MB/s. Similarly, MMHC can halve the Bluetooth inquiry period over MS operating systems at the expense of risking not to sense only a small fraction of connectors as proposed first in [9 Network]; that optimization is impossible with Linux-based BlueZ drivers. In any case, CM operations for connector evaluation and channel establishment are very time-consuming, especially for Bluetooth; that makes necessary the proactive approach adopted in MMHC, where CM operates continuously to offer an already determined set of channels to RM.
Starting from this initial situation, to evaluate middleware responsiveness, consider the case of D, E, and F that join the self-organizing network. The middleware decides to connect them to C, which routes their packets toward A (greater throughput than G). RM at C requires 273ms on average to establish the new paths between A and the new clients: 60ms to select the best path and to consequently update routing rules, the remaining part to distribute monitoring data.
About responsiveness to path disruption, for instance in the case that A abruptly leaves the network, RM at C needs 1357ms on average to re-establish a new path from its clients to G. That relatively relevant delay is mainly due to the fact that our CM does not aggressively monitor all the available paths: to reduce communication overhead, it only pings remote devices with a default (dynamically reconfigurable) period of 1s.
About responsiveness to the availability of new suitable paths, if A returns to join the network, the middleware will reconnect C to it again, while E and F will continue to exploit their path to G. On the opposite, D will switch to the newly available path because it requires greater throughput toward C. RM at C employs 258ms, from path renegotiation request by D to actual path reconfiguration.
Finally, we have evaluated the time needed to PAS to re-qualify a path in response to the abrupt disappearance of the associated channel. PAS has shown to require only 0.106/0.228s to re-establish connectivity via another path. Let us stress that the PAS performance is also compatible with seamless soft handover in challenging deployment scenarios, such as for video-on-demand applications.
These results show that the MMHC middleware can effectively manage multi-hop multi-path heterogeneous connectivity opportunities by imposing limited delay, fully compatible with currently available device characteristics and widely within the order of magnitude of usual time intervals that standard IEEE 802.11/Bluetooth requires to simply establish single-hop connections. Finally, let us note that, in response to availability or reliability/quality variations, our MMHC middleware updates the exploited paths by operating local management actions on the limited sub-set of nodes in the locality where variations occur. Localized management operations, which do not propagate with domino effects along the whole paths, favor limited middleware intrusiveness and good scalability while growing the number of hops/nodes.