An Architecture supporting the development of Collaborative Applications for Mobile Users

1. An Architecture supporting the development of Collaborative Applications for Mobile Users Vagner Sacramento, Markus Endler, Hana Rubinsztejn, Luciana Lima, Kleder Gonçalves Giulliano Bueno Laboratory for Advanced Collaboration PUC-Rio, Brazil

2. Agenda • Mobile vs. Static Collaboration • Main Components and their interaction • Monitor • Context Information Service (CIS) • Client and Server APIs • Service for Indoor Location Inference • A first case study: Wireless Chat • Conclusion and Future work

3. Collaboration among mobile users • Loss of QoS of wireless connection (or disconnection) may temporarily restrict the user’s ability to intereact with the group  new concept of collaboration awareness • Locality and proximity among users may determine the group of collaborators and the form of collaboration. Examples: • Chat or sharing of notes in classroom or meeting room • Spontaneous interaction at a conference site • Finding interesting people at a party • Search for a specialist in the vincinity • Mobility enables spontaneous encounters where common interests may trigger some form of collaboration, e.g.: • Information sharing (music, news, directions, expertise, etc.) • Mobile Collaboration is situation-oriented rather than goal-oriented

4. Research Goals Main Goals: • Design and implement a middleware to support the development and deployment of such collaborative applications; • Experiment with new forms of collaboration, develop applications using the middleware, and evaluate their usability and usefulness. Target setting: • Structured wireless network (802.11) • Users with laptops and palmtops • Intra-domain applications (e.g. for University campus-community, corporation) We called it the Mobile Collaboration Architecture (MoCA)

5. MoCA MoCA consists of basic services for collecting and processing individual and group context, and APIs and a proxy Framework that facilitate the use of these services by collaborative applications. Essentially, the basic services support • Distributed monitoring, storage and complex queries about the execution context of mobile devices. • Advertisement and dynamic discovery of applications and middleware services. In MoCA, each application is composed of 3 kinds of components: Clients (on modile devices), Proxies and Servers (on static hosts)

6. Main Components of MoCA • Monitor (at the mobile device): • Is in charge of: (i) probing the state information (aka execution context) of the mobile device and (ii) sending this information to the Context Information Service (CIS) executing in the static network; • Configuration Service (CS): • Stores and manages the configuration of each mobile device: • MAC Address, (IP:port) pair of CIS, periodicity of the Monitor repots to the CIS, and (IP:port) pair of the Discovery Service; • Context Information Service (CIS): • stores and processes the state information received from the Monitors, and eventually sends notifications about context changes to Proxies which have subscribed to such notifications; • Discovery Service (DS): • Accepts announcements of applications, and allows Clients to locate the corresponding Servers and Proxies;

7. Subscr client context register which CIS? register Appl. Client Proxy? event Handover req req reply mod_reply Subscr client event M Typical Pattern of Interactions DS CIS CS MoCA Services Appl server Appl. Proxy Appl. Proxy

8. Main Components • Monitor • is a daemon executing on the mobile device; • Periodically polls (and sends to the CIS) state information about the mobile device’s resources and wireless RF signals, e.g.: • Strength of RF signal received from all visible Access Points ; • CPU utilization, available memory and energy; • MAC Address, IP and currently used Access Point; • RF signals are obtained through WiFi scan operations, in a uniform way, independently of the 802.11 network interface; • Implemented for Linux, WinXP (partially, for WinCE) • The Monitor also reports to the CIS any change of the current IP address or Access Point of the device (i.e. a migration) • Periodicity of resource polling and scans can be set as required

9. Monitor

10. Main Components Context Information Service (CIS) Delivers context information to the proxies (via queries or subscription-notifications. Stored context information: • % of CPU usage • Available Memory (in kbytes) • % of remaining energy • Current Access Point • IP Address and mask • List of all audible Aps, with the corresponding signal strengts (in dB) • Usually, applications are interested in: • State of the device (e.g. available memory, enery level) • Wireless connectivity status and quality • Aproximate geographic position of the device

11. Main Components Context Information Service (CIS) • CIS can be deployed as a pool of servers (each one collecting the context information from Monitors); • CIS-Monitor communication uses sockets/UDP; • The proxies subscribe to the CIS informing the devices’s MAC-Address (as the Subject) and the Context-change events they are interested in (expressed in standard SQL92). Example: Subject=”02:DA:20:3D:A1:2B”, Properties = “roaming = True” OR “FreeMem < 15%” OR “CPU > 90%”;

12. Client and Server APIs The APIs make the interaction with MoCA services transparent to the application. Main functions: • Obtain addresses & register at basic MoCA services (e.g. DS). Client gets address of CIS and a proxy; • start the Monitor (Client only); • Select a protocol (JMS, SMS, sockets/TCP, sockets/UDP) for communication with the proxy; • Primitives for synchronous or asynchronous communication.

13. Location Inference Service LIS é um serviço para a inferência aproximada da localização de dispositivos com interface 802.11 em ambientes indoor Características: • Medidor de intensidade de sinal em Pontos de Referência previamente selecionados e GUI para marcação destes pontos em uma planta baixa • Através de triangulação infere a distância aproximada os Pontos de Referência com padrão de sinal mais parecidos • Quando pontos de referência tem coordenadas, retorna uma coordenada (x,y). Senão retorna somente o nome simbólico da área • Disponibiliza uma API para consultas diretas (request-reply) e subscrição/notificação (eventos)

14. Location Inference Service Uma aplicação usa uma instância da classe LIService e pode invocar qualquer método a seguir. • String getArea(String DeviceID)// área de localização do Device • List getDevices()// lista de todos os dispositivos • List getDevices(String areaName)// todos disp. em áreaName • addLIServiceListenener(LIServiceListener listener, List devices)// registra interesse de ser notificado sobre qq disp em devices • removeLIServiceListener(LIServiceListener listener, List devices)// revoga o interesse de ser notificado sobre qq disp em devices Cada vez que um disp. entra ou deixa uma área o LIS notifica todas as aplicações registradas através do método onAreaChanged, informando o areaName e DeviceID

15. Location Inference Service • Atualmente, o LIS só funciona com áreas em um nível. • Futuramente, o LIS se comunicará com um AreaManager, que terá uma representação aninhada/hierarquica de áreas: CampusPUC PrédioRDC ... Andar4 Sala403 Andar5 salas, etc. PrédioFPLF Andar2 LAC

16. Proxy Framework Proxy is the element dealing with mobility-related tasks such as: • Wired-wireless protocol translation • Caching/Hoarding during disconnection • Handover Management • Notice context changes and perform context-specific adaptations • ... • But each collaborative application has specific demands; • Hence, MoCA proposes a “white-box” object-oriented Framework which can be customized to the specific application needs;

17. Proxy Structure Authentication Service Discovery Profile Mngt Setup Communication Handover Mngt Caching Mngt Message Filtering Client Protocol Translation Server subscribe Context Processing Event Dispatching Context Processing Hot and Frozen Spots subscribe notifications Frozen Hot Context Information Service

18. A Wireless Chat As a first case study we implemented a wireless Chat (W-Chat) which disseminates the wireless connectivity status of the participants of a chat room;

19. Conclusion Current Status of implementation: • Monitor for Linux, WinXP; • Centralized Configuration Service (CS) • Context Information Service (CIS) • Prototype indoor Location Inference Service based on 802.11 RF signals Being Developed: • Monitor for other platforms: PalmOS and WinCE • Discovery Service (DS) • Distributed version of CIS • The Proxy Framework and some instantiations • Other LBSs and collaborative applications