MobiShare: Sharing
Context-Dependent
Data & Services from
Mobile Sources
Efstratios Valavanis, Christopher
Ververidis, Michalis Vazirgianis, George
C. Polyzos, Kjetil Norvag
Presented by Amy Sliva
Introduction

Connecting diverse resources under a common
framework presents many challenges
 Uniform
ubiquitous connectivity
 Heterogeneity of sources
 Effective and precise resource discovery

Context awareness is an essential feature
 Sense
dynamic information in real-time about the
environment
 Position, orientation, lighting conditions, people’s identity,
etc.
Goals of MobiShare




Provide a middleware system for managing
resources
Provide infrastructure architecture to offer
ubiquitous connectivity to mobile devices
Optimize a solution for data requested and shared
by moving nodes
Data-centric approach
 Service
Oriented
System Design

Communication cell:
 Area
of coverage of a wireless network access point
 Mobile device connected to exactly one AP at any given
time

Cell Administration Server (CAS):
 Manage
the area of coverage of an AP
 Responsible for maintaining list of devices and available
services
 Provides service discovery capability
 Stores statistical info about users and devices
System Design (cont.)

Service discovery occurs through the CAS, data transfers
are P2P
Mobile Devices


Assume one-to-one relationship between devices and
users
Hardware Requirements:

Digital Compass
 GPS receiver
 Wireless communication interface

Software Requirements:

Request definition tool
 Service definition tool
 Application server (if the device can be a data source)
 Viewer applications (for documents, images, etc.)
Central Application Servers

Functionalities:






Assign addresses and ids to devices
Perform authentication and access control
Handle requests
Publish services offered and host description files
Maintain list of neighboring CASs, etc.
Data Flows between CASs:




Extension of requests to neighbors
Forwarding list of neighbors
Request or deliver location information
Push service description files
Central Application Servers
(cont.)






Global service taxonomy of service categories
Service directory of services offered by devices in
the cell
Service description repository of local services
CAS directory of addresses of other CASs
Device repository of devices in the cell
Temporal profile manager for storing access
patterns for devices
Device Location Mechanism



Upon entering a new cell a device reports its
previous location and any services it hosts
When a device leaves a cell, the previous cell
stores the next location
When a request for a device’s service is received:
 CAS
returns the current IP if it is in the device repository
 If the device is not found locally, the request is forwarded
to neighboring cells
 Follows chain of “next” cells for the device to locate it
Service Description




Always one CAS responsible for maintaining master copy
of a service description
Each new CAS that acquires the description has to notify
the initial CAS
If the description is updated, the local CAS takes
ownership of the master copy
When publishing a service:


Declare an initial area of availability
Specify whether the service is fixed or mobile
Service Submission




Service definition tool helps user classify his
service using a fixed service ontology
Use WSDL to define the user interface
Use RDF to store the semantic information
Advertisement profile



User-defined
Mobility-based
Request-based
Service Discovery




Locate services on-demand in reasonable time
Retrieve all available resources and filter the
results
Refine the results by context
Example Service Request:
 Tourist
with a mobile device submits a request to locate
services that find taxis in his communication cell
Request Process





Request handler is initiated that stores metadata of the
request
Search string sent to the taxonomy module, and the
set of services that semantically match are forwarded
to the user
Selected services are sent to the service handler
which checks the service and device directories for
availability
User chooses a service to invoke
Search can extend to adjacent cells
Semantic Matching


First we have to understand what the user is looking for
WSDL and UDDI do not contain semantic information





Exact matching is not good enough
A service ontology is stored in RDF
Use dictionary to match words to points in the service
taxonomy
Use distance measure to select part of the taxonomy
Filter resulting set of services

i.e., Exclude services that originate on non-local devices
Taxonomy Path Example

Request: “travel, book, taxi”
Context-awareness

Two types of context:

Location (both requestor and source)
 Mobility parameters of the requestor



All requests include location and orientation of requestor
If user is located at the border between cells, the request
is forwarded to the CAS in the neighboring cell
Users can specify a request radius--helpful if the cell
covers a large area
Implementation

Part of DBGlobe project


Data-centric approach to global computing
Prototype developed

Uses IEEE 802.11b WLAN
 Cells managed by Microsoft Windows 2000 Servers running the MobiShare
CAS module
 Software developed using C# for .NET
 Metadata based on standards (XML, RDF, WSDL,etc.)

CAS Modules


Device Repository, Device Controller, Service Publisher, Service Request
Handler, Service Description Repository, Service Directory
Mobile Device Modules

Request Definition Tool, Application Server, Viewer, and Service Definition
Tool
Preliminary Results


Mobile devices take 2 seconds to detect they have
entered a new cell
5 seconds for a newly published service to
become available
Questions?