1. Ultra-Low-Power Sensor Nodes Featuring a Virtual Runtime Environment
Emanuele Lattanzi and Alessandro Bogliolo
DiSBeF – University of Urbino
NeuNet

2. Agenda Introduction HW-SW platform Power states
DPM issues and solutions
Experimental results

3. Introduction Need for energy efficient wireless sensor nodes
Lifetime maximization
Compatibility with energy harvesters
Attractiveness of runtime virtual environment
Development
Deployment
Re-use/Re-programming
Availability of ultra-low-power micro controller units (MCUs) featuring
16-bit RISC architectures clocked at tens of MHz
16kbytes of main memory
64kbytes of flash memory
Voltage-frequency scaling
Low-power modes with sum ms wake-up time

4. Objective Ultra-low power sensor node
Java-compatible virtual run-time environment
Full exploitation of low-power modes
Off-the-shelf low-cost components
Open-hardware PCB
Open-source software stack

5. Agenda Introduction HW-SW platform Power states
DPM issues and solutions
Experimental results

6. HW platform TI MSP430F54xxa MCU 16-bit RISC 8.9mA @ 25MHz 6 LP modesuA
5us wake-up

7. HW platform
VirtualSense provides a new Pareto-optimal point in the power-performance design space of wireless sensor modules

8. SW stack Contiki OS
Operating-source real-time OS for sensor networks and networked embedded systems
Portability
Multi-tasking
Memory efficiency
Event-driven organization
Elementary DPM which exploits the stand-by state of the MCU and wakes it up every 10ms

9. SW stack Darjeeling VM Open-source VM for extremely limited devices
Java compatibility
Limited requirements (10kbytes of RAM)
Bytecode efficiency (infuser)
Runs as a single process
Supports multi-threading
Preemptive round-robin scheduling

10. Agenda Introduction HW-SW platform Power states
DPM issues and solutions
Experimental results

11. Power modes         Active mode Standby mode Sleep mode
CPU
Clock
Memory 
Active mode
1-10mW
Reboot at external interrupt [1-100ms]
External interrupt [<1ms]
Self wake up [1-10us]
Standby mode  
1-100uW
Sleep mode  
1uW
Hibernation mode   
100nW

12. SW-stack dimension Active Standby Sleep Hibernation OS boot VM boot
Int
hand OS
sch VM
sch
Vtask
Vtask
Standby
Sleep
Hibernation

13. Wake-up transitions Active Standby Sleep Hibernation OS boot VM boot
Int
hand OS
sch VM
sch
Vtask
Standby
Sleep
Hibernation

14. Voltage and frequency scaling
The PMM can provide four different levels of VCORE and it can be programmed in order to select the lowest supply voltage compatible with the speed of the CPU. 

15. Voltage and frequency scaling

16. Agenda Introduction HW-SW platform Power states
DPM issues and solutions
Experimental results

17. Standby mode ContikiOS schedules a self-wakeup every 10ms
Int
hand OS
sch VM
sch
Vtask
ContikiOS schedules
a self-wakeup
every 10ms
There are 3 cases:
The VM has no tasks to resume a
The OS has no processes to resume b
The VM has a task to resume
Actual wake up

18. Standby mode abstract state diagram
Vtask
Active
1-10mW
Exploitation issues: c
The self-loop longer than 10ms
No power saving a
1-10mW
Standby b
Not supported by the SW
stack (VM always active)
1-100uW
Not supported by Contiki OS
Lack of timing info
1-10uW
Stanby mode is not compatible with the SW stack!

19. Standby mode improvements
Modified Contiki OS to make it able to dynamically adjust the INTERVAL of timer interrupts
Modified Darjeeling VM scheduler to make it able to set the OS timer and suspends the VM PROCESS_WAIT_EVENT_UNTIL()
Implemented a timed standby mode with just-in-time predictive wake-up
Mounted an external low-power (0.3uW) real-time clock (RTC) to preserve timing accuracy

20. Standby mode modified state diagram
Vtask
6.6mW
4.5uW uJ/T
Standby.a(T)
Families of
low-power states
depending on T
Standby.b(T)
4.5uW uJ/T
4.5uW + 0.3uW
Standby.t
4.5uW
Standby

21. Sleep mode issues Unable to issue self-events
Wakup can only be triggered by external interrupts
Cannot be exploited is there are processes/tasks that need to resume at a given time (e.g., periodic monitoring tasks typical of many WSN applications)
Lack of timing information
No information about the time elapsed since shut down
No time stamps associated with external interrupts
Sleep mode can ony be exploited in case of time-independent reactive applications

22. Sleep mode improvements
Implemented a timed sleep mode with just in time predictive wakeup based on the external RTC
Used the external RTC to provide relative and absolute timing information at wake up
1.5uW + 0.3uW
Sleep.t
1.5uW
Sleep

23. Hibernation mode issues
Unable to issue self-events
As for Sleep mode
Lack of timing information
Lack of data retention
Requires a complete reboot
Impossible to resume a process/task
Hibernation mode can ony be exploited in case of memor-less reactive applications

24. Hibernation mode improvements
Used the external RTC as for the Sleep mode
Implemented a native method in the main of the VM to save and restore the heap of the VM in falsh memory
1.5uW + 0.3uW
Hibernation.t
1.5uW
Hibernation

25. Agenda Introduction HW-SW platform Power states
DPM issues and solutions
Experimental results

26. Characterization results
Data refer to a MSP430F5418a MCU powered at 3V and clocked at 16MHz

27. Experimental results
Average power consumption of the MCU used to execute a periodic monitoring task which keeps the CPU busy for 1s

28. Conclusions Ultra-low-power sensor node
Java-compatible virtual runtime environment
Power consumption ranging from 6.6mW to 0.1uW (in Hibernation)
Capable of reacting to external events and resume execution from any low-power state
All low-power modes directly exploitable from the Java runtime environment
Open-HW / Open-SW approach

29. Future directions Hardware filtering of non-Intended frame
Multitasking support
Ultrasound remote wake-up
On-board ultrasound localization

30. Frame filtering
Filtered
CCA
Non-inteded
Intended

31. Frame filtering

32. Multitasking support
The application manager receives applications to be installed or upgraded through the network and stores its on the applications memory.

33. Multitasking support
Task manager is responsible for loading, starting, stopping, and unloading into the VirtualSense VM the installed applications.

34. Multitasking support
The VirtualSense network dispatcher is responsible for managing communication between concurrent tasks and the low-level system network.