Proactive

1
Proactive Energy-efficient Middleware

• The Minuteman Project

2
Wireless Networking Computing Technology

• Until Now
• Provide interaction between people and
  human-mediated data sources (other people, web
  services)
• of users of networked nodes
• Resource-rich nodes
• Facilitate human-centered interactive decision
  making
• Communicate bits among geographically distributed
  nodes
• Focus on networking interactive computers

• The Future
• Provide interaction between people and the
  instrumented physical world (sensors, actuators)
• of users ltlt of networked nodes
• Resource-constrained nodes
• Facilitate human-supervised autonomous decision
  making
• Compute answers by fusing real-time information
  from distributed nodes
• Focus on distributed embedded computation

3
Example Future System

• Mobile users query and track mobile targets in
  a battle space instrumented with a number of
  sensor networks composed of a large number of
  energy limited air-borne and ground-based sensor
  nodes (e.g. cameras)
• Users rovers, UAVs, soldiers
• Sensors rovers UAVs carrying sensors, static
  sensor nodes
• Targets vehicles, soldiers

4
Research Issue

• What is the distributed software infrastructure,
  or middleware, to autonomously manage (allocate
  and schedule)
• Sensing
• Communication
• Processing
• Actuation
• in these systems?
• Hurdles
• Large-scale
• Ad hoc
• Dynamic
• Energy-constrained
• Uncertain

5
Problems with what exists

• Conventional network architecture a misfit
• Scale id-based naming and routing does not
  scale
• e.g. unlikely to say give video from UAV with
  address a.b.c.d
• Application-specific no best routing strategy
  for all tasks
• depends on in-network processing local physical
  observations
• Heavy weight protocols too demanding for
  energy-limited nodes
• Energy(wireless bit) gtgt Energy(instruction)
• energy need to be a first class citizen
• Collaborative processing just data
  communications to human-centers not enough
• e.g. directing video-equipped UAVs to locations
  where cheap ground-based sensor clusters detect
  interesting events
• Current sensor network architecture inadequate
• No mobility limited to ground-based static nodes
• No flexibility do not support application
  operational programmability
• Simplistic architecture do not support rich
  hierarchy of sensors
• UAVs (few, global, costly) to UGVs to static
  sensors (many, local, cheap)
• Limited data types seismic, acoustic but not
  streaming vide
• User-centered database query model not
  autonomous distributed

6
Need a Distributed Computing Perspective

• Distributed algorithms with application-specific
  data dissemination protocols
• e.g. localization, tracking, beamforming
• application-specific routing helps with power,
  latency etc.
• Dynamic, resource-constrained environment
• computing-communication trade-offs
• Algorithm specific node coordination
• target detection, target tracking, collaborative
  signal processing, network monitoring, sensor
  coverage, distributed power management,
  coordinated actuation
• Co-design of networking protocols with sensing
  and control computation
• Key is the ability for applications to customize
  the sensing, data dissemination, and actuation
  process

7
Minuteman Middleware Architecture Key Features

• Autonomous agent-based system software model
• Mobile agent scripts injected as queries tasks
  for application-defined processing at the nodes
• replicate and migrate according to application
  logic and the state of the physical world
• Suite of core services for sensing, processing,
  communication, and actuation available at each
  node
• energy-management
• attribute-based sensor data dissemination
• dynamic address configuration
• timing synchronization
• location management
• distributed estimation
• Energy as the key resource
• Actuation gtgt Communication gtgt (Processing,
  Sensing)
• Energy-aware wireless scheduling
• Distributed radio shutdown
• Energy-based admission control
• Sensor-coordinated actuation

8
Agent-based Software Architecture
9
Mobile Agent Scripts

• Self-contained entity with ability to
• execute code on behalf of the user
• not require user interaction
• communicate with its peer
• discover and utilize resources
• spawn new agents and replicate itself
• recursive program
• Why?
• Traditional message passing not convenient
• forces a node-centric programming style
• cannot image all possible scenarios beforehand
• Viewing as a database doesnt work either
• hard to express many tasks as conventional
  queries
• heavy cost of database updates and query
  resolution
• user-in-the-loop

