Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction to Wireless Sensor Networks

Originally, sensors were electromechanical detectors for measuring physical quantities. Their first use can be traced back to 1933, in the first room thermostats [1]. Early microelectromechanical systems (MEMS) consisted of a multi-chip, where a sensor and its electronics and mechanics were housed on separate chips and packages. This resulted in larger size, more cost, and lower yield of the sensor [2]. Recent advances in MEMS and integrated circuits (IC) have enabled the development of small-scale sensors and the integration of its actuators and electronics into one cost-effective high-performance chip. Over the past decade, these sensors have evolved into smart sensors, which now include an on-board processor, memory, and transceiver, all in a small-scale factor, powered by a battery source. These smart sensors constitute a node in the Wireless Sensor Network (WSN).

The benefit of the small-scale node is twofold, first, the low production cost and second, the easy and low installation cost. Currently, the price of a WSN node ranges in hundreds to thousands of dollars; however, it is envisioned to reduce to a couple of dollars with advances in technology and mass production [3]. The small size and low cost of the node allows an ease in the installation process, where nodes can be randomly air-dropped or precisely placed, based on the application.

These low-cost nodes with processing, storage, and sensing capabilities, coupled with the attractive infrastructure-less networking capabilities of the transceiver, market the WSN as a powerful, low-cost solution for numerous problems in diverse areas of research. They offer collaboration in a distributed environment for sensing and processing information. Vital information is routed through a multi-hop ad hoc network to a WSN sink, a collector of data or to a base station, which acts as a gateway to a fixed infrastructure. Variations of WSNs include nodes with actuators that comprise a Wireless Sensor and Actuator Network (WSAN) [4, 5], mobile nodes in WSNs [3], or nodes capable of handling multimedia content like audio and video streaming or still images in a Wireless Multimedia Sensor Network (WMSN) [6].

Myriad applications exist that leverage WSNs as low-cost solutions for observing the environment, for example, in military and civilian surveillance and target detection and tracking applications (e.g., [7–10]), for monitoring and controlling industrial processes [11], for precision farming and agriculture [12], environment and habitat monitoring [13, 14], patient monitoring in health care [15, 16], residential applications like energy management [17], in vehicular networks for safety [18] and efficiency [19] and even for outer space explorations [20].

In the following sections, we will discuss the various characteristics of WSN nodes and the intrinsic nature of WSN, followed by a discussion of the traffic patterns and network architecture protocols for WSN and their taxonomy. We will proceed with an overview of TinyOS, an operating system for WSN, and delineate a sample program to illustrate the methodology of programming in WSN. We will conclude with a summary of the challenges and limitations of WSN.

1.1 WSN Nodes and Their Characteristics

Technological advances in MEMS and IC instigate the widespread availability of low-cost, small-scale sensors, which evolved into smart, battery powered sensors, with processing and communicating capabilities. These smart sensors constitute the WSN node, referred to as motes, hereafter, in honor of the first WSN nodes, which were University of Berkley’s Rene and Mica Motes [21]. Figure 1 illustrates a typical WSN mote with its fundamental units. Minimally, a mote consists of a battery-operated unit with single or multiple sensors, a processing unit with storage and a transceiver. Typically, expansion slots exist or can be attached to expand the mote to include other application-specific units, such as global positioning system (GPS) for localization, or power harvesting units from solar or wind energy, or complementary metal–oxide semiconductor (CMOS) chips for multimedia capabilities.

Fig. 1
figure 1

A typical WSN mote with its fundamental units

Full size image

These motes are placed on programming boards, interfaced with a computer, so that the WSN application and its operating system can be flushed into the memory of the mote. At this time, the motes can also be programmed with a specific identification number and/or group identification number. Various motes can also be programmed without a physical connection to the computer, known as over-the-air (OTA) programming.

WSN motes can vary greatly, with respect to the size, their cost, processing power, communication range, protocols, and operating systems. WSN motes can be as large as a shoebox, e.g. Sensoria Wireless Integrated Network Sensors (WINS) Next Generation (NG) 2.0 [22], or as miniature as a coin, like Moteiv Corporation’s Tmote Mini [23], but typical WSN mote dimensions are in the order of a couple of centimeters [24].

WSN motes are typically equipped with multiple sensors for sensitivity to various environmental factors, e.g. mechanical, thermal, biological, chemical, optical, and magnetic. Often motes have expansion slots that enable them to be equipped with mechanical actuators, wheels for mobility or CMOS chips or microphone for multimedia capabilities. The processors used in these motes can range from ultra-low-power 8 bit processors to more powerful 32 bit processors, similarly, memory space can vary from a couple of kilobytes to the order of megabytes [25].

