MOBILE _ UBIQUITOUS COMPUTING
Document Sample


MOBILE & UBIQUITOUS
COMPUTING
Lâm Vĩnh Tuyên
Nguyễn Công Thương
1
Outline
Introduction
Association
Interoperation
Sensing and context-awareness
Security and privacy
Adaptation
Summary
2
Introduction
Mobile computing: (1980)
Paradigm in which users could carry their
personal computers and retain some
connectivity to other machines
Laptops, PDAs, mobile phones, …
Infrared, WiFi, Bluetooth, GPRS, …
Size, battery capacity >< processing
power, screen and resource restrictions
3
Introduction (cont)
Ubiquitous computing: (Mark Weiser
1988)
To be found everywhere
Wearable computing:
Devices attached to clothes, worn like
watches, jewellery, …
Context-aware computing:
E.g: device will automatically switch
itself to “vibrate” instead of “ring” when
it is in the cinema
4
Introduction (cont)
Volatile systems: changes are
common rather than exceptional
Relevant forms of volatility:
Failures of devices and communication
links
Changes in the characteristics of
communication such as bandwidth
The creation and destruction of
associations between software
components resident on the devices
5
Introduction (cont)
Smart space (SS): physical space
with embedded services (servers,
printers, sensors, …)
Types of movement occur in SS:
Physical mobility
Logical mobility
Add or withdraw static devices
Devices may fail and disappear from a
space
6
Introduction (cont)
Device model:
Limited energy
Resource constraints
Sensors and actuators
Motes
Camera phones
7
Introduction (cont)
Volatile connectivity:
Technology: Bluetooth, WiFi, GPRS, …
Disconnection
Variable bandwidth and latency:
Too big => increase error rates
Too small => increase congestion and
waste energy
8
Introduction (cont)
Spontaneous interoperation:
interactions during association
Lowered trust and privacy:
Trust in volatile systems is problematic
because of spontaneous interoperation
Privacy: user may distrust systems
because of their sensing capabilities
9
Association
Logical relationship formed when at
least one of a given pair of
components communicates with the
other over some well-defined period
of time
Network bootstrapping: solutions rely
on servers accessible within SS (e.g:
DHCP)
10
Association (cont)
The association problem and the
boundary principle:
How to associate approximately =>
address 2 main aspects: scale and scope
Smart space need to have system
boundaries
Solution to the association problem is
using “Discovery services”
11
Association (cont)
Discovery services (DS): is a
directory service
The directory data required by a
particular client
There may be no infrastructure in the SS
to host a directory server
Services registered in the directory may
spontaneously disappear
The protocols need to be sensitive to the
energy and bandwidth they consume
12
Association (cont)
Methods for service Explanation
de/registration
Lease:=register(address,attribu Register the service at the given
tes) address with the given attributes; a
lease is returned
Refresh(lease) Refresh the lease returned at
registration
Deregister(lease) Remove the service record registered
under the given lease
Method invoked to look up a
service
serviceSet:=query(attributeSpec Return a set of registered services
ification) whose attributes match the given
specification
13
Association (cont)
Issues in the design of a DS:
Low-effort, appropriate association: without any
human effort
Service description and query language: match
services to client’s request for services
Smart-space-specific discovery: access an
instance (scope) of DS which is appropriate to
physical circumstances
Directory implementation: network bandwidth,
timeliness of DS and energy consumption
Service volatility: handle client and service
disappearance
14
Association (cont)
Physical association: the following
techniques have been developed
Human input to scope discovery:
Sensing and physical constrained channels to
scope discover:
Direct association: without using a DS
Address-sensing: use a device to sense the
network address of the target device directly
Physical stimulus: use it to cause the target
device to send its address
Temporal or physical correlation: use temporary
or physically correlated stimuli to associate
devices
15
Interoperation
Models for interoperation including various
forms of inter-process communication,
method invocation and procedure
invocation
Problem: software interface incompatibility
Approach:
Allow interfaces to be heterogeneous
Constrain interfaces to be identical in syntax
across as wide a class of components as
possible
16
Interoperation (cont)
Data-oriented programming for volatile
systems:
Models for interoperation between indirectly
associated components:
Event systems
Tuple spaces
Designs for interoperation between directly
associated components:
JetSend: for interactions between appliances
such as cameras, printers, scanners and TVs
Speakeasy
17
Interoperation (cont)
Event Service
event event
(structured data)
Publisher Subscriber
Event System
18
Sensing & context-awareness
Sensors: some examples
Location, velocity and orientation:
satellite navigation units,
accelerometers, magnetometer
Ambient conditions: thermometers,
sensors measure light intensity, sound
intensity
Presence: sensors measure physical load
19
Sensing & context-awareness
(cont)
4 challenges in designing context-
aware systems:
Integration of idiosyncratic sensors
Abstracting from sensor data
Sensor outputs may need to be
combined
Context is dynamic
20
Sensing & context-awareness
(cont)
Architectures support context-aware
applications:
Sensing in the infrastructure: set of
sensors is relatively stable
Wireless sensor networks:
Set of sensors forms a volatile system
Consist of a number of small, low-cost
devices or nodes each with facilities for
sensing, computing and wireless
communication
21
Sensing & context-awareness
(cont)
Location-sensing: the most attention
Type Mechanism Limitations Accuracy Type of location Privacy
data
GPS Multilateration Outdoors 1-10m Absolute Yes
from satellite only geographic
radio sources (satellite coordinates
visibility) (latitude,
longitude,
altitude)
Active Bat Infrared Sunlight or Room Proximity to Tag
sensing fluorescent size known entity identity
light disclose
d
Easy Vision, Camera Variable Relative (room) No
Living triangulation installation coordinates
s
22
Sensing & context-awareness
(cont)
Architecture for location-sensing:
The location stack: it divides location-
sensing systems for individual SS into
layers
The sensor layer: contains drivers for
extracting raw data from a variety of
location sensors
The measurements layer: turns raw data
into common measurement types including
distance, angle and velocity
The fusion layer: combines the
measurements from different sensors to
infer the location of an object 23
Security and Privacy
User and admin require security for
their data and resources
(confidentiality, integrity, availability)
– Trust is lowered in volatile systems.
Privacy – ability to control the
accessibility of information.
24
Hardware related issues
Portable devices are more easily
stolen and tampered. A security
design should not rely on the integrity
of any subset of devices.
Devices in volatile systems don’t have
sufficient computing resources for
assymetric (public-key) cryptography
symmetric cryptography sharing
key.
25
Hardware related issues
Energy – security protocol must be
design to minimize communication
overheads and new type of denial of
service attack.
Disconnected operation – avoid
security protocols that rely on
continuous online access to a server.
26
New type of resource sharing
The admin of a smart space expose a
service accessible to visitors over
wireless network.
Two employees of the same company
exchange a document between their
mobile phone at a conference.
A nurse take a wireless heart-rate
monitor from a box, attaches it to
patient.
27
New type of resource sharing
Secure spontaneous device association
– secure transient association problem.
Goal is to create a secure channel
between two devices by securely
exchanging a session key.
Assumptions: any device or user
Not share a secret with the other.
Not posess the other’s public key.
Don’t have access to a trusted third party.
28
Potential threats
Attacker can eavesdrop, replay and
synthesize messages.
Attacker may attempt to launch a
man-in-the-middle attack.
29
Solutions
Users can exchange their own key,
but short string can be learned by
exhaustive search.
Using side channel with certain
physical properties: one of devices
generates a fresh session key and
sends it to the other over a receive-
constrained channel: physical
contact, infrared, audio, laser,
barcode and camera.
30
Solutions (cont.)
Use a constrained channel to physically
authenticate one device’s public key,
then use it to exchange a session key
devices are powerful enough.
Exchange a session key insecurely and
then validate it - use a physical
constrained channel to verify that the
key is possesed solely by the required
physical source.
31
Association methods
The methods are vary in the degree of
security but are suitable for spontaneous
association:
None requires online access.
None requires users to authenticate
themselves.
32
Location-based authentication
Users require privacy don’t want to
provide personal information.
Admins require security require
access control.
Base on location of the services’
clients.
33
Privacy protection
Even though users withhold their
identity, there may be some type of
potentially identifying information.
34
Solutions
Provide name and addresses in
service accesses.
Using MAC-level address – visible to
other devices such as access point.
Using RFID tags.
link to the user’s personal
information.
using “soft” address.
35
Solutions (cont.)
Using privacy proxy: each device has
a secure, private channel to the
proxy.
Problems:
Central point of vulnerability.
Proxies don’t hide which services the
users access.
36
Solutions (cont.)
Mixing:
Construct an overlay network of proxies
that encrypt, aggregate, re-order, and
forward messages. Each proxy trusts and
shares keys only with its neighbors.
Obscure users’ locations by exploiting
the presence of many users in each
location.
37
Adaptation
Devices in volatile systems are much
more heterogeneous than PCs in
processing power, I/O capabilities
and energy capacity.
The presence of runtime change
itself: runtime conditions such as the
available bandwidth and energy are
prone to chage dramatically.
38
Context-aware adaptation of
content
Multimedia application.
Send the same content bandwidth
limitations and device heterogeneity.
Content is a function of context:
media producer should take account
not only of the consuming device’s
capability, but also such factors as
the preferences of the device’s user,
and the nature of his or her task.
39
Solutions
HTTP protocol:
A client specifies preferences for the
MIME types of the content it cac accept
in its request header.
The server try to match those
preferences in the content it returns.
40
Solutions (cont.)
Type-specific compression: proxies perform
compression:
Compression should be lossy but specific to the
media type semantic information can be used
to decide which media features it is important to
retain.
Transcoding should be performed on the fly
because statically pre-prepared content forms
will not provide sufficient flexibility to cope with
dynamic data.
Transcoding should be performed in proxy
servers so that both clients and services are
transparently separated from transcoding 41
concerns.
Problems
Volatile systems require adaption between
any pair of dynamically associated devices.
Adaption is not restricted to clients of
particular services.
There are potentially many more providers
whose content needs to be adapted.
The providers may also be too resource-
poor to perform certain types of adaption
themselves.
42
Adapting to changing
system resources
OS support for adaptation to volatile
resources: Satyanarayanan:
Application request and obtain resource
reservation.
Notify the user of changed levels of
resource availability they can act
according to application.
OS notify the application of changing
resource conditions and the application
adapt according to its particular needs.
43
Solutions
OS support for adaptation to volatile
resources: Odyssey architecture:
Applications manage data types (video,
images)
When resource conditions change, they
adjust the fidelity – the type-specific
quality
Viceroy divides the device’s total
resources between each of several
applications running on it.
44
Solutions (cont.)
Odyssey architecture
Each application runs with a window of
tolerance to changes in resource
conditions.
When the viceroy has to change resource
levels to a value outside the window of
tolerance, it makes an upcall into the
application, which then reacting
accordingly.
45
Solutions (cont.)
Taking advantage of smart space
resources: Cyber foraging:
A processing-limited device discovers a
compute server in a smart space and
overloads some of its processing load to
it.
Energy-aware adaptation: save the
portable device’s batteries by allocating
work to the mains-powerd compute
server.
46
Solutions (cont.)
Challenging requirements:
The application needs to be decomposed.
The compute server should run a part of
the application that involves relatively
little communication with portable
device.
The overall energy consumption for the
portable device must be satisfactory.
Communication is energy-intensive
energy cost of communication is high.
47
Solutions (cont.)
Goyal and Carter: decompose the
application in to separate
communicating programs. Example the
speech recognition
The application runs entirely on the mobile
device.
The mobile device runs only the user
interface, which ships the digital audio to a
program running on the compute server
48
Summary
Volatile systems:
The set of users, hardware and software
components are unpredictable changed.
Connection bandwidth can vary widely.
Components are heterogeneous.
Energy is limited.
Association.
Interoperation.
49
Summary
Sensing and context awareness.
Security and privacy.
Adaptation.
50
Question
Thank you very much
51
Get documents about "