Ubiquitous Computing Spontaneous Interaction 24012007

1
Ubiquitous ComputingSpontaneous
Interaction24/01/2007

• Hans Gellersen

2

• Spontaneous Interaction
• Discovery Systems
• Interoperability Frameworks
• Security for Spontaneous Interactions

3

• Spontaneous
• Interaction

4
What is it ?

• Spontaneous Interaction
• Interaction between devices (and resources) that
  do not have prior knowledge of each other
• Not explicitly designed to work with each other
• Not pre-configured to work with each other
• Interaction that can happen spontaneously without
  administrative overhead
• Spontaneous as is unplanned encounters,
  opportunities
• Spontaneous as in self-acting operation out of
  the box, plug and play

5
Why is it relevant to Ubicomp ?

• Ubiquitous Computing
• Mobile users
• Many devices and services in their environment
• Applications that depend on a combination of
  devices/services
• General Drivers
• Network effect added value from flexible
  combination of many devices, emerging
  applications
• Mobility support interact in changing
  environments
• Zero configuration mass deployment of networked
  devices is only realistic if new devices can be
  introduced without overhead

6
Examples

• Guest lecturer gives a presentation using the
  local projector, a remote file system, and their
  PDA as control
• Conference attendees exchange data between their
  PDAs/Laptops
• Visitor sends photo to friends printer (not the
  neighbours)
• Group of people in a Café play a wireless game
• --gt Spontaneous association of devices
• Often for a short-lived purpose

7
Challenges

• When a device enters an environment, how can
  mutual awareness and availability be achieved?
• Discovery systems for ubicomp
• Among which devices and services is interaction
  appropriate? And how will the devices and
  services be able to interact with one another?
• Interoperability frameworks
• How can devices/services be protected from
  undesirable interactions? Users require security
  for their resources, and privacy for themselves.
• New approaches to security

8

• Discovery Systems

This section is largely based on Discovery
Systems in Ubiquitous Computing,Keith Edwards,
IEEE Pervasive Computing Magazine, April-June
2006
9
What is Discovery ?

• Discovery lets services and devices become aware
  of peers on the network without explicit
  administration
• aware of their availability and capability
• Services entering the network make themselves
  available as resources by registering with the
  discovery system
• Providing a self-description (e.g. type,
  attributes)
• Clients provide criteria describing the resources
  theyre interested in
• Discovery is the process of notifying clients of
  the availability of desirable services or devices
• Clients are provided with information that they
  can subsequently use to contact the resource

10
Discovery versus Naming Systems

• Discovery are like naming systems
• let clients retrieve references to resources
• provide mechanisms for describing resources
• allow clients to search using descriptive
  criteria
• But they differ in three major ways
• in discovery systems, clients and resources find
  the directory automatically (no
  pre-configuration)
• the directory gets automatically updated as
  resources come and go (no editing of registries)
• client can be notified about changes in available
  resources (dont have to poll the directory)
• All this enables spontaneity

11
Characterizing Discovery Systems

• The high-level goal of discovery systems is
  always to help services find each other but there
  are many differences in the detail
• Topology directory-based or peer-to-peer
• Transport over IP, or over other networks and
  communication channels
• Scope the set of resources that are discoverable
  by a given client
• it can be desirable to limit the scope
• Search sophistication of supported queries
  (based on resource type, or on full-blown
  predicate languages)

12
Simple Service Discovery Protocol

• SSDP is used in UPnP, Universal Plug and Play
• Web-centric SSDP is defined on top of HTTP, and
  resources are identified using URI.
• Multilayered devices can host one or more
  services
• No directory using local-link multicast to let
  clients discover resources directly (scope
  defined by IP network topology)
• Simple form of search based on resource type
• Presence announcement and discover request have
  the same form
• URI identifying resource type
• ID of the resource
• URL pointing to an XML description

13
Jinis Discovery Protocols

• Two-stage topology
• Initial discovery of a lookup service
• Discovery supported by the lookup service
• Services communicate with clients through proxy
  objects (complete Java objects)
• Transmitted to the client, lets the service
  control both communication end points
