1 Agillas System Architecture Agillas Computational Model Node @ - - PDF document

SLIDE 1

1 Middleware for Sensor Networks: Agilla, Agimone and Servilla

Chien Chien-Liang Fok

• Liang Fok, Gruia-Catalin Roman, and

Chenyang Lu CSE 467S Spring 2009 Wireless Sensor Network Research Group Department of Computer Science and Engineering

Wireless Sensor Networks (WSNs)

• Integration of entire system into a tiny

package (CPU, RAM, wireless NIC, sensors)

• Battery Powered
• Weak radio (IEEE 802.15.4)



Low power consumption



Ad hoc mesh network

Mica2 & Mica2dot

Tmote Sky Intel iMote Tyndall 25mm cube Smart Dust

2

Applications

Structure Monitoring Habitat Monitoring Medical Care Military Container Monitoring Micro-Climate Research Industrial Monitoring

3

Problem Definition

• Software development for sensor networks is

hard



Limited resources



Difficult to debug



Large & dynamic network

• Existing software lacks flexibility



Cannot adapt to changes in

• the environment
• user requirements

4

Motivating Example

• Three applications: 1) Environmental Monitoring, 


2) Fire Detection, 3) Fire Tracking

5

Agilla: A Flexible Middleware for Sensor Networks

• Env. monitoring agent

Fire detection agent Fire tracking agent

• Sensor network as a shared computing resource



Flexible application deployment

6

SLIDE 2

2

Agilla’s System Architecture

TinyOS

Node @ (1,1)

Tuplespace

Agilla Middleware Agents TinyOS

Node @ (2,1)

Tuplespace

Agilla Middleware Agents

migrate remote access

Neighbor List Neighbor List Middleware Services Middleware Services

7

Agilla’s Computational Model

Clone

• r

Migrate Code Stack Heap Condition Codes PC Two variants: 1) Strong (code + state) 2) Weak (code only)

8

Location-Base Addressing

• Capture spatial aspect of WSNs

(3,1) (3,2) (3,3) (2,2) (1,1) (1,3)

clone to (3,3) clone to (3,1)

Fire Detection Agent

9

Tuple Space Coordination: Decoupling

Tuplespace

in {[string:”job”], [type: string]} worker

• ut {[string:”job”], [string:”sense”]}

boss 1 2 bosses workers

10

Lime: Federated Tuple Space

Tuplespace

in {[string:”job”], [type: string]} worker

• ut {[string:”job”], [string:”sense”]}

boss 1 2 bosses workers

11

Agilla: Distributed Tuple Spaces

• Unreliable wireless network
• Distributed transactions are too costly

Distributed transactions are too costly

• Create a unique tuple space to each node



But enable remote access

“out” “rout” “in”

Tuplespace Tuplespace

“in”

12

SLIDE 3

3

Agilla Tuple Space API

• Remotely accessible localized tuple spaces
• Stores context information
• Facilitates inter-agent coordination
• ut:

insert in: remove rd: read inp: probing remove rdp: probing read regrxn: register reaction deregrxn: deregister reaction rout: insert rinp: probing remove rrdp: probing read rrdpg: probing group read (1-hop)
 routg: group out (1-hop) Local Remote

Tuplespace

in

• ut

13

Neighbor Discovery

• Beacon-based



Contains own location + location of known base station

• Each node maintains a list of known neighbors



Access via: getnbr, numnbrs, cisnbr, randnbr

BEGIN pushc 0 // push 0 onto stack getnbr // get 1st neighbor in list rjumpc GOTNBR // jump if neighbor exists halt GOTNBR wclone // weak clone to neighbor pushc 1 putled // turn on red LED halt

Agent @ (x,y): weak clone to first neighbor if one exists

14

Implementation on TinyOS 1.x

• Agilla is available for Mica2 and MicaZ motes



4 agents/node

• Agent Injector



Written in Java



Remote Injection via RMI

• Key Challenges:



Memory:

• ROM: 54.7KB of 128KB
• RAM: 3.5KB of 4KB



Message loss

15

Engineering Challenges (1 of 3)

