MODULE-2

OR
Energy Consumption of Sensor
Nodes
 Power States of Sensor Nodes
• Active (Pactive): Sensor is working and
consuming full power
• Sleep (Psleep): Sensor is resting to save
energy
• Goal: Switch to sleep mode when idle to
avoid wasting energy
 Why Sleep Mode?
• If sensor remains active while waiting →
energy wasted
• Sleep mode helps save energy until the next
event
• Example: Between two events, node can sleep
instead of idling
 Switching Costs (Overheads)
• To enter sleep → takes time (tdown) and
energy(average)
• To wake up → takes time (tup) and energy
• These costs = Eoverhead
• Sleep is useful only if Esaved > Eoverhead

Once event to be processed occurs, an additional overhead is incurred.

 When is Sleep Beneficial?
• Sleep mode saves energy only if waiting time
is long enough
• Condition: (tevent – t1) > Switching Overhead
Time
• Otherwise, energy is wasted in switching
 Microcontroller Energy Consumption
• Controllers have multiple operational states
• Dynamic Voltage Scaling (DVS): run at lower
speeds to save energy
• Choose speed carefully: must meet deadlines
while reducing power
 Memory Consumption
• On-chip memory → energy-efficient, used
most often
• Off-chip memory → rarely used, consumes
more energy
• Reading memory uses similar energy across
types
• Writing to Flash memory is expensive (erase +
write cycles)
• Minimize writes for better energy efficiency
 Radio Transceivers
• A radio transceiver sends and receives data between sensor
nodes.
• To save energy, transceivers stay off most of the time and are
activated only when needed.
• They usually work at a low duty cycle (short active time, long
sleep time).
• However, switching them on/off introduces extra time, energy,
and complexity overheads.
• Energy use must be modeled per bit for sending and receiving
data.
Power Consumption of Sensors and Actuators
•Power use depends on the type of sensor or
actuator.
•Passive sensors (like light or temperature)
consume very little energy (often negligible).
•Active devices (like sonar) consume a lot
more energy.
•For such devices, power demand must be
considered carefully when designing sensor
nodes and batteries.
•To estimate energy use correctly, one must
consider both the application scenario and
the types of sensors used.
 Summary
• Sleep mode saves energy if idle time >
switching overhead
• Microcontrollers save energy with Dynamic
Voltage Scaling (DVS)
• On-chip memory is more efficient than off-
chip
• Minimize Flash memory writes to reduce
energy use
 OR
Operating Systems and Execution
Environments in WSNs
OS: An Operating System (OS) is a system software that
acts as an intermediary between computer hardware and
application programs.
Key roles of an OS:
Controls hardware – manages CPU, memory, disk, sensors, etc.
Runs applications – platform to use software like browsers, games, or Word.
Manages resources – decides which program gets how much memory or processor
time.
Handles input/output – manages things like keyboard, mouse, screen, and network.
Provides security – controls who can access files, apps, or devices.
 Introduction, Embedded OS
•Traditional OS tasks:
•Control and protect access to resources (including CPU,M, I/O).
•Manage allocation of resources to different users.
•Support concurrent execution of processes (allows multiple tasks
(programs/processes) to work seemingly at the same time) and inter-
process communication (process need to share data or talk to each
other).
•Embedded systems (like WSNs) differ:
•Only some OS tasks are needed because code is restricted and well-
harmonized.
•Lack resources to support a full-fledged operating system.
•Requirements for WSN operating systems/execution environments:
•Must support energy-efficient execution (e.g., controlled shutdown,
Dynamic Voltage Scaling - DVS).
•Should efficiently handle external components (sensors, radio modem,
timers).
•Must manage asynchronous events occurring at arbitrary times.
 Programming Paradigms
Concurrent Programming in WSNs:
• Sensor nodes must handle data from many sources (sensors, radio) at unpredictable
times.
• A simple step-by-step (sequential) model can cause missed data or packets,
especially if one task takes too long.

