Internet of Things imposes demanding requirements on wireless sensor networks as key players in context awareness procurement. Temporal and spatial ubiquities are one of the essential features that meet technology boundaries in terms of energy management. Limited energy availability makes anywhere and anytime sensing a challenging task that forces sensor nodes to wisely use every bit of available power. One of the earliest and most determining decisions in the electronic design stage is the choice of the silicon building blocks that will conform hardware architecture. Designers have to choose between dual architectures (based on a low-power microcontroller controlling a radio module) and single architectures (based on a system on chip). This decision, together with finite state machine design and application firmware, is crucial to minimize power consumption while maintaining expected sensor node performance. This paper provides keys for energy analysis of wireless sensor node architecture according to the specific requirements of any application. It thoroughly analyzes pros and cons of dual and single architectures providing designers with the basis to select the most efficient for each application. It also provides helpful considerations for optimal sensing-system design, analyzing how different strategies for sensor measuring and data exchanging affect node energy consumption.
1. Introduction
Internet of Things (IoT) applications and scenarios are very heterogeneous: environmental monitoring in large areas [1], people monitoring in their own homes [2], or industrial environments [3] are some examples. This derives different requirements regarding network architecture and sensing nodes design [4]. According to Merriam-Webster dictionary, ubiquity is defined as the capacity of presence everywhere and in many places simultaneously. Sensors are today needed in different scenarios, and in all of them it is desirable that they be operative everywhere and every time they are required; for this reason, it is said that future sensors must be ubiquitous. It has two faces: spatial ubiquity—which inherently forces wireless communications and absence of wired power sources—and temporal ubiquity—which implies availability along functioning time (maximum energy autonomy) and also availability at any given time. Whichever the case, it leads to the common need of installation’s runtime maximization and consequently minimization of energy demanded by sensing nodes [5]. There are many options to power wireless sensor nodes [6], but a real installation usually poses severe limitations: there is not unlimited power source available, energy from the environment is scarce and not enough for continuous running (e.g., indoors), maintenance of sensors is problematic (e.g., physically hard to reach to change batteries or expensive), and so forth. Thus, is critical to minimize node’s power consumption while maintaining application’s required quality of service. It is well known that power consumption has a high impact over quality of service offer by a WSN and its lifetime [3–5, 7]; the paper is centered on its analysis.
Depending on the deployment scenario, sensor duties will vary: data sensing, processing, aggregation, forwarding, sending, and so forth. In this paper we focus on a common case in many IoT applications: a sensor node periodically samples (every tSAMPLE) one or more sensors (temperature, humidity, light, presence, chemical concentration, etc.), and then it performs some data processing and reports the readings to the network every tREPORT.
Standard IEEE 1451 describes a set of open, common, network-independent communication interfaces for connecting transducers (sensors or actuators) to microprocessors, instrumentation systems, and control/field networks [8]. IEEE 1451 introduces the concept of a transducer interface module (TIM) as a module that contains the interface, signal conditioning, analog-to-digital and/or digital-to-analog conversion, and, in many cases, the transducer. The specification defines a generic finite state machine (FSM) in Figure 1 that describes the operation of sensing nodes—TIMs—with three different operational states: initialization, active, and sleep [9].
Finite state machine that defines a sensing node attending to IEEE 1451 and ZigBee standards.
IEEE 1451 is not restricted to any communication technology, and thus FSM definition is generic and leaves to each standard the specification of the substates needed. There are many WSN protocols available [10], and we select ZigBee for the study as it is a mature wireless standard for sensor networks, worldwide accepted, and with many hardware manufacturers available. The methodology described could be easily applied to any other standard. According to the standard specification [11], FSM states are defined as follows (Figure 1).
Initialization State. Besides hardware startup (oscillator warmup, peripheral initialization, etc.), the ZigBee node has to initialize the network which means to check its network parameters (PANID—personal area network identifier—and channel mask), and if previously not joined to any network then scan the radio channels to discover available networks, join to a specific network, announce itself in the network,and, if the network has security enabled, wait to be authenticated by the Trust Center and for successful acquisition of the network key.
Active State. Minimum tasks defined are polling its parent (to check if there are messages pending for the node), responding to any device discovery or service discovery operations requested, periodically requesting the Trust Center to update its network key (if security is enabled), processing device announce messages from other nodes, rejoining the network if disconnected for any reason, searching for alternative parent in order to optimize recovery latency and reliability, and so forth. Besides these network tasks, the node will also manage the sensors it might has, process and send sensor data, and so forth.
Sleep State. It generically does not have any network or sensor and process duty assigned. This state is devoted to power electronics down to the maximum and to wait until there is any task to do switching to active state.
Temporal ubiquity of a wireless sensor node might suppose that communication with node must be guaranteed with a minimal latency time. This is commonly implemented following two different strategies that ensure lowest power of a wireless node: stay connected doing periodical network polls to receive incoming messages or leave the network and periodically reconnect. According to ZigBee specification, this is implemented following two different strategies shown in Figure 1.
Polling configuration indicates that sensor node never leaves the network and periodically polls its “parent” (another node in the network that holds its messages while it sleeps).
Rejoining configuration indicates that sensor node leaves the network between reporting periods.
Both strategies are considered in ZigBee standard but no one is always more convenient than the other; while the first strategy guarantees that the node will receive messages from the network every time it polls, the second strategy reduces radio power consumption between reports to the minimum.
Energy required to retrieve and send data from the sensor to its destination must be as small as possible and its optimization needs from a multidisciplinary knowledge are improved electronic stages, network management optimization, cooperative tasking, or other alternatives [12]. It should be approached from a combined perspective [13] that merges network, (spatial distribution of network nodes [14], medium access control [15], routing [16], etc.) and node design considerations. Hardware [17] and firmware [18] design of the sensing node is crucial and it is usually done in a superficial way, just looking at the power requirements of the different hardware blocks and optimizing firmware [19].
This paper analyses energy issues associated with the different design alternatives. The next section shows main hardware architectures used to build a wireless sensor: single and dual. Then, based on the implementation of the previously described finite state machine, a mathematical model of energy consumption is defined. The energetic impact derived from hardware architecture and runtime pattern is presented in Section 4. Finally, several considerations about how design strategies impact over energy consumption and performance comparison of different WSN platforms are shown.
2. Hardware Architecture
The building blocks of a sensor node are power management, sensor, communication, and control and/or processing. Wireless communications are the power hungriest part in a node [20]; nevertheless, its impact in overall energy demand can be reduced as these systems optimize its use to the maximum. On the contrary, power consumption of the sensor is often lower compared to communications, but it can have larger influence on the overall system performance depending on how the node performs the measuring process (sampling rate, signal conditioning, data acquisition, etc.) [21]. As a consequence, hardware architecture of node is critical when implementing a real application and electronic designers must decide between two different architectures.
Dual architecture is composed of a microcontroller (uC) that runs the application and control and a radio module (RM) that implements wireless communication. Depending on the radio module, it can just be a transceiver implementing the lowest ISO/OSI layers of a standard (e.g., TI’s CC2420 [22], that is, IEEE 802.15.4 compliant) or implementing a specific wireless standard to the application level (e.g., Ember’s EM260 network coprocessor implementing ZigBee stack). Both cases share in common the RM that is not programmed, but is just configured or controlled through Universal Asynchronous Receiver/Transmitter (UART), Serial Peripheral Interface (SPI), or Inter-Integrated Circuit (I2C) protocols [23] using a set of commands provided by the manufacturer.
Single architecture is composed of a system-on-chip (SoC) embedding a radio module and a programmable microcontroller. In this case, the hardware manufacturer provides wireless standard compliance through an API and/or development environment that the programmer uses and implements the application and downloads it to the SoC. (e.g., Ember’s 35x with EmberZNet Pro [24] or TI’s CC2530 [25] with Z-Stack).
As seen in Figure 2, both architectures can be used to implement a low power consumption end node. Hardware manufacturers are clearly pointing to single architectures in order to maximize energy efficiency, reduce complexity, easily design, and so forth. Nevertheless, is this always true?, under which conditions?, is the strategy of splitting tasks between two low power microcontrollers more convenient in terms of energy efficiency? [26]. In order to answer these questions, in the following sections we compare both architectures analyzing the energy consumption related to each state first theoretically (Section 3) and then with two real implementations.
Sensor node’s single and dual hardware architecture.
3. Runtime Energy Consumption Analysis
Energy monitoring during design and commissioning of a wireless sensor network is challenging. Real measurement in specific nodes is possible [27]; nevertheless, WSN characteristics make it difficult to set nodal energy meters all over the network. Thus, it is common to use tools based on nodes’ and networks’ models that simulate hardware [28], data traffic [29], and associated energy consumption. As it is of key importance to understand the origin of every nanoamp in order to achieve the lowest power consumption [30] and due to the fact that there are no models that consider the architectures described, in the following we study in depth the energy associated with each substate and transition of the sensing node’s FSM described in Figure 1.
Minimization of energy consumption is a tradeoff between strategy chosen, application times between events (tSAMPLE, tREPORT, and tPOLL), and hardware architecture. According to this, many authors propose different energy models, most of them differentiating between four silicon modules: microprocessor, transceiver, sensor, and power supply [31]. In this study, as we aim to compare the hardware architectures discussed in previous section, it is not needed to consider sensor and power supply models because both will equally affect the energy balance; for example, whichever sensor(s) we use, they will output a digital serial communication interface (e.g., SPI and I2C) or an analog signal that will be, respectively, digitalized by the uC or the SoC.
The estimation of the power consumption of a sensor node is normally based on determination of each of the operation modes of the sensor [32]. These modes are highly influenced by the communication protocol and system hardware. In Table 1, we specify all the power modes in which a node will work.
Power modes per silicon blocks (uC, RM, and SoC).
Power mode 0 (PM0)
Power mode 1 (PM1)
Power mode 2 (PM2)
Power mode 3 (PM3)
Microcontroller
Deep sleep (low power timer running)
Low power (slow oscillator, peripherals interrupts on)
High power (fast oscillator)
Not applicable
Radio module
Deep sleep or powered off
Not applicable
Not applicable
Radio on
System on chip
Deep sleep (low power timer running)
Not applicable
Internal uC high power and radio off
Internal uC active and radio on
Table 2 specifies the power mode in which the hardware (uC, RM, and SoC) of the sensor will be in order to work according to poll configuration scheme in Figure 1. (We use poll configuration as it is the most complex scenario and rejoin configuration eliminates “poll parent” state, and the PM0 of the RM will be reduced, while PM0→x will increase.) Energy necessary to switch between power modes is not negligible, especially when going from low power to high power [33], thus it is also indicated in Table 2.
Power modes in each substate of a normal operating cycle of a sensing node.
States
Substates
Dual architecture
Single architecture
UC
RM
SoC
Init network
Scan channels
PM0
PM3
PM3
Discover networks
PM0
PM3
PM3
Join network
PM0
PM3
PM3
Announce node in network
PM0
PM3
PM3
Sense data
Change power mode
PM0→1
PM0
PM0→2
Activate sensor and wait for data ready
PM1
PM0
PM2
Acquire data
PM1
PM0
PM2
Report data
Change power mode
PM0→2
PM0→2
PM0→2
Exchange “report_data” command (RM→uC)
PM2
PM3
—
Change power mode
PM2→0
PM2→3
PM2→3
Rejoin network (if not polling periodically)
PM0
PM3
PM3
Send data to the network
PM0
PM3
PM3
Poll parent
Change power mode
PM0→2
PM0→2
PM0→2
Exchange Poll event (uC→RM)
PM2
PM2
—
Change power mode
PM2→1
PM2→3
PM2→3
Poll parent in the network
PM1
PM3
PM3
Change power mode
PM1→2
PM3→2
—
Exchange “poll response” (RM→uC)
PM2
PM2
—
Sleep
Change power mode
PMx→0
PMx→0
PMx→0
Sleep
PM0
PM0
PM0
Energy consumed in a given state “x” will be the sum of its “m” substates calculated as
(1)Ex=V×∑j=0m∫0tjij(t)dt=V×∑j=0mQj,
where V is the voltage supply and the second term is the integral of the current consumed ij and during the time tj the substate lasts.
Attending to the substates and considering the information that can be measured and extracted from hardware datasheets and application notes, the charge demanded by each state is defined in Table 3, where IUC,RM,SoC0,1,2,3 is the current consumed by uC, RM, and SoC in power modes 0, 1, 2, and 3 respectively, QUC,RM,SoC0,1,2,3→0,1,2,3 is the charge drained by uC, RM, and SoC in transitions between corresponding power modes, tUC0,1→1,2,3 is the time needed by uC to change from modes 0 and 1 to 1 and 2, respectively, QRM,SoCINIT,REPORT,POLL is the charge drained by RM and SoC in network initialization, data report, and parent poll, tRM,SoCINIT,REJOIN,REPORT,POLL is the time needed by RM and SoC in respective network process, tSENSOR is the time needed by the sensing entities to sensor a valid measure in their outputs, IUC,SoCACQ is the current needed by uC and SOC for data acquisition from the sensing entities, for example, A/D conversion, tUC,SoCACQ is the time needed by uC and SOC for data acquisition from the sensing entities, for example, A/D conversion, IUC,RMSCI is the current needed by uC and RM for data communication via serial communication interface, tSCIREPORT,POLL,POLL_
ANSW
, is the times needed to communicate between RM and uC via serial communication interface, and tSLEEP is the time in sleep mode.
Consumption in each substate of a normal operating cycle of a sensing node.
States
Substates
Dual architecture
Single architecture
Init network
Scan channels
IUC0×tINIT+QRMINIT
QSoCINIT
Discover networks
Join network
Announce node in network
Change power mode
QUC0→1+IRM0×tUC0→1
QSoC0→2
Sense data
Activate sensor and wait for data ready
(IUC1+IRM0)×tSENSOR
ISoC2×tSENSOR
Acquire data
(IUC1+IUCACQ+IRM0)×tUCACQ
(ISoC2+ISoCACQ)×tSoCACQ
Change power mode
QUC1→0
QSoC2→0
Change power mode
QUC0→2+QRM0→2
QSoC0→2
Exchange “report_data” command (RM→UC)
(IUC2+IUCSCI+IRM2+IRMSCI)×tSCIREPORT
0
Report data
Change power mode
QUC2→0+QRM2→3
QSoC2→3
Send data to the network (rejoin if needed)
(IUC0×tREPORT)+QRMREJOIN+QRMREPORT
QSoCREJOIN+QSoCREPORT
Change power mode
QRM3→0
QSoC3→0
Poll parent
Change power mode
QUC0→2+QRM0→2
QSoC0→2
Exchange Poll event (UC→RM)
(IUC2+IUCSCI+IRM2+IRMSCI)×tSCIPOLL
0
Change power mode
QUC2→1+QRM2→3
QSoC2→3
Poll parent in the network
(IUC1×tPOLL)+QRMPOLL
QSoCPOLL
Change power mode
QUC1→2+QRM3→2
QSoC3→0
Exchange “poll response” (RM→UC)
(IUC2+IUCSCI+IRM2+IRMSCI)×tSCIPOLL_ANSW
0
Change power mode
QUC2→0+QRM2→0
Sleep
Sleep
(IUC0+IRM0)×tSLEEP
ISoC0×tSLEEP
As we aim to compare both architectures, many simplifications are possible.
Terms related to network operations (QRM,SoCINIT,SEND,POLL) and power state change (QRM,SoC0,1,2,3→0,1,2,3) are equivalent in terms of energy consumption for RM and SoC. (This assumption can be considered as RM and SoC from the same manufacturer share the same radiofrequency hardware, for example, Texas Instruments’ CC2520 transceiver and CC2530 SoC or Ember’s EM357 coprocessor and EM357 SoC.)
Charge needed for network initialization is only consumed once and it is negligible compared to the charge needed by other states and consequently to the charge of the battery (below 0,05% with a 1000 mAh battery).
Current in power mode 0 of uC, RM, and SoC is several orders of magnitude lower compared to power modes 1, 2, or 3.
Time in sleep mode is several orders of magnitude larger than any other times.
Considering the former simplifications and application times between events (tSAMPLE, tREPORT, and tPOLL), the resulting energy balance between dual and single architecture for a given cycle is
(2)QCYCLED-S=tREPORTtSAMPLE×QSENSED-S+tREPORTtPOLL×QPOLLD-SQCYCLED-S+QREPORTD-S+tREPORT×ISLEEPD-S,
where
(3)QSENSED-S=QuC0→1+QuC1→0+IRM0QSENSED-S×(tuC0→1+tuCACQ)+(IuC1+IuCACQ)QSENSED-S×tuCACQ-QSoC0→2-QSoC2→0QSENSED-S-(ISoC2+ISoCACQ)×tSoCACQQSENSED-S+(IRM0+IUC1-ISoC2)×tSENSOR,QPOLLD-S=QuC0→2+QuC2→0+QuC1→2+QuC2→1QPOLLD-S+(IuC2+IuCSCI+IRM2+IRMSCI)QPOLLD-S×(tSCIPOLL+tSCIPOLLANSW)+(IUC1×tPOLL),QREPORTD-S=QUC0→2+QUC2→0QREPORTD-S+(IUC2+IUCSCI+IRM2+IRMSCI)QREPORTD-S×tSCIREPORT+(IUC0×tREPORT),ISLEEPD-S=IUC0+IRM0-ISoC0.
Thus, when QCYCLED-S<0, the dual architecture will be more power efficient than the single architecture and vice versa when QCYCLED-S>0.
4. Experimental Method and Results
As mentioned above, there are different WSN simulation tools that focus on specific aspects of the network: latency times, bandwidth, collisions, message integrity, and so forth. According to the previous section analysis, we need to focus more deeply on the architecture of the node and associated states, than on the network characteristics. Thus, we used MATLAB suite to model energy consumption of real sensing nodes’ hardware and simulate FSM operation.
Comparison between architectures has been done analyzing two real implementations with devices having similar characteristics: both ZigBee standard chipsets and microcontrollers with 16 bit RISC architecture similar to MIPS, power supply ranges, integration of peripherals (ADC, serial communication interfaces, clocks, etc.), and memory capacity. Table 4 shows how theoretical analysis shown in Section 3 is specified for two different implementations of ZigBee standard (Texas Instruments and Ember, but now Silicon Labs) and for two different families of ultralow power microcontrollers (Microchip and Texas Instruments). (uCPIC = PIC24F16KA102; RMEmber = SoCEmber = EM357; uCTI = MSP430F2001; RMTI = SoCTI = CC2530. SoC manufacturers usually allow their devices to operate as RM running a specific firmware. Thus, in order to eliminate hardware dependencies in analysis, we decided to use the same chipset operating in different configurations in both architectures. The indicated energy consumption corresponds to the scenarios in which both architectures have optimized and similar performance: similar peripheral, clocks sources, and power configuration. It is important to remark that internal RTCC in PM0 has been selected.)
Figures involved in the calculation of power consumption.
Dual architecture
Single architecture
uCPIC
RMEmber
uCTI
RMTI
SoCEmber
SoCTI
I0
0.835 µA
0.4 µA
0.9 µA
0.4 µA
1 µA
1 µA
I1
15 µA
—
41 µA
—
—
—
I2
3.05 mA
6 mA
2.2 mA
3.4 mA
6 mA
3.4 mA
I3
—
27 mA
—
28.7 mA
27 mA
28.7 mA
IACQ
1 mA
—
850 µA
—
1.1 mA
1.2 mA
ISCI
0.5 µA
200 µA
0.5 µA
200 µA
—
—
Q0→1
15 pC
—
16 pC
—
—
—
Q0→2
0.39 µC
12.4 µC
10 pC
51.57 µC
12.4 µC
51.57 µC
Q2→3
—
9.94 µC
—
40.95 µC
9.94 µC
40.95 µC
Q3→0
—
3.3 µC
—
13.6 µC
3.3 µC
13.6 µC
t0→1
1 µs
—
0.4 µs
—
—
—
t0→2
128 µs
—
0.4 µs
—
—
—
tACQ
4.125 µs
—
2.06 µs
—
42.7 µs
68 µs
tSCI_POLL
16 µs
16 µs
8 µs
8 µs
—
—
tSCI_POLL_ANSW
4 µs
4 µs
2 µs
4 µs
—
—
tSCI_REPORT
34 µs
34 µs
17 µs
34 µs
—
—
tREPORT
—
8 ms
—
8 ms
8 ms
8 ms
tPOLL
—
6 ms
—
6.8 ms
6 ms
6.8 ms
For a given conditions and according to the analysis in Section 3, Table 5 shows the charge difference between dual and single architecture (%QXD-S) of each substate, expressed in percentage contribution to the normalized total consumption per cycle. On one hand, it highlights the importance of sleeping and sensing processes related to total energy consumption evidencing their importance in autonomy maximization. It also proves the slight differences between chipsets, which together with the fact that information available about power consumption is more profuse for Microchip-Ember configuration leads us to choose it for further analyses.
Rate of consumption of each substate (considering that treport = 8 hours, tSAMPLE = 10 min, tPOLL = 4 min, tSENSOR = 10 ms).
Microchip-Ember
Texas Instruments
%QSENSED-S
33.707%
32.094%
%QPOLLD-S
0.773%
0.315%
%QREPORTD-S
0.007%
0.002%
%(ISLEEPD-S×tREPORT)
65.513%
67.589%
4.1. Sensing and Reporting
When focusing on measurement process, there are two important tasks: data acquisition and reporting. Figure 3 represents how the power savings ratio (PSR) of the dual architecture versus single architecture (defined as PSRDSvsS=QCYCLED-S/QCYCLES≜ΔQ/Q) varies depending on tSAMPLE, tPOLL, and tSENSOR. Values above zero indicate better performance of the dual architecture and vice versa when PSRDSvsS is below zero.
Variation of PSRDvsS with tSAMPLE and tPOLL (e.g., tREPORT=4 hours and several tsensor).
It is appreciated that variation in tPOLL has reduced impact on PSRDSvsS. The major effect comes from the variation of the time between measurements (tSAMPLE) and the time needed to have valid sensor signal (tSENSOR) [34]; the more time the node spends in sensing tasks, the more effective the dual architecture becomes. This fact is evidenced in Figure 4, where PSRDSvsS is represented versus tSAMPLE for various values of tSENSOR.
PSRDSvsS versus tSAMPLE (e.g., tREPORT=4 hours tPOLL=4 min).
We can clearly observe the impact of the measurement process on energy savings in the following example. Considering a sensor node getting one sample each 100 seconds from a sensor that needs 5 ms to provide a valid value (point A in Figure 3), the dual architecture would need 10% of energy less than single architecture. This effect is mainly derived from the higher flexibility in terms of clock sources of low power microcontrollers that is so far not available in SoCs (PIC24F16KA102 has five external and internal clock sources, providing 11 different clock modes with a minimum CPU clock speed of 31 kHz. Ember 357 has four clock sources with a minimum CPU clock speed of 6 MHz. The same happens to TI’s hardware); that is, microcontrollers consider low power modes with slow clocks (PM1) that are very convenient for sensing tasks. On the other hand if tSENSOR is reduced to 500 us (point B in Figure 3), single architecture would be 6% more efficient. Finally, when sampling time tSAMPLE exceeds 5 minutes (point C in Figure 3), for the conditions given (tREPORT=4 hours; tPOLL=4 min; tSENSOR≤10 ms), single architecture will be always more efficient.
4.2. Rejoining and Polling Strategies
Regardless of the dual or single architectures, if it is assumable that the node is not connected to the network, a rejoin strategy can be more optimal depending mainly on the reporting period (tREPORT). This basically occurs when the overconsumption due to rejoin process compensates the accumulated energy consumptions of the polls. Figure 5 compares PSR between rejoining and polling strategies for single and dual architectures.
Comparison and single dual architecture with rejoining versus polling strategies (example for tSAMPLE = 1 min tSENSOR = 5 ms).
Intersection between lines with zero (points A in Figure 4) indicates the tREPORT above which rejoining strategy would be more convenient for any architecture. Intersection between red and blue lines (points B in Figure 4) indicates the tREPORT above which dual architecture is more efficient than single architecture.
As expected, the energy savings of rejoining strategy increases with time between reports, faster at the beginning, until reaching a final stable value. This is because increasing time between reports decreases relative impact of QREJOIN over the total. For this same reason, the final PSR is much more affected by the time between polls rather than by the value of QREJOIN.
4.3. Sleeping
As we have seen in Table 5, with any given sampling/polling/reporting conditions, the current in sleep mode is a relevant variable that has major impact in node lifetime. Thus, it is evident that the primary goal of a low power system is being in sleep mode as long as possible [35]. Some authors propose adaptive runtime to maximize efficiency [36]. Indeed, it is common to perform nodal power consumption analysis according to sleeping duty cycle [37]. Given the presented FSM tasks, considering sleeping time that is several orders of magnitude higher than the time devoted to all other tasks, having a battery charged with QBATT and “n” being the number of reports performed by the node during its lifetime, charge will be drained as
(4)QBATT=QINITQBATT+n×(tREPORTtSAMPLE×QSENSE+tREPORTtPOLLQBATT+n××QPOLL+QREPORT+tREPORT×ISLEEPtREPORTtSAMPLE).
Dual architecture with low power microcontrollers allows greater versatility to reduce sleep current, due to additional capabilities provided by a microcontroller: ultralow wakeup with external capacitor and radio module’s totally powered off. (Frequently, microcontrollers have external interrupts based on discharged time of a capacitor. (See Microchip AN879 Using the Microchip Ultra Low-power Wake-up Module) or high impedance RC external circuits could be used in an low power interrupt. Note that the consumption for charging this capacitor is negligible.) Both architectures can also use an external RTCC to reduce to the maximum energy required for timing. (Low-Current High-ESR Crystals (such as Maxim DS1341) with I2C communication and one output used to activate an alarm interrupt of the microcontroller.) Table 6 shows pros and cons of different sleep mode strategies, sleep current of hardware, and associated PSR of dual architecture versus single architecture.
PSRDSvsD for several configurations (tSAMPLE = 120 s, tPOLL = 4 min, and tSENSOR = 1 ms).
Sleeping strategy
ISLEEP (Dual)
ISLEEP (Single)
PSRcycle (DSvsS)
Pros and cons
uCPIC + RTCCDS
RMEmber
SoCEmber
Polling
Internal RTCC wakeup
0.835 µA
0.4 µA
1 µA
5.68%
+ Node can receive messages+ High precision in wakeup timing
Internal WDT wakeup
0.585 µA
0.4 µA
0.8 µA
2.58%
+ Node can receive messages− Low precision in wakeup timing
External RTCC wakeup
0.035 µA + 0.25 µA
0.4 µA
0.4 µA + 0.25 µA
0.78%
+ Node can receive messages+ High precision in wakeup timing− Additional RTCC chip necessary
Ultralow power wakeup
0.035 µA
0.4 µA
0.8 µA
−41.63%
+ Node can receive messages− The lowest precision in wakeup timing
Rejoining
Internal RTCC wakeup
0.835 µA
0
1 µA
−25.90%
− Node cannot receive messages+ High precision in wakeup timing
Internal WDT wakeup
0.585 µA
0
0.8 µA
−35.94%
− Node cannot receive messages− Low precision in wakeup timing
External RTCC wakeup
0.035 µA + 0.25 µA
0
0.4 µA + 0.25 µA
−59.47%
− Node cannot receive messages+ High precision in wakeup timing− Additional RTCC chip necessary
Ultra low power wakeup
0.035 µA
0
0.8 µA
−90.66%
− Node cannot receive messages− The lowest precision in wakeup timing
For polling (node can receive messages) and rejoining (node cannot receive messages) configurations, we considered four sleeping strategies. Using internal or external RTCC (additional chip necessary) provides node’s conscience about clock and calendar and high precision in wakeup timing. It can be useful to build time synchronized WSNs, to accurately monitor variables or to timestamp measurements. Internal WDT reduces current consumption and loses timing functionalities. Finally, ultralow power wakeup has the most inaccurate timing (that could be enough to form any applications) but greatly reduces current consumption.
Evidently, the more the silicon modules that can be powered off, the less the power consumption in sleep mode. Thus, due to its higher flexibility, the dual architecture can be very convenient in case the application requirements allow it; it is especially remarkable to note the PSR difference in the rejoining strategy with ultralow power wakeup.
4.4. Hardware Architecture Performance Comparison
In order to range the importance of the issues described here, this section provides a hardware architecture performance comparison of well-known WSN platforms [38–40]. The methodology followed has been to model the hardware blocks of the platforms according to chip manufacturer specifications and calculate the expected battery lifetime in a realistic scenario. Table 7 show the life expectancy expressed in years and the ratio compared to the best performance architecture. (Test framework considered: Vsupply=3 V; internal oscillator, main frequency = 8 mhz, secondary frequency = 1 MHz; External Oscillator, Crystal frequency = 32.768 kHz; tSAMPLE=120 s, tPOLL=4 min, tSENSOR=1 ms; tREPORT=60 min; Battery type = LiMnO2, model = 2032/5004LC, capacity = 210 mAh). Obviously, it is necessary to consider that older systems are at disadvantage as chipset performance improves every year.
WSN hardware platform performance comparison.
Platform
Hardware architecture
Life expectancy (Years)
Ratio (%)
Microcontroller
Transceiver
Texas Instruments
MSP43F2001
CC2530
2.75
100%
Microchip-Ember
PIC24F16KA102
EM357
2.45
89.12%
Iris-It (2008)
ATMega 1281
AT86RF230
1.03
37.42%
Dual
Libelium (2012)
ATMega 1281
EM357
0.99
36.16%
TelosB, Shimmer (2005)
MSP430F1611
CC2420
0.75
27.47%
MicaZ (2004)
Atmega 128L
CC2420
0.42
15.11%
Sun SPOT (2007)
AT91SAM9G20
CC2420
0.14
5.20%
Single
Texas Instruments
CC2530
2.13
74.34%
Ember
EM357
1.42
48.90%
According to the results in previous sections, dual architecture is more efficient than the single one for the given conditions. Also both Texas Instruments and Microchip-Ember provides the highest performance. As sensing duties are not exigent in terms of microcontroller requirements, we can observe the negative effect of oversizing them (SunSpot’s microcontroller is very powerful) in terms of life expectancy. Also, comparing performance of platforms sharing the same transceiver (CC2420 and EM357), the influence of the microcontroller chosen is obvious.
5. Conclusions
WSNs are essential in the next generation of Internet where ubiquitous interconnected objects are available for interaction. Ubiquity means everywhere and anytime availability of sensing nodes implying wireless communication, energy harvesting, low power, and so forth; concepts that if not properly considered can lead to reduced systems’ autonomy killing many real IoT applications. With these considerations in mind, low power consumption is one of the most important targets when designing IoT ready sensors.
This paper studies different sensor node hardware architectures, deepening in the power consumptions associated with each state of the runtime cycle and time-relationship between them. It compares the energy consumption involved in the operation of a sensor node implemented using two different architectures: dual (based on a low power microcontroller and a radio module) and single (based on a system on chip). The specific finite state machine that describes the operation of sensing node is based on standard IEEE 1451 and the specific communications substates are modeled according to ZigBee Pro standard.
One important conclusion is that energy required in the sensing procedure has an important impact on this balance. There are some tasks, such as waiting for a valid sensor output (tSENSOR) or acquiring the sensor data, which might require relevant amount of energy depending on the sampling rate (tSAMPLE). This can turn dual architecture more efficient than the single one. One reason is that because low power microcontrollers in single architecture have higher flexibility than SoC architectures in terms of low power oscillator configurations, microcontrollers embedded in SoCs are usually not able to run with kHz oscillators. The second reason is because low power microcontroller peripherals are more optimized, something which can be especially relevant in case of using analog sensors that require the use of analog-digital converter (the same performance in terms of quality of the conversion requires less current and time in low power microcontroller than in SoC).
Considering temporal ubiquity requirements, if the IoT application does not require nodal availability at any time (for example to change sampling parameters), nodes can disconnect from the WSN. In case of ZigBee standard, this can be implemented using rejoining and polling strategies. In that case, when energy needed to rejoin exceeds consumption due to several polls, polling strategy turns to be more energy efficient. It also shows that, above a certain reporting period, dual architecture is more efficient because rejoining strategy allows to totally power off the radio module when not using it.
Power consumption in sleep mode has major impact on node lifetime, so there is a need to design a system with a current in sleep mode as low as possible. Again, dual architecture might be more convenient because low power microcontrollers are more flexible in terms of oscillator configuration and have additional low power modules such as ultralow-power wake-up module.
The main conclusion of the study evidences that, despite what could be considered initially and stated in datasheets, no architecture is always energetically more efficient than the other; deep contextualized system analysis is mandatory to squeeze batteries to the maximum. This paper provides generic guidelines that would help electronic designers in this analysis in order to decide the most energy efficient hardware architecture of sensor nodes. We also find it useful for firmware and even software developers in order to provide understanding about how IoT application requirements (e.g., reporting time) affect WSN performance and lifetime. Finally, a performance comparison of different WSN platforms attending to their hardware architecture evidences the impact of the issues just stated.
As a final example, making clear the importance of the analysis, if a sensor that polls for data every 4 min samples every minute a sensor that needs 5 ms to set up and reports data each 4 hours is implemented using a dual architecture, it would need 24% less energy than implemented using a SoC. But just changing sampling rate from 1 minute to 5 minutes would turn the situation making the dual architecture consume 6% more energy than single architecture.
MirabellaO.BrischettoM.A hybrid wired/wireless networking infrastructure for greenhouse management20116023984072-s2.0-7865133629510.1109/TIM.2010.2084250PostolacheO. A.GiraoP. M. B. S.MendesJ.PinheiroE. C.PostolacheG.Physiological parameters measurement based on wheelchair embedded sensors and advanced signal processing20105910256425742-s2.0-7795671537810.1109/TIM.2010.2057590GungorV. C.HanckeG. P.Industrial wireless sensor networks: challenges, design principles, and technical approaches20095610425842652-s2.0-7034961916310.1109/TIE.2009.2015754GómezC. C.ParadellsJ.CaballeroJ. E.2010Fundación Vodafone EspañaSharmaA.ShinghalK.SinghR.SrivastayaN.Energy management for wireless sensor network nodes20111713KnightC.DavidsonJ.BehrensS.Energy options for wireless sensor nodes2008812803780662-s2.0-5814919528210.3390/s8128037SouaR.MineP.A survey on energy efficient techniques in wireless sensor networksProceedings of the Wireless and Mobile Networking Conference (WMNC '11)2011Le Chesnay, FranceINRIAHigueraJ. E.PoloJ.IEEE 1451 standard in 6LoWPAN sensor networks using a compact physical-layer transducer electronic datasheet2011608275127582-s2.0-7996041577310.1109/TIM.2011.2129990IEEE Standard 1451.5IEEE standard for a smart transducer interface for densors and actuators—wireless communication protocols and transducer electronic data sheet (TEDS) formatsIEEE, 2007BurattiC.ContiA.DardariD.VerdoneR.An overview on wireless sensor networks technology and evolution200999686968962-s2.0-7035002338510.3390/s90906869ZigBee AllianceZigBee SpecificationDocument 053474r17, 2008GaoR. X.FanZ.Architectural design of a sensory node controller for optimized energy utilization in sensor networks20065524154282-s2.0-3364531581410.1109/TIM.2006.870321BilouhanS.GuptaR.Optimization of power consumption in wireless sensor networks201125AkkayaK.YounisM.A survey on routing protocols for wireless sensor networks2005333253492-s2.0-1394428339310.1016/j.adhoc.2003.09.010Al AmeenM.IslamS. M. R.KwakK.Energy saving mechanisms for MAC protocols in wireless sensor networks20102010162-s2.0-7995283310410.1155/2010/163413163413Ahmad MadaniS. M.2008YuP.QinghuaL.XiyuanP.The design of low-power wireless sensor nodeProceedings of the IEEE International Instrumentation and Measurement Technology Conference (I2MTC '10)May 20109179222-s2.0-7795782544010.1109/IMTC.2010.5488015ParkT. R.LeeM. J.Power saving algorithms for wireless sensor networks on IEEE 802.15.420084661481552-s2.0-4574913722910.1109/MCOM.2008.4539479SalvadoriF.de CamposM.SausenP. S.de CamargoR. F.GehrkeC.RechC.SpohnM. A.OliveiraA. C.Monitoring in industrial systems using wireless sensor network with dynamic power management2009589310431112-s2.0-6924922137910.1109/TIM.2009.2016882CabanS.José AntonioG.RuppM.Measuring the physical layer performance of wireless communication systems2011145817AlippiC.AnastasiG.Di FrancescoM.RoveriM.Energy management in wireless sensor networks with energy-hungry sensors200912216232-s2.0-6554916008410.1109/MIM.2009.4811133Texas Instruments Incorporatedhttp://www.ti.com/product/cc2420XP Semiconductors N.V.http://www.nxp.com/campaigns/i2c-bus/Silicon Laboratories Inc.http://www.silabs.com/products/wireless/zigbee/Pages/zigbee-chips-em35x.aspxTexas Instruments Incorporatedhttp://www.ti.com/product/cc2530ChouP. H.ParkC.Energy-efficient platform designs for real-world wireless sensing applicationsProceedings of the IEEE/ACM International Conference on Computer-Aided Design (ICCAD '05)November 20059139202-s2.0-3375142540410.1109/ICCAD.2005.1560192GaoM.PanX.DengL.HuangC.ZhangD.NiL.A versatile nodal energy consumption monitoring method for wireless sensor networks testbedProceedings of the IEEE 17th International Conference on Parallel and Distributed Systems2011388395Castaliahttp://castalia.research.nicta.com.au/index.php/en/MerrettG. V.WhiteN. M.HarrisN. R.Al-HashimiB. M.Energy-aware simulation for wireless sensor networksProceedings of the 6th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks (SECON '09)June 20092-s2.0-7044965768010.1109/SAHCN.2009.5168932YuP.QinghuaL.XiyuanP.The design of low-power wireless sensor nodeProceedings of the IEEE International Instrumentation and Measurement Technology Conference (I2MTC '10)May 20109179222-s2.0-7795782544010.1109/IMTC.2010.5488015ZhouH.-Y.LuoD.-Y.GaoY.ZuoD.-C.Modeling of node energy consumption for wireless sensor networks2011311823CasilariE.Cano-GarcíaJ. M.Campos-GarridoG.Modeling of current consumption in 802.15.4/ZigBee sensor motes2010106544354682-s2.0-7795478682610.3390/s100605443GholamzadehB.NabovatiH.Concepts for designing low power wireless sensor network200845559565WangW. S.O'KeeffeR.WangN.HayesM.'FlynnB. O.Ó MathúnaS. C.Reducing power consumption in metrics for building energy management apllicationsProceedings of the 23rd European Conference Forum Bauinformatik2011Cork, IrelandViswanathanA.BoultT. E.Power conservation in ZigBee networks using temporal controlProceedings of the 2nd International Symposium on Wireless Pervasive ComputingFebruary 2007Boulder, Colo, USAUniversity of Colorado Press1751802-s2.0-3454812786510.1109/ISWPC.2007.342596Chern LimJ.BleakleyC.AdaptiveWSN scheduling for lifetime extension in environmentalMonitoring applications201220121728698110.1155/2012/286981ChungY. W.HwangH. Y.Modeling and analysis of energy conservation scheme based on duty cycling in wireless Ad Hoc sensor network2010106556955892-s2.0-7795479369910.3390/s100605569MadanV.ReddyS.Review of wireless sensor mote platforms2012225055ChienT. V.Nguyen ChanH.Nguyen HuuT.A comparative study on hardware platforms for wireless sensor networks201221LajaraR.Pelegrí-SebastiáJ.Perez SolanoJ. J.Power consumption analysis of operating systems for wireless sensor networks2010106580958262-s2.0-7795480622310.3390/s100605809