Save Our Sensors: Architecture Consideration for Reconfigurable Wireless Sensor Network

1
Save Our Sensors Architecture Consideration for
Reconfigurable Wireless Sensor Network

• Chih-Chieh Han
• Ramkumar Rengaswamy
• Roy Shea

2
24/7 Uninterrupted Sensing

• Traditional hardware solutions extending network
  lifetime
• Design time Low power sensors
• Deploy time High redundant sensor deployments
• Run time ???
• Traditional Software solutions reliability and
  adaptability
• Design time large scale simulation small scale
  deployment
• Run time ???

3
Reconfigurable Wireless Sensor Network

• Benefits
• Reconfigurability extends system lifetime.
• Reconfigurability helps reliability.
• Reconfigurability provides adaptability.
• Goals Sustainability
• Sustain through sensor nodes replacement/addition
• Sustain through software failures

4
Network reprogramming

• Wirelessly Change system behavior after
  deployment.
• Bug fix, environment adaptation, on demand
  tasking, etc.
• Existing approaches
• Mate virtual machine
• Pros portable, reliable.
• Cons inefficient low level operations.
• and operation is 33.5 times slower than native
  instruction.
• Remote code patching
• Pros efficient system image
• Cons state destruction after patching
• Cons does not address the reliability of the
  image.
• E.g. software logic bug, protocol deadlock.
• Cons cannot change protocol stack

5
SOS approach

• An insmod like interface to insert binary
  module into running kernel.
• Running low level operations in processors
  speed.
• Preserve existing operating system states.
• Modules are treated as unreliable code.
• Fault tolerant system.

6
Challenges and Approaches

• Challenges
• Highly energy and memory constrained system.
• Need to minimize number of byte transmitted.
• Need to minimize the use of run-time memory.
• Low processing power
• Need to minimize the complexity of algorithm
  used.
• Reliability
• Module insertion should have minimal impact on
  existing system.
• Possible approaches that dont work
• Linuxs insmod parse ELF file to link and load
  the file.
• But complex, memory hungry
• 4857 vs 426 bytes for one of modules.
• TinyOS and Emstar
• Static component binding at compile time.
• Globally reserved memory for each component.
• Replacing one component will affect others.

7
Our solution SOS

• Create a new OS that dynamically binds functions
  during run-time.
• Essentially a message passing system.
• Simultaneously,
• Minimize the meta data in the module.
• Minimize run-time memory requirement for
  insmod.
• Minimal complexity for insmod on the mote.
• No impact on other modules during insertion.

8
Communication Architecture
Inter-module communication
System communication
9
Reliability

• Watch dog is always on with resetting before
  entering the module.
• Prevent modules holding CPU for too long.
• Dynamic memory with bound checking.
• Monitor critical system status before and after
  messages to module.
• Interrupt status.
• System removes misbehaving module after reset
• E.g. watch dog timeout, system crash.

10
Performance Measurement

• Crossbow MICA2 running at 7.3728 MHz
• 4KB RAM, 128 KB Flash
• Compare message passing against native function
  calls.
• Define local(n) function dispatch time for n
  local arguments.
• Define pointer(n) function dispatch time for n
  arguments in the structure.
• Local(3) foo(a, b, c)
• Pointer(3) foo(s-a, s-b, s-c)

11
Function Dispatch Delay (us)
12
Dispatch Overhead in clock cycles
13
Module Insertion (PC side)

• Kernel exposes well-known addresses for all
  system calls.
• Module is compiled with stub.
• During module link time, module section is
  extracted.
• Extract machine binary out of ELF file.
• Add in module id and the size of memory state.
• Finally, use sos_insmod to insert new module!
• And all of above can be done just by make mica2
  install!

14
Moduled (at MICA2 side)

• Perform very simple parsing for module insertion.
• Use bit map to record flash usage and maintain
  module location for rmmod (not yet
  implemented).

15
Evaluation

• Minimal number of bits transmitted.
• Essentially the machine code size 4 bytes.
• Minimal memory size requirement.
• Essentially bit map (60 bytes) 4 bytes per
  module.
• Minimal insmod complexity.
• Moduled code size 1214 bytes
• No impact on existing modules.