The MACHINE Target Scenario

MACHINELogoSmall
 


 
To better clarify the motivations and the potential advantages behind the idea of MACHINE, let us rapidly sketch an example of envisioned application scenario where the primary goal is the provisioning of seamless Internet connectivity

Suppose that Alice is at the University campus with her laptop, which hosts three different wireless cards for Bluetooth, Wi-Fi, and UMTS-based connectivity. Alice is willing to browse the Web to download the files with today’s lesson slides. To that purpose, differently from what today’s solutions require, Alice simply opens her Web browser without specifying which wireless connectivity to exploit. In fact, it is MACHINE that seamlessly discovers that there are currently two connectors available: a free Wi-Fi AP of the campus network and a UMTS base station of the telecom provider Alice is subscribed to. Depending on Alice’s preferences, the middleware transparently decides either to establish a channel based on the free AP if the reduction of economic costs is the priority or to simultaneously exploit two channels (based on Wi-Fi and UMTS) if Alice desires maximum bandwidth.

Then, Alice meets her colleague Bob who carries a smart phone with Bluetooth and UMTS interfaces. Bob is willing to download Web files as well and opens an ftp client on his phone. This time the middleware, by exploiting the applicable context with Bob’s preferences of prioritizing free connectivity, transparently establishes a Bluetooth-based channel towards Alice’s laptop, which works as a collaborative peer to forward packets via the Wi-Fi AP.

Afterwards, Alice moves towards a green recreational area where there is no campus Wi-Fi coverage; there, she requests streaming an audio file from an Internet server. Since the applicable context specifies to prefer free connectivity opportunities and the middleware estimates that Carol’s laptop is still relatively to Alice, the middleware now decides to establish a channel via ad-hoc Wi-Fi towards Carol’s laptop who is studying at the park boundaries covered by the campus Wi-Fi signal.

Finally, Alice decides to go home by continuing to listen to the streaming audio service: when Carol’s connectivity is lost, the middleware automatically requalifies Alice's channel by exploiting the UMTS connector during the way back and the domestic (less expensive) Wi-Fi AP when entering home. If Alice was simply interested in sending non-urgent (delay-tolerant) emails while moving back home, the middleware could decide to temporarily store the messages and forward them only when encountering free connectors; temporary channel interruptions are not an issue for this service.


A simple example of envisioned heterogeneous multi-hop application scenario.

The above application scenario, even if addressing the simplified and easy understandable case of heterogeneous multi-hop scenario for Internet connectivity, e.g., excluding peer-to-peer non-Internet-based services, clearly shows the potential complexity of the targeted problem and the unsuitability of delegating final users to take proper channel management decisions. There is the need for innovative and effective middleware to properly handle the numerous technical challenges involved, from heterogeneity of interfaces/connectors and their proper combination for channel establishment, to context-dependent channel re-qualification at runtime. That requires suitable logical abstractions with differentiated visibility of implementation details, clearly separating different levels of logical/physical connectivity resources and their management, and exploiting rich context metadata to take effective management decisions at runtime.

 
9-nov-09