Motes are equipped with short-range radio frequency (RF) transceivers to enable WSN applications [25] and to ease the query and retrieval of data from the WSN [26]. The use of a short-range radio directly influences the antenna size, since short-range radio waves have higher frequencies and shorter wavelengths they can be received and transmitted by small compact antennas. Through the high frequencies of 800–1,000 MHz, IEEE 802.15.4 or the 2.4 GHz Bluetooth, the low-power radios offer varying bandwidths [25]. The low-transmission range of the motes instigates a multi-hop WSN. Though current WSN motes are equipped with RF radios, communication via infrared, ultrasound, and inductive fields [27] has also been explored [25].

WSN motes can also be equipped with power generation units that harvest power ambient energy sources such as solar [28], mechanical, and thermal [29]. Table 1 presents a comparison of some WSN motes used in academia and industry w.r.t. these characteristics [25, 24, 30].

Table 1 Comparison of some WSN motes
Full size table

We will now consider the characteristics of WSNs with respect to the various application and environmental aspects.

1.2 Characteristics of WSNs

WSNs are deployed in a region of interest over a period of time. Since the motes have a short-range radio and a small coverage area, WSNs typically contain a large number of motes. These motes form multi-hop networks and collaborate with each other to maintain connectivity and coverage. Apart from the traditional concerns on collaboration and communication in an ad hoc environment, WSN are also plagued with power and energy management concerns, due to the battery-operated motes. In this section, we will delineate the various design criteria of application-specific WSNs.

Region of Interest

The region of interest in WSN applications can be divided into those that are dangerous or isolated versus those that are mundane and cumbersome. In both scenarios, there is little or no infrastructure [3, 26]. For example, volcano monitoring [13], a dangerous task for humans, can be accomplished using low-cost motes that are deployed in the region. These motes are not only expendable but also provide critical data analysis and lifesaving information. However, a WSN used in life rhythm analysis for the elderly [31] can automate the mundane process of gathering vital signs and provides continuous statistics, rather than at fixed intervals.

Modes of Deployment

There are two distinct mote deployment strategies, random and precise. In random deployment, motes are randomly distributed like nodes in wireless ad hoc networks. This deployment could be rocket ejected or aircraft sown [32], e.g. in the aerial spread of motes for volcano monitoring [13]. Precise deployment usually consists of manual or pre-planned placement of motes, e.g. habitat monitoring on Skomer Island [33]. The deployment strategies used affect the structure of WSN and can have an impact on coverage of the region and cost of deployment [26].

Organization and Architecture

WSN can be organized into two typical structures, flat or hierarchical. Figure 2 illustrates the flat and hierarchical WSN. In a flat network, all motes in the network have the same role and importance, whereas, in a hierarchical organization, motes are clustered or organized into groups with different motes playing different roles, such as general purpose sensing motes or data aggregators or forwarders. As we climb up the hierarchy, the mote’s functionality increases with respect to its cost, size, processing power, storage size, etc.

Fig. 2
figure 2

WSN architecture, hierarchical (left) and flat (right)

Full size image

For best results, WSN deployment should consist of a hierarchical organization of heterogeneous motes, integrating a larger number of low-power general purpose motes with smaller number of specialized or high-performance motes [24]. Furthermore, these motes can be equipped with actuators [4] or consist of mobile motes [3].

In WSN architectures, single or multiple base stations preside over the entire WSN. These base stations act as a gateway between the WSN and other fixed infrastructure, e.g. Internet. The base stations are typically, high-performance, human operated devices with rechargeable power source, e.g. laptops interfaced with a mote. Lower down the hierarchy would be specialized motes with slightly better configurations than the low-cost, low-power general purpose motes at the bottom of the hierarchy or pyramid. The special purpose motes offer data aggregation, or fusion, and more complex computational and communicational power, making them ideal sink nodes in the WSN. The general purpose motes at the bottom of the hierarchy typically act as data collectors and forwarders, as illustrated in Fig. 2.

Multiple WSN can be interconnected to form a global WSN, referred to as global sensing infrastructure [34], as illustrated in Fig. 3.

Fig. 3
figure 3

Global WSN infrastructure

Full size image

Lifetime of the WSN

