Creating an Architecture for Wireless – in a nutshell Sensor Networks

Download Report

Transcript Creating an Architecture for Wireless – in a nutshell Sensor Networks

Creating an Architecture for Wireless
Sensor Networks – in a nutshell
David Culler, Scott Shenker, Ion Stoica
Electrical Engineering and Computer Sciences
University of California, Berkeley
NETS/NOSS Infosession
Sensor Network Networking Today
Appln
Hood
EnviroTrack
FTSP
Transport
Routing
Scheduling
SPIN
TTDD
Phy
5/25/2016
Ascent
GPSR
SPAN
ReORg
PC
Drip
Arrive
MintRoute
GRAD
GAF
FPS
Yao
SMAC
PAMAS
Link
Trickle
Deluge
MMRP
TORA
CGSR
AODVDSR
ARA
GSR
DBF
DSDV
TBRPF
Resynch
Topology
TinyDB
Dir.Diffusion
Regions
WooMac
TMAC
Pico
WiseMAC
Bluetooth
RadioMetrix
RFM
CC1000
NETS NOSS
eyes
BMAC
802.15.4
nordic
2
The “Internet Architecture”
• End-to-end flows
– Pt-to-pt dominantly
– Many applications sharing
the network
application
transport
network
IP
link
physical
• 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
5/25/2016
NETS NOSS
3
What role a “sensor net architecture”?
Env. Monitoring
Structures
Detection/Alarm
Active
•
Environments
Tracking
Distr. Control
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
5/25/2016
NETS NOSS
4
Emerging view of sensor networking
Applications
Compose what they need
Multiple
Network
Layer
Protocols
Pt-Pt
Routing
1-1
Tracking
Application
Neighborhood
Sharing
1-k / k-1
Sensing
Application
Aggregation
N --- 1
Data
Collection
N-1
Robust
Dissemination
1-N
5/25/2016
NETS NOSS
???
infneon
BlueTooth
IEEE
802.15.4
***
Multiple
Link and
Physical
Layers
CC1000
Rich Common Link Interface (SP)
5
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
5/25/2016
NETS NOSS
6
Areas of Work
•
Physical Architecture
–
–
–
–
•
Programming Architecture
–
1.
2.
3.
4.
5.
6.
7.
•
•
•
•
Multitier, non-homogeneous (patches, transit, internet)
SNA should not require unconstrained nodes
Should utilize unconstrained nodes to reduce burden on constrained ones
Mobility within physically embedded context
SNA will define consistent interfaces that encompass seven communication
abstractions underlying range of programming models
Dissemination
Collection
Aggregation
Localized Neighborhood
Point-to-point
Data-centric storage
Attribute-based routing
Functional Architecture
Protocol Architecture
System Support Architecture
Design Principles
5/25/2016
NETS NOSS
7
Areas of Work (2)
•
•
•
Physical Architecture
Programming Architecture
Functional Architecture
– Thin-waist as expressive interface to best-effort 1-hop broadcast - SP
– implement over a range of links, utilize by a range of network protocols
– Higher level optimization within control & info exposed by SP
•
Protocol Architecture
– 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
– Name based: simple set of primitives at SP layer that allow network layer
services to dictate and use naming schemes
» Discovery, formation, maintenance, forwarding
» Application-independent portions support sharing of partner
networks
– In-network storage: provide soft-state abstraction as building-block for
variety of address-free and name-based network protocols
– active in-network storage: identify minimalist actions that are flexible
enough to higher levels to express meaningful predicates and queries
• System Support Architecture
NETS NOSS
• 5/25/2016
Design Principles
8
Areas of Work (3)
•
•
•
•
Physical Architecture
Programming Architecture
Functional Architecture
Protocol Architecture
– Key cross-layer issues: discovery, time coordination, power
management, network management security
– Focus on cooperative interfaces
• System Support Architecture
– SNA independent of particular OS, but implemented on one
– extend TinyOS to better support SNA processing
» Encapsulation, Buffer management, Robustness, Scheduling
• Design Principles
– Initial set guide the SP approach
– Refined through the process
5/25/2016
NETS NOSS
9
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
5/25/2016
NETS NOSS
10