MobiShare: Sharing Context-Dependent Data & Services from Mobile Sources

1. MobiShare: Sharing Context-Dependent Data & Services from Mobile Sources Efstratios Valavanis, Christopher Ververidis, Michalis Vazirgianis, George C. Polyzos, Kjetil Norvag Presented by Amy Sliva

2. 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.

3. 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

4. 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

5. System Design (cont.) • Service discovery occurs through the CAS, data transfers are P2P

6. 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.)

7. 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

8. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. Taxonomy Path Example • Request: “travel, book, taxi”

17. 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

18. 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

19. 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

20. Questions?