EC8702 AD HOC AND WIRELESS SENSOR NETWORKS L T P C
3 0 0 3
OBJECTIVES:
The student should be made to:
Learn Ad hoc network and Sensor Network fundamentals
Understand the different routing protocols
Have an in-depth knowledge on sensor network architecture and design issues
Understand the transport layer and security issues possible in Ad hoc and Sensor networks
Have an exposure to mote programming platforms and tool
UNIT I AD HOC NETWORKS – INTRODUCTION AND ROUTING 9
PROTOCOLS
Elements of Ad hoc Wireless Networks, Issues in Ad hoc wireless networks, Example commercial
applications of Ad hoc networking, Ad hoc wireless Internet, Issues in Designing a Routing Protocol for
Ad Hoc Wireless Networks, Classifications of Routing Protocols, Table Driven Routing Protocols -
Destination Sequenced Distance Vector (DSDV), On–Demand Routing protocols –Ad hoc On–Demand
Distance Vector Routing (AODV).
UNIT II SENSOR NETWORKS – INTRODUCTION & ARCHITECTURES 9
Challenges for Wireless Sensor Networks, Enabling Technologies for Wireless Sensor Networks, WSN
application examples, Single-Node Architecture - Hardware Components, Energy Consumption of
Sensor Nodes, Network Architecture - Sensor Network Scenarios, Transceiver Design Considerations,
Optimization Goals and Figures of Merit.
UNIT III WSN NETWORKING CONCEPTS AND PROTOCOLS 9
MAC Protocols for Wireless Sensor Networks, Low Duty Cycle Protocols And Wakeup Concepts - S-
MAC, The Mediation Device Protocol, Contention based protocols - PAMAS, Schedule based protocols
– LEACH, IEEE 802.15.4 MAC protocol, Routing Protocols- Energy Efficient Routing, Challenges and
Issues in Transport layer protocol.
UNIT IV SENSOR NETWORK SECURITY 9
Network Security Requirements, Issues and Challenges in Security Provisioning, Network Security
Attacks, Layer wise attacks in wireless sensor networks, possible solutions for jamming, tampering, black
hole attack, flooding attack. Key Distribution and Management, Secure Routing – SPINS, reliability
requirements in sensor networks.
UNIT V SENSOR NETWORK PLATFORMS AND TOOLS 9
Sensor Node Hardware – Berkeley Motes, Programming Challenges, Node-level software platforms –
TinyOS, nesC, CONTIKIOS, Node-level Simulators – NS2 and its extension to sensor networks, COOJA,
TOSSIM, Programming beyond individual nodes – State centric programming.
TOTAL:45 PERIODS
OUTCOMES:
At the end of the course, the student would be able to:
Know the basics of Ad hoc networks and Wireless Sensor Networks
Apply this knowledge to identify the suitable routing algorithm based on the network and
user requirement
Apply the knowledge to identify appropriate physical and MAC layer protocols
Understand the transport layer and security issues possible in Ad hoc and sensor
networks.
Be familiar with the OS used in Wireless Sensor Networks and build basic modules
TEXT BOOKS:
1. C. Siva Ram Murthy and B. S. Manoj, ―Ad Hoc Wireless Networks Architectures and Protocols‖,
Prentice Hall, PTR, 2004. (UNIT I)
2. Holger Karl , Andreas willig, ―Protocol and Architecture for Wireless Sensor Networks‖, John wiley
publication, Jan 2006.(UNIT II-V)
References
1. Feng Zhao, Leonidas Guibas, ―Wireless Sensor Networks: an information processing
approach‖, Elsevier publication, 2004.
2. Charles E. Perkins, ―Ad Hoc Networking‖, Addison Wesley, 2000.
3. I.F. Akyildiz, W. Su, Sankarasubramaniam, E. Cayirci, ―Wireless sensor networks: a
survey‖, computer networks, Elsevier, 2002, 394 - 422.
EC8702 - AD HOC AND WIRELESS SENSOR NETWORKS
UNIT I
AD HOC NETWORKS – INTRODUCTION AND ROUTING PROTOCOLS
Elements of Ad hoc Wireless Networks, Issues in Ad hoc wireless networks,
Example commercial applications of Ad hoc networking, Ad hoc wireless
Internet, Issues in Designing a Routing Protocol for Ad Hoc Wireless Networks,
Classifications of Routing Protocols, Table Driven Routing Protocols - Destination
Sequenced Distance Vector (DSDV), On–Demand Routing protocols –Ad hoc On–
Demand Distance Vector Routing (AODV).
Ad Hoc Wireless Network
Introduction
• Ad Hoc Network is a multi-hop relaying
network
• ALOHAnet developed in 1970
• Ethernet developed in 1980
• In 1994, Bluetooth proposed by Ericsson to
develop a short-range, low-power, low-
complexity, and inexpensive radio inteface
• WLAN 802.11 spec. is proposed in 1997
1
Cellular and Ad Hoc Wireless Networks
• Cellular Wireless Networks: infrastructure
dependent network
• Ad Hoc Networks: multi-hop radio relaying
and without support of infrastructure
– Wireless Mesh Networks
– Wireless Sensor Networks
• The major differences between cellular
networks and ad hoc networks as summarized
in Table 5.1
2
Wireless Mesh
Networks
Cellular Wireless Networks Hybrid Wireless
Networks
Wireless Sensor
Networks
Infrastructure Dependent Ad Hoc Wireless Networks
(Single-Hop Wireless Networks) (Multi-Hop Wireless Networks)
Figure 5.1. Cellular and ad hoc wireless networks.
3
B
A
D
E
Switching Center
+
Gateway
Base Station Mobile Node Path from C to E
2009/11/2 4
5
Figure 5.2. A cellular networks.
B
A
C
F
E D
Mobile Node Wireless Link Path from C to E
2009/11/2 5
6
Figure 5.3. An ad hoc wireless networks
Table 5.1 Differences between cellular networks and ad hoc
wireless networks
Cellular Networks Ad Hoc Wireless Networks
Fixed infrastructure-based Infrastructure-less
Single-hop wireless links Multi-hop wireless links
Guaranteed bandwidth Shared radio channel
(designed for voice traffic) (more suitable for best-effort data traffic)
Centralized routing Distributed routing
Circuit-switched Packet-switched
(evolving toward packet switching) (evolving toward emulation of circuit
switching)
Seamless connectivity Frequency path break
(low call drops during handoffs) due to mobility
High cost and time of deployment Quick and cost-effective deployment
Reuse of frequency spectrum through Dynamic frequency reuse based on carrier
geographical channel reuse sense mechanism
6
2009/11/2 7
Table 5.1 Differences between cellular networks and ad hoc
wireless networks (cont.)
Easier to achieve time synchronization Time synchronization is difficult and
consumes bandwidth
Easier to employ bandwidth reservation Bandwidth reservation requires complex
medium access control protocols
Application domains include mainly civilian Application domains include battlefields,
and commercial sector emergency search and rescue operation, and
collaborative computing
High cost of network maintenance Self-organization and maintenance properties
(backup power source, staffing, etc.) are built into the network
Mobile hosts are of relatively low complexity Mobile hosts require more intelligence
(should have a transceiver as well as
routing/switching capacity)
Major goals of routing and call admission are Man aim of routing is to find paths with
to maximize the call acceptance ratio and minimum overhead and also quick
minimize the call drop ratio reconfiguration of broken paths
Widely deployed and currently in the third Several issues are to be addressed for
generation successful commercial deployment even
though widespread use exists in defense
7
2009/11/2 8
Applications of Ad Hoc Wireless Networks
• Military Applications
– Establishing communication among a group of soldiers for
tactical operations
– Coordination of military object moving at high speeds
such as fleets of airplanes or ships
– Requirements: reliability, efficiency, secure communication,
and multicasting routing,
• Collaborative and Distributed Computing
– Conference, distributed files sharing
• Emergency Operations
– Search, rescue, crowd control, and commando operations
– Support real-time and fault-tolerant communication paths
8
Wireless Mesh Networks
• An alternate communication infrastructure for
mobile or fixed nodes/users
• Provides many alternate paths for a data
transfer session between a source and
destination
• Advantages of Wireless Mesh Networks
– High data rate, quick and low cost of deployment,
enhanced services, high scalability, easy
extendability, high availability, and low cost per bit
9
Wired Network
Gateway node
Transmission range
A house with rooftop transceiver Wired link to the Internet
Wireless link
Figure 5.4. Wireless mesh networks operating in a residential zone
10
Internet
Radio relay node
Multi-hop radio relay link Lamp
Wired link to the Internet Coverage area
Figure 5.5 Wireless mesh network covering a highway
11
Wireless Sensor Networks
• A collection of a large number of sensor nodes
that are deployed in a particular region
• Applications:
– military, health care, home security, and
environmental monitoring
• Differences with the ad hoc wireless networks:
– Mobility of nodes, size of network, density of
deployment, power constraints, data/information
fusion, traffic distribution
12
Hybrid Wireless Networks
• HWN such as Multi-hop cellular networks and
integrated cellular ad hoc relay networks
– The base station maintains the information about the
topology of the network for efficient routing
– The capacity of a cellular network can be increased if the
network incorporates the properties of multi-hop relaying
along with the support of existing fixed infrastructure
• Advantages:
– Higher capacity than cellular networks due to better
channel reuse
– Increased flexibility and reliability in routing
– Better coverage and connectivity in holes
13
B
A
E Switching Center
+
Gateway
Base Station Mobile Node MCN communication
Figure 5.6. MCN architecture.
14
Issues in Ad Hoc Wireless Networks
• Medium access scheme
• Routing, Multicasting, TPC protocol
• Pricing scheme, QoS, Self-organization
• Security, Energy management
• Addressing and service discovery
• Deployment considerations
15
Medium Access Scheme
• Distributed operation
– fully distributed involving minimum control overhead
• Synchronization
– Mandatory for TDMA-based systems
• Hidden terminals
– Can significantly reduce the throughput of a MAC protocol
• Exposed terminals
– To improve the efficiency of the MAC protocol, the exposed
nodes should be allowed to transmit in a controlled fashion
without causing collision to the on-going data transfer
• Access delay
16
The Major Issues of MAC Scheme
• Throughput and access delay
– To minimize the occurrence of collision, maximize channel
utilization, and minimize controloverhead
• Fairness
– Equal share or weighted share of the bandwidth to all
competing nodes
• Real-time traffic support
• Resource reservation
– Such as BW, buffer space, and processing power
• Capability for power control
• Adaptive rate control
• Use of directional antennas
1
18
2009/11/2 7
The Major Challenge of Routing Protocol
• Mobility result in frequent path break, packet
collision, and difficulty in resource reservation
• Bandwidth constraint: BW is shared by every node
• Error-prone and share channel: high bit error rate
• Location-dependent contention: distributing the
network load uniformly across the network
• Other resource constraint: computing power, battery
power, and buffer storage
18
The Major Requirement of Routing Protocol
• Minimum route acquisition delay
• Quick route reconfiguration: to handle path breaks
• Loop-free routing
• Distributed routing approach
• Minimum control overhead
• Scalability
• Provisioning of QoS:
• supporting differentiated classes of services
• Support for time-sensitive traffic
• Security and privacy
19
The Major Issues in Multicast Routing
Protocols
• Robustness
– recover and reconfigure quickly from link breaks
• Efficiency
– minimum number of transmissions to deliver a data packet
to all the group members
• Minimal Control overhead
• QoS support
• Efficient group management
• Scalability
• Security
20
Transport Layer Protocols
• Objectives: setting up and maintaining
– End-to-end connections, reliable end-to-end data
delivery, flow control, and congestion control
• Major performance degradation:
– Frequent path breaks, presence of old routing
information, high channel error rate, and frequent
network partitions
21
Quality of Service Provisioning
• QoS often requires negotiation between the host and
the network, resource reservation schemes, priority
scheduling and call admission control
• QoS in Ad hoc wireless networks can be on a per
flow, per link, or per node
• Qos Parameters: different applications have different
requirements
– Multimedia: bandwidth and delay are the key parameters
– Military: BW, delay, security and reliability
– Emergency search –and-rescue: availability is the key
parameters, multiple link disjoint paths
– WSN: battery life, minimum energy consumption
22
Quality of Service Provisioning
• QoS-aware routing:
– To have the routing use QoS parameters for finding a path
– The parameters are network through put, packet delivery
ratio, reliability, delay, delay jitter, packet lost rate, bit error
rate, and path loss
• QoS framework:
– A frame work for QoS is a complete system that attempts
to provide the promised service
– The QoS modules such as routing protocol, signaling
protocol, and resource management should react
promptly according to changes in the network state
23
Self-Organization
• An important property that an ad hoc wireless
network should exhibit is organizing and maintaining
the network by itself
• Major activities: neighbor discovery, topology
organization, and topology reorganization
• Ad hoc wireless networks should be able to perform
self-organization quickly and efficiently
24
Security
• The attack against ad hoc wireless networks are
classified into two types: passive and active attacks
• Passive attack: malicious nodes to observe the
nature of activities and to obtain information in the
network without disrupting the operation
• Active attack: disrupt the operation of the network
– Internal attack: nodes belong to the same network
– External attack: nodes outside the network
25
Major Security Threats
• Denial of service: either consume the network BW or
overloading the system
• Resource consumption
– Energy depletion: by directing unnecessary traffic through
nodes
– Buffer overflow: filling unwanted data, routing table attack
(filling nonexistent destinations)
• Host impersonation: A compromised node can act as
another node and respond control packets to create
wrong route entries and terminate the traffic
• Information disclosure: support useful traffic pattern
• Interference: create wide-spectrum noise
26
Addressing and Service Discovery
• An address that is globally unique is required for a
node to participate communication
– Auto-configuration of address is required to allocate non-
duplicate address to the nodes
– In networks frequent partitioning and merging of network
components require duplicate address detection
mechanisms
• Nodes in the network should be able to locate
services that other nodes provide
27
Energy Management
• Transmission power management:
– RF hardware design ensure minimum power consumption
– Uses variable power MAC protocol
– Load balance in network layer
– Reducing the number of retransmissions at the transport
layer
– Application software developed for mobile computers
28
Energy Management (cont.)
• Battery energy management: extending the battery
life by taking chemical properties, discharge patterns,
and by the selection of a battery from a set of
batteries that is available for redundancy
• Processor power management: CPU can be put into
different power saving modes during low processing
load conditions
• Devices power management: can be done by OS by
selectively powering down interface devices that are
not used or by putting devices into different power-
saving modes
29
Scalability
• The latency of path-finding involved with an
on-demand routing protocol in a large ad hoc
wireless network may be unacceptably high
• A hierarchical topology-based system and
addressing may be more suitable for large ad
hoc wireless networks
30
Deployment Considerations
• The deployment of a commercial ad hoc wireless
network has the following benefits
– Low cost of deployment
– Incremental deployment
– Short deployment time
– Re-configurability
31
Major Issues for Deployment
• Scenario of deployment
– Military deployment
• Data-centric (e.g. WSN)
• User-centric (soldiers or vehicles carrying with wireless
communication devices)
– Emergency operations deployment
– Commercial wide-area deployment
– Home network deployment
• Required longevity of network: regenerative power
source can be deployed when the connectivityis
required for a longer duration of time
• Area of coverage 32
Major Issues for Deployment
• Service availability: redundant nodes can be
deployed to against nodes failure
• Operational integration with other infrastructure:
can be considered for improve the performance or
gathering additional information, or for providing
better QoS
• Choice of protocols: the choices of protocols at
different layers of the protocol stack is to be done
taking into consideration the deployment scenario
33
Ad Hoc Wireless in Internet
• Similar to wireless internet, the ad hoc
wireless internet extends the service of the
Internet to the end user over an ad hoc
wireless network
• Gateways: entry points to the wired Internet
• Address mobility: similar to the Mobile IP
• Routing: major problem in ad hoc wireless Internet
• Transport layer protocol
• Load balancing, pricing/billing, security, QoS
• Service, address, and location discovery
34
TCP/IP protocol stack TCP/IP protocol stack TCP/IP protocol stack
Application Layer Application Layer Application Layer
(HTTP, TELNET, SMTP, (HTTP, TELNET, SMTP, (HTTP, TELNET, SMTP,
etc.) etc.) etc.)
Transport Layer Transport Layer Transport Layer
(TCP/UDP) (TCP/UDP) (TCP/UDP)
Network Layer Network Layer Network Layer Network Layer
(IPv4/IPv6) (IPv4/IPv6) (IPv4/IPv6) (IPv4/IPv6)
802.11/HIPERLAN 802.11/HIPERLAN 802.3/802.4/802.5
802.11 802.3/802.4/80
HIPERLAN 2.5
Internet
Mobile node that Mobile node that can relay Ad hoc wireless Internet
can be connected packets to any mobile node gateway connected to a
to any AP running running ad hoc wireless subnet of the Internet
ad hoc wireless routing protocol
routing protocol
Multi-hop wireless part of ad hoc wireless Internet Traditional wired Internet
Flow of an IP packet from the wired Internet to a mobile node
Transceiver antenna
3
36
Figure 5.7. A schematic diagram of the ad hoc wireless Internet 5
Internet
A
Gateway Node
A house with rooftop transceiver Transmission range
Path 1 Wired link to the Internet
Path 2 Wireless link
Figure 5.8. An illustration of the ad hoc wireless Internet implemented
by a wireless mesh network
36
Routing Protocols for Ad Hoc
Wireless Networks
■ 1
Introduction
• Routing protocols used in wired networks cannot
be directly applied to ad hoc wireless networks
– Highly dynamic topology
– No infrastructure for centralized administration
– Bandwidth constrained
– Energy constrained
• For the above reasons, we need to design new
routing protocols for ad hoc networks
■ 2
Issues in Designing a Routing Protocol
• Mobility:
– Ad hoc is highly dynamic due to the movement of nodes
– Node movement causes frequent path breaks
– The path repair in wired network has slow convergence
• Bandwidth Constraint:
– Wireless has less bandwidth due to the limited radio band:
Less data rate and difficult to maintain topology
information
– Frequent change of topology causes more overhead of
topology maintenance
– Target: Bandwidth optimization and design topology
update mechanism with less overhead
■ 3
Issues in Designing a Routing Protocol
• Error-prone shared broadcast radio channel:
– Wireless links have time varying characteristics in terms
of link capacity and link-error probability
– Target: Interact with MAC layer to find better-quality link
– Hidden terminal problem causes packet collision
– Target: Find routes through better quality links and find
path with less congestion
• Hidden and exposed terminal problems
– RTS-CTS control packet cannot ensure collision free, see
Fig. 7.2
• Resource Constraints:
– Limited battery life and limited processing power
– Target: optimally manage these resources
■ 4
T R A B
r
T RTS CTS Data
Distance
Collision
R RTS CTS Data RTS
A CTS Data RTS
B Data
Time
■
Figure 7.2. Hidden terminal problem with RTS-CTS-Data-ACK scheme. ■
5
5
Characteristics of an Ideal Routing Protocol
for Ad Hoc
• Fully distributed
• Adaptive to frequent topology changes
• Minimum connection setup time is desired
• Localized
– global maintenance involves a huge state propagation
control overhead
• Loop free and free from stale routes
• Packet collision must seldom happen
■ 6
Characteristics of an Ideal Routing Protocol
for Ad Hoc (cont.)
• Converge to optimal route quickly
• Optimally use scarce resource
– Bandwidth, computing power, memory, and battery
• Remote parts of the network must not cause updates
in the topology information maintained by this node
• Provide quality of service and support for time-
sensitive traffic
■ 7
Classifications of Routing Protocols
• Routing protocol can be broadly classified into four
categories :
– Routing information update mechanism
– Use of temporal information for routing
– Routing topology
– Utilization of specific resource
• These classification is not mutually exclusive
■ 8
Based on the Routing Information Update
Mechanism
• Proactive or table-driven routing protocols
– Maintain routing information in the routing table
– Routing information is flooded in the whole network
– Runs path-finding algorithm with the routing table
• Reactive or on-demand routing protocols
– Obtain the necessary path while required
• Hybrid routing protocols
– In the zone of given node : use table-driven
– Out of the zone of given node : use on-demand
■ 9
Based on the Use of Temporal Information
for Routing
• Using past temporal information
– Past status of the links or
– the status of links at the time of routing to make routing
decision
• Using future temporal information
– Expected future status of the links to make decision
– Node lifetime is also included
• Ex: remaining battery charge, prediction of location,
and link availability
■ 10
Based on the Routing Topology
• Flat topology routing protocols
– Flat addressing scheme similar to IEEE 802.3 LANs
– Globally unique addressing mechanism for nodes
• Hierarchical topology routing protocols
– Logical hierarchy
– Associated addressing scheme
– May based on geographical information or hop distance
■ 11
Based on the Utilization of Specific Resource
• Power-aware routing
– Minimize consumption of resource
• Ex: Battery power
• Geographical information assisted routing
– Improve the routing performance
– Reduce control overhead
■ 12
Classifications of Routing Protocol:
(3) (1)
■ 13
• Table-Driven Routing Protocols
• On-Demand Routing Protocols
■ 14
Table-Driven Routing Protocols
• We introduce these routing protocols:
– Destination Sequenced Distance-Vector Routing
Protocol (DSDV)
– Wireless Routing Protocol (WRP)
– Cluster-Head Gateway Switch Routing Protocol (CGSR)
– Source-Tree Adaptive Routing Protocol (STAR)
■ 15
Destination Sequenced Distance-Vector
Routing Protocol (DSDV)
• Enhanced from distributed Bellman-Ford
algorithm
• Obtain a table that contains shortest path from
this node to every node
• Incorporate table updates with increasing
sequence number tags
– Prevent loops
– Counter the count-to-infinity problem
– Faster convergence
■ 16
DSDV (Cont.)
• Exchange table between neighbors at regular time
interval
• Two types of table updates
– Incremental update
• Takes a single network data packet unit (NDPU)
– When no significant change in the local topology
– Full dumps update
• Takes multiple NDPUs:
– When local topology changes significantly
– Or incremental updates require more than a NDPU
■ 17
DSDV (Cont.)
• Table updates are initiated by the destination with
the new sequence number which is always greater
than the previous one
• Single link break cause propagation of table update
information to the whole network
– With odd sequence
• The changed node informs neighbors about new
shortest path while receiving the table update
message
– With even sequence
■ 18
■ 19
11 DestinationID
Node 15
Movement Dest NextNode Dist SeqNo
14 2 2 1 22
13
3 2 2 26
4 5 2 32
11 12
9 5 5 1 134
8 6 6 1 144
7 2 3 162
10
8 5 3 170
9 2 4 186
4 7
10 6 2 142
6 11 5 4 180
5
12 5 3 190
3
13 5 4 198
2 14 6 3 214
1
15 5 4 256
SourceID
Figure 7.6. Route maintenance in DSDV
■ 20
DSDV (Cont.)
• Advantages:
– Route setup process is very fast
– Make the existing wired network protocol apply to ad
hoc network with fewer modifications
• Disadvantages:
– Excessive control overhead during high mobility
– Node must wait for a table update message initiated by
the destination node
• Cause stale routing information at nodes
■ 21
On-demand Routing Protocol
• Unlike the table-driven routing protocols, on-
demand routing protocols execute the path-finding
process and exchange routing information only when
a path is required by a node to communicate with a
destination.
■ 22
On-demand Routing Protocol
• Dynamic Source Routing Protocol (DSR)
• Ad Hoc On-demand Distance-Vector Routing Protocol
(AODV)
• Temporally Ordered Algorithm (TORA)
• Location-Aided Routing (LAR)
• Associativity-Based Routing(ABR)
• Signal Stability-Based Adaptive Routing Protocol (SSA)
• Flow-Oriented Routing Protocol (FORP)
■ 23
Dynamic Source Routing Protocol (DSR)
• Beacon-less: no hello packet
• Routing cache
• DSR contains two phases
– Route Discovery (find a path)
• Flooding RouteRequest with TTL from source
• Response RouteReply by destination
– If an forwarding node has a route to the destination in its
route cache, it sends a RouteREply to the source
– Route Maintenance (maintain a path)
• RouteError
■ 24
Routing Discovery
DestinationID
15
14
13
Network Link
11 12
9
8 RouteRequest
10
RouteReply
4 7
Path1: 1-2-3-7-9-13-15
6 Path2: 1-5-4-12-15
5
Path3: 1-6-10-11-14-15
3
2
1
Sour ceID
Figure 7.10. Route establishment in DSR. 2
36
■■
5
Routing Maintain DestinationID
15
14
13
Network Link
11 12
9
Selected Path
8
10 RouteError
4 7 Broken Link
6
5
2
1
SourceID
Figure 7.11. Route maintenance in DSR.
■ 26
UNIT II
SENSOR NETWORKS – INTRODUCTION & ARCHITECTURES
Challenges for Wireless Sensor Networks, Enabling Technologies for
Wireless Sensor Networks, WSN application examples, Single-Node
Architecture - Hardware Components, Energy Consumption of Sensor
Nodes, Network Architecture - Sensor Network Scenarios, Transceiver
Design Considerations, Optimization Goals and Figures of Merit.
Unit -2 SENSOR NETWORKS –
INTRODUCTION & ARCHITECTURES
Ad hoc and Sensor Networks
Motivation & Applications
Goals of this chapter
• Give an understanding what ad hoc & sensor networks are
good for, what their intended application areas are
• Commonalities and differences
• Differences to related network types
• Limitations of these concepts
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 2
Outline
• Infrastructure for wireless?
• (Mobile) ad hoc networks
• Wireless sensor networks
• Comparison
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 3
Infrastructure-based wireless networks
• Typical wireless network: Based on infrastructure
• E.g., GSM, UMTS, …
• Base stations connected to a wired backbone network
• Mobile entities communicate wirelessly to these base stations
• Traffic between different mobile entities is relayed by base stations
and wired backbone
• Mobility is supported by switching from one base station to another
• Backbone infrastructure required for administrative tasks
Gateways IP backbone
s
Server
Router
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 4
Infrastructure-based wireless networks – Limits?
• What if …
• No infrastructure is available? – E.g., in disaster areas
• It is too expensive/inconvenient to set up? – E.g., in remote, large
construction sites
• There is no time to set it up? – E.g., in military operations
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 5
Possible applications for infrastructure-free networks
• Factory floor • Disaster recovery • Car-to-car
automation communication
• Military networking: Tanks, soldiers, …
• Finding out empty parking lots in a city, without asking a server
• Search-and-rescue in an avalanche
• Personal area networking (watch, glasses, PDA, medical appliance, …)
• …
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 6
Outline
• Infrastructure for wireless?
• (Mobile) ad hoc networks
• Wireless sensor networks
• Comparison
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 7
Solution: (Wireless) ad hoc networks
• Try to construct a network without infrastructure, using
networking abilities of the participants
• This is an ad hoc network – a network constructed “for a special
purpose”
• Simplest example: Laptops in a conference room –
a single-hop ad hoc network
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 8
Problems/challenges for ad hoc networks
• Without a central infrastructure, things become much more
difficult
• Problems are due to
• Lack of central entity for organization available
• Limited range of wireless communication
• Mobility of participants
• Battery-operated entities
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 9
No central entity ! self-organization
• Without a central entity (like a base station), participants
must organize themselves into a network (self-
organization)
• Pertains to (among others):
• Medium access control – no base station can assign transmission
resources, must be decided in a distributed fashion
• Finding a route from one participant to another
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 10
Limited range ! multi-hopping
• For many scenarios, communication with peers outside
immediate communication range is required
• Direct communication limited because of distance, obstacles, …
• Solution: multi-hop network
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 11
Mobility ! Suitable, adaptive protocols
• In many (not all!) ad hoc network applications, participants
move around
• In cellular network: simply hand over to another base station
• In mobile ad hoc
networks (MANET):
• Mobility changes
neighborhood relationship
• Must be compensated for
• E.g., routes in the network
have to be changed
• Complicated by scale
• Large number of such
nodes difficult to support
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 12
Battery-operated devices ! energy-efficient operation
• Often (not always!), participants in an ad hoc network draw
energy from batteries
• Desirable: long run time for
• Individual devices
• Network as a whole
! Energy-efficient networking protocols
• E.g., use multi-hop routes with low energy consumption (energy/bit)
• E.g., take available battery capacity of devices into account
• How to resolve conflicts between different optimizations?
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 13
Outline
• Infrastructure for wireless?
• (Mobile) ad hoc networks
• Wireless sensor networks
• Applications
• Requirements & mechanisms
• Comparison
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 14
Wireless sensor networks
• Participants in the previous examples were devices close
to a human user, interacting with humans
• Alternative concept:
Instead of focusing interaction on humans, focus on
interacting with environment
• Network is embedded in environment
• Nodes in the network are equipped with sensing and actuation to
measure/influence environment
• Nodes process information and communicate it wirelessly
! Wireless sensor networks (WSN)
• Or: Wireless sensor & actuator networks (WSAN)
Ad hoc & sensor networs - Ch 1: Motivation & Applications 15
WSN application examples
• Disaster relief operations
• Drop sensor nodes from an aircraft over a wildfire
• Each node measures temperature
• Derive a “temperature map”
• Biodiversity mapping
• Use sensor nodes to observe wildlife
• Intelligent buildings (or bridges)
• Reduce energy wastage by proper humidity,
ventilation, air conditioning (HVAC) control
• Needs measurements about room occupancy,
temperature, air flow, …
• Monitor mechanical stress after earthquakes
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 16
WSN application scenarios
• Facility management
• Intrusion detection into industrial sites
• Control of leakages in chemical plants, …
• Machine surveillance and preventive maintenance
• Embed sensing/control functions into places no cable has gone
before
• E.g., tire pressure monitoring
• Precision agriculture
• Bring out fertilizer/pesticides/irrigation only where needed
• Medicine and health care
• Post-operative or intensive care
• Long-term surveillance of chronically ill patients or the elderly
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 17
WSN application scenarios
• Logistics
• Equip goods (parcels, containers) with a sensor node
• Track their whereabouts – total asset management
• Note: passive readout might suffice – compare RF IDs
• Telematics
• Provide better traffic control by obtaining finer-grained information
about traffic conditions
• Intelligent roadside
• Cars as the sensor nodes
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 18
Roles of participants in WSN
• Sources of data: Measure data, report them “somewhere”
• Typically equip with different kinds of actual sensors
• Sinks of data: Interested in receiving data from WSN
• May be part of the WSN or external entity, PDA, gateway, …
• Actuators: Control some device based on data, usually
also a sink
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 19
Structuring WSN application types
• Interaction patterns between sources and sinks classify
application types
• Event detection: Nodes locally detect events (maybe jointly with
nearby neighbors), report these events to interested sinks
• Event classification additional option
• Periodic measurement
• Function approximation: Use sensor network to approximate a
function of space and/or time (e.g., temperature map)
• Edge detection: Find edges (or other structures) in such a
function (e.g., where is the zero degree border line?)
• Tracking: Report (or at least, know) position of an observed
intruder (“pink elephant”)
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 20
Deployment options for WSN
• How are sensor nodes deployed in their environment?
• Dropped from aircraft ! Random deployment
• Usually uniform random distribution for nodes over finite area is
assumed
• Is that a likely proposition?
• Well planned, fixed ! Regular deployment
• E.g., in preventive maintenance or similar
• Not necessarily geometric structure, but that is often a convenient
assumption
• Mobile sensor nodes
• Can move to compensate for deployment shortcomings
• Can be passively moved around by some external force (wind, water)
• Can actively seek out “interesting” areas
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 21
Maintenance options
• Feasible and/or practical to maintain sensor nodes?
• E.g., to replace batteries?
• Or: unattended operation?
• Impossible but not relevant? Mission lifetime might be very small
• Energy supply?
• Limited from point of deployment?
• Some form of recharging, energy scavenging from environment?
• E.g., solar cells
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 22
Outline
• Infrastructure for wireless?
• (Mobile) ad hoc networks
• Wireless sensor networks
• Applications
• Requirements & mechanisms
• Comparison
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 23
Characteristic requirements for WSNs
• Type of service of WSN
• Not simply moving bits like another network
• Rather: provide answers (not just numbers)
• Issues like geographic scoping are natural requirements, absent from
other networks
• Quality of service
• Traditional QoS metrics do not apply
• Still, service of WSN must be “good”: Right answers at the right time
• Fault tolerance
• Be robust against node failure (running out of energy, physical destruction,
…)
• Lifetime
• The network should fulfill its task as long as possible – definition depends
on application
• Lifetime of individual nodes relatively unimportant
• But often treated equivalently
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 24
Characteristic requirements for WSNs
• Scalability
• Support large number of nodes
• Wide range of densities
• Vast or small number of nodes per unit area, very application-
dependent
• Programmability
• Re-programming of nodes in the field might be necessary, improve
flexibility
• Maintainability
• WSN has to adapt to changes, self-monitoring, adapt operation
• Incorporate possible additional resources, e.g., newly deployed
nodes
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 25
Required mechanisms to meet requirements
• Multi-hop wireless communication
• Energy-efficient operation
• Both for communication and computation, sensing, actuating
• Auto-configuration
• Manual configuration just not an option
• Collaboration & in-network processing
• Nodes in the network collaborate towards a joint goal
• Pre-processing data in network (as opposed to at the edge) can
greatly improve efficiency
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 26
Required mechanisms to meet requirements
• Data centric networking
• Focusing network design on data, not on node identifies (id-
centric networking)
• To improve efficiency
• Locality
• Do things locally (on node or among nearby neighbors) as far as
possible
• Exploit tradeoffs
• E.g., between invested energy and accuracy
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 27
Outline
• Infrastructure for wireless?
• (Mobile) ad hoc networks
• Wireless sensor networks
• Comparison
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 28
MANET vs. WSN
• Many commonalities: Self-organization, energy efficiency, (often)
wireless multi-hop
• Many differences
• Applications, equipment: MANETs more powerful (read: expensive)
equipment assumed, often “human in the loop”-type applications, higher
data rates, more resources
• Application-specific: WSNs depend much stronger on application
specifics; MANETs comparably uniform
• Environment interaction: core of WSN, absent in MANET
• Scale: WSN might be much larger (although contestable)
• Energy: WSN tighter requirements, maintenance issues
• Dependability/QoS: in WSN, individual node may be dispensable
(network matters), QoS different because of different applications
• Data centric vs. id-centric networking
• Mobility: different mobility patterns like (in WSN, sinks might be mobile,
usual nodes static)
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 29
Wireless fieldbuses and WSNs
• Fieldbus:
• Network type invented for real-time communication, e.g., for
factory-floor automation
• Inherent notion of sensing/measuring and controlling
• Wireless fieldbus: Real-time communication over wireless
! Big similarities
• Differences
• Scale – WSN often intended for larger scale
• Real-time – WSN usually not intended to provide (hard) real-time
guarantees as attempted by fieldbuses
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 30
Enabling technologies for WSN
• Cost reduction
• For wireless communication, simple microcontroller, sensing,
batteries
• Miniaturization
• Some applications demand small size
• “Smart dust” as the most extreme vision
• Energy scavenging
• Recharge batteries from ambient energy (light, vibration, …)
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 31
Conclusion
• MANETs and WSNs are challenging and promising system
concepts
• Many similarities, many differences
• Both require new types of architectures & protocols
compared to “traditional” wired/wireless networks
• In particular, application-specificness is a new issue
SS 05 Ad hoc & sensor networs - Ch 1: Motivation & Applications 32
Single node architecture
Goals of this chapter
• Survey the main components of the composition of a node
for a wireless sensor network
• Controller, radio modem, sensors, batteries
• Understand energy consumption aspects for these
components
• Putting into perspective different operational modes and what
different energy/power consumption means for protocol design
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 2
Outline
• Sensor node architecture
• Energy supply and consumption
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 3
Sensor node architecture
• Main components of a WSN node
• Controller
• Communication device(s)
• Sensors/actuators
• Memory
• Power supply
Memory
Communication Sensor(s)/
Controller
device actuator(s)
Power supply
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 4
Ad hoc node architecture
• Core: essentially the same
• But: Much more additional equipment
• Hard disk, display, keyboard, voice interface, camera, …
• Essentially: a laptop-class device
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 5
Controller
• Main options:
• Microcontroller – general purpose processor, optimized for
embedded applications, low power consumption
• DSPs – optimized for signal processing tasks, not suitable here
• FPGAs – may be good for testing
• ASICs – only when peak performance is needed, no flexibility
• Example microcontrollers
• Texas Instruments MSP430
• 16-bit RISC core, up to 4 MHz, versions with 2-10 kbytes RAM,
several DACs, RT clock, prices start at 0.49 US$
• Atmel ATMega
• 8-bit controller, larger memory than MSP430, slower
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 6
Communication device
• Which transmission medium?
• Electromagnetic at radio frequencies? ✓
• Electromagnetic, light?
• Ultrasound?
• Radio transceivers transmit a bit- or byte stream as radio
wave
• Receive it, convert it back into bit-/byte stream
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 7
Transceiver characteristics
• Capabilities • Radio performance
• Interface: bit, byte, packet level? • Modulation? (ASK, FSK, …?)
• Supported frequency range? • Noise figure? NF = SNRI/SNRO
• Typically, somewhere in 433 MHz • Gain? (signal amplification)
– 2.4 GHz, ISM band
• Receiver sensitivity? (minimum S to
• Multiple channels? achieve a given Eb/N0)
• Data rates? • Blocking performance (achieved
• Range? BER in presence of frequency-
offset interferer)
• Energy characteristics • Out of band emissions
• Power consumption to send/receive • Carrier sensing & RSSI
data? characteristics
• Time and energy consumption to • Frequency stability (e.g., towards
change between different states? temperature changes)
• Transmission power control? • Voltage range
• Power efficiency (which percentage
of consumed power is radiated?)
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 8
Transceiver states
• Transceivers can be put into different operational states,
typically:
• Transmit
• Receive
• Idle – ready to receive, but not doing so
• Some functions in hardware can be switched off, reducing energy
consumption a little
• Sleep – significant parts of the transceiver are switched off
• Not able to immediately receive something
• Recovery time and startup energy to leave sleep state can be
significant
• Research issue: Wakeup receivers – can be woken via
radio when in sleep state (seeming contradiction!)
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 9
Example radio transceivers
• Almost boundless variety available • Chipcon CC 2400
• Some examples • Implements 802.15.4
• 2.4 GHz, DSSS modem
• RFM TR1000 family
• 250 kbps
• 916 or 868 MHz
• Higher power consumption
• 400 kHz bandwidth
than above transceivers
• Up to 115,2 kbps
• Infineon TDA 525x family
• On/off keying or ASK
• E.g., 5250: 868 MHz
• Dynamically tuneable output
• ASK or FSK modulation
power
• RSSI, highly efficient power
• Maximum power about 1.4 mW
amplifier
• Low power consumption
• Intelligent power down,
• Chipcon CC1000 “self-polling” mechanism
• Range 300 to 1000 MHz, • Excellent blocking
programmable in 250 Hz steps performance
• FSK modulation
• Provides RSSI
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 10
Example radio transceivers for ad hoc networks
• Ad hoc networks: Usually, higher data rates are required
• Typical: IEEE 802.11 b/g/a is considered
• Up to 54 MBit/s
• Relatively long distance (100s of meters possible, typical 10s of
meters at higher data rates)
• Works reasonably well (but certainly not perfect) in mobile
environments
• Problem: expensive equipment, quite power hungry
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 11
Wakeup receivers
• Major energy problem: RECEIVING
• Idling and being ready to receive consumes considerable amounts
of power
• When to switch on a receiver is not clear
• Contention-based MAC protocols: Receiver is always on
• TDMA-based MAC protocols: Synchronization overhead, inflexible
• Desirable: Receiver that can (only) check for incoming
messages
• When signal detected, wake up main receiver for actual reception
• Ideally: Wakeup receiver can already process simple addresses
• Not clear whether they can be actually built, however
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 12
Ultra-wideband communication
• Standard radio transceivers: Modulate a signal onto a
carrier wave
• Requires relatively small amount of bandwidth
• Alternative approach: Use a large bandwidth, do not
modulate, simply emit a “burst” of power
• Forms almost rectangular pulses
• Pulses are very short
• Information is encoded in the presence/absence of pulses
• Requires tight time synchronization of receiver
• Relatively short range (typically)
• Advantages
• Pretty resilient to multi-path propagation
• Very good ranging capabilities
• Good wall penetration
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 13
Sensors as such
• Main categories
• Any energy radiated? Passive vs. active sensors
• Sense of direction? Omidirectional?
• Passive, omnidirectional
• Examples: light, thermometer, microphones, hygrometer, …
• Passive, narrow-beam
• Example: Camera
• Active sensors
• Example: Radar
• Important parameter: Area of coverage
• Which region is adequately covered by a given sensor?
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 14
Outline
• Sensor node architecture
• Energy supply and consumption
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 15
Energy supply of mobile/sensor nodes
• Goal: provide as much energy as possible at smallest
cost/volume/weight/recharge time/longevity
• In WSN, recharging may or may not be an option
• Options
• Primary batteries – not rechargeable
• Secondary batteries – rechargeable, only makes sense in
combination with some form of energy harvesting
• Requirements include
• Low self-discharge
• Long shelf live
• Capacity under load
• Efficient recharging at low current
• Good relaxation properties (seeming self-recharging)
• Voltage stability (to avoid DC-DC conversion)
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 16
Battery examples
• Energy per volume (Joule per cubic centimeter):
Primary batteries
Chemistry Zinc-air Lithium Alkaline
Energy (J/cm3) 3780 2880 1200
Secondary batteries
Chemistry Lithium NiMHd NiCd
Energy (J/cm3) 1080 860 650
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 17
Energy scavenging
• How to recharge a battery?
• A laptop: easy, plug into wall socket in the evening
• A sensor node? – Try to scavenge energy from environment
• Ambient energy sources
• Light ! solar cells – between 10 W/cm2 and 15 mW/cm2
• Temperature gradients – 80 W/cm2 @ 1 V from 5K difference
• Vibrations – between 0.1 and 10000 W/cm3
• Pressure variation (piezo-electric) – 330 W/cm2 from the heel of
a shoe
• Air/liquid flow
(MEMS gas turbines)
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 18
Energy scavenging – overview
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 19
Energy consumption
• A “back of the envelope” estimation
• Number of instructions
• Energy per instruction: 1 nJ
• Small battery (“smart dust”): 1 J = 1 Ws
• Corresponds: 109 instructions!
• Lifetime
• Or: Require a single day operational lifetime = 24¢60¢60 =86400 s
• 1 Ws / 86400s ¼ 11.5 W as max. sustained power consumption!
• Not feasible!
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 20
Multiple power consumption modes
• Way out: Do not run sensor node at full operation all the
time
• If nothing to do, switch to power safe mode
• Question: When to throttle down? How to wake up again?
• Typical modes
• Controller: Active, idle, sleep
• Radio mode: Turn on/off transmitter/receiver, both
• Multiple modes possible, “deeper” sleep modes
• Strongly depends on hardware
• TI MSP 430, e.g.: four different sleep modes
• Atmel ATMega: six different modes
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 21
Some energy consumption figures
• Microcontroller
• TI MSP 430 (@ 1 MHz, 3V):
• Fully operation 1.2 mW
• Deepest sleep mode 0.3 W – only woken up by external interrupts
(not even timer is running any more)
• Atmel ATMega
• Operational mode: 15 mW active, 6 mW idle
• Sleep mode: 75 W
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 22
Switching between modes
• Simplest idea: Greedily switch to lower mode whenever
possible
• Problem: Time and power consumption required to reach
higher modes not negligible
• Introduces overhead
• Switching only pays off if Esaved > Eoverhead
• Example: Esaved Eoverhead
Event-triggered
wake up from Pactive
sleep mode
• Scheduling problem Psleep
with uncertainty
(exercise) t1 tevent time
down up
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 23
Alternative: Dynamic voltage scaling
• Switching modes complicated by uncertainty how long a
sleep time is available
• Alternative: Low supply voltage & clock
• Dynamic voltage scaling (DVS)
• Rationale:
• Power consumption P
depends on
• Clock frequency
• Square of supply voltage
• P / f V2
• Lower clock allows
lower supply voltage
• Easy to switch to higher clock
• But: execution takes longer
Memory power consumption
• Crucial part: FLASH memory
• Power for RAM almost negligible
• FLASH writing/erasing is expensive
• Example: FLASH on Mica motes
• Reading: ¼ 1.1 nAh per byte
• Writing: ¼ 83.3 nAh per byte
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 25
Transmitter power/energy consumption for n bits
• Amplifier power: Pamp = amp + amp Ptx
• Ptx radiated power
• amp, amp constants depending on model
• Highest efficiency ( = Ptx / Pamp ) at maximum output power
• In addition: transmitter electronics needs power PtxElec
• Time to transmit n bits: n / (R ¢ R )
code
• R nomial data rate, R coding rate
code
• To leave sleep mode
• Time Tstart, average power P
start
! Etx = T P + n / (R ¢ R ) (PtxElec + amp + amp Ptx)
start start code
• Simplification: Modulation not considered
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 26
Receiver power/energy consumption for n bits
• Receiver also has startup costs
• Time Tstart, average power P
start
• Time for n bits is the same n / (R ¢ R )
code
• Receiver electronics needs PrxElec
• Plus: energy to decode n bits EdecBits
! Erx = T P + n / (R ¢ R ) PrxElec + EdecBits ( R )
start start code
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 27
Some transceiver numbers
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 28
Comparison: GSM base station power consumption
Heat 602W Heat 1920W Heat 360W
• Overview
DC power RF power
AC power TRX TOC RF
3200W 480W
3802W 2400W 120W
PS -48V
TRXs ACE
84% Combining
Central Heat 800W
CE equipm.
BTS 800W Total Heat
3682W
AC Power Rack Com-
• Details
supply cabling
300W mon
220V -48V -48V
85% 99%
3802W 3232W 3200W Fans (No active cooling)
cooling
PAs consume 2400W 500W
dominant part of power
12 transceivers
(12*140W)/2400W=70%
200W
idle
140W 60W
Usable PA efficiency Converter
• (just to put things
40W/140W=28% 85%
-48V/+27V
119W Bias
Erlang
into perspective) Overall efficiency
(12*10W)/3802W=3.1%
efficiency 75%
DTX activity
9W Combiner Diplexer
TOC
47% 110W
PA 10W
15W
40W
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 29
Controlling transceivers
• Similar to controller, low duty cycle is necessary
• Easy to do for transmitter – similar problem to controller: when is it
worthwhile to switch off
• Difficult for receiver: Not only time when to wake up not known, it
also depends on remote partners
! Dependence between MAC protocols and power consumption is
strong!
• Only limited applicability of techniques analogue to DVS
• Dynamic Modulation Scaling (DSM): Switch to modulation best
suited to communication – depends on channel gain
• Dynamic Coding Scaling – vary coding rate according to channel
gain
• Combinations
SS 05 Ad hoc & sensor networs - Ch 2: Single node architecture 30
Unit 3 - Ad hoc and Sensor
Networks Medium access
control protocols
Goals of this chapter
Controlling when to send a packet and when to listen for a
packet are perhaps the two most important operations in a
wireless network
Especially, idly waiting wastes huge amounts of energy
This chapter discusses schemes for this medium access
control that are
Suitable to mobile and wireless networks
Emphasize energy-efficient operation
Ad hoc & sensor networs - Ch 5: MAC protocols 2
Overview
Principal options and difficulties
Contention-based protocols
Schedule-based protocols
IEEE 802.15.4
3
Principal options and difficulties
Medium access in wireless networks is difficult mainly
because of
Impossible (or very difficult) to sende and receive at the same time
Interference situation at receiver is what counts for transmission
success, but can be very different from what sender can observe
High error rates (for signaling packets) compound the issues
Requirement
As usual: high throughput, low overhead, low error rates, …
Additionally: energy-efficient, handle switched off devices!
4
Requirements for energy-efficient MAC protocols
Recall
Transmissions are costly
Receiving about as expensive as transmitting
Idling can be cheaper but is still expensive
Energy problems
Collisions – wasted effort when two packets collide
Overhearing – waste effort in receiving a packet destined for
another node
Idle listening – sitting idly and trying to receive when nobody is
sending
Protocol overhead
Always nice: Low complexity solution
5
Main options
Wireless medium access
Centralized
Distributed
Schedule- Contention-
based based Schedule- Contention-
based based
Fixed Demand
assignment assignment Fixed Demand
assignment assignment
6
Centralized medium access
Idea: Have a central station control when a node may
access the medium
Example: Polling, centralized computation of TDMA schedules
Advantage: Simple, quite efficient (e.g., no collisions), burdens the
central station
Not directly feasible for non-trivial wireless network sizes
But: Can be quite useful when network is somehow divided
into smaller groups
Clusters, in each cluster medium access can be controlled
centrally – compare Bluetooth piconets, for example
! Usually, distributed medium access is considered
Ad hoc & sensor networs - Ch 5: MAC protocols 7
Schedule- vs. contention-based MACs
Schedule-based MAC
A schedule exists, regulating which participant may use which resource at
which time (TDMA component)
Typical resource: frequency band in a given physical space (with a given
code, CDMA)
Schedule can be fixed or computed on demand
Usually: mixed – difference fixed/on demand is one of time scales
Usually, collisions, overhearing, idle listening no issues
Needed: time synchronization!
Contention-based protocols
Risk of colliding packets is deliberately taken
Hope: coordination overhead can be saved, resulting in overall improved
efficiency
Mechanisms to handle/reduce probability/impact of collisions required
Usually, randomization used somehow
Ad hoc & sensor networs - Ch 5: MAC protocols 8
Overview
Principal options and difficulties
Contention-based protocols
MACA
S-MAC, T-MAC
Preamble sampling, B-MAC
PAMAS
Schedule-based protocols
IEEE 802.15.4
9
Distributed, contention-based MAC
Basic ideas for a distributed MAC
ALOHA – no good in most cases
Listen before talk (Carrier Sense Multiple Access, CSMA) –
better, but suffers from sender not knowing what is going on at
receiver, might destroy packets despite first listening for a
! Receiver additionally needs some possibility to inform
possible senders in its vicinity about impending
transmission (to “shut them up” for this duration)
Hidden
terminal Also:
scenario: recall
exposed
terminal
A B C D
scenario
SS 05 Ad hoc & sensor networs - Ch 5: MAC protocols 10
Main options to shut up senders
Receiver informs potential interferers while a reception is
on-going
By sending out a signal indicating just that
Problem: Cannot use same channel on which actual reception
takes place
! Use separate channel for signaling
Busy tone protocol
Receiver informs potential interferers before a reception
is on-going
Can use same channel
Receiver itself needs to be informed, by sender, about impending
transmission
Potential interferers need to be aware of such information, need
to store it
Receiver informs interferers before transmission – MACA
Sender B asks receiver C
whether C is able to receive a
transmission
Request to Send (RTS)
Receiver C agrees, sends out
a Clear to Send (CTS)
Potential interferers overhear
either RTS or CTS and know
about impending transmission
and for how long it will last
Store this information in a
Network Allocation Vector
B sends, C acks
! MACA protocol (used e.g. in
IEEE 802.11)
RTS/CTS
RTS/CTS ameliorate, but do not solve hidden/exposed
terminal problems
Example problem cases:
MACA Problem: Idle listening
Need to sense carrier for RTS or CTS packets
In some form shared by many CSMA variants; but e.g. not by busy
tones
Simple sleeping will break the protocol
IEEE 802.11 solution: ATIM windows & sleeping
Basic idea: Nodes that have data buffered for receivers send
traffic indicators at pre-arranged points in time
Receivers need to wake up at these points, but can sleep
otherwise
Parameters to adjust in MACA
Random delays – how long to wait between listen/transmission
attempts?
Number of RTS/CTS/ACK re-trials?
…
Sensor-MAC (S-MAC)
MACA’s idle listening is particularly unsuitable if average data rate is
low
Most of the time, nothing happens
Idea: Switch nodes off, ensure that neighboring nodes turn on
simultaneously to allow packet exchange (rendez-vous)
Only in these active periods,
packet exchanges happen
Need to also exchange
wakeup schedule between
neighbors
When awake, essentially
perform RTS/CTS
Use SYNCH, RTS, CTS
phases
S-MAC synchronized islands
Nodes try to pick up schedule synchronization from
neighboring nodes
If no neighbor found, nodes pick some schedule to start
with
If additional nodes join, some node might learn about two
different schedules from different nodes
“Synchronized islands”
To bridge this gap, it has to follow both schemes
A A A A A A
B B B B B
E
E E E E E E
C
C C C C
D Time
SS 05 Ad D D5: MAC protocols
hoc & sensor networs - Ch D 16
Timeout-MAC (T-MAC)
In S-MAC, active period is of
constant length A B C D
What if no traffic actually
happens? CTS
Nodes stay awake needlessly
long May not
Idea: Prematurely go back to send
sleep mode when no traffic has
happened for a certain time
(=timeout) ! T-MAC
Timeout,
Adaptive duty cycle!
go back to
One ensuing problem: Early sleep as
sleeping nothing
C wants to send to D, but is happened
hindered by transmission A! B
Two solutions exist – homework!
Preamble Sampling
So far: Periodic sleeping supported by some means to
synchronize wake up of nodes to ensure rendez-vous
between sender and receiver
Alternative option: Don’t try to explicitly synchronize nodes
Have receiver sleep and only periodically sample the channel
Use long preambles to ensure that receiver stays awake
to catch actual packet
Example: WiseMAC
Start transmission:
Long preamble Actual packet
Check Check Check Check
channel channel channel channel
Stay awake!
B-MAC
Combines several of the above discussed ideas
Takes care to provide practically relevant solutions
Clear Channel Assessment
Adapts to noise floor by sampling channel when it is assumed to
be free
Samples are exponentially averaged, result used in gain control
For actual assessment when sending a packet, look at five channel
samples – channel is free if even a single one of them is
significantly below noise
Optional: random backoff if channel is found busy
Optional: Immediate link layer acknowledgements for
received packets
B-MAC II
Low Power Listening (= preamble sampling)
Uses the clear channel assessment techniques to decide whether
there is a packet arriving when node wakes up
Timeout puts node back to sleep if no packet arrived
B-MAC does not have
Synchronization
RTS/CTS
Results in simpler, leaner implementation
Clean and simple interface
Currently: Often considered as the default WSN MAC
protocol
Power Aware Multiaccess with Signaling – PAMAS
Idea: combine busy tone with RTS/CTS
Results in detailed overhearing avoidance, does not address idle
listening
Uses separate data and control channels
Procedure
Node A transmits RTS on control channel, does not sense channel
Node B receives RTS, sends CTS on control channel if it can
receive and does not know about ongoing transmissions
B sends busy tone as it starts to receive data
Control RTS CTS Busy tone
channel A!B B!A sent by B
Time
Data Data
channel A!B
PAMAS – Already ongoing transmission
Suppose a node C in vicinity of A is already receiving a
packet when A initiates RTS
? B
Procedure C
A sends RTS to B A
C is sending busy tone (as it receives data)
CTS and busy tone collide, A receives no CTS, does not send data
Similarly: Ongoing
Busy tone by C transmission near B
Control RTS CTS destroys RTS by
channel A!B B !A busy tone
Time
Data No data!
channel
Overview
Principal options and difficulties
Contention-based protocols
Schedule-based protocols
LEACH
SMACS
TRAMA
IEEE 802.15.4
Low-Energy Adaptive Clustering Hierarchy (LEACH)
Given: dense network of nodes, reporting to a central sink,
each node can reach sink directly
Idea: Group nodes into “clusters”, controlled by
clusterhead
Setup phase; details: later
About 5% of nodes become clusterhead (depends on scenario)
Role of clusterhead is rotated to share the burden
Clusterheads advertise themselves, ordinary nodes join CH with
strongest signal
Clusterheads organize
CDMA code for all member transmissions
TDMA schedule to be used within a cluster
In steady state operation
CHs collect & aggregate data from all cluster members
Report aggregated data to sink using CDMA
LEACH rounds
SMACS
Given: many radio channels, superframes of known length
(not necessarily in phase, but still time synchronization
required!)
Goal: set up directional links between neighboring nodes
Link: radio channel + time slot at both sender and receiver
Free of collisions at receiver
Channel picked randomly, slot is searched greedily until a collision-
free slot is found
Receivers sleep and only wake up in their assigned time
slots, once per superframe
In effect: a local construction of a schedule
SMACS link setup
Case 1: Node X, Y both so far unconnected
Node X sends invitation message
Node Y answers, telling X that is
unconnected to any other node
Node X tells Y to pick slot/frequency for the
link
Node Y sends back the link specification
Case 2: X has some neighbors, Y not
Node X will construct link specification and
instruct Y to use it (since Y is unattached)
Case 3: X no neighbors, Y has some
Y picks link specification
Case 4: both nodes already have links
Nodes exchange their schedules and pick Message exchanges
free slots/frequencies in mutual agreement protected by
randomized backoff
TRAMA
Nodes are synchronized
Time divided into cycles, divided into
Random access periods
Scheduled access periods
Nodes exchange neighborhood information
Learning about their two-hop neighborhood
Using neighborhood exchange protocol: In random access
period, send small, incremental neighborhood update information
in randomly selected time slots
Nodes exchange schedules
Using schedule exchange protocol
Similar to neighborhood exchange
TRAMA – adaptive election
Given: Each node knows its two-hop neighborhood and
their current schedules
How to decide which slot (in scheduled access period) a
node can use?
Use node identifier x and globally known hash function h
For time slot t, compute priority p = h (x © t)
Compute this priority for next k time slots for node itself and all two-
hop neighbors
Node uses those time slots for which it has the highest priority
Priorities of t=0 t=1 t=2 t=3 t=4 t=5
node A and A 14 23 9 56 3 26
its two
B 33 64 8 12 44 6
neighbors B
&C C 53 18 6 33 57 2
TRAMA – possible conflicts
When does a node have to receive?
Easy case: one-hop neighbor has won a time slot and announced
a packet for it
But complications exist – compare example
What does B
believe?
A thinks it can send
B knows that D has
higher priority in its
2-hop
neighborhood!
Rules for resolving
such conflicts are
part of TRAMA
Comparison: TRAMA, S-MAC
Comparison between TRAMA & S-MAC
Energy savings in TRAMA depend on load situation
Energy savings in S-MAC depend on duty cycle
TRAMA (as typical for a TDMA scheme) has higher delay but
higher maximum throughput than contention-based S-MAC
TRAMA disadvantage: substantial memory/CPU
requirements for schedule computation
Overview
Principal options and difficulties
Contention-based protocols
Schedule-based protocols
IEEE 802.15.4
IEEE 802.15.4
IEEE standard for low-rate WPAN applications
Goals: low-to-medium bit rates, moderate delays without
too stringent guarantee requirements, low energy
consumption
Physical layer
20 kbps over 1 channel @ 868-868.6 MHz
40 kbps over 10 channels @ 905 – 928 MHz
250 kbps over 16 channels @ 2.4 GHz
MAC protocol
Single channel at any one time
Combines contention-based and schedule-based schemes
Asymmetric: nodes can assume different roles
IEEE 802.15.4 MAC overview
Star networks: devices are associated with coordinators
Forming a PAN, identified by a PAN identifier
Coordinator
Bookkeeping of devices, address assignment, generate beacons
Talks to devices and peer coordinators
Beacon-mode superframe structure
GTS assigned to devices upon request
Wakeup radio MAC protocols
Simplest scheme: Send a wakeup “burst”, waking up all
neighbors ! Significant overhearing
Possible option: First send a short filter packet that includes the
actual destination address to allow nodes to power off quickly
Not quite so simple scheme: Send a wakeup burst
including the receiver address
Wakeup radio needs to support this option
Additionally: Send information about a (randomly chosen)
data channel, CDMA code, … in the wakeup burst
Various variations on these schemes in the literature,
various further problems
One problem: 2-hop neighborhood on wakeup channel might be
different from 2-hop neighborhood on data channel
Not trivial to guarantee unique addresses on both channels
Further protocols
MAC protocols for ad hoc/sensor networks is one the most
active research fields
Tons of additional protocols in the literature
Examples: STEM, mediation device protocol, many CSMA variants
with different timing optimizations, protocols for multi-hop
reservations (QoS for MANET), protocols for multiple radio
channels, …
Additional problems, e.g., reliable multicast
This chapter has barely scratched the surface…
Summary
Many different ideas exist for medium access control in
MANET/WSN
Comparing their performance and suitability is difficult
Especially: clearly identifying interdependencies between
MAC protocol and other layers/applications is difficult
Which is the best MAC for which application?
Nonetheless, certain “common use cases” exist
IEEE 802.11 DCF for MANET
IEEE 802.15.4 for some early “commerical” WSN variants
B-MAC for WSN research not focusing on MAC
Ad hoc and Sensor Networks
: Routing protocols
Goals of this chapter
In any network of diameter > 1, the routing & forwarding
problem appears
We will discuss mechanisms for constructing routing tables
in ad hoc/sensor networks
Specifically, when nodes are mobile
Specifically, for broadcast/multicast requirements
Specifically, with energy efficiency as an optimization metric
Specifically, when node position is available
Overview
Unicast routing in MANETs
Energy efficiency & unicast routing
Multi-/broadcast routing
Geographical routing
Unicast, id-centric routing
Given: a network/a graph
Each node has a unique identifier (ID)
Goal: Derive a mechanism that allows a packet sent from
an arbitrary node to arrive at some arbitrary destination
node
The routing & forwarding problem
Routing: Construct data structures (e.g., tables) that contain
information how a given destination can be reached
Forwarding: Consult these data structures to forward a given
packet to its next hop
Challenges
Nodes may move around, neighborhood relations change
Optimization metrics may be more complicated than “smallest hop
count” – e.g., energy efficiency
Ad-hoc routing protocols
Because of challenges, standard routing approaches not
really applicable
Too big an overhead, too slow in reacting to changes
Examples: Dijkstra’s link state algorithm; Bellman-Ford distance
vector algorithm
Simple solution: Flooding
Does not need any information (routing tables) – simple
Packets are usually delivered to destination
But: overhead is prohibitive
! Usually not acceptable, either
! Need specific, ad hoc routing protocols
Ad hoc routing protocols – classification
Main question to ask: When does the routing protocol
operate?
Option 1: Routing protocol always tries to keep its routing
data up-to-date
Protocol is proactive (active before tables are actually needed) or
table-driven
Option 2: Route is only determined when actually needed
Protocol operates on demand
Option 3: Combine these behaviors
Hybrid protocols
Ad hoc routing protocols – classification
Is the network regarded as flat or hierarchical?
Compare topology control, traditional routing
Which data is used to identify nodes?
An arbitrary identifier?
The position of a node?
Can be used to assist in geographic routing protocols because
choice of next hop neighbor can be computed based on destination
address
Identifiers that are not arbitrary, but carry some structure?
As in traditional routing
Structure akin to position, on a logical level?
Proactive protocols
Idea: Start from a +/- standard routing protocol, adapt it
Adapted distance vector: Destination Sequence Distance
Vector (DSDV)
Based on distributed Bellman Ford procedure
Add aging information to route information propagated by distance
vector exchanges; helps to avoid routing loops
Periodically send full route updates
On topology change, send incremental route updates
Unstable route updates are delayed
… + some smaller changes
Proactive protocols – OLSR
Combine link-state protocol & topology control
Optimized Link State Routing (OLSR)
Topology control component: Each node selects a minimal
dominating set for its two-hop neighborhood
Called the multipoint relays
Only these nodes are used for packet forwarding
Allows for efficient flooding
Link-state component: Essentially a standard link-state
algorithms on this reduced topology
Observation: Key idea is to reduce flooding overhead (here by
modifying topology)
Proactive protocols – Combine LS & DS: Fish eye
Fisheye State Routing (FSR) makes basic observation:
When destination is far away, details about path are not
relevant – only in vicinity are details required
Look at the graph as if through a fisheye lens
Regions of different accuracy of routing information
Practically:
Each node maintains topology table of network (as in LS)
Unlike LS: only distribute link state updates locally
More frequent routing updates for nodes with smaller scope
Reactive protocols – DSR
In a reactive protocol, how to forward a packet to
destination?
Initially, no information about next hop is available at all
One (only?) possible recourse: Send packet to all neighbors –
flood the network
Hope: At some point, packet will reach destination and an answer
is sent pack – use this answer for backward learning the route
from destination to source
Practically: Dynamic Source Routing (DSR)
Use separate route request/route reply packets to discover route
Data packets only sent once route has been established
Discovery packets smaller than data packets
Store routing information in the discovery packets
DSR route discovery procedure
Search for route from 1 to 5
[1] [1,7]
1 2 2
1
[1] 7 7
[1,7]
5 5
4 3 4
6 3
6
[1,4]
2 1 2
1
[1,7,2] 7
7
[1,4,6] 5
5
4 4 3
3 6
6 [5,3,7,1]
[1,7,3]
Node 5 uses route information recorded in RREQ
to send back, via source routing, a route reply
DSR modifications, extensions
Intermediate nodes may send route replies in case they already know a
route
Problem: stale route caches
Promiscuous operation of radio devices – nodes can learn about
topology by listening to control messages
Random delays for generating route replies
Many nodes might know an answer – reply storms
NOT necessary for medium access – MAC should take care of it
Salvaging/local repair
When an error is detected, usually sender times out and constructs entire
route anew
Instead: try to locally change the source-designated route
Cache management mechanisms
To remove stale cache entries quickly
Fixed or adaptive lifetime, cache removal messages, …
Reactive protocols – AODV
Ad hoc On Demand Distance Vector routing (AODV)
Very popular routing protocol
Essentially same basic idea as DSR for discovery procedure
Nodes maintain routing tables instead of source routing
Sequence numbers added to handle stale caches
Nodes remember from where a packet came and populate routing
tables with that information
Reactive protocols – TORA
Observation: In hilly terrain, routing to a river’s mouth is
easy – just go downhill
Idea: Turn network into hilly terrain
Different “landscape” for each destination
Assign “heights” to nodes such that when going downhill,
destination is reached – in effect: orient edges between neighbors
Necessary: resulting directed graph has to be cycle free
Reaction to topology changes
When link is removed that was the last “outlet” of a node, reverse
direction of all its other links (increase height!)
Reapply continuously, until each node except destination has at
least a single outlet – will succeed in a connected graph!
Alternative approach: Gossiping/rumor routing
Turn routing problem around: Think of an “agent”
wandering through the network, looking for data (events, …)
Agent initially
perform random walk
Leave “traces” in the
network
Later agents can use
these traces to find
data
Essentially: works ?
due to high
probability of line
intersections
Overview
Unicast routing in MANETs
Energy efficiency & unicast routing
Multi-/broadcast routing
Geographical routing
Energy-efficient unicast: Goals
Particularly interesting performance metric: Energy efficiency
Goals 4
Minimize energy/bit A 2
3
Example: A-B-E-H 1
Maximize network 1
lifetime 2 C
3 B
Time until first node 2
D 1
failure, loss of
coverage, partitioning
2 4
Seems trivial – use 3 E 2
2 F
proper link/path metrics 1 G
2
(not hop count) and 2
4
standard routing H
Example: Send data from node A to node H
Basic options for path metrics
Maximum total available
battery capacity
Path metric: Sum of 4
battery levels A 2
Example: A-C-F-H 3
1
Minimum battery cost
routing 1
2 C
Path metric: Sum of B
reciprocal battery levels 3 2
Example: A-D-H D 1
Conditional max-min
battery capacity routing 2 4
2
Only take battery level 3 E 2 F
into account when below G
a given level 1 2
Minimize variance in 4 2
power levels
H
Minimum total
transmission power
A non-trivial path metric
Previous path metrics do not perform particularly well
One non-trivial link weight:
wij weight for link node i to node j
eij required energy, some constant, i fraction of battery of node i
already used up
Path metric: Sum of link weights
Use path with smallest metric
Properties: Many messages can be send, high network
lifetime
With admission control, even a competitive ratio logarithmic in
network size can be shown
Multipath unicast routing
Instead of only a single path, it can be useful to compute
multiple paths between a given source/destination pair
Disjoint paths Secondary path
Multiple paths
can be disjoint
or braided
Used
simultaneously,
alternatively, Source Sink
randomly, … Primary path
Braided paths
Source Sink
Primary path
Overview
Unicast routing in MANETs
Energy efficiency & unicast routing
Multi-/broadcast routing
Geographical routing
Broadcast & multicast (energy-efficient)
Distribute a packet to all reachable nodes (broadcast) or
to a somehow (explicitly) denoted subgroup (multicast)
Basic options
Source-based tree: Construct a tree (one for each source) to reach
all addressees
Minimize total cost (= sum of link weights) of the tree
Minimize maximum cost to each destination
Shared, core-based trees
Use only a single tree for all sources
Every source sends packets to the tree where they are distributed
Mesh
Trees are only 1-connected ! use meshes to provide higher
redundancy and thus robustness in mobile environments
Optimization goals for source-based trees
For each source, Steiner tree
minimize total cost Source Destination 2
2
This is the Steiner tree
problem again
2 1
Destination 1
For each source,
minimize maximum cost Shortest path tree
to each destination Source Destination 2
2
This is obtained by
overlapping the individual
2 1
shortest paths as
computed by a normal
routing protocol Destination 1
Summary of options (broadcast/multicast)
Broadcast Multicast
One tree Shared tree Mesh
per source (core-based tree)
Minimize Minimize Single Multiple
total cost cost to each node core core
(Steiner tree) (e.g., Dijkstra)
Wireless multicast advantage
Broad-/Multicasting in wireless is unlike broad-/multicasting
in a wired medium
Wires: locally distributing a packet to n neighbors: n times the cost
of a unicast packet
Wireless: sending to n neighbors can incur costs
As high as sending to a single neighbor – if receive costs are
neglected completely
As high as sending once, receiving n times – if receives are tuned to
the right moment
As high as sending n unicast packets – if the MAC protocol does not
support local multicast
! If local multicast is cheaper than repeated unicasts, then
wireless multicast advantage is present
Can be assumed realistically
Steiner tree approximations
Computing Steiner tree is NP complete
A simple approximation
Pick some arbitrary order of all destination nodes + source node
Successively add these nodes to the tree: For every next node,
construct a shortest path to some other node already on the tree
Performs reasonably well in practice
Takahashi Matsuyama heuristic
Similar, but let algorithm decide which is the next node to be added
Start with source node, add that destination node to the tree which
has shortest path
Iterate, picking that destination node which has the shortest path to
some node already on the tree
Problem: Wireless multicast advantage not exploited!
And does not really fit to the Steiner tree formulation
Broadcast incremental power (BIP)
How to broadcast, using the wireless multicast advantage?
Goal: use as little transmission power as possible
Idea: Use a minimum-spanning-tree-type construction
(Prim’s algorithm)
But: Once a node transmits at a given power level &
reaches some neighbors, it becomes cheaper to reach
additional neighbors
From BIP to multicast incremental power (MIP):
Start with broadcast tree construction, then prune unnecessary
edges out of the tree
BIP – Algorithm
BIP – Example
Round 1: A Round 2: A Round 3: A
5 3 4 3 2 3
S 1 B S (1) B S (3) B
10 9 7
3 7 2 7 7
D 1 D 1 D 1
Round 4: A Round 5: A
C C C
2 3 3
S (3) B S (5) B
7 10
6 7
D D
C (1) C (1)
Example for mesh-based multicast
Two-tier data dissemination
Overlay a mesh, route along mesh intersections
Broadcast within the quadrant where the destination is (assumed
to be) located
Sink
Event
Overview
Unicast routing in MANETs
Energy efficiency & unicast routing
Multi-/broadcast routing
Geographical routing
Position-based routing
Geocasting
Geographic routing
Routing tables contain information to which next hop a
packet should be forwarded
Explicitly constructed
Alternative: Implicitly infer this information from physical
placement of nodes
Position of current node, current neighbors, destination known –
send to a neighbor in the right direction as next hop
Geographic routing
Options
Send to any node in a given area – geocasting
Use position information to aid in routing – position-based
routing
Might need a location service to map node ID to node position
Basics of position-based routing
“Most forward within range r” strategy
Send to that neighbor that realizes the most forward progress
towards destination
NOT: farthest away
from sender!
Nearest node with (any) forward progress
Idea: Minimize transmission power
Directional routing
Choose next hop that is angularly closest to destination
Choose next hop that is closest to the connecting line to
destination
Problem: Might result in loops!
Problem: Dead ends
Simple strategies might send a packet into a dead end
Right hand rule to leave dead ends – GPSR
Basic idea to get out of a dead end: Put right hand to the
wall, follow the wall
Does not work if on some inner wall – will walk in circles
Need some additional rules to detect such circles
Geometric Perimeter State Routing (GPSR)
Earlier versions: Compass Routing II, face-2 routing
Use greedy, “most forward” routing as long as possible
If no progress possible: Switch to “face” routing
Face: largest possible region of the plane that is not cut by any edge
of the graph; can be exterior or interior
Send packet around the face using right-hand rule
Use position where face was entered and destination position to
determine when face can be left again, switch back to greedy routing
Requires: planar graph! (topology control can ensure that)
GPSR – Example
Route packet from node A to node Z
Leave face
routing
E I
B K
F H
Z
A D
Enter
J
face L
routing G
C
Geographic routing without positions – GEM
Apparent contradiction: geographic, but no position?
Construct virtual coordinates that preserve enough
neighborhood information to be useful in geographic
routing but do not require actual position determination
Use polar coordinates
from a center point
Assign “virtual angle
range” to neighbors of
a node, bigger radius
Angles are recursively
redistributed to
children nodes
GeRaF
How to combine position knowledge with nodes turning
on/off?
Goal: Transmit message over multiple hops to destination node;
deal with topology constantly changing because of on/off node
Idea: Receiver-initiated forwarding
Forwarding node S simply broadcasts a packet, without specifying
next hop node
Some node T will pick it up (ideally, closest to the source) and
forward it
Problem: How to deal with multiple forwarders?
Position-informed randomization: The closer to the destination a
forwarding node is, the shorter does it hesitate to forward packet
Use several annuli to make problem easier, group nodes according
to distance (collisions can still occur)
GeRaF – Example
A4
A3
A2
A1
1 D-1
40
D
Overview
Unicast routing in MANETs
Energy efficiency & unicast routing
Multi-/broadcast routing
Geographical routing
Position-based routing
Geocasting
41
Location-based Multicast (LBM)
Geocasting by geographically restricted flooding
Define a “forwarding” zone – nodes in this zone will forward
the packet to make it reach the destination zone
Forwarding zone specified in packet or recomputed along the way
Static zone – smallest rectangle containing original source and
destination zone
Adaptive zone – smallest rectangle containing forwarding node
and destination zone
Possible dead ends again
Adaptive distances – packet is forwarded by node u if node u is
closer to destination zone’s center than predecessor node v
(packet has made progress)
Packet is always forwarded by nodes within the destination
zone itself
42
Determining next hops based on Voronoi diagrams
Goal: Use that neighbor to forward packet that is closest to
destination among all the neighbors
Use Voronoi diagram computed for the set of neighbors of
the node currently holding the packet
S
D
A
43
Geocasting using ad hoc routing – GeoTORA
Recall TORA protocol: Nodes compute a DAG with
destination as the only sink
Observation: Forwarding along the DAG still works if
multiple nodes are destination (graph has multiple sinks)
GeoTORA: All nodes in the destination region act as sinks
Forwarding along DAG; all sinks also locally broadcast the packet
in the destination region
Remark: This also works for anycasting where destination
nodes need not necessarily be neighbors
Packet is then delivered to some (not even necessarily closest)
member of the group
44
Trajectory-based forwarding (TBF)
Think in terms of an “agent”: Should travel around the
network, e.g., collecting measurements
Random forwarding may take a long time
Idea: Provide the agent with a certain trajectory along
which to travel
Described,
e.g., by a
simple curve
Forward
to node closest
to this trajectory
45
Mobile nodes, mobile sinks
Mobile nodes cause Source
some additional problems
E.g., multicast tree to
distribute readings has to Sink moves
be adapted downward
Source
Source
Sink
moves
upward
46
Conclusion
Routing exploit various sources of information to find
destination of a packet
Explicitly constructed routing tables
Implicit topology/neighborhood information via positions
Routing can make some difference for network lifetime
However, in some scenarios (streaming data to a single sink),
there is only so much that can be done
Energy efficiency does not equal lifetime, holds for routing as well
Non-standard routing tasks (multicasting, geocasting)
require adapted protocols
47
Unit 4
Security in Wireless Sensor
Networks
Overview
• WSN security: Too many problems... A number of solutions...
Enough?
• Survey Paper: outlines security issues, discusses some existing
solutions, and suggests possible research directions
• Issues include:
– key establishment
– secrecy
– authentication
– privacy
– denial-of-service attacks More info in a later set of slides
– secure routing More info in a later set of slides
– node capture
• Also discuses some sample security services for wireless sensor
networks
Problems Applying Traditional Network Security
Techniques
• Sensor devices are limited in their energy,
computation, and communication capabilities
• Sensor nodes are often deployed in open
areas, thus allowing physical attack
• Sensor networks closely interact with their
physical environments and with people,
posing new security problems
Key Establishment and Trust
• Sensor devices have limited computational power,
making public-key cryptographic primitives too
expensive in terms of system overhead.
• Simplest solution is a network-wide shared key
– problem: if even a single node were compromised, the secret
key would be revealed, and decryption of all network traffic
would be possible
• Slightly better solution:
– use a single shared key to establish a set of link keys, one
per pair of communicating nodes, then erase the network-
wide key
– problem: does not allow addition of new nodes after initial
deployment
Key Establishment (continued)
• Bootstrapping keys using a trusted base
station
– Each node needs to share only a single key
with the base station and set up keys with
other nodes through the base station
– The base station becomes a single point of
failure
• Utilize tamper-resistant packaging for the base
station, reducing the threat of physical attack
• Most existing work assumes base station is safe
– Good assumption???
Random-key pre-distribution protocols
• Large pool of symmetric keys is chosen
• Random subset of the pool is distributed to each sensor node
• To communicate, two nodes search their pools for a common key
– If they find one, they use it to establish a session key
– Not every pair of nodes shares a common key, but if the key-
establishment probability is sufficiently high, nodes can
securely communicate with sufficiently many nodes to obtain
a connected network
• No need to include a central trusted base station
• Disadvantage: Attackers who compromised sufficiently many
nodes could also reconstruct the complete key pool and break
the scheme
Secrecy and Authentication
• We need cryptography as protection against
eavesdropping, injection, and modification of packets
• Trade-offs when incorporating cryptography into
sensor networks:
– end-to-end cryptography achieves a high level of security but
requires that keys be set up among all end points and be
incompatible with passive participation and local broadcast
– link-layer cryptography with a network-wide shared key
simplifies key setup and supports passive participation and
local broadcast, but intermediate nodes might eavesdrop or
alter messages
Hardware vs. Software Cryptography
• Hardware solutions are generally more efficient, but
also more costly ($)
• University of California, Berkeley, implementation of
TinySec incurs only an additional 5%–10%
performance overhead using software-only methods
– Most of the overhead is due to increases in packet size
– Cryptographic calculations have little effect on latency or
throughput, since they can overlap with data transfer
– Hardware reduces only the computational costs, not packet
size
• Thus, software-only techniques are sufficient (or
reasonable to be more careful)
Privacy
• Issues
– Employers might spy on their employees
– Shop owners might spy on customers
– Neighbours might spy on each other
– Law enforcement agencies might spy on
public places
• Technological improvements will only
worsen the problem
– Devices will get smaller and easier to
conceal
– Devices will get cheaper, thus surveillance
will be more affordable
Privacy (continued)
• Sensor networks raise new threats that are
qualitatively different from what private citizens
worldwide faced before
– Sensor networks allow data collection, coordinated analysis,
and automated event correlation
– Networked systems of sensors can enable routine tracking of
people and vehicles over long periods of time
– EZ Pass + OnStar == Big Brother?
• Suggested ways of approaching solution include a mix
of:
– Societal norms
– New laws
– Technological responses
Robustness to Denial of Service
• Simple form: Radio jamming
• Sophisticated form: Transmit while a
neighbor is also transmitting or continuously
generating a request-to-send signal
• Possible solution (when the jamming affects
only a portion of the network):
– Detect the jamming
– Map the affected region
– Route around the jammed area
Secure Routing
• Proper routing and forwarding are essential for
communication in sensor networks
• Injection attacks
– Transmit malicious routing information into the network
resulting in routing inconsistencies
– Authentication might guard against injection attacks, but
some routing protocols are vulnerable to replay by the
attacker of legitimate routing messages
• Sensor network routing protocols are particularly
susceptible to node-capture attacks
– Compromise of a single node could be enough to take over the
entire network or prevent any communication within it
Resilience to Node Capture
• In traditional computing, physical security is often
taken for granted
• Sensor nodes, by contrast, are likely to be placed in
open locations
– Attacker might capture sensor nodes
– Extract cryptographic secrets
– Modify programs/Replace them with malicious nodes
• Tamper-resistant packaging may be one defense, but
it’s expensive
Algorithmic Solutions
to Node Capture
• Attempt to build networks that operate
correctly even in the presence of nodes that
might behave in an arbitrarily malicious way
– Replicate state across the network and use
majority voting to detect inconsistencies
– Gather redundant views of the environment and
crosscheck them for consistency
• Most challenging problems in sensor network
security
– We are far from a complete solution
Network Security Services
• So far, we’ve explored low-level security
primitives for securing sensor networks.
• Now, we consider high-level security
mechanisms.
– Secure group management
– Intrusion detection
– Secure data aggregation
Secure Group Management
• Protocols for group management are
required to
– securely admit new group members
– support secure group communication
• Outcome of group computation must be
authenticated to ensure it comes from a
valid group
• Any solution must also be efficient in
terms of time and energy
Intrusion detection
• In wired networks, traffic and computation are typically
monitored and analyzed for anomalies at various
concentration points
– expensive in terms of the network’s memory and energy
consumption
– hurts bandwidth constraints
• Wireless sensor networks require a solution that is fully
distributed and inexpensive in terms of communication,
energy, and memory requirements
• In order to look for anomalies, applications and typical
threat models must be understood
• It is particularly important for researchers and
practitioners to understand how cooperating adversaries
might attack the system
• The use of secure groups may be a promising approach for
decentralized intrusion detection
Secure Data Aggregation
• One benefit of a wireless sensor network is the fine-grain
sensing that large and dense sets of nodes can provide
• The sensed values must be aggregated to avoid
overwhelming amounts of traffic back to the base station
• Depending on the architecture of the network, aggregation
may take place in many places
– All aggregation locations must be secured
• If the application tolerates approximate answers, powerful
techniques are available
– Randomly sampling a small fraction of nodes and checking
that they have behaved properly supports detection of
many different types of attacks
Conclusions
• Constraints and open environments of wireless sensor
networks make security for these systems challenging.
• Several properties of sensor networks may provide
solutions.
– architect security into these systems from the
outset (they are still in their early design stages)
– exploit redundancy, scale, and the physical
characteristics of the environment in the solutions
– build sensor networks so that they can detect and
work around some fraction of their nodes which are
compromised
Future Research Areas
• Securing wireless communication links against
– Eavesdropping
– Tampering
– Traffic analysis
– Denial of service
• Resource constraints
• Asymmetric protocols
– Most of the computation done at base station
• Public-key cryptographic systems
– How to make efficient on low-end devices?
• Working around the lack of physical security
– redundancy
– knowledge about the physical environment
Denial of Service in
Sensor Networks
Anthony D. Wood
and John A. Stankovic
Why Security?
• Battlefield
• Disasters
– Protect the location and status of casualties from
unauthorized disclosure, particularly if the disaster relates
to ongoing terrorist activities
• Public safety
– False alarms about chemical, biological, or environmental
threats could cause panic or disregard for warning systems.
An attack on the system’s availability could precede a real
attack on the protected resource
• Home healthcare
– Because protecting privacy is paramount, only authorized
users can query or monitor the network. These networks can
also form critical pieces of an accident-notification chain,
thus they must be protected from failure
DENIAL OF SERVICE THREAT
• A DoS attack is any event that diminishes or
eliminates a network’s capacity to perform its
expected function
• Hardware failures, software bugs, resource
exhaustion, environmental conditions, or their
combination
• Intentional Attack
Adversary Capability
• Physically damaged or manipulated node
– May be less powerful than a normally functioning
node
• Subverted nodes (or added ones)
– Interact with the network only through software
– As powerful as other nodes
• Immensely more powerful adversaries
– Existing wired network with virtually unlimited
computational and energy resources possible
Attacks on Physical Layer
• Jamming
– Defenses
• Spread-spectrum
• Region mapping: Less expensive
• Tampering
– Defenses: Tamper-proofing, hiding
Link Layer Attacks
• Collision
– Use error-correcting codes
• Exhaustion
– Rate limitation
• Unfairness
– Small frames
Network and Routing Attacks
• Neglect and greed
– Redundancy, probing
• Traffic analysis
– Encryption: enough? Maybe not
• Misdirection
– Egress filtering, authorization, monitoring
• Black holes
– Authorization, monitoring, probing,
redundancy
Neglect and Greed
• Neglect
– Drops packets arbitrarily
• Greed
– Gives undue priority to it’s own messages
• Use multiple paths and/or redundant
messages to mitigate these effects.
Traffic Analysis
• Geographic forwarding allows attacker to
figure out where important nodes are
• Encrypting headers as well as content might
alleviate this issue
• Cryptographic means may not help when the
communication pattern is many-to-one
– Just watch traffic intensity
– INSENS [ICDCS ‘03]
Misdirection
• Diverting traffic away from intended
destination
– Targets the sender
• Misdirecting many flows in one direction
– Targets an arbitrary victim (receiver)
• Defense
– Egress Filtering
• Verification of source addresses
• Legitimately generated from below?
Black Holes
• Distance-vector-based protocol weakness
• Nodes advertise zero-cost routes to every
other node.
• Fixes:
– Authorization
– Monitoring
• Watchdog the next hop transmission of your packets by
neighbors [Mobicom ’00]
– Probing
• Send periodic messages across topology to test for
blackout regions
– Redundancy
Transport Layer DoS
• Flooding
– Client puzzles
• Make the adversary commit resources
• Only useful if the adversary has limited
resources
• Desynchronization
– Authentication
PROTOCOL VULNERABILITIES to
DoS
Analyzing these vulnerabilities helps
show why developers should consider
DoS susceptibility at design time.
Adaptive Rate Control – MAC Protocol
by Woo & Cull
• Give preference to route-through traffic
– This preserves the network’s investment in packets
that may have already traversed many hops
• Makes flooding attacks more effective
– High bandwidth packet streams that an adversary
generates will receive preference
– Thus, the network gives preference to malicious
traffic
RAP
• Real-time communication architecture
– Geographic forwarding
– Velocity monotonic scheduling (VMS) policy
• Originator of message sets deadline and
destination
– VMS layer computes velocity based on time
to deadline and distance remaining
RAP Vulnerability
• Flood with high velocity packets
– Set destination at long distance
• Possibly outside the network
• Intermediate node adversary could lower the
velocity of route through traffic
– Causes deadline misses
• If relying on a synchronized clock, attacking
that mechanism could cause another node to
always drop
– Protecting clock synchronization is a challenging
yet important problem by itself
Secure Routing in Wireless Sensor
Networks: Attacks and
Countermeasures
Key Contributions
• Secure routing issues in WSNs
– Show how they are different from ad hoc
networks
– Introduce two new classes of attacks
• Sinkhole attack
• Hello flood attack
• Analyze security aspects of major routing
protocols
• Discuss countermeasures & design
considerations for secure routing in WSNs
WSNs vs. Ad Hoc Networks
• Multi-hop wireless communications
• Ad hoc nets: communication between two
arbitrary nodes
• WSNs
– Specialized communication patterns
• Many-to-one
• One-to-many
• Local communication
– More resource constrained
– More trust needed for in-network processing,
aggregation, duplicate elimination
Assumptions
• Insecure radio links
• Malicious nodes can collude to attack
the WSN
• Sensors are not tamper-resistant
• Adversary can access all key material,
data & code
• Aggregation points may not be
trustworthy
• Base station is trustworthy
Threat Models
• Device capability
– Mote class attacker
– Laptop class attacker: more energy, more
powerful CPU, sensitive antenna, more radio
power
• Attacker type
– Outside attacker: External to the network
– Inside attacker: Authorized node in the
WSN is compromised or malicious
Security Goals
• Secure routing
– Support integrity, authenticity, availability
of messages in presence of attack
– Data confidentiality
Potential Attacks
• Attacks on general WSN routing
• Attacks on specific WSN protocols
Attacks on General WSN Routing
Protocols
• Spoof, alter, or replay routing info.
– Create loops, attack or repel network
traffic, partition the network, attract or
repel network traffic, etc.
– Message authentication can partly handle
these issues
• Selective forwarding
– Malicious node selectively drops incoming
packets
Sinkhole attack
• Specific to WSNs
– All packets are directed to base station
– A malicious node advertises a high quality
link to the base station to attract a lot of
packets
– Enable other attacks, e.g., selective
forwarding or wormhole attack
Sybil attack
• A single node presents multiple ID’s to other
nodes
• Affect geographic routing, distributed
storage, multi-path routing, topology
maintenance
Wormhole attack
• Two colluding nodes
• A node at one end of the wormhole
advertises high quality link to the base
station
• Another node at the other end receives
the attracted packets
Hello flood attack
• Specific to WSNs
– In some protocols, nodes have to periodically
broadcast “hello” to advertise themselves
• Not authenticated!
– Laptop-class attacker can convince it’s a neighbor
of distant nodes by sending high power hello
messages
Acknowledge spoofing
• Adversary spoofs ACKs to convince the
sender a weak/dead link support good
link quality
Attacks on Specific Routing Protocols
• TinyOS beaconing
– Construct a BFS rooted at the base station
– Beacons are not authenticated
– Adversary can take over the whole WSN by
broadcasting beacons
Directed diffusion
• Replay interest
• Selective forwarding & data tampering
• Inject false data
Geographic routing
• Adversary can provide false, possibly
multiple, location info.
– Create routing loop
– GEAR considers energy in addition to
location
• Laptop-class attacker can exploit it
Countermeasures
• Shared key & link layer encryption
– Prevent outsider attacks, e.g., Sybil attacks, selective
forwarding, ACK spoofing
– Cannot handle insider attacks
• Wormhole, Hello flood, TinyOS beaconing
• Sybil attack
– Every node shares a unique secret key with the base station
– Create pairwise shared key for msg authentication
– Limit the number of neighbors for a node
• Hello flood attack
– Verify link bidirectionality
– Doesn’t work if adversary has very sensitive radio
Countermeasures
• Wormhole, sinkhole attack
– Cryptography may not help directly
– Good routing protocol design
– Geographic routing
• Geographic routing
– Location verification
– Use fixed topology, e.g., grid structure
• Selective forwarding
– Multi-path routing
– Route messages over disjoint or Braided paths
– Dynamically pick next hop from a set of candidates
– Measure the trustworthiness of neighbors
Countermeasures
• Authenticated broadcast
– uTESLA
• Base station floods blacklist
– Should be authenticated
– Adversaries must not be able to spoof
Conclusions
• WSN security is challenging, new area
of research
• #Problems >> #Solutions
• Any ideas to address a problem?
Unit 5
Sensor Network
Platforms and Tools
Introduce
WSNs are subject to
Energy, Bandwidth, Computation, Storage, Real-
time constraints, Ad hoc deployment, Frequently
changing network topology
Different from traditional distribution systems
WSNs can hardly assume an always-on
infrastructure.
Introduce
There two types of programming for WSNs
End users: query to get data from WSNs
Application developers: provide end users of a
sensor network with the capabilities of data
acquisition, processing, and storage.
This chapter focuses on software design
issues.
Introduction
7.1 Sensor Node Hardware
7.2 Sensor Network Programming
Challenges
7.3 Node-Level Software Platforms
7.4 Node-Level Simulators
7.5 State-Centric Programming
7.6 Summary
7.1 Sensor Node Hardware
Sensor node hardware can be grouped into
three categories
Augmented general-purpose computers
Dedicated embedded sensor nodes
System-on-chip (SoC)
Berkley motes due to their small form factor,
open source software development, and
commercial availability, have gained wide
popularity in the sensor network research
community.
Augmented general-purpose
computers
Off-the-shelf operating systems such as
WinCE, Linux and with standard wireless
communication protocols such as 802.11 or
Bluetooth.
Relatively higher processing capability
More power hungry
Fully supported popular programming
languages
Ex: PDAs
Dedicated embedded sensor
nodes
In order to keep the program footprint small
to accommodate their small memory size,
programmers of these platforms are given full
access to hardware but barely any operating
system support.
Typically support at least one programming
language, such as C.
Ex: mica, TinyOS, nesC
System-on-chip (SoC)
Build extremely low power and small footprint
sensor nodes that still provide certain sensing,
computation, and communication capabilities.
Currently in the research pipeline with no
predefined instruction set, there is no
software platform support available.
Berkley motes
Mica mote
Two-cpu design
Main microcontroller (MCU), Atmel
Much less capable coprocessor, only active when the MCU
is being reprogrammed.
Memory inside the MCU
512KB flash memory
4KB data memory
A separate 512KB flash memory unit that can hold
data.
50kbps raw data rate (40kbps transmission rate)
300 feet (90m)
Mica mote
Fig7.2
Mica mote
51 pin I/O extension connector
Sensor board
Temperature, light, accelerometer, magnetometer,
microphone, beeper
Communicate with a PC in real time through
serial I/O(UART)
Parallel connection is primarily for download
programs
Mica mote
Transmission bears the maximum power
consumption
Energy-saving
Suspend the MCU and the RF receiver as long as
possible
Mica mote
Fig7.3
7.2 Sensor Network
Programming Challenges
Event-driven execution allows the system to
fall into low-power sleep mode when no
interesting events need to be processed.
At the extreme, embedded operating systems
tend to expose more hardware controls to the
programmers, who now have to directly face
device drivers and scheduling algorithms,
and optimize code at the assembly level.
7.3 Node-level software
platforms
Node-centric design methodologies:
Programmers think in terms of how a node
should behave in the environment.
A node-level platform can be a node-centric
OS, which provides hardware and networking
abstractions of a sensor node to
programmers.
7.3.1 TinyOS
No file system
Static memory allocation: analyzable, reduce
memory management overhead
Only parts of OS are compiled with the
application
TinyOS
A program executed in TinyOS has two
contexts, tasks and events.
Tasks are posted by components to a task
scheduler. Without preempting or being
preempted by other tasks
Triggered events can be preempted by other
events and preempt tasks
TinyOS
Split-phase operation
Command send() event sendDone()
Avoid blocking the entire system
Not accepting another packet Until sendDone() is
called, avoid race condition
7.3.2 Imperative Language:
nesC
nesC is an extension of C to support the design of
TinyOS.
A component has an interface specification and an
implementation.
A component specification is independent of the
component implementation.
A provides interface is a set of method calls
exposed to the upper layers.
A uses interface is a set of method calls hiding the
lower layer components.
nesC
Fig7.7,7.8
nesC
An event call is a method call from a lower
layer component to a higher layer component.
(signal)
A command is the opposite. (call)
A component may use or provide the same
interface multiple times. Give each interface
instance a separate name using as notation.
nesC– component
implementation
There are two types of components in nesC,
depending on how they are implemented:
modules and configurations.
Modules are implemented by application
code.
Configurations are implemented by
connecting interfaces of existing components.
A.a=B.a, the interface a of A is the interface a of B
A.a->B.a, interface is hidden from upper layers
nesC
fig7.9,7.10
Error?
HWClock
nesC
An application must contain the Main module
which links the code to the scheduler at run
time.
The Main has a single StdControl interface,
which is the ultimate source of initialization of
all components.
nesC—concurrency and
atomicity
A keyword atomic to indicate that the
execution of a block of statements should not
be preempted.
Method calls are not allowed in atomic block.
A shared variable x is outside of an atomic
statement is a compile-time error.
A norace declaration of the variable can
prevent the compiler from checking the race
condition on that variable.
nesC—concurrency and
atomicity
Fig7.11
7.3.3 Dataflow-style language:
TinyGALS
Dataflow languages are intuitive for
expressing computation on interrelated data
units by specifying data dependencies among
them.
A data flow program has a set of processing
units called actors.
Actors have ports to receive and produce
data.
TinyGALS
Fig
7.13,14,15
Queue size
7.4~7.6
Node-Level Simulators
For engineer to perform performance study,
which in terms of
Power
Bandwidth
Etc
Node-Level Simulators (2)
Simulators are consisted by the following
models
Sensor node model
Communication model
Physical environment model
Statistics and visualization
Time concept
A sensor network simulator simulates the
behavior of sensor network with respect to
time
In which, time may advance in differ ways:
cycle-driven or discrete-event.
Cycle-driven simulation
A cycle-driven (CD) discretize the continuous
real time into ticks
Simulator computes phenomenon at each
tick. Like: physical environment, sensing data,
communication data, etc.
Communication by RF is assumed to be
finished in a tick.
Cycle-driven simulation cont.
CD simulators are easy to implement and use
Most CD simulators issue are detecting and
dealing cycle dependencies among nodes
(ex: RF) or algorithms (ex: Thread).
Discrete-event simulation
Discrete-event (DE) simulator assumes the
time is continuous.
Usually use a Global event queue to store
events.
All events are stored chronologically in the
Global event queue.
Example figure
Sending a big file(1MB), 0.1MB/s max.
CD
Ticks
DE
Comparison
DE simulators are considered as better than
CD simulators, because they are more actual.
But they’re more complex to design and
implement.
Most popular sensor network simulators are
DE simulators, like TOSSIM and NS2.
Ns2 + Sensor network
Ns2 was meant to be wired network simulator,
so extensions are being made for wireless
(802.11,TDMA) and sensor networks.
Ns2 + Sensor network cont.
Protocol supported:
802.3
802.11
TDMA
Ad hoc routing
Sensor network routing
TOSSIM
Which is dedicated to TinyOS applications to
running on Motes.
With some visualization packet, the TinyViz.
Result can be plot in some more
understandable graphs.
State-Centric Programming
Applications that isn’t just simply generic
distributed programs over an ad hoc network.
We have to centralize data into nodes.
EX: target tracking.
State-Centric Programming
Def:
X: state of a system
U: inputs
Y: outputs
K: update index
F: state update function
G: output observation function
State-Centric Programming
Xk+1 = F( Xk, Uk )
Yk = G( Xk ,Uk)
In state-centric programming, X and K come
from many nodes. So many issue are
discussed.
State-Centric Programming
Where are the state vars stored?
Where do the inputs com from?
Where do the outputs go?
Where are the functions f and g evaluated?
How long does the acquisition of inputs take?
Collaboration Group
Which is a set of entities to update data.
Protocol example:
Geographically constrained group
N-hop neighborhood group
Publish/Subscribe group
Acquaintance group
Mixing
Geographically constrained
group
Since some phenomenon will be sensed in a
area, GCG is useful.
By broadcasting from one specific sensor,
those have heard the packet will become the
same group.
N-hop neighborhood group
An anchor sets the hop limit and
broadcasting it. Those who heard and is
under the limit will become the same group.
0-hop: itself
1-hop: neighbors one hop away
Publish/Subscribe group
Dynamically defined by the requirement
Only those have interested data will become
the same group.
Acquaintance group
More dynamically, nodes will be invited to join
a group. They can also quit.
Group leader is selected beforehand, uses a
ad hoc routing method to retrieve data from
other nodes, then decide which one to invite.
Collaboration Group
Simulator: PIECES (Programming and
Interacting Environment for Collaborative
Embedded Systems)
Summary
Overview of software and hardware of sensor
network.
Most software are tightly bounded with
specific hardware. A generic and high
performance simulator is expected
Programming methodologies are so
important to sensor network, like VHDL and
Verilog served the VLSI.