Wireless Sensor Networks: The Current State of Technology

Transcription

1 Wireless Sensor Networks: The Current State of Technology Brad Christensen Student The University of Waikato, NZ Richard Sanger Student The University of Waikato, NZ Abstract Wireless sensor networks and their surrounding technologies have been heavily researched in the last 30 years and have moved from the realms of research into commercial deployments. This paper describes the origins of wireless sensor networks and the technical challenges involved with their development. We aim to give a broad overview of both software and hardware developments focusing upon the most commonly used standards seen in research and industry today and the issues these attempt to resolve. I. INTRODUCTION Wireless sensor networks (WSN) refers to a type of sensor network that uses wireless communication. Sensors convert a physical parameter or event into a digital representation allowing us to monitor the physical world around us. Two or more sensors can be linked together reporting there readings to a single destination to form a sensor network. WSNs allow the deployment of sensors cost effectively and quickly in remote areas where running a cable would be impossible, especially in situations where sensors are mobile or need to be rapidly deployed. Wireless sensors (or sensor nodes) compose of a sensor and additional on-board processing, storage capabilities and a wireless transmitter [1]. These processing and storage capabilities are often completely programmable allowing different operating systems and network protocols to be employed as required. Many factors make WSNs challenging to implement: sensor nodes are often battery powered and have significant processing and power usage constraints; deployment situations call for failure resilient protocols to adapt to a changing topography; and hardware restrictions limit range of wireless communications. WSNs are currently used in the real world outside of laboratory settings. The Golden Gate Bridge in San Francisco uses a WSN to monitor vibrations to assess the bridge s structural health [2]. Smart meters have been developed to monitor utilities such as electricity usage of homes to help power and line companies detect faults quickly and charge electricity based on the current rate. One such deployment has been carried out by WEL Networks, an electricity distribution company in New Zealand, placing smart meters into 45,000 homes [3]. These use wireless transmitters to transmit data back to WEL Networks through repeater stations placed on power poles. In section II of this report we will provide an overview of the history of WSNs, section III describes some of the unique challenges faced. Later in section IV we discuss the current state the hardware followed by software in section V. Finally we conclude with future predictions and suggestions for areas where more research could be useful. II. HISTORY The original development of sensor networks was for defence and military purposes. One of the first uses of a wired sensor network was in the 1950 s when the USA funded the Sound Surveillance System used to detect Russian submarines during the Cold War [4]. Acoustic sensors were deployed on the ocean floor with their output transmitted via cables back to base stations on shore where analysis took place [5]. In 1978 the Defense Advance Research Project Agency (DARPA) organised the Distributed Sensor Nets workshop which investigated the challenges with sensor networks including network protocols, signal processing techniques and distributed algorithms [1], [4]. Shortly after this, DARPA started the Distributed Sensor Networks (DSN) program to research these questions. This period of time is seen as the beginning of research into modern sensor networks [4]. As part of the DSN program work was conducted to create an experimental network using acoustic sensors to track low flying aircraft. This was the first sensor network to feature wireless communication in the form of large mobile nodes driven around on trucks which used microwave radio to communicate [4]. Work on small integrated devices like we imagine today when we think of WSNs was started by the University of California, Los Angeles in 1993 named Wireless Integrated Network Sensors (WINS); the first working version of the system was complete in 1996 [6]. WINS used battery powered sensors that communicated wirelessly with a conventionally powered base station. The sensor nodes were custom-fabricated for the project using a low cost CMOS fabrication process. Low power consumption was a primary concern for the project to allow these nodes to run on a battery for years at a time [7]. Many projects worked to better wireless sensors. The Smart Dust [8] project aimed to create wireless sensors with networking built-in in just a few cubic millimetre (effectively dust sized) sensors which they named motes. The largest problem that Smart Dust needed to overcome was the power consumption and size requirements that traditional radio wireless had with the need for a large antenna. The project included a passive retroreflector to reflect light back to the base station

