TargetEnvironment Heterogeneoussensors TinyWebServices: - - PDF document

11/4/08
 1


Tiny
Web
Services:



Design
and
Implementa=on
of
Interoperable
and
Evolvable
 Sensor
Networks


Nissanka
Priyantha,
Aman
Kansal,
 Michel
Goraczk,
Feng
Zhao
 Sensys
2008


Presented
by
Chien‐Liang
Fok
for
CSE
521S,
Fall
2008


Target
Environment


• Heterogeneous
sensors

• Deployment
in
an
enclosed
area


– All
sensors
within
a
few
hops
of
the
gateway
 – E.g.,
office,
home,
warehouse


• Mul=ple
co‐exis=ng
sensing
tasks


2


Example
Applica=on


• Home
energy
consump=on
management

• The
United
States
in
2001:


– 107
million
residen=al
homes
 – 21.86
quadrillion
(1015)
Btu
consumed
 – $157.5
billion


• WSN
can
help
op=mize
energy
consump=on


– “Evolu=onary
deployment”
needed
for
cost
 effec=veness


3


Problem


• Current
WSNs
use
proprietary
protocols
and


message
formats


– Gateway
cannot
expose
new
node
func=onali=es


• Prohibits



– evolu=onary
WSNs
 – addi=on
of
end‐user
applica=ons


4


Solu=on


• Provide
an
API
such
that
all
sensors
are


available
to
all
applica=ons


• Increases
cost‐effec=veness
of
WSN


5


Two
Fundamental
Requirements


• Structured
Data


– Sensor
data
must
be
understood
by
applica=ons
 – E.g.,
XML


• Programma=c
descrip=on
of
func=onality


– Func=onality
of
sensor
node
must
be
 automa=cally
understood
by
programs
 – Enables
programs
to
adapt


6


11/4/08
 2


Exis=ng
Solu=on:
Web
Services


• Access
remote
resources
as
if
they
were
local


– Float temperature = GetTemperature(string Location)

• Used
on
the
Internet

• Structured
data:
web
method
call

• Func=onality
descrip=on:
web
service


descrip=on


7


Advantages
of
using
Web
Services


• Support
evolving
systems

• Interoperability

• Improved
system
programmability

• Ease
of
integra=on
with
enterprise
systems
via


the
Internet


8


Research
Goals


• Quan=fy
cost
of
providing
web
services
in


WSNs


• Enumerate
design
op=ons
and
tradeoffs


– Iden=fy
op=mal
configura=on
for
WSNs


• Implement
the
system


– Efficiency


• Simplify
applica=on
programming


– Use
exis=ng
web
service
development
tools


9


Research
Non‐Goals


• Simplify
programming
of
WSN
nodes


– May
use
exis=ng
tools
like
TinyOS
and
SOS
 – Only
requires
a
web
service
interface
and
WSDL
 descrip=on


• Restrict
in‐network
processing


– Method
calls
may
s=ll
result
in
mul=ple
nodes
 collabora=ng
 – May
use
any
protocol
(including
proprietary
ones)


10


Sources
of
Overhead


• The
network
layer
(IP)

• The
transport
layer
(TCP)

• The
applica=on
layer
(web
services)


11


TCP/IP
Design


• Overhead
between
WSN
node
and
PC:

• TCP
message
latencies:


TCP
 TCP
Retransmission


11/4/08
 3


TCP/IP
Op=miza=ons


– Persistent
TCP
connec=ons



• 25ms
savings


– Disabled
delayed
TCP
 acknowledgements


• 200ms
savings


– Link
Layer
re‐transmissions


• 2900ms
savings


– Low‐power
mode
between
TCP
 messages
 – 6lowpan
&
link
layer
fragmenta=on


13


TCP
without
delayed
ACK


Duty
Cycling
Nodes


• Many
sensors
can
be
event
driven


– IR‐based
mo=on
sensor,
glass‐break
detectors,
 door
intrusion
sensors,
smoke
sensors,
etc.


• Duty‐cycle
these
nodes
to
increase
efficiency

• Use
web
service
even=ng:


14


Web
Service
Method
Encapsula=on


• Web
Service
Descrip=on
Language
supports


three
protocols:



– SOAP,
HTTP,
and
MIME


• SOAP
is
the
de‐facto
standard,
but
too
costly:

• TinyWebServices
use
HTTP


15


Accessing
a
Service


• HTTP
GET


– E.g.,
hkp://192.168.1.4/setTemp?temp=25


• URL
Replacement


– E.g.,
hkp://192.168.1.4/setTemp/temp/25


• XML
Post


– Send
an
XML
message
with
method
name
and
 parameters


• Tiny
Web
Services
uses
the
first
two
because
they


are
less
verbose
and
require
a
simpler
interpreter


16


XML
on
WSN
Nodes


• Implement
custom
node‐specific
parser
to


conserve
memory


– Only
parses
expected
“simple”
messages
 – Transparent
to
client
applica=on


• Compress
XML
messages


17


Evalua=on
Testbed
Planorm


• MSP430F1611
processor,
6MHz,
48K
ROM,


10K
RAM


• CC2420
IEEE
802.15.4
radio,
250kbps

• μIP
TCP/IP
stack


18


11/4/08
 4


Evalu=on
Testbed
Configura=on


• Fine
granularity
=ming
measurements

• Hard‐wire
connec=ons
to
=ming
node


19


Message
Comm.
and
Processing
Time


• Processing
=me:


– First
TCP
packet:
10.67‐9.68
=
0.99ms
 – Second
TCP
packet:
36.35
–
35.53
=
0.82ms


20


Energy
Cost


• Incremental
cost
of
web
services
is
low

• Cost
is
higher
as
message
frequency
increases


– Home
energy
mgmt
applica=on
uses
messaging
 periods
between
10‐100
minutes


21


Response
Time


• Response
=me
not
significantly
affected
by


request
size,
so
long
as
it
fits
in
one
packet


22


System
Implementa=on


• Home
energy
management
applica=on

• 12
day
deployment

• Client
applica=ons
wriken
using
Visual
Studio
or
Net
Beans
IDE

• Uses
sensors
typical
of
security
and
medical
alert
applica=ons


23


Memory
Consump=on


• Power
sensor
node:

• Can
easily
fit
on
MSP430


24


11/4/08
 5


The
Smart
Socket


• WSN
node
has
Smart
Socket
for
controlling


power
to
device


25


Sensor
Data
from
Home
Deployment


• From
volunteer
family

• Time
axis
omiked
to


protect
privacy


• Applica=on
uses
data


from
mul=ple
sensors
 to
determine
home


• ccupancy


26


Energy
Savings
Results


• Lower
temperature
when
home
not
occupied

• Total
energy
consump=on
reduc=on
was
7.2%


27


Remaining
Challenges


• Sleep
modes


– Persistent
TCP
and
even=ng
supports
sleep
modes
 – Must
ensure
network‐layer
services
are
not
 broken
by
sleep
modes


• Mesh
overheads


– All
results
are
on
single‐hop
wireless
network


• Security


– Need
to
secure
the
system


28


Conclusions


• Web
services
can
be
op=mized
for
use
in


WSNs


– Supports
evolvable
systems
 – Enables
interoperability
 – Overhead
is
not
significant


29


Ports
and
Binding


• Two
key
components
of
web
services

• Ports


– Applica=on
layer
func=onali=es
that
are
provided
 – E.g.,
callable
methods


• Binding


– The
network
protocols
that
are
supported
 – E.g.,
SOAP


• Both
are
specified
using
web
service


descrip=on
language
(WSDL)


30