WSN are deployed with the intention of providing long-term data collection at previously unimaginable scales and resolutions [35]. Typical WSN habitat monitoring applications benefit from long-term data that help decipher data trends and are necessary to detect significant change in habitat [36]. Thus, the lifetime of a WSN is a fundamental characteristic. It is bounded by the finite power source of the battery-operated motes and the nature of the deployed region, and infeasible or cumbersome task of replacing and disposing these batteries. This necessitates power management in hardware and software components of the motes [37, 3] and in WSN protocols [38]. Reinforcement strategies are also being explored in WSN through power harvesting techniques, from solar [28], mechanical, and thermal [29] sources.

Ad Hoc Communication

The lack of infrastructure in WSN is an intrinsic property of other communication systems like Bluetooth and mobile ad hoc networks (MANETs) [3]. Bluetooth employs discovery protocols and MANETs use robust and dynamic configuration protocols to establish and maintain the network infrastructure. Though these systems are the closest peers of WSN, there are fundamental differences that distinguish WSN from its peers [3]. First, WSN has larger number of motes with smaller transmission power and radio range, whereas Bluetooth and MANETs have smaller number of nodes with larger transmission power and longer radio ranges. Second, WSN and MANETs suffer from dynamic topology changes due to mote/node mobility and drop-out, but rate of mobility and drop-out is slower in WSN. Lastly, WSN motes have a finite, non-rechargeable power source, whereas Bluetooth and MANET nodes can be recharged. The critical power management in WSN imposes challenging requirements in WSN protocols and inhibits the direct use of existing Bluetooth and MANET protocols in WSN [3]. Therefore, WSN needs power-aware protocols for a large-scale, autonomous, and heterogeneous network of low-processing power and low-transmission rate motes. These protocols are needed for establishing and maintaining a secure network infrastructure through self-discovery, configuration, and healing, routing and inherent fault-tolerance.

Self-configuration and Organization

Various types of self-discovery algorithms exist for use in WSN, some are adaptations from Bluetooth discovery mechanism and others developed specially for WSN. Algorithms delineated in [39–41] and their like consist of a suite of protocols responsible for discovering motes and organizing the wireless infrastructure, despite topology changes and mote failures.

Connectivity and Coverage

Establishing and maintaining connectivity and coverage is an essential step in the deployment of a WSN. It is important to determine the initial number of motes required to maintain connectivity and coverage in the region of interest, in face of mote failure and drop-out. It is generally assumed that mote communication and sensing range are uniform and unidirectional, usually depicted as circular regions (cf. Sect. 2.1.1, Fig. 4).

Fig. 4
figure 4

WSN infrastructure-based data delivery models, unicast, broadcast, multicast, and many-to-many

Full size image

Furthermore, it is imperative for the configuration algorithms to maintain connectivity in the face of dynamic topology changes. Berman et al. [42] propose dominating k-connectivity, such that in the face of up to k mote failures, connectivity to a WSN sink is still maintained. Abbasi et al. [43] present a recovery technique for preserving connectivity in the face of mote failure. Others ([44–47], etc.) have also studied the matter of connectivity and coverage in WSN in great detail.

2 Communication Patterns and Protocols in WSN

After the WSN configuration and organization algorithms have set up the WSN infrastructure for routing and communication. WSN motes can collaboratively perform the application-specific distributed tasks across the WSN. Over the lifetime of the WSN, human operated base stations, which are essentially gateways to fixed infrastructure, e.g. Internet backbone, are used to query and retrieve data from the WSN.

2.1 Communication Patterns

There are two different approaches in sampling and retrieving data from the WSN, namely, the push and pull approach. In a push approach, WSN motes are programmed to autonomously sample the environment at fixed intervals and push their data into the network. They push data towards data collectors like the base station or sink. On the other hand, in the pull approach, motes wait for an explicit command from the base station or sink to start sampling [48]. Both approaches have their own advantages and drawbacks. Obviously, push approach suffers from continuous sampling, bottleneck at sink or base station but enjoys low latency query response [48], whereas in the pull approach, there is an increase in the number of messages required for querying and there is a longer delay in query response, but conserves power by explicit sampling rather than continuous sampling [48].

WSN applications typically utilized the push approach to conserve energy, when radio communication was more expensive than sensing on a mote [48]; however, advances in radio technologies have significant improvements in the power consumption, resulting in ultra-low-power radios, e.g. ZigBee radio [48]. Bose and Helal [48] propose a hybrid push–pull approach to sampling and retrieving data from a WSN to leverage the benefits of both techniques. The push, pull, or hybrid approach yields three distinct network traffic patterns in WSN. The push approach causes a many-to-one communication pattern, where motes are pushing data towards the sink or base station. In the pull approach, before motes-to-sink communication occurs, the sink or base station sends the explicit command to start sensing, which is one-to-many communication. When motes are collaboratively communicating to self-configure, localize, or for data fusion at multiple sinks, many-to-many communication occurs [49].

