System Architecture for Sensor Networks Jason Hill and David Culler

1. System Architecture for Sensor Networks Jason Hill and David Culler

2. Different platforms need different solutions Highly constrained (memory, cpu, storage, power) Solutions: TinyOS,… StarGate Capabilities MK - II Ample resources Solutions: Linux, uCos Emstar… MICA Mote Spec Size, Power Consumption, Cost

3. Technology push towards miniaturization • CMOS miniaturization • 1 M trans/$ => tiny (~mm2), inexpensive processing and storage • 1-10 mW active, 1 mW passive (at 1% use 100 mW ave) • Micro-sensors (MEMS, Materials, Circuits) • acceleration, vibration, gyroscope, tilt, magnetic, heat, motion, pressure, temp, light, moisture, humidity, barometric • chemical (CO, CO2, radon), biological, microradar, ... • actuators too (mirrors, motors, smart surfaces, micro-robots) • Communication • short range, low bit-rate, CMOS radios (1-10 mW) • Power • batteries remain primary storage (1,000 mW*s/mm3), fuel cells 10x • solar (10 mW/cm2, 0.1 mW indoors), vibration (~uW/gm), flow • 1 cm3 battery => 1 year at 10 msgs/sec

4. Goal: Build low-end sensor node COTS prototype for mm3 device SENSING SUB-SYSTEM PROCESSING SUB-SYSTEM COMMUNICATION SUB-SYSTEM ACTUATION SUB-SYSTEM POWER MGMT. SUB-SYSTEM • Small physical size: 1 mm3 • Low Power Consumption: < 50 mW

5. Communication Sub-System • Functions • Transmit – Receive data packets wirelessly • Co-ordinate/Network with other nodes • Implementation • Radio • Modulation – Demodulation • Two types of radios: RFM, ChipCon CC1000 • RFM: Mica & predecessors • CC1000: Mica2 onwards

6. Wireless Comm. Basics • RFM Radio– Simple radio, only modulates-demodulates bits • CC1000 Radio– Performs Manchester coding-decoding and synchronization also

7. Radio Power Management • Radio has very high power consumption • Tx power is range dependant - 49.5 mW (0 dBm) • Rx power is also very high - 28.8 mW • Power-down sleep mode - 0.6 uW • Above data for CC1000, 868 MHz (Check out CC1000 data-sheets for more numbers) • Radio power management critical • Idle state channel monitoring power = Rx Power • Put radio to sleep when not in use • But then, how do we know when somebody is trying to contact us ?

8. Typical sensor network operation • Sensing Subsystem • Keep the very low power sensors on all the time on each node in the network • Processing subsystem • Low-power sensors interrupt (trigger) processor when “events” are identified OR • Processor wakes up periodically on clock interrupt, takes a sample from sensor, processes it, and goes back to sleep. • Radio subsystem • Processor wakes up radio when event requires collaborative processing or multi-hop routing. • Tiered architectures of above subsystems can be envisaged in other platforms

9. Traditional Systems • Well established layers of abstractions • Strict boundaries • Ample resources • Independent apps at endpoints communicate pt-pt through routers • Well attended Application Application User System Network Stack Transport Threads Network Address Space Data Link Files Physical Layer Drivers Routers

10. by comparison ... • Highly Constrained resources • processing, storage, bandwidth, power • Applications spread over many small nodes • self-organizing Collectives • highly integrated with changing environment and network • communication is fundamental • Concurrency intensive in bursts • streams of sensor data and network traffic • Robust • inaccessible, critical operation

11. sensors actuators storage network Characteristics of Network Sensors • Small physical size and low power consumption • Concurrency-intensive operation • multiple flows, not wait-command-respond => never poll, never block • Limited Physical Parallelism and Controller Hierarchy • primitive direct-to-device interface • Asynchronous and synchronous devices => interleaving flows, events, energy management • Diversity in Design and Usage • application specific, not general purpose • huge device variation => efficient modularity => migration across HW/SW boundary • Robust Operation • numerous, unattended, critical => narrow interfaces

12. Design Goals of TinyOS • Concurrency-Intensive Operations • flow information from place to place on-the-fly • Example: simultaneously capture data from sensors, processing the data, then send out to the network • Robust Operations • Cross devices redundancy prohibitive • Individual reliable devices desired • Application tolerant individual device failures

13. Design Goals of TinyOS (cont.) • Limited Physical Parallelism and Controller Hierarchy • Less independent controllers • Less processor-memory-switch level • Sensor and Actuator directly interact with the single-chip micro controller • Diversity in Design and Usage • Sensor network application specific design • But wide range potential applications • deep modularity of software needed

14. application = scheduler + graph of components • event-driven architecture • single shared stack • NO kernel, process/memory management, virtual memory TinyOS

15. msg_rec(type, data) msg_send_done) Tiny OS Concepts • Scheduler + Graph of Components • constrained two-level scheduling model: threads + events • Component: • Commands, • Event Handlers • Frame (storage) • Tasks (concurrency) • Constrained Storage Model • frame per component, shared stack, no heap • Very lean multithreading • Efficient Layering Events Commands send_msg(addr, type, data) power(mode) init Messaging Component internal thread Internal State TX_packet(buf) Power(mode) init RX_packet_done (buffer) TX_packet_done (success)

16. Radio Packet packet Radio byte byte RFM bit TOS Execution Model data processing application comp • commands request action • ack/nack at every boundary • call cmd or post task • events notify occurrence • HW intrpt at lowest level • may signal events • call cmds • post tasks • Tasks provide logical concurrency • preempted by events • Migration of HW/SW boundary message-event driven active message event-driven packet-pump crc event-driven byte-pump encode/decode event-driven bit-pump

17. Evaluation • meet power constraints?

18. Battery Lifetime for sensor reporting every minute DutyCycle Estimated Battery Life Full Time Listening 100% 3 Days Full Time Low Power Listening 100% 6.54 Days Periodic Multi-Hop Listening 10% 65 Days No Listening 0.01% Years Evaluation • meet power save?

19. Component Frame Tasks Commands Events • Commands and Events are function calls • Application: linking/glueing interfaces (events, commands) Components • A component has: • Frame (internal state) • Tasks (computation) • Interface (events, commands) • Frame : • one per component • statically allocated • fixed size

20. Commands/Events • commands: • deposit request parameters into the frame • are non-blocking • need to return status => postpone time consuming work by posting a task • can call lower level commands • events: • can call commands, signal events, post tasks, can not be signaled by commands • preempt tasks, not vice-versa • interrupt trigger the lowest level events • deposit the information into the frame

21. main { … while(1) { while(more_tasks) schedule_task; sleep; } } Tasks Preempt POST FIFO events commands commands Interrupts Time Hardware Scheduler • two level scheduling: events and tasks • scheduler is simple FIFO • a task can not preempt another task • events preempt tasks (higher priority)

22. Tasks • FIFO scheduling • non-preemptable by other task, preemtable by events • perform computationally intensive work • handling of multiple data flows: • a sequence of non-blocking command/event through the component graph • post task for computational intensive work • preempt the running task, to handle new data

23. Questions ???