2 without the need to power a laser on the mote [8]. While the project did not produce working dust-sized sensors by 2001 when DARPA funding ended, it had made prototypes demonstrating that this was going to be physically possible in the future [9]. In 1998, Motorola started working on a low power mesh networking protocol. In 2001 they made a proposal to the working group for the low rate standard, which emphasised the need for a low cost system having excellent sensitivity and long battery life [10]. Several companies including Motorola formed the ZigBee Alliance in 2002 to define the ZigBee specification for communication atop , which was ratified in 2004 [11]. Today while research into WSNs continues many commercially viable companies have been formed (many are spin-offs from research projects) that sell WSN devices and deployments [1]. III. CHALLENGES WSNs pose fundamental challenges over wired sensor networks. Some of these are due to application-specific requirements, many of which were simply not feasible using wired sensors such as applications using mobile sensor nodes. Other challenges come from the physical limitations of wireless and the additional hardware used to support it. Suggested uses of WSNs are broad and all-encompassing, from battlefield scenarios to industrial settings and the home, with dependences upon the network s performance ranging from a convenience to a critical piece of safety infrastructure with people s lives in the balance. Circumstances range from temporary deployments where minimising deployment time is important to long term monitoring projects where sensor nodes are expected to perform for years without human intervention. A. Energy Restrictions Most often WSNs are deployed in situations where a constant wired power supply in not available. In these cases a battery is used to power the sensor nodes. The sensor node power usage must be kept minimal to ensure maximum battery life. Wireless communications are the most taxing component of a sensor node on its battery: transmitting 1 Kb for distance of 100 m is approximately the same as that for the executing 3 million instructions by 100 million instructions per second/w processor [12, pp. 20]. As such, a large focus of research has gone into effectively reducing the power usage of nodes. Network protocols such as IEEE sacrifice speed and range for lower powered transmitters suitable for WSNs [13]. Media access control algorithms are designed to limit the contended access which wastes power when a radio transmission is started at the same time as another node resulting in both needing to retry [1]. Other approaches include taking advantage of the network topography using multiple hop mesh networks to allow a lower radio transmission power to be used reducing power consumption. This requires a routing protocol that can determine the network topography and efficiently route data with consideration of the power usage of other nodes, ensuring any one node is not used too frequently, which would deplete its battery [14]. Fig. 1. Base station Star topology Base station Mesh topology A star network topography (left) compared to a mesh topography Other techniques used to save battery include putting nodes into low power sleep states turning of the wireless radio completely for both transmitting and receiving and only waking at set intervals to report results and route network traffic [14]. Rechargeable batteries are also used with solar panels or other energy sources. B. Security and Reliability The network should attempt to remain functioning with the loss of nodes whether temporary or permanent. Factors such as faulty hardware, physical damage and outside interference with wireless communications could degrade the performance, cause incorrect results to be reported or remove a node from the network. In many situations the data collected by WSNs is private such as medical information and the data transfered across the network needs to be kept secure. In other circumstances such as battlefield deployment there is also the added risk of enemy forces sabotaging the network, inserting false data or destroying equipment. Security consists of meeting three main requirements: confidentiality, integrity and availability [1]. Typically encryption is used to ensure confidentiality, however algorithms that provide encryption are typically computationally expensive, which makes them unsuitable for wireless nodes due to both resource limitations and power constraints [1]. Integrity is most often maintained by the addition of a unique digital signature as part of encryption process. Availability is a challenge to maintain due to the unreliable nature of the nodes and wireless communications used in a WSN. Routing protocols like that used by ZigBee can form a mesh network [15]. Such protocols are designed to be resilient to node failing by attempting to route traffic on an alternative path. A few sensors may still fail to report data and as such WSN systems are often designed to aggregate results from multiple sensors allowing computations to continue even with missing data [15]. Faulty sensors can also be detected by comparing with neighbouring results. Due to the nature of the deployment of wireless senor nodes, often physical security is not possible; nodes are often located in remote locations and could easily be removed or tampered with, along with any data stored on them. C. Network Topography and Protocols Two main network topographies exist: a star network and mesh networks, as shown in Figure 1. A star network topography is a single-hop networks which consists of a