Apart from these traffic patterns in WSN, Tilak et al. [50] decompose communication paradigms in WSN into two categories, that is, application-based and infrastructure-based communication. Application-based communication refers to getting the sensed data from nodes to application user, whereas infrastructure-based protocols are those that are used to provide the underlying primitives to achieve the application-based communication.

We will discuss data delivery models from the application and infrastructure-based communication perspectives, followed by a discussion of the network architecture in WSN.

2.1.1 Data Delivery Models

From the aspect of infrastructure-based communication protocols the flow of data packets is based on four distinct data delivery models: unicast, broadcast, multicast [50], or many-to-many. Unicast is one-to-one communication between two motes, versus, the one-to-many (i.e., all motes in the communication range of a mote) communication of broadcast. The motes within the communication range of a mote are often referred to as one-hop neighbor or simply neighbors. In multi-hop communication, data is routed between motes, using unicast communication.

Multicast pertains to communication of motes in a group. Motes are categorized into groups by the application and only process those packets that contain a group identification number that matches the motes group identification number. These WSN groups can form a connected or disconnected sub-network. In a disconnected group, multi-hop communication would be used to enable multicast data delivery models. If there is a geographic overlay on the multicast WSN and packets are transmitted to motes based on their specific geographical location [51], then this specialized form of multicast data delivery is known as Geocasting. Multicast data delivery model can also be specialized to behave in a many-to-one data delivery manner.

Finally, many-to-many data delivery models result in the presence of multiple sinks or gateways accessing the WSN for data and information [49]. These data delivery models in WSN are illustrated in Fig. 4.

From the perspective of the application-based communication protocols, the data delivery models consist of continuous, event-driven, query-driven, or a hybrid approach of these [50, 52], as illustrated in Fig. 5. In continuous, also known as periodic, data delivery models, data is transmitted from the motes to the sink or gateways at periodic intervals. In event-driven models, the motes are sensitive to one or more physical factors of the environment, when the sensed value (sensor readings) meets or exceeds a predetermined threshold, an event is triggered. The triggered motes propagate their sensor readings back to the sink(s) or gateways. In query-driven data delivery models, user initiates a query and network motes which meet the query criteria transmit their sensor readings. In the hybrid approach, one or more of the data delivery models are used together. For example, in a volcano monitoring application, the motes would be primarily event-driven. However, occasionally the user may want to poll or query the WSN for current seismic or temperature readings.

Fig. 5
figure 5

WSN application-based data delivery models in WSN, periodic, event-driven, and query-driven

Full size image

2.2 Network Architecture of WSNs

The inherent characteristics of the motes in a WSN, such as limited processing, memory and communication capabilities, impose design and performance criteria on the routing and communication protocols in WSN. Communication protocols are used to dictate, manage, and control all aspects of communication, from the lowest layer of accessing the physical medium to higher layers responsible for end-to-end transmission of packets and routing of data, to the top most application layer for data and packet formation. Figure 6 depicts an overview of the network architecture in WSN.

Fig. 6
figure 6

Network architecture in WSN

Full size image

This is essentially different from typical network models due to the need for power management across all layers of the model. Furthermore, due to the constrained nature of motes and the application-specific nature of WSN, there is no clear demarcation in the network architecture layers, as in traditional network architecture. Often, fundamental WSN communication protocols for querying, routing, and data delivery are integrated under data dissemination and aggregation techniques in WSN [53]. These limitations instigate the use of a cross-layer approach in developing network protocols for WSNs.

In the following sections, we will discuss the various concepts of the transport, network, and data link layers with respect to WSNs.

2.2.1 Transport Layer Protocols

Transport layer protocols are responsible for end-to-end transmission of data packets. These protocols include provisions for reliable or unreliable data delivery and for centralized or distributed congestion control. It is imperative that these protocols be designed carefully, since they can quickly overwhelm the constrained WSN. As WSN applications mature, it is important to design and implement efficient protocols for the network architecture to ensure reliability in a data-driven network. Primitives are built into transport layer protocols for reliable data delivery that prompt retransmission of packet(s) in the event of packet drop. This can be achieved by using packet sequence numbers, a series of acknowledgements to confirm delivery of packets, or time-out or round-trip intervals to access packet loss. These primitives allow senders and receivers to account for packets received and packets missed. Such primitives are crucial in WSN applications, which are essentially data-driven networks.