Process-based Programming:
• Process-based concurrency (running multiple processes in parallel) works in general
OS, but in WSNs it creates problems:
• Too much overhead from frequent task switching.
• Each process needs memory for its own stack, which is limited in sensor nodes.
 Event-based Programming
System waits for events: sensor data, packet arrival, timers.
Event handlers: records the information, non-blocking.
Actual processing is done separately.
Performance gains: 8× faster, 2×–30× less instructions/memory, 12× less power.

Event-based Programming Model

 API & Interfaces
Interfaces to the Operating System (OS):
Interfaces let the system’s internal state be checked or modified.
In WSNs, protocol stacks and applications often overlap, so
interfaces must allow components to interact.
These interfaces are provided through APIs (Application
Programming Interfaces), which include:
Abstractions: links, nodes, etc.
Functions: check/set state, send/receive data, access
hardware (sensors, actuators, radios).
Policies: balance energy use vs. performance.
No universal standard API exists yet; current systems mostly rely
on de facto standards.
 Protocol Stack Structure
Structure of OS and Protocol Stack (WSN context):
Traditionally, protocols are organized in layers, each depending only on the
layer below. This makes systems modular, reusable, and easy to manage.
In WSNs, keeping the protocols separate is not always efficient.
For example:
The physical layer measures signal strength.
Normally, this info stays only in the physical layer.
But in WSNs, this same info is very useful for other tasks like:
Routing (choosing the best path if a signal is getting weaker).
Localization (estimating distance between nodes).
So instead of restricting data to one layer, WSNs benefit from cross-layer
sharing, where information can flow between layers to improve performance.
WSNs often use a component model:
Large layers are broken into small, reusable components (modules).
Components interact freely (not just with neighbors) through defined
interfaces.
This suits event-based programming in WSNs.
Example: TinyOS uses component wiring for event exchange. For flexible
communication (like receiving signal strength only when needed), a blackboard
model (publish/subscribe) helps by loosely coupling components.
 Dynamic Energy & Power
Management
•Goal: Save energy in Wireless Sensor Networks (WSNs) by managing how
components (CPU, sensors, memory, radio) switch between active and sleep states.
•Challenge: Switching between states takes both time and energy, so decisions must
be smart rather than immediate.
Key Techniques:
[Link] Power Management (DPM):
•OS, protocol stack, or applications decide when to put components into low-
power states.
•Uses algorithms to balance energy savings vs. the risk of missing events.
[Link] State Transition Policies:
•Predict when the next event may occur using probability models.
•Choose the deepest possible sleep state without missing important tasks.
[Link] Voltage Scaling (DVS):
•Adjust CPU clock speed and voltage depending on workload.
•Needs smart schedulers to balance deadlines, performance, and energy use.
[Link] Accuracy for Energy:
•Some tasks don’t always need 100% accuracy.
•WSNs can save energy by computing approximate results first and refining them
if energy remains.
•Example: Polynomial calculation where partial results still provide useful
 Case Study – TinyOS & nesC
TinyOS: lightweight event-driven OS for WSNs
nesC: programming language for TinyOS
Features: modular components, event-command model, FIFO scheduler
Benefits: efficient concurrency, energy-aware scheduling
 Key Terminologies
•Concurrent execution: For example, while you are listening to music, you can also
browse the internet and download a file.
•The CPU quickly switches between these tasks, giving the impression that they are
running simultaneously.
•Controlled shutdown: Switching off unused parts of a device to save energy
• DVS: Dynamic Voltage Scaling (DVS)
• Adjusting the voltage and speed of the processor based on the work it is doing.
• High voltage/speed → for heavy tasks.
• Low voltage/speed → for light tasks → saves battery.
• Example: Your laptop CPU slows down when you are just typing, but speeds up when you
play a game.
• Event-based programming: The system essentially waits for any event to happen, where
an event typically can be the availability of data from a sensor, the arrival of a packet, or
the expiration of a timer. Such an event is then handled by a short sequence of
instructions that only stores the fact that this event has occurred and stores the necessary
information– for example, a byte arriving for a packet or the sensor’s value– somewhere.
The actual processing of this information is not done in these event handler routines, but
separately, decoupled from the actual appearance of events.
Network Scenarios
Basic Scenarios in WSN
1. Types of Sources and Sinks