• Search by ID, type or attribute
• Scope Java-capable devices but it is possible to
  have surrogates for other devices

14
Jini Service Registration
Lookup service
1. Find Lookup Service
2. Return stub to lookup
3. Return stub to service
Network
Alarm Clock Service
15
Jini Service Leasing
1. Find Lookup Service
Lookup service
2. Return stub to lookup
3. Query for service
4. Service returned
Network
Alarm Clock Service
Coffee Maker
Find interface Alarm Clock (ownerHans)
16
Using Services
Lookup service
Network
Alarm Clock Service
Coffee Maker
Can use any protocol to communicate to
service (or stub can contain service itself!)
17
Bluetooth Service Discovery Protocol

• Bluetooth is a short-range RF-based communication
  technology
• for devices and their accessories (phone/headset)
• for personal area networking (piconet/scatternet)
• Devices implement one or more profiles, which
  define the operations available to clients
• Unlike Jini and SSDP not based on IP
• Separate processes for low-level discovery of
  SDP-capable peers, and actual service discovery
  using SDP
• Discoverability is based on physical proximity
  for peer-to-peer networking

18
eSquirt / Cooltown

• Cooltown a web-based infrastructure for
  UbicompResearch project at HP Labs (1999-2002)
• eSquirt is an example of a system using an
  out-of-band channel for service discovery
• a user can electronically squirt a URL at a
  device, for example using infrared or Bluetooth
  communication
• The user rather than the technology provides the
  search function
• Physical selection of a device, and selection of
  a service based on standard web technology

19
RELATE

• EC Project coordinated at Lancaster (since 2005)
• Supporting discovery and interaction with peer
  devices in spatial proximity
• Devices are extended with RELATE dongles
• Wireless sensor nodes that use a combination of
  RF and Ultrasonic (US) communication for relative
  positioning
• Two-level discovery
• Dongle protocol to discover peer dongles within
  RF/US range
• Devices advertise their IP address and service
  descriptions over the dongle RF network to other
  devices
• Devices can then establish direction interaction
• Facilitated through a spatially organised user
  interface

20
RELATE Video
21
Summary on Discovery

• Many different systems, largely varying depending
  on application domain
• No one-fits-all approach!
• Discovery is only the first step to get a device
  interact with a desired service
• Discovery provides a handle to a resource and
  then gets out of the way
• Even if two parties agree on a discovery
  platform, there is no guarantee that they will
  actually be able to work together

22

• InteroperabilityFrameworks

23
Interoperability

• In order to interoperate, two entities must have
  some shared agreement on the form and function of
  their communication
• The agreement defines the interfaces each entity
  exports, and which are known to the other party
• e.g. a web browser and a web server must agree on
  a set of common protocols (HTTP) as well as
  format and semantics of data exchanged (usually
  HTML, XML)
• Web services and their clients must agree upon
  known service interfaces and protocols for their
  invocation
• The agreement must be a priori, and built-in to
  each party

24
Nonscalable Integration

• The Combinatorial Complexity of Ongoing
  Integration
• For interoperability, devices have to be
  programmed to recognize the specific protocols,
  standards, data formats, and operations of all
  expected peer devices
• If we want to integrate a new device type into a
  network, all existing devices must be updated
• Because developers program against standards
  known at development time, they cant accommodate
  entirely new devices that dont resemble existing
  standards

25
Nonscalable Integration

• For example UPnP Interoperability based on
• Platform assumptions (TCP/IP, HTTP, XML, SSDP)
• Profiles that describe each device types
  capabilities
• Profiles are very specific, e.g. for printers,
  scanners, mediaservers, etc
• Because they are so specific, they cannot be
  reused for new device types
• Even new devices of a common type may have
  capabilities that require a profile extension

26
Data-oriented Interoperation

• Two alternative approaches to method invocation
• Event systems
• Tuple spaces
• Programming interface comprises only a few fixed
  operations
• Components interact only with one type of service
  directly (event service, or tuple space)
• Component interactions are data-oriented
• Components need to have a priori agreement on
  data types and what they mean

27
Data-oriented Interoperation