Furthermore, transport layer protocols are also responsible for congestion controlled. This is achieved by installing primitives that control transmission rate of motes, to ensure that the rate at which data packets are being transmitted does not overwhelm the underlying network or create a bottleneck at the base station. Table 2 classifies some of the transport layer protocols developed for WSN with respect to these primitives [54–56].

Table 2 Classification of some transport layer protocols for WSN
Full size table

2.2.2 Routing in Network Layer

As in Wireless Computing, routing protocols can be decomposed into reactive, proactive, cooperative [57], or hybrid protocols. Proactive routing protocols are also known as table-driven protocols since each node maintains a route table for all destinations at all times. Reactive protocols are on-demand routing protocols, which only discover routes to a destination when it is required, outdated, or invalid. The obvious trade-offs include data delivery latency, routing protocol traffic overhead, and storage requirements. Data delivery latency is low in networks using proactive routing protocols, since path information is readily available. However, there is overhead incurred by the motes in the WSN, to discover and maintain paths to all destinations, even those that may never be used in the WSN. Routing protocol traffic overhead is minimized in reactive networks, when there is light network traffic and little changes to the network topology. Moreover, storage requirements of proactive routing protocols increase proportionally to the size of the network. In cooperative routing protocols, data is sent to a central entity that can further process the data and disseminate it accordingly [57].

Routing protocols can also be distinguished based on the communication entities involved in the routing protocol. In this perspective, there is node-centric and data-centric routing. In node-centric routing, data is routed between nodes, based on the node addresses. However, in data-centric routing, attribute based addressing is used, where nodes query for an attribute and only those nodes respond that can satisfy the query. For example, a mote can query for temperature greater than 72 °C, and those motes that have temperature readings more than 72 °C will respond.

Routing protocols are also designed for specific WSN topologies, classified as flat and hierarchical topologies, as illustrated in Fig. 2. On top of these WSN topologies, routing can also be geographical in nature, where packets are routed to motes closest to destination.

WSN routing protocols can also be based on different application defined criteria or operation-based attributes [57]. These operation-based attributes can include multipath, negotiation-based, query-based, QoS parameters (reliability, data integrity, energy efficiency), coherent [57] based routing techniques to increase reliability, security, etc., attributes.

Figure 7 depicts the various characteristics of WSN routing protocols, which can be integrated to design an efficient application-specific routing protocol for a WSN.

Fig. 7
figure 7

WSN routing protocol characteristics

Full size image

Multipath features in routing protocols can have a twofold benefit for WSN. Multipath routing can reduce frequency of updating routes, balance traffic load, and increase rate of data delivery [58]. This consequentially increases the lifetime and reliability of WSN. Earlier researchers proposed to use suboptimal routing paths with low energy consumption [59] or select a routing path based on the residual energy of the motes on the path [60]. The authors in [61] study the trade-off between traffic overhead and reliability using multipath routing in WSN. More recently, [58] uses multipath routing to increase lifetime of WSN and reduce collisions for transmission. Furthermore, researchers are utilizing ant colonization optimization, a swarm intelligence optimization technique, due to their proven success [62] in routing protocols for WSN. In [63], ant colonization is used to discover optimal routes to increase network lifetime and reliability, whereas [62] uses multipath routing to reduce congestion at the mote and link level. Authors in [64] survey swarm intelligence based routing protocols in WSN.

Routing protocols that are built on the pull approach, where queries can be propagated, are known as query-based routing protocols. Routing algorithms such as directed diffusion and rumor routing [57] are specifically implemented for query-driven data delivery models, where motes that meet the query requirements set up interest gradients or paths along which the data is routed to the sink. Negotiation-based routing algorithms suppress redundant data and use negotiation messages to ensure non-redundant data before transmission, e.g. Sensor Protocols for Information via Negotiation (SPIN) [65]. QoS-based routing ([66–69], etc.) ensures that routing in WSN meets application defined QoS metrics, of delay, energy, bandwidth, reliability, fault-tolerance, data integrity, etc. Data aggregation is also an important aspect of WSN and their applications, and is often accounted for when designing and developing routing protocols, to ensure efficient performance.

Not only is it important to secure the data and the motes in the WSN, but also the network traffic patterns. Since malicious motes can redirect traffic, inject false data or drop packets and cause havoc in the WSN, typical uses of asymmetric key cryptography or complicated symmetric key cryptography are infeasible for resource constraint WSN [70]. While there are techniques for implementing security on the data link layer in WSN, researchers are designing novel techniques for securing routing protocols [71–73], to increase reliability of WSN.