10
Middleware Architecture
Message exchanging
External user can inject agent script
Apps, Services
Apps, Services
Scripts
Scripts
Script migration
Middleware
Middleware
OS
OS
HW abstraction layer
Node 1
HW abstraction layer
Node 2
Hardware
Hardware
Middleware
APIs
Runtime environment
Mobility
Networking
Sensing
interpreter
Script State keeping
Resource handling tasks
Sensor Abstraction
Timers CPU control
Energy-based Admission control resource
management
Networking
11
Prototype Implementation

• Magnetic Sensor
• - uC Based with RS232
• Range of /- 2Gausus
• Adjustable Sampling Rate
• X, Y, Z output
• Device ID Management

• WaveLan Card
• IEEE 802.11b Compliant
• 11 Mbit/s Data Rate

• Familiar v0.5
• Linux Based OS for iPAQ H3600s
• JFFS2, read/write iPAQs flush
• Tcl ported

• iPAQ 3670
• Intel StrongARM
• Power Management (normal, idle sleep mode)
• Programmable System Clock
• IR, USB, Serial (RS232) Transmission

12
System Operation Overview
Script Code injecting

• Mobile Script
• Light weight
• Programmable
• Code Mobility
• Tcl front end

13
Software Organization
14
Event-driven Computation Model

• Agents express the event they are interested in
• Sensor event
• event -data ltnamegt -sample_period ltvaluegt
• -buffer_size ltvaluegt
• -wakeup_period ltvaluegt
• -threshold ltvaluegt
• Timer event
• event -timer ltnamegtltvaluegt
• Network event
• event -net ltnamegt ltstartgt ltreg expgt
• agent can generate network event
• Timer and data event generated by the system
• send ltnode.user.family.instancegt ltmsggt
• wait -net lteventsgt ... -data lteventsgt ...
  -timer lteventsgt ...

15
Mobile Agent Scripts API

• spawn ltnodegt -sltcodegt
• ltbindgt ...
• Binding variables
• Pass-by-name
• Encourage agent reusability
• Support agent modulation
• Embedded Agents
• Agents that are being carried by other ones
• Two methods
• Static
• Prone to errors
• Cannot reuse Mission specific
• High memory usage Carrier has to stay alive!
• Dynamic
• High modulation
• Helper APIs
• nid -all-node-user-family-instance
• Request Network Identification
• neighbor

16
Performance Evaluation

• Key command is spawn
• Derived delay model
• Time difference between spawning agents spawn
  command and spawned agents first command
• Things that affect spawn
• The size of agent
• Larger -gt high cost of memory operation
• Number of existing agents
• Larger -gt long waiting time
• Measurement-based empirical model for current
  implementation
• D a S b N c 0.69S 14.7N 5318
  ?s

17
Tracking Scenario
18
System Operation Phases

• Discovery of user-defined region of interest by
  the initial agent
• Initiate monitoring by lower tier sensors, rest
  asleep
• Detection of an event of interest
• Resource discovery, allocation, wake-up, and
  actuation of higher-tier sensors
• Establishment of data path to user (commander,
  weapon platform)
• Cooperative distributed tracking
• Driver scenario video tracking of targets
  detected by lower echelon sensors
• Simulation preview with O(100) nodes
• Testbed implementation with O(10) nodes
• Demonstration during poster session

19
Energy Management
20
Energy Management Problem

• Actuation energy is the highest
• Strategy ultra-low-power sentinel nodes
• Wake-up or command movement of the mobile nodes
• Communication energy is the next important issue
• Strategy energy-aware data communication
• Adapt the instantaneous performance to meet the
  timing and error rate constraints, while
  minimizing energy/bit

MICA mote Berkeley
WINS node RSC
21
Radio Energy
Tx Sender
Rx Receiver
Incoming information
Outgoing information
Channel
Power amplifier
Transmit electronics
Receive electronics
nJ/bit
nJ/bit
nJ/bit
WLAN 50 m
RFM 10 m
GSM 1 km
22
Managing the Radio Energy

• Region of scaling
• Tuning the energy vs. performance control knobs
• Increase in transmission time results in energy
  decrease
