Embedded Systems and Sensor Networks

1. Embedded Systems and Sensor Networks Pete Broadwell <pbwell@cs.berkeley.edu> Joe Polastre <polastre@cs.berkeley.edu>

2. Introduction Network-enabled embedded systems currently are approaching widespread use. We make a case for the “access network” approach to converging such networks with larger networks, and present wireless sensor networks as a case study.

3. Talk Outline • Introduction to embedded systems • Design considerations • Networking options • Strategies for network convergence • Access networks • Service discovery • Sensor networks: a case study • Operating environment • Networking implementation • Supported applications

4. Embedded Systems Pete Broadwell <pbwell@cs.berkeley.edu>

5. Tiny Webserver What is an embedded system? • Hardware and software components • Part of a larger system • Operates without human intervention • Example: • Single-board microcomputer • Software stored in ROM • Runs special-purpose app until turned off

6. Types of embedded systems • Sensors* • Collect data • Passive interaction with environment • Actuators* • Control machines • May introduce changes into environment • Beacons* • No sensing or actuation • Can alert other sensors to changes in environment * All can benefit from being networked!

7. Embedded devices: Traditional electronics: temperature sensor +5V controlling ROM comparator thermistor comm. bus interface +5V speaker environment monitor comm. bus Why the interest in embedded systems? • Embedded systems are becoming ubiquitous • Moore’s Law: more computing power in smaller devices • Example: laboratory temperature alarm

8. Why network them? • Some embedded systems have no use for network connectivity • Example: my car’s ABS (or do they?) • Others benefit from network access • Example: refrigerator orders milk when it’s low • It’s easy: ubiquitous large network access • Infrared • Wireless • Cable, telephone, power lines…

9. Motivations for networked embedded systems Remote actuation “Smart spaces” Access to sensor network data (more later) Stanford iRoom Remote surgery

10. Embedded systems design issues • Power consumption • OS/programming API • Real-time? Event-driven? • Communication • Medium? Protocol? • Localization • Monitoring • Security

11. Communications decisions • Messaging format choices: • Active messages (asynchronous • RPC (synchronous) • Proprietary • Network setup choices: • Ad-hoc or static • TCP/IP compatibility • Internet connectivity • Medium choices: • Infrared • Wireless • Fiber • Protocol choices: • IrDA • Bluetooth • Ultra Wideband (eventually) • PicoNet

12. OS/Programming model • Example: Windows XP Embedded • Componentized version of consumer OS • Device-specific “enabling features” • Embedded Linux is similar XP Embedded configuration screen

13. Computation in the network • Embedded systems push functionality into the network • Leaving data processing/decision making to supervisor is slow and wasteful • One solution: Active Messages • Facilitate asynchronous intra-network computation • May support distributed queries of sensors (treating sensor networks as a DB)

14. Relation to network convergence • Embedded systems employ an extremely diverse range of programming models and communication methods. • Common thread: connectivity exists among hosts, as well as between hosts and a central supervisor entity with greater computing resources.

15. A case for the Access Network approach to convergence Treat networks of embedded systems as “access networks” Internet

16. Unresolved issue: service discovery • How do hosts on a large network discover services offered by networked embedded systems? • Service discovery protocols • Sun’s Jini • Microsoft’s UPnP • Salutation • Bluetooth* • PicoNet* • IrDA* * Per-connection only

17. Nosy Dan’s eavesdropping device 1. “Register service: Mote 1 listening in Room 1” 6. “Establish connection With Mote 1” 3. “Request service: Listening in Room 1” Nosy Dan’s competitor Nosy Dan 4. “Lookup service: Listening in Room 1” 5. “Reply: Mote 1 Listening in Room 1” 2. “Register service: Mote 1 listening in Room 1” Service Discovery Protocols: Electronic eavesdropping example • An Internet-scale solution to this problem has yet to be developed. Base Station Base Station Mote 1 Room 1 Room 2 LAN Lookup server

18. Sensor Networks Joe Polastre <polastre@cs.berkeley.edu>

19. Planetary Services • PDAs / HPCs/ smartphones • Microscopic sensor/embedded networks Emerging Extremes and Convergence • Open Internet Services • Internet Services • Servers • Workstations • Personal Computers From David Culler’s Invited Lecture at USC, February 28, 2001

20. Sensor Networks Concurrency intensive data streams and real-time events, not command-response Huge variation in load population usage & physical stimuli robustness Hands-off (no UI) Dynamic configuration, discovery Self-organized and reactive control Converged Network Concurrency intensive provides real time services via different network mechanisms Different elements of the converged network have varied loads May or may not have UI Network is adaptive service discovery major part of huge, all-encompassing network Network Convergence • Complimentary roles • tiny semi-autonomous devices empowered by infrastructure • infrastructure services connected to the real world

21. TX Drivers 0-100kbps CCR or diode Power Power input ambient light sensor Photodiode TinyOS/Mica Platform – Berkeley (Culler) SmartDust – Berkeley (Pister) WINS NG 2.0 – Sensoria 2001 Oscillator ADC Optical Receiver 13 state FSM controller Sensor input 330µm 1mm Sensor Networks • Existing Research Platforms

22. Sensor IntegrationThe TinyOS Platform Application Model Environment monitoring DB IP Traditional network SerialForwarder RF Remote control console for motes IP SerialForwarder SerialForwarder Inventory tracking IP

23. Services… What about Sensors? • Variety of sensors & actuators available • All-in-one sensor board includes light, temperature, microphone, sounder, accelerometer, and magnetometer • Environmental monitoring sensor board includes light, calibrated temperature, thermopile, humidity, barometric pressure • Remote control sensor board includes external pin connections to control physical devices including RC vehicles

24. Multi-Network Data Acquisition--- Demo --- • Two motes are sensing light and reporting the results back to a base station • Base station allows IP clients to connect and read sensor data or control motes from anywhere on Internet

25. Robust CommunicationGeographic Routing: QoS multi-hop data acquisition • GeoCast (Navas and Imielinski 1996) • Architecture for addressing and routing in wide are networks • GeoMote (Pete, Joe, Rachel 2001) • Sensor network implementation of GeoCast: lower power, adhoc • Primary Services: • Geographic Multicast • Nearest Neighbor Service Discovery • Geographic Network Reprogramming and Reconfiguration • Low Power Pursuer/Evader Games

26. Geographic Routing Architecture Client Process Event Router Gateway Host Direct Message Event Client Process

27. Low-Power Pursuer Evader Evader

28. Geographic (sensor) Routers may never talk to Hosts and vice versa Gateways are entry/exit points but have no routing info Broadcast medium dependant on distance from source Internet Functions of the gateway and router are typically merged Gateways perform routing functions and are entry/exit points Broadcast medium dependant on physical network Geographic vs. Internet Architecture

29. Directed Diffusion • Data-Centric • Register “interests” in the network • < Attribute, Value > pairs • Nodes diffuse the interest towards producers via a sequence of local interactions • Gradients determine path of data • Achieve efficient distribution of data through reinforcement and negative reinforcement

30. Sending data Source Sink Reinforcing stable path Source Source Sink Sink Recovering from node failure Illustrating Directed Diffusion Setting up gradients Source Sink Illustration courtesy of Deborah Estrin, UCLA

31. Distributed Algorithms • Completely new area to investigate robust distributed algorithms on sensor networks • Example:New Distributed Algorithm for Connected Dominating Sets in Wireless Ad-Hoc Networks ---Alzoubi et. al. • Connected Dominating Set Typically Used as a backbone for wireless networks—useful to compose the backbone dynamically

32. 0 1 1 INVITE JOIN INVITE JOIN 2 2 2 2 3 3 3 3 4 4 Connected Dominating Set 1) Set the rank of each node 2) Lowest Rank Among Neighbors Start Dominator DOMINATOR INVITE JOIN 3) If all lower rankingneighbors domineethen you are dominator DOMINEE DOMINEE 4) Invite black nodesto participate indominating tree DOMINATOR DOMINATOR DOMINEE This is all occurring over RF broadcasts!