3 single wireless link between each sensor node and the base station [1]. By far this is the simplest to implement and is compatible with the dominant wireless IEEE standards. One downside to this approach is that sensor nodes cannot be placed outside of the range of the base station, which is particularly of concern if low powered wireless standards such as IEEE are being used due to their short range. In such cases mesh networks which are multi-hop are used, allowing other sensor nodes along the path to the base station to be used as repeaters [1]. This requires more complex routing protocols which are aware of a node s position in the topography and power management schemes to ensure nodes along the path are kept awake to forward data [14]. Other cases such as ad-hoc deployment, where sensors are deployed as needed in an undetermined pattern, require network protocols to discover neighbours and routing [14]. Situations where nodes are mobile on vehicles or persons also require discovery and tracking within the routing protocols. These algorithms are required to be lightweight in terms of memory usage, computation and data transfers due to the resource constraints of the sensor nodes. Due to the large number of nodes possible in WSNs, algorithms need to work with only small groups of immediate neighbors and complete network topography is not known [1]. IV. HARDWARE Wireless sensor nodes are small, low cost and low power devices that can be effectively deployed in high numbers across environments that tend to be large and volatile. For these reasons, a device typically consists of a microcontroller with a small amount of flash memory, a radio transceiver for wireless communication, a power supply, and transducers [15]. A transducer in a sensor node converts tangible energy to a signal for processing [16], [17]. Transducers are either soldered on to the microcontroller board or attached externally via an expansion bus, depending on the application [15]. The external approach is obviously more versatile and suited to ad-hoc applications, but the integrated approach may be more economically suitable to manufacture in high quantities. Most WSNs are passive, however in a cyber-physical systems network, a node would also include actuators that control the environment based on the signals it processes [17]. IEEE is now a de facto standard for wireless sensor networking [18]. It is a wireless standard that specifies the physical and medium access control layers of highly resource-constrained, low speed wireless personal area networks, providing reliable, potentially real-time performance [19], [18] with a maximum throughput of 250kbps [20]. This performance is acceptable for WSNs (which may only require a throughput of around 20kbps) and may be reduced even further to achieve a lower power draw as required. Wireless sensor nodes are therefore typically equipped with radios draws considerably less power than (WiFi) [21], and therefore is ideal for wireless sensor networks, whose nodes must typically be powered by batteries. In fact, based devices should be expected to last from several months to even years on a single battery charge, depending on the application. They could even outlive the shelf-life of their batteries [22]. In addition to WSNs, is particularly suitable for Internet of Things (IoT) devices [23], [24] and in future may be useful in certain cyber-physical systems [25] meets a wider variety of needs than Bluetooth for industrial applications [11]. Mesh networking is not part of , however the standard was designed with mesh networking in mind, leaving its implementation to the network layer [26]. The standard defines reduced-function and full-function devices: reducedfunction devices can only communicate with full-function devices, while full-function devices can communicate with any other devices. With these constraints, network topologies can be formed to suit the types of devices they contain. The standard defines star and peer-to-peer topologies [27]. V. SOFTWARE The ZigBee Alliance has developed several communication specifications for wireless products operating over , and commercial standards intended for the certification of Internet of Things devices. Historically, the ZigBee Alliance made a major tradeoff to not use the IP suite in their Zig- Bee specification an interesting choice, given that ZigBee primarily targeted IoT devices that would then still have to be indirectly connected to the Internet by some means. The decision to eschew the Internet Protocol came as a result of maximum packet sizes in being much smaller than the sizes of packets carried over Ethernet; the lack of mesh networking support in IP; and the desire to avoid as much unnecessary overhead as possible. However, avoiding IP turned out to be a poor choice, as although the specification was used effectively by many applications in millions of devices, it was not easily translatable for use atop other protocols such as WiFi or HomePlug. As such, the ZigBee Alliance eventually committed to producing an alternative, IP-based standard [28]. Meanwhile however, in response to two fundamental inadequacies with the ZigBee standard, an alternative communication protocol was developed known as 6LoWPAN, an implementation of IPv6 over LoWPAN firstly addressed the need for direct Internet connectivity in IoT devices, and secondly made available an open-source alternative to the commercial ZigBee standard. 6LoWPAN is typically used in conjunction with the Routing Protocol for Low-powered and Lossy Networks (RPL) [23]. ZigBee Alliance later released the ZigBee IP stack, which incorporates 6LoWPAN and RPL [29]. ZigBee IP became the first mesh networking solution for IP-based devices, as 6LoWPAN/RPL do not support mesh networking on their own [26]. While specifications produced by the ZigBee Alliance are available for free to the general public, membership in the ZigBee Alliance is required to market products using the ZigBee brand and to participate in development of standards [30], [31]. The paid membership requirement conflicts with the GNU General Public License and as such, free software developers are unable to use ZigBee in their own products [26]. Especially notably, this caused Linux developers to abandon ZigBee in favour of incorporating 6LoWPAN into the Linux kernel instead [26], [32].

