Towards a Network Architecture for Wireless Sensor Networks where do we need to think different abou

1
Towards a Network Architecture for Wireless
Sensor Networks - where do we need to think
different about these networks -

• David Culler
• NSF Sensor Net Panel
• USC/ISI
• 2/20/04

2
The Quest

• Monitoring Managing Spaces and Things

applications
Store
Comm.
uRobots actuate
MEMS sensing
Proc
Power
technology
Miniature, low-power connections to the physical
world
3
A.M. (ante-mote) emphasis
Applications
Collaborative sig. Proc.
tuple-based naming
cluster formation
Redundancy utilization
Dissem. Alg.
Topology formation
Xmit control
MAC alg
Technology
4
P.M. emphasis
Applications
Mech. design
deployments
Robust gateways
data vis.
Mhop collect
transit pub/sub
bcast
logging
net prog
prog. env
Quer. Proc.
nD store
agg.
Nbr mgmt
O.S.
Mhop anal.
watchdog
Power mgmt
sensor i/f
loss character
link estimation
MAC impl.
Technology
5
Now time to work on the architecture
Applications
Sensor Network System
Architecture
Technology
6
Starting points ???

• 0. Many ind. Pt-pt flows
• Multiplex utilization of diverse nets
• Internet continue despite loss of nets
• Multiple types of comm svc
• Accommodate variety of nets
• Distributed mgmt
• Cost effective
• Easy host attach
• Accountable

• E2E
• Reliable byte stream over best effort packet
• hard layering
• 1 net loss rule
• Evolution of arch from multiple implementations

7
Capability Catalog

• Traffic Patterns gt collectives, topology
  sensitive
• N-1 Data collection / Aggregation
• 1-N Broadcast / Disseminate
• 1-k Local neighborhood
• 1-1, K-K Few dynamic Pt Pt
• Transport
• Low frequency, small packet, best effort
• Bursts of high fidelity bulk xfer, reliable
• Time Correlation
• Discovery
• Connectivity, neighborhoods, routing, groups
• Route / Role formation and management
• Management
• Debugging
• Security
• DEEP power management
• Limited storage
• Intermittent, infrequent, changing connectivity

telnet, ftp http, smtp,
tcp, udp
ntp
igmp
ospf, bgp
snmp
icmp
8
Example Classical Thinking about Routing

• Discover connectivity graph
• Determine routing subgraph
• relative to traffic pattern
• Route data hop-by-hop
• Queuing, multiplexing, scheduling,
  retransmission, coding,

9
Informed from below
non-isotropic

• Connectivity Determination
• Underlies routing, comm. Scheduling, in-network
  processing
• Under appreciated in mobile ad hoc work
• Reams of geo-based studies
• Numerous recent studies characterizing links
• Connectivity not a simple binary relation
• many occasional receptions
• asymmetries, affinities,
• stable long links
• temporal changes
• Fundamental to mhop sensor net routing
• Not just bad radios
• Quality of neighborhood info fundamentally
  limited by storage, bandwidth, duty cycle, power
• Engages multiple layers

10
What is connectivity?

• CS Ability to correctly receive a large fraction
  of transmitted packets
• EE Signal-to-noise ratio exceeds some threshold

11
The Amoeboed cell
Distance
12
Which node do you route through?
13
What does this mean?

• Always routing through nodes at the hairy edge
• Wherever you set the threshold, the most useful
  node will be close to it
• The underlying connectivity graph changes when
  you use it
• More connectivity when less communication
• Discovery must be performed under load
• Estimation Blacklist not enough
• Need to deal meaningfully with the variation and
  uncertainty
• Impact basic algorithmic structure

14
In-concert above

• Example Radio Power Management
• Traditionally restricted to MAC or Phy layer
• Early rejection of non-dest packets, protocol
  response
• TDMA, cluster head,
• Transparent savings of lt2x, not 100x
• Monitoring applications have natural schedules
• Sample / sleep epochs
• Sleep / Log / burst
• Alarm triggers
• Sleep closely related to storage management,
  reliability technique, fidelity deadline
  requirement
• Informed below passive vigilance techniques
• Other Examples channel back-off, neighborhood
  management,

15
Challenge in the middle