• Unreliable communication



divide agent into small (< 41 bytes) packets



use link-level ARQs



perform hop-by-hop migration

(1,1) (2,1) (3,1) (4,1)

clone(4,1 )

16

Engineering Challenges (2 of 3)

• Low bandwidth communication



Remote tuplespace operations do not utilize hop-by- hop acknowledgements



Minimize overhead

(1,1) (2,1) (3,1) (4,1)

rrdp(…)

17

Engineering Challenge (3 of 3)

• Limited memory (MICA2 motes have 4KB RAM)
• Delicate memory allocation:



Agent code: 264 bytes



Tuple Space: 100 bytes



Tuple: 25 bytes max



Reaction Manager: 10 reactions, 360 bytes



Neighbor list: 8 neighbors, 32 bytes



Agent op stack: 150 bytes



Max number of agents per node: 3

• Memory usage:



3.5KB RAM



54.7KB ROM

18

SLIDE 4

4

Compact Code: An Example (1 of 2)

• 1. Registers a reaction sensitive to fire alert tuples
• 2. Clones itself onto a node that detects fire

1 BEGIN pushn fir 2 pusht LOCATION 3 pushc 2 // push template onto stack 4 pushc FIRE // push callback address 5 regrxn // register reaction 6 wait // wait for reaction to fire 7 FIRE pop 8 sclone // clone to node detecting fire … // fire tracking code

The fire tracking agent:

19

Compact Code: An Example (2 of 2)

BEGIN pushc TEMPERATURE sense // sense the temperature pushc 1 // indicate 1 field in tuple pushloc 1 1 // push location (1,1) onto stack rout // remote out pushc 1 sleep // sleep for 1/8 second rjump BEGIN // jump back to BEGIN BEGIN pusht READING // push type=reading pushc 1 // indicate 1 field in tuple in // blocking in operation pushloc uart_x uart_y // push UART address onto stack rout // remote out rjump BEGIN // jump back to BEGIN

Agent @ (1,1): Block for reading tuple & forward it to laptop, loop Agent @ (x,y): Take a reading & send result to base station, loop

20

Alternative Agent Using Reactions

BEGIN pusht READING // push type=reading pushc 1 // indicate 1 field in tuple pushc FIRE // push address of FIRE_RXN regrxn // register a reaction … // do other tasks FIRE pushloc uart_x uart_y // push UART address onto stack rout // remote out jumps // jump back to orig. location

Agent @ (1,1): Register reaction for reading tuples & forwards them to the laptop

21

Agilla 1.x Test Bed

• 6x9 Mica2 Mote 


Test Bed

• Multi-hop Grid
• One base station

Base Station

22

Performance Evaluation:

migration vs. remote tuple space access

Migration instructions are more reliable because of hop-by-hop acknowledgements… …but remote tuplespace operations have less overhead

23

Agilla Instruction Execution Times

Local Operations Remote Operations

24

SLIDE 5

5

Comparison with Alternate Systems

• What are the alternative systems?



Maté



Deluge

25

Difficulty to Compare Agilla

• Agilla is not intended to be used as a code-

propagator

• Alternative systems only epidemically propagates

code

• Agilla propagates agents at application level

application level with slight optimization



Use tuples to prevent duplicate agents

26

Experimental Setup

• Washington University Wireless Sensor Network

Testbed



31 TelosB nodes, 5th floor of Jolley Hall

27

Comparison Results

28

More Application Experiences

• Fire Detection & Tracking



Presented at MURI 3-Year Review and IPSN 2005

• Efficient Network Exploration



In collaboration with UCI



Presented at MURI 3-Year Review

• Intruder Detection and Tracking



Yuling Liang’s CS 521S Class Project

• Cargo Tracking



In collaboration with

• Robot Navigation Around Fires



In collaboration with the Media Machines Lab

29

Fire Detection and Tracking

30

SLIDE 6

6

The Static Fire Agent

31

The Fire Detector Agent

32

The Fire Tracker Agent

• Entire agent is 58 lines of code

33

Static Fire Mapping

• Fire doesn’t move, how fast do tracker agents