4 The three ZigBee Alliance specifications are ZigBee (available as ZigBee or ZigBee PRO), ZigBee IP and ZigBee RF4CE. The latter is designed for simple, device-to-device networks for applications such as light switches, garage door openers and other remote control systems [33]. ZigBee and ZigBee IP are more suitable for use in WSNs. 6LoWPAN is the primary alternative to these two protocols, and in some cases may be the only viable option with regards to licensing. A. Operating Systems Operating systems for wireless sensor nodes are typically stripped down to the minimum feature set required for a particular application due to the fact that they are deployed on embedded platforms. For this reason, they do not resemble operating systems used for general-purpose computing. Their purpose is therefore primarily to provide an abstraction layer for simplified access to hardware functions, and to provide a scheduler for handling the execution of processes. They can also provide memory management, file management, and commonly required tools for application development [1]. Operating systems are not typically compatible with ZigBee Alliance specifications, as they are largely open-source. Using operating systems to deploy software on wireless sensor nodes also allows developers to take advantage of the ability to strongly modularise applications. This follows the Separation of Concerns law in programming. Using an operating system can also mean that applications are trivially portable to other hardware supported by the operating system currently and in the future [1]. A potential disadvantage could be the overhead of execution performed by the operating system, however operating systems designed for WSNs typically have strictly constrained memory, power and execution footprints already. Three currently prominent, continuously developed operating systems for use in WSNs are TinyOS, Contiki and LiteOS, and are discussed briefly below. Many other operating systems have also been developed for WSNs but none have installation bases as large as these three. 1) TinyOS: TinyOS is an open-source operating system targeted towards wireless sensor networks furthermore, Levis et al. [34] claim it to be the platform of choice for sensor network research, and Dargie and Poellabauer [1] claim that it is the most widely used, richly documented runtime environment in WSNs. TinyOS features more than a decade worth of software development, and provides a 6LoWPAN/RPL IPv6 stack [35]. TinyOS chose to eschew the multi-threaded concurrency model because of the memory overhead of threads, instead opting to use an event-triggered model [36]. TinyOS applications are written in a dialect of C called nesc. TinyOS was the first operating system of its kind for wireless sensor networks and as such, other operating systems such as Contiki and LiteOS draw on its performance and development experiences in their implementations. 2) Contiki: Contiki is a rapidly developing operating system designed to be used for IoT devices. It is open-source and provides support for a full IPv4 or IPv6 stack including UDP and TCP. It also supports HTTP, 6LoWPAN, RPL and Constrained Application Protocol (CoAP), a RESTful protocol for accessing device resources, which runs over UDP [37]. Contiki additionally provides a custom wireless networking stack called Rime, which provides a set of lightweight communication primitives based on what typical sensor network protocols use [38]. Contiki uses lightweight, stackless threads called protothreads for concurrent programming. Protothreads are not preemptable, meaning that context switches can only occur on blocking operations [39]. Dunkels et al. [40] believe that protothreads reduce the complexity of high-level sensor node programs, compared to the model of concurrency used in TinyOS. 3) LiteOS: The purpose of LiteOS is to reduce the learning curve typically associated with building applications for WSNs, such as with the event-driven programming model and non-standard language dialect required by TinyOS. LiteOS provides Unix-like abstractions for wireless sensor networks, aiming to provide novel features that make developing the operating system more intuitive for users with backgrounds in Unix [41]. One such feature is the representation of the sensor network as a Unix-like file system, with the tradeoff that more network traffic is required to maintain state information [1]. VI. CONCLUSION Innovation is slowing in WSN research as the technology reaches its maturity. WSNs are no longer confined to research labs and military deployments; in the past decade, their commercialisation has been widespread. Networks consisting of tens of thousands of nodes are not uncommon, let alone no longer only theoretical. With that said however, some of the most recent developments, although iterative, have had the most significant implications. Commercialisation has only become possible with the establishment of robust software and consistent, agreed-upon standards. The failure of the ZigBee Alliance to produce an IP-based protocol for directly connecting devices to the Internet presented a fundamental inadequacy for several years before the advent of 6LoWPAN and subsequently the very recent introduction of ZigBee IP. With ZigBee IP finally comes the possibility for IP-based devices to be connected via a mesh network, which makes available all desirable features of WSN communication in one specification. This represents a significant step forward in WSN technology, but it is unfortunately not the final hurdle. Due to the licensing incompatibility between ZigBee Alliance intellectual property and the GPL, it is not likely that we will see the ZigBee IP standard supported in the Linux kernel, or by any free-libre software in the near future, such as the embedded operating systems we have discussed above. Those not willing to use the ZigBee Alliance specifications are therefore limited to using 6LoWPAN, which lacks support for mesh networking. Future developments in WSN research will further improve the robustness of software, as hardware has now largely become irrelevant. This will be driven by the market for IoT devices and, in future, development of cyber-physical systems.

