Chapter 3
An Application Metrics Estimation Model for Embedded Wireless Sensor Networks*
Advancements in semiconductor technology, as predicted by Moore's law, have enabled high transistor density in a small chip area resulting in the miniaturization of embedded systems (e.g., sensor nodes). Wireless sensor networks (WSNs) are envisioned as ubiquitous computing systems, which are proliferating in many application domains (e.g., defense, health care, surveillance systems) each with varying application requirements that can be defined by high-level application metrics (e.g., lifetime, reliability). However, the diversity of WSN application domains makes it difficult for commercial off-the-shelf (COTS) sensor nodes to meet these application requirements.
Since COTS sensor nodes are mass-produced to optimize cost, many COTS sensor nodes possess tunable parameters (e.g., processor voltage and frequency, sensing frequency), whose values can be tuned for application specialization [69]. The WSN application designers (those who design, manage, or deploy the WSN for an application) are typically biologists, teachers, farmers, and household consumers that are experts within their application domain, but have limited technical expertise. Given the large design space and operating constraints, determining appropriate parameter values (operating state) can be a daunting and/or time-consuming task for nonexpert application managers. Typically, sensor node vendors assign initial generic tunable parameter value settings; however, no one tunable parameter value setting is appropriate for all applications. To assist the WSN managers with parameter tuning to best fit the application requirements, an automated parameter tuning process is required.
Application metrics estimation for distributed EWSNs is still in infancy. Only a few lifetime estimation model exists for distributed EWSNs [70–72]; however, these models either do not consider low-level sensor node tunable parameters or only consider a few low-level sensor node tunable parameters. Furthermore, existing models for distributed EWSNs focus mainly on networking issues in distributed EWSNs as opposed to embedded issues (e.g., processor, transceiver, sensors) in an embedded sensor node. Moreover, the literature does not discuss application metrics estimation model for other application metrics apart from lifetime such as throughput and reliability.
In this chapter, we propose an application metrics estimation model that estimates high-level application metrics from low-level sensor node tunable parameters and the sensor node's hardware internals (e.g., transceiver voltage, transceiver receive current). Dynamic optimization methodologies for distributed EWSNs (discussed in Part three of this book) leverage this estimation model while comparing different operating states for optimization purposes.
Application metrics estimation modeling has a broad impact on EWSN design and deployment. Our application metrics estimation model provides a first step toward high-level metrics estimation from sensor node tunable parameters and hardware internals. The estimation model establishes a relationship between sensor node operating state and high-level metrics. Since application managers typically focus on high-level metrics and are generally unaware of low-level sensor node internals, this model provides an interface between the application manager and the sensor node internals. Additionally, our model can potentially spark further research in application metrics estimation for EWSNs.
This chapter's highlights are as follows:
- Proposal of an application metrics estimation model that estimates high-level application metrics (lifetime, throughput, and reliability) from low-level sensor node tunable parameters and the sensor node's hardware internals (e.g., transceiver voltage, transceiver receive current).
- Examples demonstrating the estimation process of application metrics using the proposed model.
The remainder of this chapter is organized as follows. Section 3.1 describes our application metrics estimation model that is leveraged by various dynamic optimization methodologies for distributed EWSNs. Experimental results are presented in Section 3.2. Finally, Section 3.3 concludes this chapter.
3.1 Application Metrics Estimation Model
This section presents our application metrics estimation model, which is leveraged by our dynamic optimization methodology. This estimation model estimates high-level application metrics (lifetime, throughput, reliability) from low-level tunable parameters and sensor node hardware internals. The use of hardware internals isappropriate for application metrics modeling as similar approaches have been used in the literature especially for lifetime estimation [70–72]. Based on tunable parameter value settings corresponding to an operating state and hardware specific values, the application metrics estimation model determines the corresponding values for high-level application metrics. These high-level application metric values are then used in their respective objective functions to determine the objective function values corresponding to an operating state (e.g., lifetime estimation model determines 
(lifetime offered by state 
), which is then used in the lifetime objective function to determine the lifetime objective function value). This section presents a complete description of our application metrics estimation model, including a review of our previous application metrics estimation model [73] and additional details.
3.1.1 Lifetime Estimation
A sensor node's lifetime is defined as the time duration between sensor node deployment and sensor node failure due to a wide variety of reasons (e.g., battery depletion, hardware/software fault, environmental damage, external destruction). Lifetime estimation models typically consider battery depletion as the cause of sensor node failure [74]. Since sensor nodes can be deployed in remote and hostile environments, manual battery replacement after deployment is often impractical. A sensor node reaches the failed or dead state once the entire battery energy is depleted. The critical factors that determine a sensor node's lifetime are battery energy and energy consumption during operation.
The sensor node lifetime in days 
can be estimated as
where 
denotes the sensor node's battery energy in joules and 
denotes the sensor node's energy consumption per hour. The battery energy in milliwatt hour 
can be given by
where 
denotes battery voltage in volts and 
denotes battery capacity, typically specified in milliampere hour. Since 1 J = 1 W s, 
can be calculated as
The sensors in the sensor node gather information about the physical environment and generate continuous sequences of analog signals/values. Sample-and-hold circuits and analog-to-digital (A/D) converters digitize these analog signals. This digital information is processed by a processor, and the results are communicated to other sensor nodes or a base station node (sink node) via a transmitter. The sensing energy is the energy consumed by the sensor node due to sensing events. The processing energy is the energy consumed by the processor to process the sensed data (e.g., calculating the average of the sensor values over a time interval or the difference between the most recent sensor values and the previously sensed values). The communication energy is the energy consumed due to communication with other sensor nodes or the sink node. For example, sensor nodes send packets containing the sensed/processed data information to other sensor nodes and the sink node, which consumes communication energy.
We model 
as the sum of the processing energy, communication energy, and sensing energy, that is,
where 
, 
, and 
denote the sensing energy per hour, processing energy per hour, and communication energy per hour, respectively.
The sensing (sampling) frequency and the number of sensors attached to the sensor board (e.g., the MTS400 sensor board [75] has Sensirion SHT1x temperature, and humidity sensors [76]) are the main contributors to the total sensing energy. Our model considers energy conservation by allowing sensors to switch to a low power, idle mode while not sensing. 
is given by
where 
denotes the sensing measurement energy per hour and 
denotes the sensing idle energy per hour. 
can be calculated as
where 
denotes the number of sensing measurements per second, 
denotes the sensing board voltage, 
denotes the sensing measurement current, and 
denotes the sensing measurement time. 
can be calculated as
where 
denotes the number of sensors on the sensing board and 
denotes the sensing frequency. 
is given by
where 
denotes the sensing sleep current and 
denotes the sensing idle time. 
is given by
We assume that the sensor node's processor operates in two modes: active mode and idle mode [77]. The processor operates in active mode while processing the sensed data and switches to the idle mode for energy conservation when not processing. The processing energy is the sum of the processor's energy consumption while operating in the active and the idle modes. We point out that although we only consider active and idle modes, a processor operating in additional sleep modes (e.g., power-down, power-save, and standby) can also be incorporated in our model. 
is given by
where 
and 
denote the processor's energy consumption per hour in the active and idle modes, respectively. 
is given by
where 
denotes the processor voltage, 
denotes the processor active mode current, and 
denotes the time spent by the processor in the active mode. 
can be estimated as
where 
denotes the average number of processor instructions to process one sensing measurement and 
denotes the processor frequency. 
can be estimated as
where 
denotes the average number of processor instructions to process 1 bit and 
denotes the sensing resolution bits (number of bits required for storing one sensing measurement).
is given by
where 
denotes the processor idle mode current and 
denotes the time spent by the processor in the idle mode. Since the processor switches to the idle mode when not processing sensing measurements, 
can be given as
The transceiver (radio) is the main contributor to the total communication energy consumption. The transceiver transmits/receives data packets and switches to the idle mode for energy conservation when there are no more packets to transmit/receive. The number of packets transmitted (received) and the packets' transmission (receive) interval dictate the communication energy. The communication energy is the sum of the transmission, receive, and idle energies for the sensor node'stransceiver, that is,
where 
, 
, and 
denote the transceiver's transmission energy per hour, receive energy per hour, and idle energy per hour, respectively. 
is given by
where 
denotes the number of packets transmitted per hour and 
denotes the transmission energy per packet. 
can be calculated as
where 
denotes the packet transmission interval in seconds (1 h = 3600 s). 
is given as
where 
denotes the transceiver voltage, 
denotes the transceiver current, and 
denotes the time to transmit one packet. 
is given by
where 
denotes the packet size in bytes and 
denotes the transceiver data rate (in bits per second).
The transceiver's receive energy per hour 
can be calculated using a similar procedure as 
. 
is given by:
where 
denotes the number of packets received per hour and 
denotes the receive energy per packet. 
can be calculated as
where 
denotes the packet receive interval in seconds. 
can be calculated as
where 
denotes the number of neighboring sensor nodes. 
is given as
where 
denotes the transceiver's receive current and 
denotes the time to receive one packet. Since the packet size is the same, the time to receive a packet is equal to the time to transmit the packet, that is, 
.
can be calculated as
where 
denotes the transceiver's sleep current and 
denotes the transceiver's idle time per hour. 
can be calculated as
3.1.2 Throughput Estimation
Throughput is defined as the amount of work processed by a system in a given unit of time. Defining throughput semantics for sensor nodes is challenging because three main components contribute to the throughput, sensing, processing, and communication (transmission), and these throughput components can have different significance for different applications. Since these throughput components are related, one possible interpretation is to take the throughput of the lowest throughput component as the effective throughput. However, the effective throughput may not be a suitable metric for a designer who is interested in throughputs associated with all three components.
In our model, we define the aggregate throughput as the combination of the sensor node's sensing, processing, and transmission rates to observe/monitor a phenomenon (measured in bits per second). The aggregate throughput can be considered as the weighted sum of the constituent throughputs. Our aggregate throughput model can be used for the effective throughput estimation by assigning a weight factor of 1 to the slowest of the three components and assigning a weight factor of 0 to the others. Since aggregate throughput modeling allows flexibility and can be adapted to varying needs of a WSN designer, we focus on modeling of the aggregate throughput. We model aggregate throughput as
where 
, 
, and 
denote the sensing, processing, and communication throughputs, respectively, and 
, 
, and 
denote the associated weight factors.
The sensing throughput, which is the throughput due to sensing activity, depends on the sensing frequency and sensing resolution bits per sensing measurement. 
is given by
where 
denotes the sensing frequency.
The processing throughput, which is the processor's throughput while processing sensed measurements, depends on the processor frequency and the average number of instructions required to process the sensing measurement. 
is given by
The communication throughput, which measures the number of packets transferred successfully over the wireless channel, depends on the packet size and the time to transfer one packet. 
is given by
where 
denotes the effective packet size excluding the packet header overhead (i.e., 
, where 
denotes the packet header size).
3.1.3 Reliability Estimation
The reliability metric measures the number of packets transferred reliably (i.e., error-free packet transmission) over the wireless channel. Accurate reliability estimation is challenging due to dynamic changes in the network topology, number of neighboring sensor nodes, wireless channel fading, sensor network traffic, packet size, and so on. The two main factors that affect reliability are transceiver's transmission power 
and receiver sensitivity. For example, the AT86RF230 transceiver [78] has a receiver sensitivity of 
101 dB m with a corresponding packet error rate (PER) 
1% for an additive white Gaussian noise (AWGN) channel with a physical service data unit (PSDU) equal to 20 bytes. Reliability can be estimated using Friis free space transmission equation [79] for different 
values, distance between transmitting and receiving sensor nodes, and assumptions on fading model parameters (e.g., shadowing fading model). Different reliability values can be assigned corresponding to different 
values such that the higher 
values give higher reliability; however, more accurate reliability estimation requires using profiling statistics for the number of packets transmitted and the number of packets received. These profiling statistics increase the estimation accuracy of the PER and, therefore, reliability.
3.1.4 Models Validation
Our models provide good accuracy in estimating application metrics since our models accommodate many sensor node hardware internals such as the battery voltage, battery capacity, sensing board voltage, sensing sleep current, sensing idletime, and sensing resolution bits and so on. Our models are also highly flexible since our models permit calculations for particular network settings such as the number of neighboring sensor nodes and different types of sensors with different hardware characteristics (e.g., sensing resolution bits, sensing measurement time, sensing measurement current).
Since our models provide a first step toward modeling application metrics, our models' accuracy cannot be completely verified against other models because there are no similar/related application metrics estimation models. The existing models for lifetime estimation take different parameters and have different assumptions, thus an exact comparison is not feasible; however, we observe that our lifetime model yields result in a similar range as other models [70–72]. We also compare the lifetime estimation from our model with an experimental study on WSN lifetimes [74]. This comparison verifies conformity of our lifetime model with real measurements. For example, with a sensor node battery capacity of 2500 mA h, experiments indicate a sensor node lifetime ranging from 72 to 95 h for a 100% duty cycle for different battery brands (e.g., Ansmann, Panasonic Industrial, Varta High Energy, Panasonic Extreme Power) [74]. Using our model with a duty cycle of 36% on average for the sensing, processing, and communication, we calculated that a lifetime of 
can be attained. Similarly, for a duty cycle of 0.25% on average for the sensing, communication, and processing, the lifetime can be calculated as 
(e.g., lifetime calculations using our model is given in Section 3.2.2.1).
The relative comparison of our models with existing models and real measurements provide insights into the accuracy of our models; however, more accurate models can be constructed following our modeling approach by considering additional parameters and more detailed hardware models for sensor nodes.
3.2 Experimental Results
In this section, we describe the experimental setup and results obtained from our application metrics estimation model.
3.2.1 Experimental Setup
Our experimental setup is based on the Crossbow IRIS mote platform [80] with a battery capacity of 2000 mA h using two AA alkaline batteries. The IRIS mote platform integrates an Atmel ATmega1281 microcontroller [77], an MTS400 sensor board [75] with Sensirion SHT1x temperature and humidity sensors [76], and an Atmel AT86RF230 low-power 2.4- GHz transceiver [78]. Table 3.1 showsthe hardware-specific values of the sensor node, corresponding to the IRIS mote platform, which are used by the application metrics estimation model [76–78, 80].
Table 3.1 Crossbow IRIS mote platform hardware specifications
| Notation | Description | Value |
 |