Three types of sinks in a very simple, single-hop sensor network

2. Single-hop vs Multi-hop Networks
 Multi-hop Networks
• To overcome such limited distances it better to use relay stations. The
data packets taking multi hops from source to the sink.
• Multi-hopping improves the energy efficiency of communication as it
consumes less energy to use relays instead of direct communication, the
radiated energy required for direct communication over a distance d is
cdα (c some constant, α≥ 2 the path loss coefficient) and using a relay at
distance d/2 reduces this energy (to 2c(d/2)α).
• Multi-hop networks operating in a store and forward fashion are
considered. In such a network, a node has to correctly receive a packet
before it can forward it somewhere.
3. Multiple Sinks and Multiple Sources
4. Three Types of Mobility
Node Mobility
WSN Sink Mobility
Sink Mobility
 Event/Object Mobility: Track the pink
elephant
• In tracking applications, the objects/events to be tracked can be mobile.
• Important that the observed event is covered by a sufficient number of sensors at
all time.
• As the event source moves through the network, it is accompanied by an area of
activity within the network –frisbee model. This notion is described by Figure
below, where the task is to detect a moving elephant and to observe it as it moves
around.
Event Mobility
 Design Principles of WSNs
•Main Design and Optimization goals of WSN:
•Quality of Service (QoS) support
•Energy efficiency
•Scalability
•These goals don’t directly explain how to structure the
network to achieve them.
•A few basic design principles have been identified for
developing networking protocols.
•Distributed organization principle:
•WSNs should avoid a single centralized controller (like a base
station) because it creates failure points and is hard to implement in
limited-range radio networks (WSNs).
•Instead, nodes should self-organize using distributed algorithms
and protocols.
•Centralized vs Distributed trade-off:
•Centralized systems can sometimes be more efficient and
resource-saving (small, stable, central controller with strong resources).
•To combine benefits, localized centralization can be used by
electing certain nodes temporarily to act as coordinators.
•Dynamic hierarchy:
•Elected coordinator nodes should change over time to prevent
overloading or energy drain.
•Continuous reelection ensures robustness and balances resource
usage.
 In-Network Processing
• Def: Nodes in a wireless sensor network (WSN) don’t just forward data
but also process data inside the network to improve efficiency.
• Goal: Reduce communication overhead, save energy, and enhance
application performance.
• Key Techniques of In-Network Processing
• Aggregation
– Combines data from multiple nodes (e.g., average, min, max) instead
of sending all raw data.
– Reduces the number of transmissions → saves energy.
– Example: Instead of sending all temperature readings, send only the
average.
 In-Network Processing..
Distributed Source Coding / Compression
Instead of each sensor sending all of its raw data to the sink, sensors take
advantage of the fact that their readings are often similar (correlated).
This similarity (correlation) can be in space (nearby sensors record similar
values) or in time (a sensor’s data doesn’t change much between
measurements).
Based on the Slepian-Wolf theorem, even if sensors compress their data
independently, the sink can still reconstruct the full information as long as
correlations are exploited.
For example:
Two sensors measuring temperature in the same room will record almost
the same values.
Instead of sending both full readings, one can send its raw data, and the
other can send only the difference or compressed version.
Reduces communication cost – fewer bits are transmitted.
Saves energy – transmitting data consumes more power than processing.
Maintains accuracy – even though data is compressed, the sink reconstructs the
original values.
 In-Network Processing
•Distributed and Collaborative Signal Processing
•Complex tasks (e.g., FFT, beamforming, target tracking) are split
across multiple sensor nodes.
• In WSNs, distributed computation of FFT splits the work across multiple
sensor nodes instead of sending all raw data to one central node.
• If all data is sent to one place → high communication cost (more energy
wasted in transmitting).
• If part of the data is processed locally at each node → less data needs to
be transmitted, reducing energy use.
• This balance between local computation (which uses little energy) and
communication cost (which uses high energy) makes the system more
energy-efficient overall.
•Inspired by parallel computing but optimized for energy efficiency.
 In-Network Processing