5 REFERENCES [1] W. Dargie and C. Poellabauer, Fundamentals of wireless sensor networks: theory and practice. John Wiley & Sons, [2] S. Glaser and T. Parkkila, Sensor-networks in the real world, ERCIM News, vol. 76, pp , [3] WEL Networks, Smartbox at a Glance, Network/Smartbox/Smartbox-at-a-glance/, [Online; accessed 1-May- 2014]. [4] C.-Y. Chong and S. P. Kumar, Sensor networks: evolution, opportunities, and challenges, Proceedings of the IEEE, vol. 91, no. 8, pp , [5] E. C. Whitman, Sosus: The secret weapon of undersea surveillance, Undersea Warfare, vol. 7, no. 2, p. 256, [6] G. J. Pottie and W. J. Kaiser, Wireless integrated network sensors, Communications of the ACM, vol. 43, no. 5, pp , [7] K. Bult, A. Burstein, D. Chang, M. Dong, M. Fielding, E. Kruglick, J. Ho, F. Lin, T.-H. Lin, W. J. Kaiser et al., Low power systems for wireless microsensors, in Low Power Electronics and Design, 1996., International Symposium on. IEEE, 1996, pp [8] J. M. Kahn, R. H. Katz, and K. S. Pister, Next century challenges: mobile networking for smart dust, in Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking. ACM, 1999, pp [9] K. Pister, Smart Dust, pister/smartdust/, [Online; accessed 1-May-2014]. [10] E. Callaway, PHY proposal for the low rate standard, Slides, July [Online]. Available: TG4-Motorola-PHY-Proposal.ppt [11] N. Baker, ZigBee and Bluetooth: Strengths and weaknesses for industrial applications, Computing & Control Engineering Journal, vol. 16, no. 2, pp , [12] D. K. Gupta, A review on wireless sensor networks, Network and Complex Systems, vol. 3, no. 1, pp , [13] J. A. Gutierrez, M. Naeve, E. Callaway, M. Bourgeois, V. Mitter, and B. Heile, IEEE : a developing standard for low-power lowcost wireless personal area networks, network, IEEE, vol. 15, no. 5, pp , [14] E. Niewiadomska-Szynkiewicz, P. Kwaśniewski, and I. Windyga, Comparative study of wireless sensor networks energy-efficient topologies and power save protocols, Journal of Telecommunications and information technology, pp , [15] P. Baronti, P. Pillai, V. W. Chook, S. Chessa, A. Gotta, and Y. F. Hu, Wireless sensor networks: A survey on the state of the art and the and ZigBee standards, Computer communications, vol. 30, no. 7, pp , [16] F. L. Lewis, Wireless sensor networks, Smart environments: technologies, protocols, and applications, pp , [17] R. Frank, Smart sensor basics, in Understanding smart sensors. Artech House, [18] C. Na, Y. Yang, and A. Mishra, An optimal GTS scheduling algorithm for time-sensitive transactions in IEEE networks, Computer Networks, vol. 52, no. 13, pp , [19] Y.-H. Wei, Q. Leng, S. Han, A. K. Mok, W. Zhang, and M. Tomizuka, RT-WiFi: Real-time high-speed communication protocol for wireless cyber-physical control applications, in Real-Time Systems Symposium (RTSS), 2013 IEEE 34th. IEEE, 2013, pp [20] J.-S. Lee, Y.-W. Su, and C.-C. Shen, A comparative study of wireless protocols: Bluetooth, UWB, ZigBee, and Wi-Fi, in Industrial Electronics Society, IECON rd Annual Conference of the IEEE. IEEE, 2007, pp [21] E. Callaway, Low power consumption features of the IEEE /ZigBee LR-WPAN standard, Slides, November [Online]. Available: callaway.pdf [22] A. Prince-Pike and J. Collins, Power characterisation of zigbee wireless networks, in 16th Electronics New Zealand Conference (ENZCon 2009), T. Molento, Ed., Dunedin, New Zealand, 2009, pp [23] J. Schönwälde, Internet of things: , 6LoWPAN, RPL, CoAP, Slides, October [Online]. Available: utwente-6lowpan-rpl-coap.pdf [24] D. Minoli, Building the Internet of Things with IPv6 and MIPv6: The Evolving World of M2M Communications. Wiley, [Online]. Available: [25] F. Xia, A. Vinel, R. Gao, L. Wang, and T. Qiu, Evaluating IEEE for cyber-physical systems, arxiv preprint arxiv: , [26] A. Ott, Wireless networking with IEEE and 6LoWPAN, Slides, November [Online]. Available: Networking with IEEE and 6LoWPAN.pdf [27] IEEE Computer Society, IEEE standard for local and metropolitan area networks - part 15.4: Low-rate wireless personal area networks (LR-WPANs), IEEE Std , [28] B. Gohn, The ZigBee IP-ification wars, May [Online]. Available: %E2%80%9Cip-ification%E2%80%9D-wars [29] ZigBee Alliance, ZigBee IP specification overview. [Online]. Available: [30], Membership FAQ, Internet Archive, November [Online]. Available: [31], Membership FAQ, Internet Archive, November [Online]. Available: [32] A. Aring, Current state of the IEEE /6LoWPAN stack inside the Linux kernel, Slides, January [Online]. Available: 351/export/events/attachments/deviot04/slides/351/ linux iot 6lowpan slides.pdf [33] ZigBee Alliance, ZigBee RF4CE overview. [Online]. Available: [34] P. Levis, S. Madden, J. Polastre, R. Szewczyk, K. Whitehouse, A. Woo, D. Gay, J. Hill, M. Welsh, E. Brewer et al., TinyOS: An operating system for sensor networks, in Ambient intelligence. Springer, 2005, pp [35] TinyOS developers, A 6LoWPAN implementation for TinyOS 2.x, Readme file, March [Online]. Available: [36] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. Culler, and K. Pister, System architecture directions for networked sensors, in ACM SIGOPS operating systems review, vol. 34, no. 5. ACM, 2000, pp [37] Contiki developers, Contiki, March [Online]. Available: [38], Contiki 2.6: The Rime communication stack, Contiki Source Code Documentation. [Online]. Available: [39] A. Dunkels, O. Schmidt, T. Voigt, and M. Ali, Protothreads: Simplifying event-driven programming of memory-constrained embedded systems, in Proceedings of the 4th International Conference on Embedded Networked Sensor Systems, ser. SenSys 06. New York, NY, USA: ACM, 2006, pp [Online]. Available: [40] A. Dunkels, O. Schmidt, and T. Voigt, Using protothreads for sensor node programming, in Proceedings of the REALWSN, vol. 5, [41] Q. Cao, T. Abdelzaher, J. Stankovic, and T. He, The liteos operating system: Towards unix-like abstractions for wireless sensor networks, in Information Processing in Sensor Networks, IPSN 08. International Conference on. IEEE, 2008, pp