Table 3 classifies some WSN routing protocols based on the routing protocol characteristics illustrated in Fig. 7 [52, 57, 74–76, 71, 77–79].

Table 3 Classification of some WSN routing protocols
Full size table

2.2.3 Medium Access Control (MAC) Protocols at Data Link Layer

The MAC protocols at the data link layer manage how motes access the shared wireless medium and the backoff approach they employ in the event of a collision. In typical Wireless Networks, the radio channel is decomposed into multiple channels using techniques like time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA) to allow collision-free transmission of multiple message, simultaneously. Traditional WSN motes used a simple single channel radio to conserve energy, which is required to maintain the complex multiple channel radios [80]. However, recent advances in research have given rise to multi-channel radios for WSN motes.

WSN MAC protocols can be broadly classified into schedule based or contention-based medium access protocols. Schedule or reservation based MAC protocols devise an assignment that motes can follow for accessing the physical medium to avoid collision. Contention-based MAC protocols do not require an assignment, they define a backoff algorithm for motes to follow, when there is a collision in accessing the physical medium. Schedule based protocols can be further decomposed into synchronous, asynchronous, and hybrid protocols.

Since the MAC protocol directly controls the radio on a mote, an important technique used by motes is called duty cycling, where active motes periodically turn their radio off and go to sleep [81]. Synchronous schedule based MAC protocols require time synchronization and topology information to ensure that neighboring motes are active at the same time to communicate. However, asynchronous protocols do not require such synchronization or topology information and instigate communication between motes in different active cycles.

Contention-based MAC protocols eliminate the overhead of synchronization or network topology from schedule based MAC protocols. Motes can transmit packets immediately and retransmit in the event of a collision. A refined approach is to sense the physical medium for transmission, and when the medium is idle then access the medium and transmit the packet. This is the general concept in carrier sense multiple access (CSMA), which is one of the canonical contention-based MAC protocols.

Ye et al. [82] have identified four significant aspects of wasteful energy consumption, namely, collision, overhearing, control packet overhead, and idle listening at the data link layer. When two or more motes transmit at the same time, their respective packets are corrupted and require retransmissions increasing energy consumption and latency. Energy consumed in overhearing is energy spent listening for packets destined for other motes. Sending and receiving control packets without useful data is also wasteful with respect to energy consumed. Listening to the channel even when there are no radio transmissions is considered idle listening, which is an energy consumption overhead [81].

Contention-based protocols include techniques like CSMA and offer multiple benefits like low implementation complexity, flexibility in face of mobility, and varying traffic patterns [80]. However, schedule based MAC protocols like TDMA have intrinsic energy conserving features since there are no collisions, overhearing, and idle listening. Due to the energy conservation necessary in resource constraint WSN, it is important for MAC protocols for WSN to incorporate primitives for conserving energy by reducing collisions, overhearing, reduced control packet overhead, and idle listening, without the need for expensive time synchronization.

These MAC protocols require different degrees of collaboration and cooperation amongst the motes to achieve medium control access. Motes in the network could work completely independently in a random manner like those in contention-based MAC protocols, to slightly organized slotted MAC protocols and then to the very organized synchronous schedule based protocols like TDMA [80].

Various MAC protocols have been designed and implemented including synchronous duty cycling MAC protocols such as S-MAC [82], T-MAC, TRAMA, SCP, and DW-MAC. and asynchronous duty cycling MAC protocols such as X-MAC [83], B-MAC, WiseMAC, PW-MAC [81], and ASCEMAC [84]. An exhaustive MAC protocols survey is presented in [85]. MAC protocols are also being designed to include important features like security [86], power management [87], and QoS [88]. Table 4 delineates some of these protocols and their classification [80, 89].

Table 4 Classification of some WSN MAC protocols
Full size table

3 WSN Applications and Problem Space

Numerous intrinsic WSN characteristics distinguish it from its peers in other infrastructure-less communication systems [3] and distributed computing environments [90], where their nodes are more powerful (w.r.t. processor and radio) and reliable than WSN motes. Figure 8 [90] illustrates the difference in the problem space of WSN with other computing paradigms, with respect to functionality of the network nodes, size of the network, and spatial-temporal awareness of the nodes in the network.

Fig. 8
figure 8

Comparison of problem space of WSN with other computing paradigms

Full size image

WSN are distinguishable from real-time embedded systems primarily due to the lack of spatial awareness in embedded system nodes. Real-time embedded systems can include various other computing paradigms, especially, infrastructure-less mobile environments like Bluetooth personal area networks (PAN), MANET, cellular networks, and ad hoc networks.