•Mobile Code / Agent-Based Networking
•Small pieces of code (agents) move from node to node, process
data locally, then decide the next step(switch to which node, forward
the results/ do further processing of data) .
•Inspired by software agents and swarm intelligence.
•Used in WSNs for tasks like query routing and data fusion
• Why use Mobile Agents?
• Query Routing
– Suppose you want to ask all nodes in a forest WSN: "What is the
temperature above 35°C?"
– Instead of every node sending back data (which consumes a lot of
energy), the mobile agent moves node to node, gathers only the
relevant answers, and sends back one optimized result.
– This reduces network traffic and energy use.
• Data Fusion
– In WSNs, multiple sensors may detect the same event (e.g., fire,
intruder, or sound).
– A mobile agent can visit those nodes, combine (fuse) the data (e.g.,
take average, filter duplicates, confirm the event), and send only one
meaningful report.
– This avoids redundancy and improves accuracy.
 Adaptive Fidelity and Accuracy in
WSNs
• Idea: The accuracy of results (fidelity) in WSNs should adapt based on available
energy and network conditions(Bandwidth).
• In WSN, fidelity = accuracy/quality of data collected, & reported.
• Sensors use energy to sense, process, and transmit.
• With enough energy & good connectivity, sensors send high-accuracy, frequent
data. If the device battery is high, it sends heart rate every second.
• With low energy or poor network, fidelity is reduced (fewer, less precise, or
aggregated data) to save energy and extend network life. If the battery is low, it
may send only average heart rate every 5 minutes.

• Mechanism:
– More sensors → higher accuracy but more energy use.
– Applications must define acceptable accuracy levels (even if approximate).
– Communication protocols should achieve this accuracy in an energy-efficient way.
• Adaptation Factors:
– Number of active/failed nodes.
– Energy availability (battery or energy harvesting).
– Environmental/operational conditions (e.g., critical events).
 Adaptive Fidelity in WSN
• Why this is important?
– Energy saving → prolongs network lifetime.
– Adaptability → ensures that even with limited resources,
the system still works.
– Efficient use of network → avoids congestion when
bandwidth is low.
 Data-Centricity in WSNs
• In WSNs, the focus is on data rather than the
identity of nodes.
• Applications request information like “presence of
elephant” or “temperature in a room” instead of
addressing specific sensor nodes.
• This approach simplifies communication,
supports in-network processing (aggregation,
fusion), and improves scalability and energy
efficiency.
Implementation Options of Data-Centric
Networking
1. Overlay Networks
– An overlay network is a virtual network built on top of a physical network.
– Nodes are connected logically (not necessarily by direct physical links).
– Example: Distributed file sharing — even if two computers are not physically close, they can be part of
a logical overlay network.
2. Distributed Hash Tables (DHTs)
– A DHT is a distributed system that stores and retrieves data using (key → value) pairs.
– Each node in the network is responsible for a portion of the key space.
– To find data, you look up the key, and the DHT efficiently routes the request to the node that stores
the value.
– Key advantage: Efficient data lookup (usually in O(log N) hops for N nodes).
3. Why This Matters for Wireless Sensor Networks (WSNs)
– Wireless Sensor Networks are resource-constrained:
– Nodes have limited energy, processing power, and memory.
– Network topology changes often (nodes die, move, or links fail).
– Communication cost (hop count, energy spent on transmissions) is critical.
– So, when applying DHTs in WSNs, special considerations are needed:
– Hop count minimization → Reduce the number of transmissions to save energy.
– Topology awareness → Must adapt to frequent changes in the network structure.
– Lightweight protocols → Classic DHTs (like Chord) may be too heavy; simplified or energy-aware
versions are required.
 Implementation Options of Data-