form perimeter?

34

Results of Static Fire Mapping

35

Dynamic Fire Tracking

Video available at: http://mobilab.wustl.edu/projects/agilla

36

SLIDE 7

7

Results of Dynamic Fire Tracker

• Slow: Fire clones every 7 seconds
• Fast: Fire clones every 5 seconds

37

Efficient Network Exploration

• Goal: Explore the whole network
• Off-line genetic algorithm

determines number of agents and tentative paths

• On-line route adaptation strategy.

Percent Network explored v. Time

38

Intruder Detection and Tracking

Base Station Tracker sends back a

• heartbeat. Base station

re-deploys tracker if heartbeat goes away.

39

Cargo Tracking

• 7 million containers arrive annually into the US



Impossible to check every container

• Existing container security devices are limited:
• Requires line-of-sight with satellite
• Low-bandwidth (six 9B msgs/day)
• $500/device, $34.95/mo

40

AgiTrack: Cargo Tracking using Agilla

base station base station

Internet

• Manifest
• Security Flags
• Find Cargo
• Load Manifest
• Find Intrusions

41

Dynamic Context Discovery & Multi- Hop Network Formation

Ship Dock

base station base station

PDA

42

SLIDE 8

8

Systematic Network Traversal

43

Robot Navigation

• Mobile agents guide robot safely around the fires

44

Robot Navigation Videos

Without sensor network data With sensor network data http://www.cse.wustl.edu/~bayazit/index.php?page=sensornet

45

System Challenges

• Multi-Hop Routing



No geographic routing implementation available for Mica2



Not enough memory on Mica2 motes for Agilla & routing

• Indoor localization



Cricket motes use different radio packet formats and have insufficient memory to run Agilla



Merge Cricket & Mica2 platforms

• Unreliable wireless network



Use ARQs



Carefully plan agent migration
 st

46

Open Issues

• Direct inter-agent communication
• Agent group communication
• In-network agent morphing
• Spatiotemporal primitives & real-time guarantees
• Higher-level agent programming language

47

Conclusions

• Mobile agent middleware simplifies application

deployment & increases network flexibility

• Empirical results show that deploying sensor

network applications via mobile agents is reliable and efficient

• There are many applications for mobile agents in

wireless sensor networks



Fire detection



Intruder detection



Cargo tracking



Robot navigation

48

SLIDE 9

9

Agilla URL: http://mobilab.wustl.edu/projects/agilla

• Source Code
• Documentation
• Tutorials
• Experience Reports

Thank you!

49

Agilla 3.0 & Agimone

• Supports multiple base stations
• Allows nodes to move (physical mobility)
• Integrates wireless sensor networks with IP

networks

Agilla Network Agilla Network Agilla Tuple Space Limone Tuple Space Limone Network (IP) Limone Service Registry Limone tuple encapsulates Agilla agent

50

A Bouncing Agent

51

End-to-End Latency of Agimone

52

Impact of Agent Size on End-to-End Latency

53

Flexible Service-Oriented Programming for Heterogeneous Sensor Networks

Chien-Liang Fok Advisors: Gruia-Catalin Roman and Chenyang Lu http://www.cse.wustl.edu/wsn Mobile Computing Laboratory Wireless Sensor Network Research Group Department of Computer Science and Engineering

SLIDE 10

10

Many Real-World Deployments

• Habitat Monitoring
• Structural Health Monitoring
• Industrial Equipment Monitoring

Golden Gate Bridge

(source: Culler’s MobiHoc’05 Keynote)

Great Duck Island

(source: IEEE Spectrum)

Intel Fabrication Plant

(source: Krishnamurthy’s SenSys’05 Paper)

55

But…

• Built on “simple” sensor networks

 Single application  Homogeneous  Static configurations

(source: Culler’s MobiHoc’05 Keynote)

Macroscope in the Woods

56

Integrated Sensing Systems

• Complex sensing systems are emerging



Shared



Heterogeneous



Dynamic


• Examples:



Building automation



Assisted living



Smart City

Streetline’s parking meter network

57

Key Challenge

