Operating Systems and Protocols for Wireless Sensor Networks

1
Operating Systems and Protocols for Wireless
Sensor Networks
2
Lecture 11, December 2, 2003

• Introduction
• TinyOS for WSNs
• Protocols for WSNs

3
What is a WSN?

• Subset of wireless networks composed of wireless
  sensor nodes
• Sensor nodes organize in networks to collaborate
  on a large sensing task

4
Sensor Node Hardware
1Kbps - 1Mbps, 3-100 Meters, Lossy Transmissions
128KB-1MB Limited Storage
Transceiver
Embedded Processor
Memory
8-bit, 10 MHz Slow Computations
Sensors
Battery
66 of Total Cost Requires Supervision
Limited Lifetime
5
Operating Systems in WSNs

• Managing the resources
• Providing an interface to user applications

6
Protocols in WSNs

• Coordinating many nodes (controls)
• Exchanging data/information (multi-hop)
• Goals energy-saving, reliability, security

7
Free Book Online

• http//www.nap.edu/books/0309075688/html/
• National Academies Press. Embedded, Everywhere A
  Research Agenda for Networked Systems of Embedded
  Computers (2001). Computer Science and
  Telecommunications Board.

8
Lecture 11, December 2, 2003

• Introduction
• TinyOS for WSNs
• Protocols for WSNs

9
What is TinyOS?

• http//webs.cs.berkeley.edu/tos/index.html
• TinyOS is a component-based runtime environment
  designed to provide support for deeply embedded
  systems which require concurrency intensive
  operations while constrained by minimal hardware
  resources.

10
Key Characteristics of WSNs

• Small physical size and low power consumption
• Limited Physical Parallelism and Controller
  Hierarchy
• Primitive direct-to-device interface
• Concurrency-intensive operation
• Flow-through, not wait-command-respond
• Must handle multiple inputs and outputs
  simultaneously
• Diverse in Design and Usage
• Application-specific, not general purpose
• Huge device variation
• efficient modularity
• migration across HW/SW boundary
• Largely Unattended Numerous
• Robust operation
• Narrow interfaces

11
Hardware Constraints

• Severe constraints in power, size, and cost,
  translated to
• Slow CPU
• Short-distance, low-bandwidth radio
• Small memory
• Limited hardware parallelisms
• CPU hit by many interrupts!
• Support sleep mode in hw components

12
MoteThe Hardware

• 4Mhz, 8bitMCU(ATMEL)
• 512 bytes RAM, 8K ROM
• 900Mhz Radio (RF Monolithics)
• 10-100 ft. range
• Temperature Sensor
• Light Sensor
• LED outputs
• Serial Port

13
Second Generation Mote

• Two Board Sandwich
• Main CPU board with Radio Communication
• Secondary Sensor Board
• Allows for expansion and customization
• Current sensors include Acceleration, Magnetic
  Field, Temperature, Pressure, Humidity, Light,
  and RF Signal Strength.
• Can control RF transmission strength Sense
  Reception Strength

14
Software Challenges

• Small memory footprint
• Efficient in power and computation
• Lack hardware parallelism - OS provides
  concurrency-intensive operation
• Real-time
• Robust
• Diversity in applications and design
• Efficient modularity
• Re-configurable hardware
• Software hardware co-design

15
How about a traditional embedded OS?

• Multi-threaded architecture
• Large number of threads gt large memory
• Context switch overhead
• I/O model
• Blocking I/O (stop and go) waste memory on
  blocked threads
• Polling (busy-wait) waste CPU cycles and power
• Protection between applications and kernel
• Overhead for crossing kernel/user boundary
  interrupt handling
• Pros
• Clean simple programming model
• Priority-based scheduling support
• Robust (protected kernel)

16
Example Existing embedded OS

• Thread 1 (high prio) runs
• read from socket 1
• block
• Thread 2 (medium priority) runs
• read from socket 2
• block
• Thread 3 (low priority) runs
• Thread 2 unblocked, preempt thread 3
• Thread 1 unblocked, preempt thread 2
• Threads 1,2,3 complete in order

3 TCBs, 6 context switches, 7 kernel/user switch
17
TinyOS Solutions

• Support concurrency event-driven architecture
• Modularity application scheduler graph of
  components
• Compiled into one executable
• Efficiency Get done quickly and sleep
• Event function calls
• Less context switch FIFO/non-preemptableschedulin
  g
• No kernel/application boundary

18
TinyOS The Software

• Provides a component based model abstracting
  hardware specifics from application programmer.
• Capable of maintaining high levels of
  concurrency.
• Allows multiple applications to be running.
• Services Provided Include
• RF messaging protocols.
• Periodic Timer Events.
• Asynchronous access to UART data transfers.
• Mechanism for Static, Persistent Storage.
• Can Swap Out system components to get necessary
  functionality.
• Complete applications fit in 4KB of ROM and 256B
  RAM.

19
TinyOS Internals

• Scheduler and Graph of Components
• constrained two-level scheduling model tasks
  events