Centric Networking
• Publish/Subscribe:
– Nodes subscribe to certain data/events (e.g., “elephant
detected”).
– Other nodes publish relevant data when available.
– Supports decoupling in time and identity.
• Database Approach:
– Treats WSNs like a virtual database where queries (e.g.,
SQL) can extract sensor data.
– Execution plans are distributed while considering
communication costs
 Key terminologies
•Exploit Location Information
•Use sensor node/event location data in protocols.
•Helps simplify design, improve efficiency, and save energy.
•Exploit Activity Patterns
•WSN traffic is often irregular: long idle times, sudden bursts (event shower effect).
•Protocols must adapt between low activity and high activity modes.
•Exploit Heterogeneity
•Nodes may differ by design (battery size, range, processing power) or by evolution
(energy depletion, environment).
•Assign tasks asymmetrically: powerful nodes handle heavy tasks (aggregation, long-
distance comms).
•Requires dynamic task reassignment as conditions change.
•Component-Based Protocol Stacks & Cross-Layer Optimization
•Prefer modular, component-based protocol design over rigid layered models.
•Provide a “toolbox” of basic components (e.g., MAC, routing, synchronization,
localization).
•Enable cross-layer information exchange for optimization.
•Self-organise:
•Decide locally what to do (when to send data, how to route packets, how to save energy).
•Work together with neighboring nodes by following common rules, algorithms, and protocols.
•Self-organize into a functioning network without human intervention or a central boss.
• centralized systems can sometimes be more efficient and resource-saving in the
following situations:
• Small-scale networks
– If the number of nodes is small and all nodes are within direct communication range of a
central controller (like a base station).
– Example: A few sensors in a smart home system.
• Stable network topology
– When the nodes are fixed (not mobile) and the network structure rarely changes, so re-
organizing isn’t needed often.
• Abundant resources at the central node
– If the central controller (like a gateway or sink) has high processing power and energy, it can
handle tasks more efficiently than tiny sensor nodes.
• Applications needing global view
– Some tasks (like data fusion, complex analysis, or global optimization) are easier when all data
is collected and processed in one place.
• Low-latency decision-making
– In cases where quick, centralized decisions are more efficient than waiting for multiple
distributed negotiations.
• Energy efficiency
• Communication is costly in WSNs. Processing data at the node and sending only
results saves energy.
 Gateways:The Need for Gateways in
WSNs
• A WSN alone is insufficient; it must interact with external
devices (e.g., PDAs, remote users, or the Internet).
• Gateways enable this interaction by connecting WSNs to
other networks, especially the Internet.
 The Need for Gateways in WSNs
• On lower layers (Physical/MAC/Link):
– Mobile devices or gateways can use the same WSN transceiver, or
– Some WSN nodes can support standard wireless technologies (e.g., IEEE
802.11).
• Design considerations:
– Trade-offs between using multi-technology sensor nodes
(Zigbee+Wifi+Bluetooth→ Direct interoprabilty, High cost, consumes high
E, No Gateway) vs. adapting mobile devices(mobile phones/tablets) act
as bridge, cheaper and energy-efficient, but depends on user devices
(less reliable if mobile is not always available).
• Gateway design challenges:
– A simple router approach (using Internet protocols directly in WSN) is
not efficient.
– WSNs need application-level gateways that use optimized, WSN-specific
protocols.
– The gateway must make decisions at the application level depending on
where the communication originates (from sensor side or Internet side).
 A simple router approach (using Internet protocols directly in WSN) is