Battery voltage | 3.6 V |
 |
Battery capacity | 2000 mA h |
 |
Processing instructions per bit | 5 |
 |
Sensing resolution bits | 24 |
 |
Transceiver voltage | 3 V |
 |
Transceiver data rate | 250 kbps |
 |
Transceiver receive current | 15.5 mA |
 |
Transceiver sleep current | 20 nA |
 |
Sensing board voltage | 3 V |
 |
Sensing measurement current | 550 μA |
 |
Sensing measurement time | 55 ms |
 |
Sensing sleep current | 0.3 μA |
We analyze six tunable parameters: processor voltage 
, processor frequency 
, sensing frequency 
, packet size 
, packet transmission interval 
, and transceiver's transmission power 
. In order to explore the fidelity of our methodology across small and large design spaces, we consider two design space cardinalities (number of states in the design space): 
and 
. The tunable parameters for 
are as follows: 
= {2.7, 3.3, 4} (V), 
= {4, 6, 8}(MHz) [77], 
= {1, 2, 3} (samples/s) [76], 
= {41, 56, 64} (bytes), 
= {60, 300, 600} (s), and 
= {−17, −3, 1} (dB m) [78]. The tunable parameters for 
are as follows: 
= {1.8, 2.7, 3.3, 4, 4.5, 5} (volts), 
= {2, 4, 6, 8, 12, 16} (MHz) [77], 
= {0.2, 0.5, 1, 2, 3, 4} (samples per second) [76], 
= {32, 41, 56, 64, 100, 127} (bytes), 
= {10, 30, 60, 300, 600, 1200} (seconds), and 
= {−17, −3, 1, 3} (dB m) [78]. All state-space tuples are feasible for 
, whereas 
contains 7779 infeasible state-space tuples because all 
and 
pairs are not feasible.
Although we analyzed our application metrics estimation model for the IRIS motes platform and two design spaces, our application metrics estimation model is equally applicable to any platform, application domain, and design space. Our application metrics estimation model accommodates several sensor node hardware internals, which are hardware platform-specific and can be obtained from the platform's datasheets. Since the appropriate values can be substituted for any given platform, our model can be used with any hardware platform.
3.2.2 Results
In this section, we present example application metrics calculations using our application metrics estimation model.
Since the objective function values corresponding to different states depends on the estimation of high-level application metrics, we present example calculations to exemplify this estimation process using our application metrics estimation model (Section 3.1) and the IRIS mote platform hardware specifications (Table 3.1). We consider the example state 
= 
.
3.2.2.1 Lifetime
First, we calculate the lifetime corresponding to 
. Using Eq. (3.2), the battery energy is 
mW h, which is 
J from Eq. (3.3). The lifetime metric calculation requires calculation of processing, communication, and sensing energy.
For the processing energy per hour, Eqs. (3.12 and 3.13) give 
and 
s, respectively. The processor's active mode energyconsumption per hour from Eq. (3.11) is 
J where 
mA corresponding to 
[77]. Using Eq. (3.15) gives 
s = 999.97 ms. The processor's idle mode energy consumption per hour from Eq. (3.14) is 
mJ where 
mA corresponding to 
[77]. The processor energy consumption per hour from Eq. (3.10) is 
mJ.
For the communication energy per hour, Eqs. (3.18 and 3.20) give 
and 
ms, respectively. Equation (3.19) gives 
J. The transceiver's transmission energy per hour from Eq. (3.17) is 
mJ. Equation (3.23) gives 
where we assume 
; however, our model is valid for any number of neighboring sensor nodes. Equations (3.22 and 3.24) give 
and 
J, respectively. The transceiver's receive energy per hour from Eq. (3.21) is 
mJ. Equation (3.26) gives 
s. The transceiver's idle energy per hour from Eq. (3.25) is 
mJ. Equation (3.16) gives communication energy per hour 
mJ.
We calculate sensing energy per hour using Eq. (3.5). Equation (3.7) gives 
(since MTS400 sensor board [75] has Sensirion SHT1x temperature and humidity sensors [76]). Equation (3.6) gives 
J. Using Eqs. (3.8 and 3.9) gives 
s and 
mJ, respectively. Equation (3.5) gives 
J.
After calculating processing, communication, and sensing energy, we calculate the energy consumption per hour from Eq. (3.4) as 
J. Equation (3.1) gives 
days.
3.2.2.2 Throughput
For the throughput application metric, Eqs. (3.28)–(3.30) give 
bps, 
kbps, and 
kbps, respectively (
where we assume 
bytes). Equation (3.27) gives 
kbps where we assume 
, 
, and 
equal to 0.4, 0.4, and 0.2, respectively.
3.2.2.3 Reliability
We estimate the reliability corresponding to 
dB m to be 0.7 (Section 3.1.3); however, an accurate reliability value can only be obtained using profiling statistics for the number of packets transmitted and number of packets lost.
Similarly, the lifetime, throughput, and reliability for state 
= 
= (5, 16, 4, 127, 10, 3) can be calculated as 10.6 days, 1321.77 kbps, and 0.9999, respectively. These calculations reveal that the tunable parameter value settings for asensor node can have a profound impact on the application metrics. For example, the lifetime of a sensor node in our two examples varied from 10.6 to 1616.8 days for different tunable parameter value settings. Hence, our proposed tunable parameter value settings technique and application metrics estimation model can help WSN designers to find appropriate tunable parameter value settings to conserve the sensor node's energy and to enhance the sensor node's lifetime after satisfying other application requirements such as throughput and reliability.
3.3 Chapter Summary
In this chapter, we proposed an application metric estimation model to estimate high-level metrics (lifetime, throughput, and reliability) from embedded sensor node's parameters. This estimation model assisted dynamic optimization methodologies for operating states' comparisons. Our application metrics estimation model provided a prototype model for application metric estimation.
Future work includes enhancing our application metrics estimation model for additional application metrics (e.g., security, delay). We plan to further validate our application metrics estimation model by comparing the statistics obtained from actual embedded sensor nodes operation in a distributed EWSN.