• Component
• Frame (storage)
• Tasks (concurrency)
• Commands, and Handlers (events)
• Constrained Storage Model
• frame per component, shared stack, no heap
• Very lean multithreading
• Layering
• components issue commands to lower-level
  components
• event signal high-level events, or call
  lower-level commands
• Guarantees no cycles in call chain

20
A Complete Application
21
TinyOS Two-level Scheduling

• Tasks do computation
• Un-preemtable FIFO scheduling
• Bounded number of pending tasks
• Events handle interrupts
• Interrupts trigger lowest-level events
• Events can signal events, call commands, or post
  tasks
• Two priorities
• Event/command
• Tasks

22
How to handle multiple data flows?

• Data/interrupt are handled by
• Respond to it quicklyA sequence of non-blocking
  event/command (function calls) through the
  component graph
• e.g., get bit out of radio hw before it gets lost
• Post tasks for long computations
• e.g., encoding/decoding
• Assumption long computation are not emergent
• Preempting tasks to handle new data

23
How should network msg be handled?

• Socket/TCP/IP?
• Too much memory for buffering and threads
• Data are buffered in network stack until
  application threads read it
• Application threads blocked until data is
  available
• Transmit too many bits (sequence , ack,
  re-transmission)
• Tied with multi-threaded architecture
• TinyOS solution active messages

24
Active Message

• Every message contains the name of an event
  handler
• Sender
• Declaring buffer space in a frame
• Naming a handler
• Requesting transmission exit
• Done completion signal
• Receiver
• The event handler is fired automatically in a
  target node
• No blocked or waiting threads on sender or
  receiver
• Behaves like any other events
• Single buffering

25
TinyOS Storage Breakdown (C Code)
3450 B code 226 B data
26
Lecture 11, December 2, 2003

• Introduction
• TinyOS for WSNs
• Protocols for WSNs

27
Wireless Sensor Network Protocols

• Primary theme building long-lived,
  massively-distributed, physically-coupled
  systems
• Coordinating to minimize duty cycle and
  communication
• Adaptive MAC
• Adaptive Topology
• Routing
• In-network processing
• Data centric routing
• Programming models

28
Selected Topics

• Adaptive topology
• Routing
• Secure routing

29
Topology

• Connectivity of the network
• How are the nodes connected?
• How many neighbors?
• How many hops to reach another node?
• What graph model? Star, ring, bus

30
Adaptive Topology in WSNs

• Can we do more than shutdown radio in between
  transmissions/receptions?
• Can we put nodes to sleep for longer periods of
  time?
• Goals
• Exploit high density (over) deployment to extend
  system lifetime
• Provide topology that adapts to the application
  needs
• Self-configuring system that adapts to
  environment without manual configuration

31
Adaptive Topology Problem Description

• Simple Formulation (Geometric Disk Covering)
• Given a distribution of N nodes in a plane.
• Place a minimum number of disks of radius r
  (centered on the nodes) to cover them.
• Disk represents the radio connectivity (simple
  circle model).
• The problem is NP-hard.

32
Connectivity Measurements

• Cant justdetermine connectivity clusters
  thrugeographic coordinates
• For the same reason you cant determine
  coordinates w/connectivity

Packet reception over distance has a heavy tail.
There is a non-zero probability of receiving
packets at distances much greater than the
average cell range
169 motes, 13x13 grid, 2 ft spacing, open area,
RFM radio, simple CSMA
33
Tradeoffs

• How many nodes to activate?
• Few active nodes
• distance between neighboring nodes high -gt
  increase packet loss and higher transmit power
  and reduced spatial reuse
• need to maintain sensing coverage (see earlier
  session on coverage/exposure)
• Too many active nodes
• at best, expending unnecessary energy
• at worst nodes may interfere with one another by
  congesting the channel.

34
Adaptive Topology Schemes

• Mechanisms being explored
• Empirical adaptation Each node assesses its
  connectivity and adapts participation in
  multi-hop topology based on the measured
  operating region, ASCENT
• Cluster-based, load sharing within clusters, CEC
• Routing/Geographic topology based, eliminate
  redundant links, SPAN, GAF
• Data/traffic driven Trigger nodes on demand
  using paging channel, STEM

35
One Example ASCENT

• The nodes can be in active or passive state.
• Active nodes forward data packets (using routing
  mechanism that runs over topology).
• Passive nodes do not forward any packets but may
  sleep or collect network measurements.
• Each node joins network topology or sleeps
  according to measured number of neighbors and
  packet loss, as measured locally.

36
State Transitions
NT neighbor threshold LT loss threshold T?
state timer values (p passive, s sleep, t
test)
37
Energy Savings Ratio
Energy Savings Ratio as a function of density.
ASCENT provides significant amount of energy
savings, with a factor of 5 for high density
scenarios.
38
Event Delivery Ratio

• Event Delivery Ratio as a function of density.
  ASCENT reduces collisions by limiting the maximum
  number of active nodes transmitting packets.

39
Other Challenging Problems

• Load Balancing.
• Larger scale experiments.
• Interaction with adaptive MAC and geographic
  routing
• Application defined Adaptive Fidelity
• Expanding on STEMs data driven characteristics
  to achieve more than on/off behavior