not efficient
• 1. Resource Constraints
– WSN nodes are tiny devices with limited memory, processing power, and energy.
– TCP/IP protocols are heavyweight (require large headers, retransmissions, etc.).
– Running them directly would quickly drain batteries and overload sensor nodes.
• 2. Overhead of Protocols
– Internet protocols are designed for powerful devices and reliable links (e.g., laptops, routers).
– WSN links are unreliable, low-bandwidth, and lossy.
– The extra control packets (handshakes, acknowledgments) waste bandwidth and E.
• 3. Scalability Issues
– WSNs may have thousands of nodes.
– Assigning unique IP addresses and running full routing tables is too complex and storage-heavy for
sensors.
• 4. Different Requirements
– Internet traffic cares about throughput & reliability.
– WSN traffic cares about energy efficiency, data aggregation, and latency for events.
– Thus, optimized protocols (like 6LoWPAN, RPL, CoAP) are preferred instead of plain TCP/IP.
• 5. Optimized Protocols for WSNs
– Protocols like 6LoWPAN compress IPv6 packets to fit into tiny WSN frames.
– RPL (Routing Protocol for Low-power and Lossy Networks) ensures efficient routing with low energy
use.
– CoAP (Constrained Application Protocol) replaces heavy HTTP with a lighter, sensor-friendly alternative.
 Why Gateway needs application-level decisions