• Network heterogeneity



Processing power



Sensing capability

16-bit 8MHz CPU, 10KB RAM 32-bit 416MHz CPU, 32MB RAM light, temp, accel, mag, sound GPS, bar. pressure, humidity

58

Servilla

• A framework for programming heterogeneous

wireless sensor networks




Efficiency: in-network processing



Flexibility: asymmetric middleware configuration



Simplicity: Application platform-independence

59

Approach

• Platform-independent applications
• Platform-specific services

Building Automation Occupancy Sensor Structural Health Monitoring Door/Window Sensor Vibration Sensor HVAC Actuators DSP Energy Meter Assisted Living Security dynamic binding

60

SLIDE 11

11

Service-Oriented Computing

• Programmatic description of functionality



WSDL, CORBA / Java IDL



SOAP, XML-RPC, Java RMI


• Mapping service users to providers



UDDI, CORBA ORB, 
 Workflow Management System

• Heavyweight, inefficient

What is the temperature? I provide a temperature sensor

Invoke

61

Related Work: Tiny Web Service

• Web services API for accessing sensor network

resources

• Each node has an HTTP server
• Numerous efficiency tweaks

Priyantha et. al., Microsoft Research, SenSys’08

No in-network processing!

62

• Two levels:



Application Tasks



Platform Services


• Both reside inside the


network


• Tasks bind to and


invoke services



Local



Remote

Servilla Programming Model

63

Servilla Task

• Implements application behavior
• Platform-independent



Flexible



Executes inside a WSN network

• High-level
• Consists of code, state, and 


service specifications

64

Servilla Services

• Platform-specific
• Implemented natively



Efficient

• Dynamically bound to scripts



Accessible both locally and remotely

65

ServillaSpec

• Programmatic description of functionality



Interface: Exact match  accuracy



Attributes: Pattern matching  Flexibility

• Could use Tiny Web Service’s WSDL syntax

Interface Attributes

66

SLIDE 12

12

ServillaScript

• Ease of programming



High-level

• Error conditions handled by the task



Future work: automated re-binding

• Blocking invoke

invoke



Simplify code

67

Modular Middleware Architecture

• Asymmetric middleware

32-bit 416MHz CPU, 32MB RAM

Servilla

Virtual Machine Service Provisioning Framework Consumer Provider

Servilla

Virtual Machine

16-bit 8MHz CPU, 10KB RAM

Servilla

Service Provisioning Framework Provider

Servilla

Virtual Machine Service Provisioning Framework Consumer

32-bit 48MHz CPU, 64KB RAM

68

Implementation

• On top of TinyOS 1.x
• Uses Agilla virtual

machine


• Tested on Imote2 and

TelosB platforms

Servilla Implementation Architecture

69

Memory Footprint on TelosB

• VM-Only is 46KB, SPF-Consumer needs >5KB more
• Modular middleware architecture is necessary

TelosB Limit (48KB)

70

Microbenchmarks – Spec Size

Servilla Tiny Web Services

71

Microbenchmarks – Latency (1 of 2)

72

SLIDE 13

13

Microbenchmarks – Latency (2 of 2)

• Servilla:
• TWS:

73

Application Case Study

• Structural Health Monitoring



Damage Localization (DLAC)

• Heterogeneous sensor network



Imote2



TelosB

Platform Platform Energy Draw Energy Draw Imote2 333mW TelosB 65mW

74

Servilla Implementation

• Imote2



Entire Servilla framework



Provides service DLAC and AccelTrigger (145mW)


• TelosB



SPF-Provider only



Provides service AccelTrigger (9mW)

75

Application Script

• Runs on high-power

node


• Exploits low-power

node to save energy

• Application runs

inside the network

76

Power Savings Results

• % Power savings of heterogeneous vs

homogeneous network

• Toggles rate of service


invocation and
 sensing frequency

77

Conclusions

• Service-oriented computing (SOC) can address

WSN heterogeneity while still enabling in-network processing

• A modular middleware architecture allows greater

adaptability to a wide range of resources

• Application case study demonstrates how

exploiting heterogeneity can save power

78