40
Routing

• Problem Given a topology, how to route data?
• Different from Internet (wired) routing.

41
The GRAB Routing Approach

• Field Based Minimum Cost Forwarding
• Each node broadcasts only once
• Cost Function
• A measure of how expensive it is to get a message
  back to the sink.
• Could be based on
• Energy needed in radio communication.
• Hop count.
• Node Cost
• Each node keeps a best estimate on its minimum
  cost.
• Estimate updated upon receipt of every ADV
  message.
• ADV message forwarding deferred for time
  proportional to nodes cost estimate.

42
ADV Dissemination Example

• Signal strength is used to measure cost.
• B sees strong signal and judges cost to be 1.
• C sees weak signal and judges cost to be 3.

43
ADV Dissemination Example contd.

• Because B has a smaller cost, he defers for a
  shorter time then C.
• C updates his cost to 2 and restarts his deferral
  timer.
• Each node has optimal cost with minimum broadcast.

44
Data Dissemination

• A node that decides it has interesting data.
  broadcasts two things (besides data)
• Total budget to get back to sink.
• Amount of budget used in initial broadcast.
• A node receiving a data message will only forward
  a data message if
• Total Budget ? Budget Spent So Far My Cost
• If the inequality holds then Budget Spent So Far
  is updated.
• Otherwise the message is dropped.

45
Data Dissemination Example

• Assume hop count was used as a cost metric.
• Node A is the sink.
• Node C is the source.

46
Data Dissemination Example contd.

• Node C sends a data message which specifies
• Total Budget 2
• Budget Spent 1
• Node E drops message
• TB lt BS Es Cost
• Node B forwards message.

47
The Routing-on-a-Curve Approach

• Trajectories are a natural name space for
  embedded networks
• By definition, network structure mimics physical
  structure that is instrumented
• Stress along a column
• Flooding along a river
• Pollution along a road
• Trajectories come from the application domain

48
TBF (Trajectory based forwarding)

• Fundamental Idea
• Route packets along a specified trajectory
• Generalization of Source Based Routing and
  Cartesian routing
• Trajectory specified in the packet

49
Specifying trajectory

• Function
• Equation
• Parametric

50
Features of TBF

• Basic Features
• Decouples pathname from the actual path
• Source based Routing (LSR, DSR etc) mixes naming
  and route path
• Applications
• Route around obstacles/changes/failures
• Trajectory forwarding need not have a
  destination
• Route along a line, pattern
• Applications
• Flooding, discovery, group communication
  (pollination)

51
Routing on a curve
52
Secure Routing

• Goals
• What are the attacks?
• Security enhancement

53
Security in sensor networks

• Security is critical
• Military apps
• Building monitoring
• Burglar alarms
• Emergency response
• Yet security is hard
• Wireless links are inherently insecure
• Resource constraints
• Lossy, low bandwidth communication
• Lack of physical security

54
Secure routing goals and threat models

• Security goals
• Confidentiality messages are secret
• Integrity messages are not tampered with
• Availability
• In-network processing makes end-to-end security
  hard
• Link layer security still possible
• Need to consider compromised nodes (insiders) and
  resourceful attackers

55
Routing in sensor networks

• Base stations and sensor nodes
• Low overhead protocols
• Specialized traffic patterns
• In-network processing
• These differences necessitate new secure routing
  protocols

56
Attacks
57
TinyOS Beaconing
58
Attack Bogus routing information

• Bogus routing information can cause havoc
• Example spoof routing beacons and claim to be
  base station

• Lessons
• Authenticate routing info
• Trust but verify

59
Attack HELLO floods

• Assumption the sender of a received packet is
  within normal radio range
• False! A powerful transmitter could reach the
  entire network
• Can be launched by insiders and outsiders

Lesson Verify the bidirectionality of links
60
Attack Wormholes

• Tunnel packets received in one part of the
  network and replay them in a different part
• Can be launched by insiders and outsiders

Lesson Avoid routing race conditions
61
Attack Sybil attack

• An adversary may present multiple identities to
  other nodes

B
A
Lesson Verify identities
62
Protocols and Attacks
All insecure
63
Countermeasures

• Need countermeasure suggestions and design
  considerations
• Example research by Karlof and Wagner, Berkeley

64
Countermeasures

• Access control with link layer crypto
• Globally shared key gt outsiders
• Per link keys gt insiders
• Authenticated broadcast and flooding
• Verify neighbors identities
• Prevents Sybil attack
• Verify bidirectionality of links
• Prevents HELLO floods
• Multipath and probabilistic routing
• Limits effects of selective forwarding

65
Countermeasures

• Wormholes are difficult to defend against
• Can be launched by insiders and outsiders
• Defenses exist for outsiders, but are not cheap
• Best solution avoid routing race conditions
• Geographic routing protocols hold promise
• Nodes near base stations are attractive to
  compromise
• Overlays

66
Reading Materials

• Will be distributed.

67
Next Week

• Send me the title of your talk well before the
  class. I will schedule/announce presentations.
• Short review session.