Creating an Architecture for Wireless Sensor Networks

1
Creating an Architecture for Wireless Sensor
Networks

• David Culler, Scott Shenker, Ion Stoica
• Electrical Engineering and Computer Sciences
• University of California, Berkeley
• NETS/NOSS PI Meeting
• 10/12/04

2
Sensor Network Networking Today
Appln
EnviroTrack
Hood
TinyDB
Regions
FTSP
Dir.Diffusion
SPIN
Transport
TTDD
Trickle
Deluge
Drip
MMRP
Arrive
Routing
TORA
Ascent
MintRoute
CGSR
AODV
GPSR
ARA
DSR
GSR
GRAD
DBF
DSDV
TBRPF
Scheduling
Resynch
SPAN
FPS
GAF
ReORg
Topology
PC
Yao
SMAC
WooMac
PAMAS
BMAC
TMAC
WiseMAC
Link
Pico
802.15.4
Bluetooth
Phy
eyes
RadioMetrix
CC1000
nordic
RFM
3
The Internet Architecture

• End-to-end flows
• Pt-to-pt dominantly
• Many applications sharing the network
• Over best effort packet delivery service
• Opaque, universal routing service
• Agnostic to physical link and application
  characteristics
• Radical simplification of a really hard problem
• Efficiency cost
• Quality cost

application
transport
IP
network
link
physical
4
More Realistically
mgmt
FTP
Telnet
HTTP
SMNP
NTP
SNMP
UDP
TCP
BGP
IGMP
OSPF
ICMP
IP

• 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

5
What role a sensor net architecture?

• Wide range of long-lived applications
• Diverse, constrained, evolving resources
• Low duty cycle
• Small tables
• Loss, noise change
• Embedded in adapting to phy. env.
• In-network processing, not E2E
• Highly application specific
• WSN needs a narrow waist
• Few applications over many nodes

6
Emerging view of sensor networking
Applications Compose what they need
Tracking Application
Sensing Application
Multiple Network Layer Protocols
7
Six Aspects of a Sensor Network Arch.

• Design Principles
• Guidelines and constraints, what functionality,
  what state
• To what are we agnostic
• Functional Architecture
• Logical building blocks/protocols, interfaces,
  interconnections, interdependencies
• Programming Architecture
• API/ISA what logical data types and operations
  are expressible
• Protocol Architecture
• Distributed algorithms to provide each component
  service, defn. of the information exchanged
  between instances
• Most existing work is of this form
• System Support Architecture
• Capabilities of the node to support the network
  arch.
• Physical Architecture
• Set of nodes, interconnects, communication
  fabrics upon which network is constructed

8
Physical Architecture

• Dense patches of sensing nodes
• Many resource constrained
• Non-homogeneous
• Modalities, roles, HW, SW
• Power, BW
• Transit tier
• Often specialized wireless
• Provides gateways
• Internet Tier
• Multiple connections to infra
• Deep storage, proc. Viz
• SNA should not require unconstrained nodes
• Should utilize unconstrained nodes to reduce
  burden on constrained ones
• Mobility within physically embedded context

Patch Network
Sensor Node
Sensor Patch
Gateway
Transit Network
Basestation
Client Data Browsing and Processing
Base-Remote Link
Data Service
9
Programming Architecture

• Real sensor networks have internal programming
  interface and external programming interface
• External how information is extracted
  from/provided to sensor net and processed upon
  conventional networked resources (not our focus)
• Internal how are applns within the sensor net
  constructed, how is each level of capability
  utilized
• Concurrent agg. / Macroprog. / Dataparallel
  Models emerging
• Nodal approaches becoming relatively established
• Key constituent communication abstractions
• Dissemination
• Collection
• Aggregation
• Localized Neighborhood
• Point-to-point
• Data-centric storage
• Attribute-based routing
• SNA will define consistent interfaces that
  encompass these seven communication abstractions
• reliability, scope, failure, join, consistency,
  power mgmt, scheduling

10
Functional Arch New Thin Waist (SP)

• Best-effort, single-hop broadcast
• Expressive abstraction to simple link layer
• Allow network-level control and optimization
• Initial and collision avoidance backoff, power
  state, xmit strength, preamble gen/sampling,
  link-level ack, retransmission, post-arbitration
  timestamping
• Upward TOA, strength, performance energy char.
• Mechanisms which higher-levels use to implement
  policy
• Hidden-terminal avoidance
• Fragmentation
• Routing
• Power management
• Comm. Scheduling
• Higher levels optimize for range of phys in
  terms of SP abstraction
• SNA will define SP, implement over a range of
  links, utilize by a range of network protocols

11
Funct. Arch Address-Free Protocols

• Sensor nets overlay physical space of interest gt
  many data processing abstractions naturally
  expressed without reference to node addresses
• Not even physical location
• Neighbor neighbor subsets, dissemination
• Names may be used to distinguish nodes when not
  used for comm.
• Provide communication over connected subset of
  nodes defined by retransmission predicate
