LEM Experimental Results

We have tested and evaluated the performance of LEM in a wireless test-bed consisting of several Linux client laptops. We use the Java Media Framework (JMF) for RTP-based audio streaming. Client nodes are Linux laptops equipped with different BT cards: ASUS Bluetooth and Mopogo Bluetooth. The relay, in addition to the BT interface hosts also an Orinoco Gold WiFi card to enable communications between the relay and the fixed multimedia server. Multimedia server execute on standard Linux v2.6 with 1.8 GHz processors and 1024MB RAM.
As regards low level system monitoring, Bluetooth RSSI can be obtained through the specific tool (hcitool) of the BlueZ stack for Linux.

In the following, we report experimental results collected with our real and ready-to-deploy content distribution solution. Shown results are averaged over a hundred relay handoff cases, while provisioning an Audio on Demand (AoD) service (WAV-encoded flows with constant frame rate = 50 frames/s and 352Kbps bandwidth).

RSSI-based mobility prediction in LEM

The first experiments demonstrates the ability of our our lightweight RSSI-Grey Model Predictor (RSSI-GMP) to effectively predict forthcoming relay handoff events. Without any loss of generality and for the sake of simplicity, we consider the relay as the only mobile node; during our experiment, the relay moves away from the center towards the borders of the AOI and then back to the center, while the three AOI clients, deployed around the relay to emulate the usual AOI deployment, are static.

The figure below and the next figure show the timelines, respectively, of the RSSI moni-tored at one of the clients (other clients show a similar trend) and of the aggregated RSSI esti-mated by RSSI-GMP at the relay. Client-side RHP extracts the RSSI values expressed in heterogeneous RSSI scales and map them into an internal LEM RSSI scale, from 0 for near nodes to 17 for distant nodes, without employing any filtering/prediction technique (see the figure below).

RSSI-GMP, instead, is able to aggregate and to smooth incoming RSSI updates from all clients, and it successfully predicts future RSSI trends due to relay movement. For instance, the RSSI increase at 80s in the figure below (relay move-away) anticipates the same increasing trend, even if with more noise due to the lack of filtering, starting at 94s in the figure above. RSSI-GMP proactively triggers relay handoff management as the predicted RSSI value overcomes the so-called relay handoff threshold that was experimentally fixed to 7.

Proactive client-side buffer management for seamless audio streaming in LEM

This second experiment proves that our proactive client-side buffer management can grant session continuity even in the most challenging case of two consecutive and close relay handoff events.

Let us stress that the delays for relay re-election and session rebind can be very high: the total sum for Bluetooth amounts to a mean value of 3.3s. That long time is mainly due to the long Bluetooth-related node inquiry and connection latencies, and confirms the need for proactive management to avoid multimedia streaming/session interruption.

The figure below shows the client buffer filling level (expressed as filling up percentage over buffer length). During the two handoff events, respectively around 10s and 25s (vertical arrows in the figure below) the buffer level decreases, but it is always sufficient to sustain audio playout, and after handoffs LEM fast (re-)transmission permits to promptly refill the buffer. In other words, client-side multimedia streaming & continuity playout stub has always a sufficient number of frames to provide high-quality audio playout without interruptions.

Simulation experimental results will be available soon. Stay tuned!

Preview of a screen-shot collected over one run with ns-2 network animator (nam).