33. Sensor Network as a Database Two Projects: • Intel Research w/ UC Berkeley: TAG • Tiny Aggregate Queries in Ad-hoc Sensor Networks • Sam Madden, Wei Hong, Joe Hellerstein, Mike Franklin, David Culler • Cornell University: Cougar • Towards Sensor Database Systems • Querying the Physical World • Philippe Bonnet, Johannes Gehrke, Praveen Seshdri

34. Database Single Physical Device Static data Centralized Failure is not an option Plentiful resources Administrated Sensor Network Numerous Devices Streaming data Large number of nodes Multi-hop network No global knowledge about the network Frequent node failure Energy is the scarce Resource, limited memory Autonomous Databases vs. Sensor Networks Want “to combine and aggregate data streaming from sensors.” Sounds like a database…

35. Fjords Use Fjords to handle lack of reliabilty and streaming push data • Allows arbitrary combinations of push/pull amongst devices • Operators assume non-blocking queue interface between each other. • Queues implement push vs. pull • Pull from A to B : Suspend A, schedule B until it produces data. A cannot go forward until B produces data. • Push from B to A : A polls, scheduler thread invokes B until it produces data. A can process other inputs while waiting for B. • Supports parallelism between operators

36.   Fjording the StreamQuerying Streaming Sensor Data Push  Pull

37. Social Networks / Active Badges • Sensor networks can record social interactions by detecting proximity • Not just a convergence of sensors and Internet, but other “networks” too! • First attempt to monitor social network at UCB NEST Retreat, January 2002 • UCLA: iBadge Prototype • Investigate behavior of children in a Kindergarten

38. Wagner Culler Social Network Visualization

39. Social Network Results

40. ConclusionsandFuture Directions

41. Future Directions • Everyone disagrees over whether sensors should directly communicate via IP • Sensors: Routing is data-centric and energy-aware • Internet: Routing is bandwidth and latency-centric • If so, we need IPv6 NOW! • Do sensors need TCP/IP overhead since the transport medium is unreliable? • Networked Sensors may choose to elect some nodes to participate in networking and others to acquire data • Partitions the network into two sets, end-hosts and infrastructure, like current Internet

42. Conclusions • Research opportunities in sensor networks is infinite (or nearly infinite) • Algorithms • Network Architecture / Routing • Data Acquisition / Aggregation • Network Convergence of Devices • Computing will continue to move within the network • Sensors and Embedded Systems will enabled ubiquitous computing efforts • Connecting Embedded Devices to Traditional Networks can be very powerful: • Environmental Monitoring • Autonomous Actuation (eg: “Smart” home)

43. References • See www.cs.berkeley.edu/~polastre/cs294-2002sp • Links to relevant papers and more information on Embedded and Sensor Networks

44. Embedded SystemsandSensor Networks