• Extreme RTP true (whole net), RTP false (one
  hop)
• Many intermediate hop count, attribute match, .
  . .
• Key question expressibility of RTP
• Operators, caching, data lifetime, consistency
• SNA build collection of address-free protocols
  over SP, focusing on general, yet efficient
  techniques for defining forwarding predicate and
  reusable mech. For duplicate detection,
  suppression, and transmission scheduling.

12
Funct. Arch Name-based Protocols

• Also an important class of network-layer services
  based on node names
• Collection, aggregation, and pt-pt
• fit of routing protocol and addressing
  structure often key to efficiency
• What naming scheme? How is forwarding done WRT
  naming? How to discover and maintain routing
  state?
• Differentially process packets based on one or
  more names
• Local or global scope, represent node, set, or
  structure (tree)
• Spatial, pseudo-spatial, structural,
• Formation and management of connectivity graph
  (routing tables) fundamental to this class
• SNA simple set of primitives at SP layer that
  allow network layer services to dictate and use
  naming schemes
• Discovery, formation, maintainence, forwarding
• Application-independent portions support sharing
  of partner networks

13
In-network Storage (INS)

• storage complicates the net. architecture
• Motivation in-network processing, high loss
  rates, intermittent connectivity, bulk transfer
• How to provide INS while preserving ability to
  operate while nodes come and go and to restart
  network from scratch?
• Storage requirements closely tied to network
  layer protocol
• collection/parent ids, aggregation/partial
  result, dissem/transaction history
• SNA provide soft-state abstraction as
  building-block for variety of address-free and
  name-based network protocols
• where in network layer storage is essential to
  provide reliability, persistence, and effective
  bulk transfer vs. in the transport layer above
• Passive storage

14
Active In-Network Storage

• Example triggering actions when data reaches a
  rendezvous point in the sensor network
• Each packet is associated with an identifier, not
  a destination
• Receiver uses identifier to obtain delivery of a
  packet
• Approach associate actions with trigger matches
• Triggers deposited into abstract identifier space
• Example send packet to all nodes that measure
  temp lt 60
• Diffusion effective when large subset involved
• Rendezvous effective when small subsets
• Sweet-spot of generality of action vs
  expressiveness?
• SNA identify minimalist actions that are
  flexible enough to higher levels to express
  meaningful predicates and queries

15
Cross Layer Issues

• Cross-layer control, as well as optimization, is
  critical in sensor networks
• Essence of application specificity
• Discovery foundation of self-organization
• Life of a sensor net planning, deployment,
  evolution
• Each level needs to identify neighbors and
  relevant charactersitics
• SNA design discovery service that consolidates
  peer-wise information across layers
• Time Coordination
• Link-level temporal relationship, propagation
  across hops, multiple uses within vertical stack
• Appln level sampling of correlated readings vs
  TDMA
• SNA configurable time service, probably with
  pieces at multiple layers, providing interfaces
  to other protocol components

16
Cross Layer (cont)

• Power Management
• Traditionally buried in MAC, scheduled routing
  protocols, aggregation epochs, application
  control,
• SNA generalize the multitude of specific
  techniques in use into a set of interfaces with a
  composable usage discipline that allows
  individual components of the arch. To establish
  their portion of the overall power scheduling
  apparatus
• Network Management
• Essential that networks monitor themselves and
  adapt.
• Node-local falesafes
• Operator based tools emerging e.g., nucleus,
  snms
• SNA Interfaces for composable management hooks
• Security
• Encryption available in the links, key management
  is challenging
• Need clear demarcation and enforcement of admin.
  Domains, despite physical collocation
• SNA security must be considered in the context
  of each component of the arch.

17
System Support

• SNA definition should be independent of any
  particular operating system, but it must be
  realized on some
• rough consensus on running code
• High quality system support can facilitate
  development, exploration and efficacy
• Plan to extend TinyOS to better support SNA
  processing
• Encapsulation,
• Buffer management
• Robustness
• Scheduling

18
Goal Open, Interactive Community Process

• Push-and-pull
• Actively pull in components developed by the
  community
• Actively push out the framework
• Interactive dialog on both
• Community Workshops early and often
• First one march 04
• Initial framework for feedback on direction
• Establish key collaboration participants in
  sub-areas
• Annual follow-ons
• Experience, feedback, planning, prioritize, next
  steps
• Winnowing process for interfaces, components
• Network stack(s) openly available to entire
  program at all times
• On testbeds as they emerge
• Series of course materials
• Intend to be shared and circulated

19
Doing Science on architecture?

• Not a matter of narrow, controlled experiments
• Develop n complete architectures their
  implementations then compare not.
• Develop the ideal architecture, implement and see
  if anyone adopts not
• Iterative process of formulating multiple
  alternatives, winnowing, and repeat
• High level analysis and evaluation
• Deep implementation of components relative to
  leading candidates
• Controlled experiment analysis within each step
• Engage the community in feedback/evaluation as
  well as next direction all along the way