1. 1 Last Time  Context Aware Applications  Defining context  Active vs. passive  Survey of some applications  No killer application yet; but maybe in the future?  Location (and time) most heavily used contexts  Sensing context  Location: Outside: GPS Inside: Need a location traction mechanism

2. 2 Sensing other low level contexts  Time?  Physical sensors possible  Light, acceleration, tilt, sound, temperature, pressure, proximity of humans  Nearby objects?  If system keeps track of location of objects, query to a database  Bandwidth? Odyssey  Orientation?  Orientation sensor based on two mercury switches (Newton MessagePad)  Directional antennas/directional transmitters?

3. 3 High Level contexts  This is by far the more difficult problem  Not just an engineering challenge  How does a node know whether this is a party or a wake?  Check your calendar or detect the cake/coffin?

4. 4 Sensing Context changes  Publish subscribe model?  Monitor polls the current context  Notifies subscribers to the context  Centralized or on a per-node?  Polling rate is a function of rate of change of context

5. 5 Modeling Context Information

6. 6 Location Model  How do we answer questions such as:  Given an object what is its location  Given a location, return the set of objects there  Determining paths between locations  How does a vehicle navigation system do it?  Geographical Information Systems/Spatial Databases  Already pretty mature (part of Oracle, mysql, etc..)  Model geometry and topology  Typically locations are organized hierarchically  Sonal Dedhia’s project

7. 7 Security and Privacy Issues  I personally hate the idea that someone can know my location all the time  I still refuse to get a cell phone, but it looks like I will finally cave in!  Par for the course, many of these systems ignore privacy and security issues

8. 8 Second Paper: Anatomy of a Context Aware Application

9. 9 Outline The Anatomy of a Context-Aware Application – Andy Harter, Andy Hopper, Pete Steggles, Andy Ward and Paul Webster. AT&T Labs, Cambridge, UK (cont)

10. 10 Overview  Paper describes the system components necessary to support a context-aware application 1.Location system 2.Data model 3.Distributed object model 4.Resource Monitors 5.Spatial monitors  Working system, real details  So what is the application? Teleporting/follow-me  Application follows you as you move around a building  Hmm!! Virtual dog? Definitely some gaming applications But what else? Virtual nanny? Framework not specific to this application

11. 11 Location System  Would like:  Fine grained (accurate in space)  High update rate (accurate in time)  Inexpensive  Works indoors  Argue for ultrasonic  Optical: expensive detectors; line of sight limitations  GPS: dies indoors  RF: multipath

12. 12 Bat Unit  Radio transceiver, ultrasonic transducer and control logic  Each bat has a GUID  Base station transmits a periodic message with the GUID; corresponding bat responds with ultrasound  Use speed of sound in air (estimated from ambient temperature) to estimate location  Ultrasonic receivers detect the delay and map it to distance  Use multiple receivers to get 3D location using multilateration  Reflections of ultrasonic waves – statistical outlier elimination (can same techniques be applied to RF multipath?)

13. 13 Bat (cont’d)

14. 14 Bat Unit (cont.)  It takes 20 ms between bat readings = 50 timeslots per base station per second  Allow echos to die  Location can be used to measure orientation  Attach many bats to the same object. Use the measurements to infer the orientation  If too cumbersome, can check “shadow” of a single bat  Base station can provide Location Quality-of-service to allocate time slots to bats based on the expected update frequency  Bats carried by people – few times a second  Bats attached to workstation – once every few minutes

15. 15 Bat Unit (cont.)  Bats perform handover when moving from one base station to another (similar to the cellular networks)  Hand off decisions can also be made based on the Bat location  Battery consumption is low, power consumed depends on the update frequency and power state  Several updates a second = several month lifetime  95% of samples within 9cm’s of actual location  95% of samples within 25 degrees with multiple bats; within 70 degrees for a single bat (orientation)  Bat is good enough to be used as a 3D mouse; it has buttons and can communicate with basestation

16. 16 How well does it work?

17. 17 Modeling the environment  Detailed model describing entities in the real world and their possible interactions  Environment consists of real objects: should use OO modeling (agree?)  Modeling language based on entity relation diagrams and multiple inheritance  Modeled people, computers, keyboards, monitors, networks, telephones and furniture  Use CORBA and databases to implement persistent distributed objects

18. 18 3 Tier Architecture

19. 19 Populating and Updating the Model  Some elements are static (e.g., furniture)  …but some are dynamic (e.g., is a keyboard in use) need to be updated automatically  Centralized data repository (to optimize information access)  Three classes of resource monitors:  Machine activity e.g. keyboard activity  Machine resource e.g. CPU usage, memory usage  Network point-to-point bandwidth and latency

20. 20 Client level event filters  Update Frequency  The frequency at which items are monitored is based on how quickly the item tends to change  Relevancy  If a value has not changed significantly, it is not sent. This value depends on the data being monitored  Caching  Caching improves performance at the cost of consistency

21. 21 Location Update  Each Bat location is tracked  Translated into object location in a type specific way (e.g., person different than workstation)