• Example Fine-grain Time Synch
• Below
• RBS and post-MA timestamp yield good fidelity
• Above
• Appln requirements well-defined, but diverse
• Data correlation, co-operative scheduling,
  protocol timeouts
• Challenge is in the middle
• NTP vco game map to usecs
• cannot convert all local readings
• Mark and interpolate
• Conversion per hop tends to accumulate error
• Coarse conversion to reference (global or
  specific)

16
Reliability at many levels

• We will use links that have reliability too low
  to use without regeneration
• Nbr and Routing must deal explicitly with loss
  rate
• Pt-Pt reliability often not meaningful
• Aggregate behavior as nodes come and go
• Need to define at appln level and carry down
• Epidemic dissemination
• Eventual consistency with convergence rate and
  response time
• Transactional routing
• Custody transfer
• Security too

17
Real Sensor Nets have Multiple Layers
Patch Networks
Verification Network

• New challenges at lowest tier
• Higher layers will be primarily IP
• Intermittent connectivity
• Power-aware
• Reframe the lowest layer
• Integrate at many points
• Deep info-mgmt around the sensor net

GW
Transit Network
Client Data Browsing and Processing
Site Link
data storage processing
18
Wither Interoperability?

• Large sensor networks will be deployed for
  particular application(s)
• Valuable even without interoperability
• Multiple distinct services / applns share network
• Interoperable factoring of the stack
• Competitive impl. of MACs, nbr, routing,
  discovery
• Increasingly multiple WS-nets will cooperate
• Backbone nodes vs sensor nodes
• Lightbulb nodes AC control nodes temp. nodes
  tag
• Routing problem ? routing service(s)
• Discovery, profile, role determination,

19
Design Elements

• Design for continual change
• Not the traditional chaotic diverse nets of IP
• Change in connectivity
• Change in components, protocols, platforms
• Change in population (loss, addition, partition)
• Change in application usage
• Change in node diversity (new layers)
• Want State-free / soft-state / easy reactivity
  and repair of E2E, with in-network processing
• Application (aggregation, region detection, CSP)
• Network layers too
• Leery of maintain network structure approaches
• Hard TDMA schedules, cluster head / gateway /
  node,
• Probabilistic schemes more attractive

20
Design Elements (cont)

• Establish traffic models / requirements
• Not statistical multiplexing of independent flows
• Collect / Aggregate / Neighborhood / Broadcast /
  Disseminate
• Net Structure and Physical Constraints DO MATTER
• Nodal scaling constraints
• Power
• everything costs listening, protocol, and
  headers
• often at very low duty cycle not saturation
• Storage
• algorithmic limits of network picture
• Complexity
• every protocol msg is another opportunity for
  loss
• every additional piece of info can be wrong
• Environmental change

21
Towards Architecture
Application
CoS
Net Prog
Agg
MCast
Diffuse
Pt-Pt
Dissem
Time
Handler dispatch
Collect
Hood
Mgmt
Disc
NBR
Protocol dispatch
SP
Net Acc
Net Acc
timer
Sensor
Cross Cutting NBR mgmt Power Mgmt Scheduling Healt
h
Link
Link
Phy
Phy
RFM, CC, 802.15.4, ???
22
Time for Careful Design Engineering

• Protocol Suite
• Protocol Multiplexing
• Sharing and independence
• Encapsulation dispatch
• Minimal set (mgmt)
• In-network proc. Intercept
• Storage limitations
• RAM, flash
• Segmentation / Frag.
• Security
• Naming addressing
• Mac, logical, routable, physical, topological
• Protocol / port
• Time

• Candidate links
• CC, RFM, 802.15.4, BT?,
• System / platform substrate
• Encapsulation w/I stack
• dispatch,
• Pwr
• Scheduling and power i/f
• Above-link packet
• Std?, diverse, IP? Fixed format?
• Nbr mgmt
• inter intra node info
• Estimation
• Min. trans. Rate?
• Transport suite
• Small best-effort vs
• Reliable bulk

23
Understanding fundamentals

• Localized algorithms Distributed computation
  where each node performs local operations and
  communicates within some neighborhood to
  accomplish a desired global behavior
• D. Estrin, 21st Century Challenges
• It takes energy to maintain structure from
  local interactions.
• How much?
• To maintain a routing tree?
• To aggregate?
• To disseminate info?
• Compression / reliability, .