Sensor Network Architecture Panel

1
Sensor Network Architecture Panel

• Deborah Estrin (UCLA)Ion Stoica (Berkeley)Hari
  Balakrishnan (MIT)
• NSF NOSS PI MeetingCambridge, MA, October 2005

2
Panel Charter

• What is a sensor network architecture?
• Some requirements
• Some examples
• What are some open architectural problems?
• How can our community converge on a few
  architectures or architectural choices?

3
Game Plan

• Ten minutes per panelist
• Position statements loosely based on questions
• Open floor to comments, brickbats, questions,
  discussion
• This means you!

4
Musings on Sensor Network Architecture

• Hari BalakrishnanMIT

5
What is an Architecture?

• Architecture (n) -- 5 the manner in which the
  components of a computer or computer system are
  organized and integrated
• Sensor network architecture (n) -- Manner in
  which mechanisms and protocols for sensor
  network-based acquisition, monitoring, control,
  and actuation are organized
• Architecture abstractions and principles, not
  implementation
• An architecture should, within limits, be
  evolvable and permit innovation

6
Designing an Architecture

• Must start with a set of requirements
• We eventually need to agree on a core set
• We should decide whether things we dont agree on
  should be optional, or eschewed
• Software architecture modules interfaces
• Network architecture is more than that

7
Some Requirements

• Heterogeneity (radios, nodes, data types, )
• Common case is wireless (radio) communication
• Generality enable unforeseen applications,
  accommodate variety of services
• Efficiency (energy, channel capacity, congestion)
• Security
• Mobility
• Intermittent connectivity

8
Some Non-Requirements

• Same network infrastructure concurrently used by
  many different applications/users
• Massive amounts of multiplexing
• Point-to-point reliable connections as the common
  case
• Accounting and billing, autonomous entities,
  greedy participants(?)

9
Sensor Network Architecture

• Addressing and naming
• Forwarding
• Channel sharing / congestion management
• Placement of various functions modules, not
  layers
• In-the-net processing
• Routing, reliable data delivery, transport,
  numerous services (localization, timesync, etc.)
• Security model
• State maintenance
• What sort of state? Who creates it? Who
  maintains it? How to cope with failures?

10
Names and Addresses

• Names Arbitrary, outside scope of architecture,
  no constraints
• Identity Each node has an identity, a flatname
• Location/topology-independent
• E.g., hash of public key
• Address All addresses should be geographic
• Location a common attribute
• Virtual coordinates (e.g., level/sibling in
  tree)
• Forwarding On both ID and addresses

11
Broadcast-based Architecture

• With wires, links are shielded from one another
• Sharing starts only at network layer
• Wireless networks have no such shielding
• Radios are not wires!
• Unnatural and inefficient to think in terms of
  links
• Need a new abstraction that embraces broadcast
• Many new techniques frame combining,
  opportunistic routing, multi-radio diversity,
  network coding, etc.
• Open question A broadcast-based wireless network
  architecture

12
In-the-net processing State semantics

• Internet architecture soft state, fate sharing
• Does not accommodate in-the-net processing
• Our generality goal is different from the
  Internet
• Open question principles for how to deal with
  state upon failure, churn, or other changes?

13
Summary

• Identity
• Broadcast-based design
• State management principles
• Security