• A gateway in a Wireless Sensor Network (WSN) acts as a bridge between the sensor nodes
and the Internet. Communication can come from two directions:
• From the sensor side (WSN → Internet):
– The gateway receives raw sensor data.
– It must process, filter, or translate this data into Internet-compatible formats (e.g.,
HTTP, MQTT).
– It decides what information is important enough to forward, to save bandwidth and
energy.
• From the Internet side (Internet → WSN):
– The gateway receives requests or commands (e.g., “turn on the light” or “send
temperature readings every 5 minutes”).
– It must translate these into WSN-specific protocols that sensor nodes understand.
– It decides how to distribute these instructions efficiently across the network.
• Why application-level decisions are needed:
• Protocols, priorities, and data handling are different on both sides.
• The gateway must adapt communication to the needs of each side instead of just passing
data blindly.
• So, the gateway doesn’t just forward packets like a router—it interprets, translates, and
optimizes data flow depending on where the communication starts.
Gateways: WSN to Internet Communication
• Routing to Gateways: Sensor nodes must find a gateway that connects the
WSN to the Internet, combining routing and service discovery.
• Multiple Gateways: If several gateways exist, the system must decide
which one to use, possibly preferring specific gateways depending on the
destination.
• Overlay Networks: An IP overlay network can be built on top of the WSN
to manage multi-gateway communication.
• Addressing Issues: Sensor nodes need a way to map semantic notions
(e.g., “Turn off lights") to concrete IP addresses.
• Gateway Translation: Even if sensor nodes cannot handle IP protocols
directly, they must embed sufficient addressing info (IP, port). Gateways
then extract and translate this into proper IP packets.
• NAT-like Functionality: Gateways act like Network Address Translation
(NAT) devices, handling source addresses and forwarding data correctly to
the Internet.
 Internet to WSN Communication

When a device on the Internet wants to access a WSN, two situations can happen:
Direct communication (simple case):
If the Internet device (like a smartphone) has the WSN transceiver and WSN
protocols, it can directly join the WSN and talk to sensors.

Remote communication (general case):

If the device is far away and cannot directly connect to the WSN, it must use a
gateway.
The gateway acts as a bridge between the Internet and the WSN.
Steps involved:
Service discovery: The Internet device must first find out whether a WSN exists
at the target location and which gateway provides access.
Accessing services: Instead of contacting individual sensors (which may not even
have IP addresses), the device sends a request to the gateway.
The gateway works as a proxy, translating Internet-style requests into WSN-
specific protocols and then returning the results.
 Internet to WSN Communication

• Why a gateway is better:

– The Internet user does not need to worry about
details like multi-hop routing inside the WSN.
– Communication becomes application-focused (what
data/service is needed) instead of node-focused
(which sensor to contact).
• Protocols and standards:
– Application-level protocols (like Web Services, WSDL)
can describe and expose WSN services in a way that
Internet devices and browsers can understand.
– These may also allow specifying details like accuracy,
energy use, or type of data.
 WSN Tunnelling

•WSN tunneling connects separate Wireless Sensor Networks (WSNs)

via gateways, creating a larger “virtual” WSN.
•Mechanism:
•Protocol messages are transparently tunneled between WSNs using the Internet as a
transport network.
•This makes physically separated WSNs appear as one unified system.
•Forms of tunneling:
•Fixed network connections.
•Mobile nodes (e.g., people carrying devices) can also provide temporary
interconnections.
1. Application-level protocol requirement
1. Needed for remote requester–gateway communication.
2. Should be simpler and more Internet-friendly than WSN protocols.
3. Remote terminal shouldn’t deal with multi-hop routes or be treated as
“just another hop.”
2. Relation to Web Service Protocols
1. Parallels exist with WSDL (Web Service Description Language).
2. Can be extended with attributes like accuracy, energy trade-offs, and
data-centric descriptions.
3. Could allow access via standard web browsers.
3. Middleware integration
1. Open research area: integrating WSN with middleware architectures.
2. A general-purpose WSN service interface (like Web services) could
standardize remote access.
 Optimization Goals and Figures of Merit
• Figures of merit: measurable performance metrics used to evaluate how well the
network meets its optimization goals (like QoS, energy efficiency, scalability, and
robustness)
1. Quality of Service (QoS) in WSNs
-WSNs(move bits from one place to another) differ from traditional networks: focus is
on event-driven communication instead of continuous data flow.
-QoS can be seen in 2 ways:
Low-level (network-observable): bandwidth, delay, jitter, packet loss.
High-level (user-observable): perceived quality of event detection/reporting.

•Bandwidth: The maximum amount of data that can be transmitted over a network in a given time
(usually measured in bits per second).
Think of it as the width of a highway — wider means more cars (data) can pass at once.
•Delay (Latency): The time it takes for data to travel from the sender to the receiver across the
network.
Example: the lag you notice in online gaming or video calls.
•Jitter: The variation in packet arrival time. Even if average delay is fine, irregular delays can cause
problems in real-time apps like voice or video.
Example: choppy audio during a call.
•Packet Loss: The percentage of data packets that never reach their destination.
Optimization goals and Figure of Merit
QoS Metrics in WSNs:
• Event detection/reporting probability → probability that an event
actually occurred is not detected and reported to the sink node.
For ex, not reporting a fire alarm to a surveillance station would be
a severe shortcoming.
• Event classification error → Events not only to be detected, but
also to be classified, accuracy of event classification must be high.
The WSN network must classify whether the event is a “forest
fire” or just “campfire smoke.
• Event detection delay → what is the time from detection of event
to reporting to sink.
• Missing reports → Applications that require periodic reporting, the
probability of undelivered reports should be small.
• Approximation accuracy → error in function approximation (e.g
approximating the temperature as a function of location for a given
area).
• Tracking accuracy →Tracking applications must not miss an object
to be tracked, the reported position should be as close to the real
position as possible, and the error should be small.
Optimization goals and Figure of Merit
2. Energy Efficiency
- Energy is a critical resource in WSNs, so energy efficiency is a key goal.
- While more energy can improve most QoS metrics, accuracy also depends
on network density.
- Energy efficiency means balancing QoS delivered with energy consumed.
-Metrics for Energy Efficiency:
• Energy per correctly received bit → energy needed to deliver one bit of
useful data.(How much energy, counting all sources of energy consumption at all
possible intermediate hops, is spent on average to transport one bit of information
(payload) from the source to the destination?)

• Energy per reported unique event → Average energy required to report

one unique event. Since the same event is sometimes reported from
various sources.

• Delay/energy trade-offs → notion of “urgent” events, which can justify an

increased energy investment for a speedy reporting of such events. Here,
the trade-off between delay and energy overhead is interesting.
Optimization goals and Figure of Merit
Network lifetime → duration the network remains functional, possible
definitions are:
• Time to first node death-When does the first node in the network
run out of energy or fail.

• Network half-life (When have 50% nodes dead/stop working).

• Time to partition (network splits into disconnected parts)-When

does the first partition of the network in two (or more)
disconnected parts occur?

• Time to loss of coverage (no sensor covers a region) -the time

when for the first time any spot in the deployment region is no
longer covered by any node’s observations.

• Time to failure of first event notification-the inability to deliver an

event. This can be due to an event not being noticed because the
responsible sensor is dead or because a partition between source
and sink has occurred.
Optimization goals and Figure of Merit

3. Scalability
- WSNs can have thousands of nodes, so scalability is essential.
- Performance should remain stable as network size increases.
- Scalability challenges:
Avoid reliance on global states (like large routing tables).
Protocols must adapt depending on network size.
- Trade-offs: smaller networks may allow more efficient solutions,
while large networks demand scalable protocols.

4. Robustness
- WSNs must tolerate node failures and environmental changes.
- Should adapt via alternative communication routes.
 Service interfaces of WSNs
• Structuring Application/Protocol Stack Interfaces:
• In WSNs, an application is another component within
the operating system and protocol stack (e.g.,
TinyOS). This allows applications to directly interact
with other components, even integrating at different
layers of protocol stack. The advantage is flexibility:
developers can insert application-specific code at
various points and choose protocols (e.g., routing)
best suited for the task.
• However, this flexibility has risks—giving
programmers direct control over protocol stacks can
lead to complexity and errors. Traditional networks
like the Internet avoid this by using standardized
interfaces such as sockets, which clearly define how
applications send, receive, and manage connections.
 Expresibility requirements for WSN
service interfaces
• Security needs and properties must be clearly stated.
When designing WSN service interfaces, it’s
important to clearly state security needs. Even if
security features are not part of the main service, it’s
helpful to add extra management options, such as
the ability to update components, within the
interface.
• Thus, two design choices exist:
• Tight integration – applications as components
within the stack, offering fine-grained
optimization but requiring expertise.
• Service interface – abstraction that hides
complexity, allowing applications to express
sensing tasks in higher-level, semantic terms (Ex.
Bank ATM).
 Expressibility requirements for WSN
service interfaces
• Synchronous event notification: Retrieving a
measured value and send it immediately or
periodically.
• Asynchronous event notification: Retrieving measured
value when ever an event occurs.
• In-network processing must be accessible for
operations involving groups of nodes, particularly
when reading values synchronously or
asynchronously. Applications should be able to specify
the type of processing, especially when results are
altered (e.g., data fusion).
 Expresibility requirements for WSN
service interfaces
• When using aggregation functions, we choose how
accurate the result should be (like how many members
contribute or how much we compress). The more
accuracy we want, the more energy or resources need
to spend to get it.
• Timeliness refers to how quickly data is delivered. For
instance, a result can be sent faster but at higher
energy cost(by forcing all the nodes to wakeup earlier
than they would wake up) or slowly but at reduced
energy costs.
• Whenever data is exchanged, the trade-off between
speed and energy use should be clearly stated.
 Expresibility requirements for WSN
service interfaces
• Sometimes, we need to access details like a node’s location,
timing, network status, or even its available energy through the
service interface.
• To easily connect different nodes or networks and access
services in a new or unfamiliar network, we need a clear
description of what each node or network can do—for example,
what physical parameters it can sense or what devices it can
control. Sgroi et al. [751] suggest creating a “concept repository”
to store this information.
 Discussion

• Designing service interfaces for WSNs is difficult due to data-centricity, energy

trade-offs, and accuracy requirements. Existing approaches include:
• Client/Server models (Sgroi et al.) – flexible but limited in in-network processing,
energy control, and protocol choice.
• Publish/Subscribe & Database models – closer to needs but require extensions
for accuracy and event handling (e.g., DSWare).
• Mobile Agent systems (SensorWare) – provide flexibility but are low-level.
• Application-specific systems (EnviroTrack) – efficient for object tracking.
• Modeling/Markup approaches (SensorML, DAML) – describe sensor capabilities
and accuracy explicitly.
• Conclusion: Current interfaces are either too heavy or too limited. A better balance
between usability, performance, and safe protocol interaction is still needed.