WSN are significantly different from traditional distributed and supercomputing paradigms. Distributed computing includes paradigms such as peer-to-peer (P2P) networks, grid and high-performance computing. Apart from the lack of spatial and temporal awareness of the network nodes, another fundamental difference lies in the functionality of the network nodes. Typically, distributed and supercomputing paradigms consist of high-performance powerful nodes, as illustrated in Fig. 8.

WSN applications are sensitive to spatial and temporal parameters and can be classified into spatially and temporally related paradigms as follows. Firstly, in the spatial domain, WSN applications can be broadly classified into local and global WSN applications based on the size and coverage of the region of interest of the application. Similarly, WSN applications can also be temporally categorized into continuous, event-driven, query-driven, or hybrid applications (cf. Sect. 2.1.1, Fig. 5). This imposes a constraint on when the motes transmit data, either motes transmit data at periodic intervals, or transmit only the data that exceeds application defined triggers or threshold levels, or only those motes transmit data that meets a query criterion or a hybrid approach of these techniques. Figure 9 [49] broadly classifies some WSN applications into these domains.

Fig. 9
figure 9

Classification of WSN applications

Full size image

WSN application operations cannot be discretely categorized into the different temporal domains, since these networks are fundamentally data-driven networks. This implies events could be triggered in an otherwise periodic sampling WSN application like environmental monitoring. Furthermore, periodic sampling WSN applications like patient vitals health monitoring could quickly become query-based, if the WSN for patient vitals monitoring is polled for specific vital reading. Therefore, WSN applications are usually designed to operate in multiple temporal domains. Figure 9 illustrates these characteristics of WSN applications and delineates some WSN application examples that accurately fit the domains.

Figure 10 [49] delineates the various design characteristics that form the intrinsic nature and behavior of WSN applications and their motes. This directly influences the design for the components of the network architecture of the WSN. The figure also summarizes the various WSN characteristics we have discussed in this chapter.

Fig. 10
figure 10

WSN application design criteria

Full size image

4 Programming WSNs

WSNs can only be fully utilized, if WSN programmers have adequate software platforms [49] for efficient and reliable programming of large number of motes. However, due to the lack of programming, debugging, and development environment platforms, WSN programmers are forced to implement application-logic intertwined with low-level WSN implementation issues [49, 90]. This makes the application code complex, harder to debug and non-scalable for complex application development due to the interdependencies between performance and function [90]. Furthermore, this sort of programming falls out of the expertise of WSN application domain experts [49]. Mottola and Picco [49] discuss various other design criteria and components of WSN programming languages and their affect on the design and development of WSN applications.

Myriad WSN motes exist that differ in functionality as delineated in Table 1. Manufacturers often ship an operating system with the motes to ease in the handling of hardware and software components. Most WSN operating systems (OS) are either event-driven or multithreaded [91]. Multithreaded OS are similar to traditional OS, therefore easier for programmers to manage, however, infeasible for resource constrained WSN. Therefore, lightweight multithreaded OS have been designed and implemented for WSN motes. Event-driven OS do not tax the resources of the WSN motes but pose a learning curve for programmers of WSN applications. Farooq and Kunz [91] survey and classify operating systems such as TinyOS, Contiki, and MANTIS, in WSN.

In the following section, we will discuss TinyOS, an operating system for WSN, and consider a component-based approach to programming applications for WSNs using TinyOS.

4.1 TinyOS: An Operating System for WSN Motes

Operating systems (OS) are programs that coordinate all other programs, such as process scheduling and memory access. in a computer. The typical size of operating systems for embedded devices ranges in the order of megabytes; however, TinyOS is a much smaller operating system for WSN motes, approximately 400 bytes [92]. It is implemented in nesC [93], a variant of C. TinyOS is different from traditional OS, since it provides a framework and a set of component for programming motes to build application-specific operating system for a WSN application. Therefore, there is an operating system for each application. Typical TinyOS applications can range from approximately 15 Kbytes to more complex applications in the range of 64 Kbytes, of these the core operating system is about 400 bytes [92]. The networking architecture is encapsulated in Active Message interfaces, which are also implemented in nesC and offer fundamental communication primitives to TinyOS applications [49, 92]. Surge is the transport layer protocol implemented in TinyOS, which is unreliable and offers no primitives for congestion control [54]. Berkley MAC (B-MAC) is the asynchronous schedule based MAC protocol implemented in TinyOS [94], with interfaces available to change or adapt the MAC protocol.

