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?