MobiTrade: Trading Content in Disruption Tolerant Networks

Design and Development of an utility driven trading system for

Efficient content sharing on top of a DTN

Mobile networking is quickly reaching a tipping point. While data has been a second-class customer for cellular networks until recently, the wide spread of smart phones, and the access these provide to existing and novel applications, are generating unprecedented amounts of mobile data. The capacity of current cellular infrastructures has already been pushed to the limit. To support the increasing number of devices generating data at high rates, ISPs will inevitably be pushed towards lowering bandwidth quotas, adopting non flat rate plans, or deploying (expensive) next generation equipment. This has leaded many researchers (and industry) to explore alternative or hybrid architectural solutions.

To this end, direct mobile-to-mobile communication can be leveraged to harvest the large amounts of unused bandwidth between wireless devices in proximity. Mobile devices with multiple wireless interfaces (e.g. Bluetooth and Wi-Fi) allow two users in range to exchange data at much higher speeds, lower power consumption, and essentially no (direct) monetary cost.

A significant share of research on opportunistic networks has focused on unicast and multicast routing. However, the increasing user demand for content is creating a shift in focus towards content and data centric systems (e.g. the CCN project), in both wired and wireless Internet. As a result, a number of content dissemination systems have been recently proposed for mobile devices in the wild to exchange content of interest in a peer-to-peer manner. MobiTrade fits within the latter category and introduces the following new features:

A formulation of the optimal content sharing problem in DTNs from the perspective of non-altruistic nodes and assuming a tit-for-tat mechanism to isolate free-riders.
MobiTrade introduces an utility-based trading solution that predicts the (exchange) value of each piece of content and provides a customized resource allocation strategy for each mobile device, matched to each own interests and mobility pattern.
Turning on the MobiTrade mechanism is an efficient Nash equilibrium. Proved using a game-theoretic framework and simulations (with both real and synthetic mobility).

Global Architecture

In a content dissemination architecture, mobile devices need first to somehow express their interests for different (types of) content and advertise these interests. To this end, we borrow the concept of channels, introduced in the CCN project. Specifically, the MobiTrade architecture relies on two data records: content and channel records (see Figure below).

Channel Record: A user asks for a set of contents by creating locally a channel record that encapsulates the set of keywords the user thinks they better describe the contents she is looking for. Channels can be added or deleted by the user, at any time. In contrast to the CCN model, the channel record in MobiTrade is one-for-many (not one-for-one). A desirable content is identified based on a match between the channel keywords and the content description (also characterized by a set of keywords). We think that such a match process is more appropriate for the communication model we are proposing, where the user might not know the exact content he is looking for, or might anyway be interested in all contents matching the description (e.g. Madonna songs, photos of Nice, sports tickets for sale).

A lot more can be said about this channel structure (e.g. hierarchies, merging and splitting of channels, semantic content matching, etc.), but this is beyond the scope of this work. Instead, we choose to use a simple channel structure here and focus on the algorithmic part of the system. Finally, each channel record contains a utility entry. This is a key quantity for MobiTrade, allowing our system to optimize various important functions (scheduling, inventory management, collaboration profiling, etc.). More details could be found within MobiTrade related publications.

Content Record: In addition to the content description, a content record contains a number of additional fields. First, we associate to each MobiTrade content a TTL (Time to Live). By the end of this time, records can be removed. The cases requiring this TTL field are many, for example someone could be interested in selling something today. To ensure devices respect this TTL field, MobiTrade devices do not reward each other for expired content.

Furthermore, to provide users with a full control over their privacy (i.e., the contents they publish and their center of interests), we choose to keep anonymous any generated channel record (no user or device ID are stored). Nevertheless, for contents, one still has the possibility to associate to them a canonical source name that refers in some way to the content publisher. This field does not correspond necessarily to the user device address, but it can hold the publisher postal address or its phone number, which can be used for distinguishing between contents, feedback mechanisms on separate communication mediums or authentication purposes.

Finally, to provide for some MobiTrade security, we choose to use a CCN like content-based security model. With this model, protection and trust travel with the content itself, rather than being a property of the connections over which it is transmitted. MobiTrade devices authenticate via the signature field, the binding between the content source ID, its description and some parts of its data. In addition to this signature, each signed MobiTrade content carries with it the public key necessary for its verification by other devices. The signature algorithm can be selected to meet the performance requirements of that particular published data.

Next, we give some more details of the MobiTrade architecture. The figure below is a schematic of the core MobiTrade device, which has five building blocks. We have already implemented this architecture on Android phones in order to conduct small scale experiments.

The Application Interface is designed so that developers can easily extend MobiTrade and create new content sharing applications that use the MobiTrade functionalities. Each MobiTrade application has a unique ID that it registers at the application interface. The application then simply communicates with the MobiTrade system using event handlers.

The Scheduling Block defines the order to follow while forwarding a set of requested contents within a limited contact opportunity. As explained before, this ordering is done based on the utility values.

The Tit-For-Tat Trading and Forwarding Block takes in charge (i) the forwarding of the stored channels records whenever a new contact is established, and (ii) the negotiation and forwarding of the requested contents.

The Content/Channel Management Block manages the channel and content storage space. It provides an API for storing and retrieving channel and content records that hides the storage technology specifics. This block also takes in charge utility updates for the stored channels and buffer management (as described in related publications).

The Link Controller Block is the lowest layer in the MobiTrade architecture. It provides a common interface for sending and receiving data across the different available wireless interfaces. It is also responsible for periodically scanning the neighborhood for devices, for establishing the contacts whenever meeting opportunities arise and for triggering the Tit-For-Tat trading and forwarding block. The link controller provides an API that hides network technology specifics (Bluetooth and Wi-Fi) from the rest of the upstream blocks.

MobiTrade Implementation

We have implemented MobiTrade for the Android framework. The minimum supported Android SDK version is 8 (android 2.2 or higher).

For the moment MobiTrade is still under testing; so, for who is interested to test/run it, we just provide the MobiTrade apk file which is going to be as soon as possible released for free on the Android Market.

Any feedback is welcome, please email it to: Amir.Krifa@inria.fr

How to install the MobiTrade APK file?

Through the Android Market

To install APK applications on your Android phone do the following:

- Copy the APK file you want to install to your phone's memory card and insert the card into your Android phone.

- Go to Android Market and search for the Apps Installer, App Installer, z-App Installer or Fast Installer application.

- Open it and click on the Install button.

- After it is installed, just open it. It will show you all the APK files stored directly in the root directory of your memory card.

- Just click on the application you want to install and it will be installed.

- You could also just install a file manager app like Astro File Manager and then browse to the APK and install it.

Using the Android SDK

There is another method that can be used; you can install APK files into your phone using the Android SDK. Download the Android SDK.

- First of all, install the Android SDK on your computer. You will also need to install the Android USB drivers to connect the SDK to your phone via USB. You can download it from here - http://dl.google.com/android/android_usb_windows.zip.

- To install applications from other sources, you also need go to Settings -> Application Settings and enable Unknown Sources. Also go to Settings -> SD Card and Phone Storage -> Disable Use for USB Storage. You can enable it again later.

- Next, just open Command Prompt and type: adb install path/file.apk where path is the full path to the APK file and file is the name of the APK application file. Your application is now installed. This is all you need to do, now just open the application on your phone and use it.