22. 22 API  Absolute and relative spatial facts  “Person is at (x,y,z) facing in direction  ”.vs. “Person is standing in front of the monitor”  Geometric containment is used for relative spatial facts monitor person Contained(person, screenspace)

23. 23 Reasoning about Space

24. 24 Scalability  With many devices, containment is complex  They use containment tree indexing system (a quad- tree based approach)

25. 25 Implementation  BAT teleportation system  With their earlier active badge based teleportation system, they only knew that a user was in the room and so they had to cycle between multiple displays in a room  If a particular display was being use, they would still cycle that display because they did not monitor machines  If a machine is dead, their system would still wait because they did not monitor machines  With the BAT system, they have more accurate location information  Event driven programming style

26. 26 Zones and Buttons  Action zone triggers teleportation  Within maintain zone, teleported desktops are maintained Action monitor Maintain

27. 27 Active Names: Flexible Location and Transport of Wide-Area Resources Michael Dahlin, Thomas Anderson, and Amit Aggarwal. In Proceedings of the Second USENIX Symposium on Internet Technologies and Systems, October 1999

28. 28 Active Names  Idea: Intelligence in the network  User specifies a name carrying some service intent  Active name is mapped to a chain of mobile programs that can customize how the service is located and presented  Each service owning a portion of the namespace has control over which protocols are used to access the service and where they run in the network  Encapsulates Service location, customization and transport  Can be used as an extensible general framework for deploying wide-area distributed services  How does relate to mobility/context-aware applications?

29. 29 What exactly are they proposing? “when a mobile user in Europe refers to cnn.com, the user probably wants to go to a different replica, fetch different data, and transform that data differently than a user in the US with a large screen and T3 connection”

30. 30 Properties of the System 1. Completeness: it can support a wide variety of extensions 2. Simple extensions can yield big performance wins 3. End to end performance information can be gathered 4. Programming model can support location independent program execution 5. Programmable model supports extensibility

31. 31 Naming – brief intro.  DNS translates from machine names to IP addresses  opal.cs.binghamton.edu  128.226.123.101  static translation (usually valid for a few days)  DNS round-robin used to dynamically match name to host (based on machine load, for example)  www.cnn.com  207.25.71.23 or 207.25.71.24 or …  Network level switch (for e.g. CISCO director)  Automatically forward network packets to some server

32. 32 Naming Intent  A URL is a hint to get some value from some server that is “appropriate” (in terms of locality and access costs) and that fits in my display  The exact host names and paths can be remapped to the appropriate forms.  My view of cnn.com depends on my device, my advertisement preferences etc. Your view of USA Today may be different from mine

33. 33 Active Names Goals  Server selection – select appropriate server from replicas spread across the Internet  Client customization – Customize the page for the present client (e.g. Transcoding, customizable portals [e.g. my.yahoo.com])  Server customization – Advertisements customized for the user, collecting statistics (e.g. hit counts, ad rotation etc.)

34. 34 Naming today Client Proxy HTTP Server2 Database Server HTTP Server1 DNS Server 1. Name 2. host 3. URL - redirect 4. URL 5. Name RESULTS www.cnn.com

35. 35 Active name system  Clients generate active names (domain:name) and name of a namespace program to resolve it.  Clients hand them to a resolver.  Name space program locates next program to run and then transports data to that program  Each program acts as a filter that transports and transforms its input to its output.

36. 36 Active Name Architecture

37. 37 Active name system  Active name resolver determines domain-specific program  These programs are location independent and can run anywhere  Application specific, the name is resolved in domain-specific manner  Domain specific code (e.g. ad rotation)  After methods are associated with each active name  After methods are a list of programs guaranteed to be called  They can perform client-specific transformation of data

38. 38 Multi-way RPC for efficiency Client Proxy Server Traditional RPC Results passed down the nodes. Adds latency

39. 39 Multi-way RPC for efficiency Client Proxy Server Multi-way RPC Results sent directly Minimal latency

40. 40 Multi-way RPC  Security implications – someone else responds to your queries  Use capability certificates to authenticate response  Resource consumption limit should be managed. Resolvers use compute resources on foreign hosts.  Hierarchical namespaces.

41. 41 Applications  Extensibility  Compared DNS round robin (next server), distributed director (closest server as measured by hop count) and Active names (number of hops; biased by a decaying histogram of previous performance)  Average latency follows Distributed Director at low load and DNS round robin at high load

42. 42 Using Transcoding Low JPEG Quality 10 KB Thumbnail 2KB Crop 40KB Grayscale 85KB Original 116 KB Transliterate few bytes Foggy road with fall foliage canopy

43. 43 Decision on where to transcode  Can transcode either on the server or proxy  Proxy is closer to client  Wide area network from server to proxy could be congested. Tradeoff between sending a smaller image across the country vs performing transcoding at the proxy  Active name migrates based on the current load

44. 44 Composability  Use server-side include to update page based on the current request  Banner ad rotation  Logs cookies  Implemented using server side and active namespaces.  Active namespaces are shown to be composable