• Up to minimum energy point
• Region of shutdown
• Do not change control knobs
• Turn radio off after transmission
• Energy per bit remains constant

RFDominates(focus Tx)
ElectronicsDominates(focus Rx Tx)
Energy
Scaling
Shutdown
Transmission time
Scaling
Shutdown
time
time
23
Example Distributed Shutdown
Example sensor node

• Sensor networks in two modes
• Monitoring to detect events most of the time
• Relay information to users fraction of the time
• Existing enough nodes kept up to handle data
  relaying
• Substantial wasted energy
• Put radios to sleep and wake them up only when
  needed
• Problem need a wakeup mechanism
• STEM protocol using a separate wakeup radio

event
24
Energy vs. Latency Trade-off
Forwarding 10
Relative energy savings
Forwarding 1
Forwarding 0.1
Setup latency per hop (s)
25
Energy vs. Latency and Spatial Redundancy
Forwarding 0.1
Only spatial redundancy (GAF)
Ts 0.05 s
Only STEM
Ts 0.07 s
Ts 0.09 s

• Spatial redundancy nodes in the same grid are
  redundant
• Each grid has one active node behaves as a
  virtual node
• Virtual nodes run STEM

Ts 0.93 s
Lower bound
Network density (average of neighbors)
26
Selected Core Services
27
Network self-configuration

• Network self-configuration essential for a
  self-organizing ad hoc network
• Needed services
• Timing synchronization
• Address assignment
• Channel/cluster assignment
• Localization
• Important issues
• Energy-efficiency
• Mobility

28
Timing Synchronization

• Limitations of existing schemes
• Synchronization via GPS not always feasible
• Foliage and obstructions
• Cost, energy and size limitations
• Vanilla NTP not scalable for ad hoc networks
• Set of servers need to be pre-specified
• Many clients multihop to few servers
• Our approach
• Level discovery phase
• nodes dynamically organized into a hierarchical
  topology with levels and a root that may elected
  via leader election
• Localized synchronization phase
• periodically initiated by root
• node at level i synchronizes to node at level i-1
• Special provisions for new, dying, and mobile
  nodes

29
Simulations Results

• Scenario typical of ground based nodes
• low rate (20 kbps) and short range (20 m) in a
  100 m x 100 m area
• 0.01 ms granularity clock with 20 ppm drift

Time for two phases vs. of nodes
Synchronization error vs. of nodes(Ave. error
0.75 ms)
30
Simulations Results (contd.)
Spatial variation of synchronization error(Ave.
neighborhood error 0.06 ms)
31
Dynamic Addressing

• Addressing in sensor networks
• Network layer addresses
• Network-wide unique ID, e.g. node 1729
• Attribute base, e.g. node with camera in
  north-west corner
• MAC layer addresses
• Uniquely identify neighboring nodes at link layer
• Need not be globally unique
• Reducing overheads
• Small data packets
• Short attribute-based network layer addresses
• Reducing MAC header overhead
• On-demand link labels instead of node addresses
• Efficient scalable representation using Huffman
  codes
• Dynamically assigned via a scalable distributed
  algorithm

32
Spatial Reuse Constraints
9
7
1
0
5
0
3
4
2
2
8
8
4
6
3
1
33
Localized Assignment Algorithm

• Local exchange of control messages
• On-demand label assignment for different traffic
  flows
• Idea is to make each node aware of its 2-hop
  neighborhood and those of the nodes at the other
  end of the link

34
Label Selection Frequency Average Label Size

• Settings
• 1000 nodes, average degree 10
• 5 end-to-end traffic flows, average path length
  20 hops

35
Energy Savings

• Protocol control messages result in energy
  overheads
• Net energy saving MAC header savings
  computational overhead protocol overhead for
  bits sent

36
Conclusions

• Software infrastructure to autonomously manage
  sensing, processing, communications, and
  actuation in emerging wireless network
• Agent-based architecture enable adaptive
  self-configuration to application needs and the
  state of the physical world
• Energy is the key resource that has to be managed
  by the software infrastructure
• Core services to self-organize nodes in address,
  time, and space using localized algorithms