TinyOS is a component-based programming model, where components are software abstractions of hardware components [92]. Therefore, a TinyOS application, which is really an application-specific operating system, is built on top of these reusable components [92], wiring them together to provide or use services. Components use interfaces to encapsulate a set of services [92]. For example, turning an LED on is a service that can be modeled by using the LED interface. Components use commands and events for inter-component communication. Commands to a component are requests to start a service, whereas events are signaled to mark the completion of the service at the component [92].

Programming in nesC consists of a configuration and module file. The configuration file connects components together, whereas the module file contains the implementation, by providing or using interfaces. Figures 11 and 12 illustrate a “hello world” TinyOS application, called Blink [95], where the red LEDS on a mote are toggled every 1,000 ms.

Fig. 11
figure 11

Blink.nc configuration file

Full size image
Fig. 12
figure 12

BlinkM.nc module file

Full size image

The Blink.nc configuration file shows how the components are wired together. A TinyOS application starts by executing the init command of the StdControl interface of the Main component. Blink configuration file wires the Main component’s StdControl to SingleTimer and Blink component StdControl. This binds the implementation of Main.StdControl to SingleTimer.StdControl and BlinkM.StdControl. The BlinkM. StdControl interface is implemented in the module file, BlinkM.nc. Similarly, the Timer and Leds interfaces used in Blink actually invoke the Timer interface provided by component SingleTimer, and Leds interface of component LedsC, respectively. Note, SingleTimer and Leds provide software abstraction of the hardware components for the clock and LEDS.

The configuration file delineates how control of execution is passed amongst components. The module file (BlinkM.nc) provides the application-specific implementation by providing and using interfaces. BlinkM.StdControl. init() initializes the application and BlinkM.StdControl.start() starts the component. When Blink starts, it sets the timer to repeat every 1,000 ms. In the event-driven operating system, since, there is no other code to execute, Blink waits until event Timer.fired() is triggered. When the event is triggered, Blink toggles the red LEDS.

The application is compiled for the target platform, any TinyOS compatible device, e.g. micaz motes, and flushed on the mote hardware using a programming board, which interfaces a mote with the development environment on a computer or laptop.

5 Summary

WSNs typically consist of large number of heterogeneous motes organized in a hierarchical manner, to monitor and/or control a region of interest, based on ambient environment factors. Generally, the number of motes deployed in the region increases and the resources decrease as you move down the hierarchy. The mobile, infrastructure-less WSN are able to truly achieve untethered communications in dangerous or mundane regions for autonomous data collection, analysis, and response via actuators. However, the greatest resource limitation of WSN is the power source, which must be optimally used or alternatively harnessed to ensure network lifetime.

There is a lack of standards for traditional network concepts, like architecture, topology, routing, and security, since WSN are application-specific in nature. Due to the different types of motes and WSNs, there are interoperability issues amongst the heterogeneous hardware units [96]. Further limitations of WSN are attributed to the lack of software for programming and debugging motes and WSN [49, 90].

Energy conservation and power management in the radio and network communications are the underlying design criteria for protocols and primitives in WSN. However, Bose and Helal [48] show that advances in technology have allowed low-power radios, like the Atmel Zlink RCB [48] for effective use in WSN and now attention needs to be on the sensor sampling technique, which consumes significantly more energy than network and application costs. Anastasi et al. [94] present a survey of energy conservation techniques in WSN.

Furthermore, apart from energy conservation, security challenges in WSN are a make it or break it criteria in the widespread use of WSN in all envisioned domains. Boyle and Newe [97] compare some security protocols in use today in WSN, like SPIN [98], consisting of SNEP (Secure Network Encryption Protocol) and μTESLA (micro version of Timed Efficient Stream Loss-tolerant Authentication), LEAP [99], and TinySec [100], which aim at building security features into network protocols.

As recent routing protocols have gained from swarm intelligence, Kulkarni et al. [101] discuss the use of other computational intelligence paradigms like neural networks, fuzzy logic, evolutionary algorithms, reinforcement learning, and artificial immune system in designing and implementing effective and efficient protocols and primitives for WSN operations like routing, deployment, localization, security, scheduling, data aggregation, and QoS management.

To summarize, in this chapter we considered the characteristics and features of WSNs and their motes. Furthermore, we reviewed the fundamental concepts in WSNs pertaining to architecture, topology, data delivery models, transport, routing, and data link layer protocols. We also presented a classification of some of the protocols for transport, routing, and data link layers. We concluded with a discussion of TinyOS, an operating system for WSN motes, and exemplified programming WSN motes in nesC.