• Event systems
• Publisher-subscriber model
• Publishers are components that publish
  self-describing data items (events) to a local
  event service
• Subscribers are components that register
  specifications with the event service,
  subscribing to particular events
• The local event service forwards a published
  event to all subscribers
• The only interaction methods are publish,
  subscribe, and handle

28
Data-oriented Interoperation

• Tuple spaces
• Repository of data tuples
• Components can add tuples, take tuples out or
  read tuples without removing them
• The only interaction methods are in, out, and
  read
• Data-oriented interoperation
• Components interact by sharing a common
  service(a tuple space, or event service)
• They dont need direct knowledge of one another
• The burden of standardization is shifted to the
  data items (events, tuples)

29
Recombinant Computing, PARC(Obje
Infrastructure, formerly known as Speakeasy)

• Main Concepts
• A small, fixed set of generic interfaces
• presumed to be known to all parties in an
  interaction
• Mobile code for dynamic extension
• sender downloading code to clients for specific
  protocols, data types
• User in the loop
• Decides which devices/service to associate
• Programmatic interfaces define only syntax, user
  must decide what makes sense

30
Set of Common Interfaces

• Data Transfer
• Sender transfers source-provided endpoint to its
  receiver, to initiate sender-specified protocol
• abstracts from the specific protocol or data
  types
• Collection
• provides an interface to a collection of
  components
• e.g. file system, discovery protocol
• Contextual Metadata
• Name-value pairs, primarily for human
  sense-making
• Control
• User interface (administrative, and
  operation-specific)

31
Speakeasy Interaction

• Custom Objects
• each of the generic interfaces is used to return
  a custom object to the caller
• Leases
• custom objects are leased to the clients for some
  period of time
• Client must provide information about itself
• in the form of a metadata custom object
• for components to know about who is requesting
  their services

32
Speakeasy Data Transfer
33
Speakeasy Collections
34
Speakeasy Human in the Loop

• Human Factors
• Control users decide about interconnection of
  services and devices
• Sense-making providing information to the user
  to understand the ubicomp environment
• Intelligibility, Accountability services must
  declare themselves
• Critical User Roles
• Finding appropriate associations (match-making)
• Understanding of service semantics, so that this
  does not need to be coded a priori into devices
• e.g. understanding that Picture Frame as a new
  type of device is good for displaying photos

35

• Security for Spontaneous Interactions

36
Securing Spontaneous Interaction

• How to protect devices
• Not all discovered components are necessarily
  friendly
• Users require security for their resources, and
  privacy for themselves
• Authentication of devices
• Humans can make judgements about trustworthiness
  of their environment
• Trusting a printer because it is in a friends
  house
• Trusting a PDA because its owner is judged to be
  trustworthy
• But how can wireless device associations be
  authenticated?

37
Securing Spontaneous Interaction

• Conference attendees exchange data between their
  PDAs/Laptops
• Visitor sends photo to friends printer (not the
  neighbours)
• Group of people in a Café play a wireless game
• Standard solutions exist for securing a wireless
  link
• But how to ensure that the right link is in
  place?
• The problem is there is no way to directly
  associate a network-discovered entity with a
  physically discovered device

38
Peer device authentication

• Peer device authentication over a wireless
  network requires an out-of-band channel
• A channel that is limited such that the presence
  of an intruder between client and target device
  can be excluded
• Keys can then be exchanged out-of-band
• Or the out-of-band channel can be used that
  wirelessly exchanged keys are in the right
  hands(Key verification)

39
Peer device authentication

• Proposed out-of-band channels
• Touch / direct electrical contact
• Transmission media with limited propagation
  characteristics (e.g. infrared beams)
• Shaking to pair devices (similar movement or
  more generally shared context as shared secret)
• Audio or visual feedback for human verification
  that the intended target received the correct key

40
Summary

• Spontaneous interaction is at the core of the
  ubiquitous computing vision
• But is far from becoming a reality
• Discovery is the smaller problem (many solutions,
  but creating islands of discoverability)
• Interoperability is a major problem
• Security and trust issues in infrastructure-less
  environments