Evolution of Software-Defined Sensor Networks - IEEE Xplore

2013 IEEE 9th International Conference on Mobile Ad-hoc and Sensor Networks

Evolution of Software-Defined Sensor Networks Deze Zeng, Toshiaki Miyazaki, Song Guo, Tsuneo Tsukahara, Junji Kitamichi and Takafumi Hayashi School of Computer Science and Engineering, The University of Aizu Aizu-wakamatsu, Fukushima, Japan [email protected]

Abstract—After a decade of extensive research on applicationspecific wireless sensor networks (WSNs), the recent development of information and communication technologies make it practical to realize a new WSN paradigm, software-defined sensor network (SDSN), which is able to adapt to various application requirements and to fully explore the communication, computation and sensing resources of WSNs. Sensor nodes in SDSNs can be dynamically reprogrammed for different sensing tasks via the over-the-air-programming technique. In this paper, we introduce the concept of SDSNs and outline several pioneering related work and enabling technologies for the realization of SDSNs.

I. I NTRODUCTION The last decade has seen a fast development of cyberphysical system (CPS) and a large increasing in sensor network usage. With the recent advancement in information and communication technologies, sensors have become cheaper, smaller and easier to use. Wireless sensor networks (WSNs) become unprecedentedly capable of building smart systems. Consequently, WSNs have been widely deployed for a wide span of applications including surveillance, tracking, and controlling. Tremendous benefits are taken to the human beings through these applications. On the other hand, cloud computing emerges as a new popular computing paradigm for enabling convenient and on-demand access to a shared pool of configurable computing resources, e.g., networks, servers, storage, applications, etc., and is bringing in an efficient model to provide various resources “as a service”, e.g., Infrastructure-as-a-Service, Platform-as-a-Service, Softwareas-a-Service, with different kinds of abstractions on the provisioning resources. As a result, a straightforward wandering is that whether we can integrate sensor resources into the cloud computing platform and enable “Sensing-as-a-Service”. It is expected that such integration will bring mutual benefits to both WSNs and cloud computing. To WSNs, several inherent WSN shortfalls like low storage and processing capacity of sensors can be solved by exploring the cloud resources. To cloud computing, by abstracting the sensors into various on-demand sensing services, existing cloud computing platform will be enriched with new service paradigm, i.e., “Sensing-as-a-Service”. It can be seen that such integration improves both the scalability, reliability, flexibility and functionality of WSNs and the richness of cloud services. An architecture overview for “Sensing-as-a-Service” paradigm is shown in Fig. 1. The service process is similar to requesting existing cloud services. A user first initiates a sensing request at any front portal. The request will be then

978-0-7695-5159-3/13 $31.00 © 2013 IEEE DOI 10.1109/MSN.2013.60

Fig. 1.

SDSNs based Cloud Sensing Architecture

forwarded to the core controller, which will interpret the sensing request and push the request to appropriative sensor network(s) that happen to satisfy the sensing request. The sensing data can be combined with existing cloud services (e.g., Google Map1 ) at the mashup server to provide mashup services [1]. The sensed data can be also stored in a local database for future use. Conventionally, in order to satisfy various sensing requests, multiple WSNs for respective tasks may need to deploy in the same area. Obviously, this incurs high deployment cost. Furthermore, altering existing code on application-specific sensor nodes is difficult, highly error-prone, and costly. What’s worse, different vendors develop their application-specific WSNs in an isolated manner, even in the same area, without sharing common functionalities, leading to service isolation and lowutilization. Software-defined sensor networks (SDSNs) consisting of software-defined sensor nodes that can dynamically change their functionalities and properties by loading different programs on-demand according to the real-time sensing requests emerge as a compelling solution to the above issues [2]– [4]. By integrating cloud computing platform into SDSNs, as shown in Fig. 1, if the requested sensing service cannot be satisfied by existing sensors, on-demand program will be injected to reprogram some sensors according to the sensing requirements. Therefore, for the realization of “Sensing-as-aService”, there shall be a natural evolution from conventional application-specific WSNs to SDSNs. SDSN plays an impor1 https://maps.google.com/

410

Fig. 2.

Fig. 3.

Software-Defined Sensor Network Architecture

Logical View of SDSN

task. Because it is difficult to incorporate such capability into existing commercially available sensor nodes, we developed an original sensor node to implement this concept. In order to handle sensed dataand communicate effectively using wireless transmission with a low-power microcontroller unit (MCU), this novel sensor node had to have both hardware and software reconfigurability.

tant role in such service paradigm. While many efforts have been made to enhance the applicability and performance of WSNs from different layers, they mainly focus on applicationspecific WSNs. SDSNs, although with great potential, are in their early age and still under-investigated. Therefore, in this paper, we are motivated to introduce the concept of SDSNs. The rest of this paper is organized as follows. Section II provides a brief overview of SDSNs. Section III gives some enabling technologies and outlines several related work to SDSNs. Then, in Section IV, we introduce an ongoing nationwide SDSNs project in Japan. Finally, Section V concludes our work.

B. Logical View Logically we can divide an SDSN into three layers, i.e., physical layer, networking layer and application layer. The physical layer refers to various computation, communication and sensing resources. On above of it, we have the networking layer mainly in charge of data transmission. Different from conventional application-specific WSNs where there is only sensing data transmission, various control information is also needed to be transmitted in this layer. On the top of the logical diagram, the application layer manages all the sensing tasks, e.g., role programs. Every layer in SDSN is softwaredefinable. The is also the main feature of SDSNs. There are also several key enabling technologies to support the software-definability. In the physical layer, we have softwaredefined radio (SDR) [7] to control the media access while in the networking layer, we have software-defined networking (SDN) [8] to control the data delivery. Operation system (OS) is available in the application-layer to manage all the sensing tasks and resources in the sensor node. Furthermore, OTAP and field-programmable gate array (FPGA) enable the software-definability in all layers.

II. OVERVIEW OF SDSN S A. SDSN Architecture As an essential part of the architecture shown in Fig. 1, a detailed overview of SDSN is shown in Fig. 2. which consists of one sensor control server and a set of softwaredefined sensor nodes. To deploy a new sensing task, the sensor control server shall reprogram some sensor nodes by distributing a corresponding program to them for the task. Only the reprogrammed sensor nodes are able to sense the related targets within its coverage area. The sensor control server provides a role generation and delivery mechanism, in which a scenario compiler generates sensor role program based on a scenario description that specifies the functions to be activated in sensor nodes. In SDSNs, “role” refers to a configuration on the activity (e.g., cluster head, data aggregator, temperature sensing, etc.) of a sensor node [5], [6]. The programs are then delivered to the appropriate sensor nodes via wireless communications to make them behave as desired. Thus, the behavior of the sensor nodes can be customized at any time after SDSN deployment. To generate a role program, the scenario compiler refers to a function library with some basic functions, e.g., data transmission, data relay, and data collection, etc., which can be retrieved to compose desired role program. For role program delivery, over-the-air programming (OTAP) technique can be explored. Each sensor node has a mechanism to dynamically initiate a “role” in response to the user requests. By invoking a generated role program downloaded to a sensor, the sensor can adjust its functionalities and properties to perform the corresponding

III. E NABLING T ECHNOLOGIES AND R ELATED W ORK In this section, we introduce the key enabling technologies mentioned in the SDSN logical view as well as their related work. A. Software-Defined Radio SDR is able to sense the vacant spectrum bands and dynamically change the operating parameters to make use of them opportunistically. This can significantly improve the overall spectrum efficiency and utilization. As there may be a lot of sensors communicating wirelessly in a WSN, WSN can be also regarded as a spectrum-hungry network. Opportunistic spectrum access may also help realize the deployment of

411

methods of distributing new software updates or configuration settings to devices with wireless communication capabilities like smartphones, wireless routers or base stations. OTAP has been widely and successfully applied to smartphones. An over-the-air update may refer simply to a software update that is distributed over Wi-Fi or mobile broadband using a function built into the operating system, with the “overthe-air” aspect referring to its use of wireless communication instead of requiring wired connection between the device and a computer to perform the update. The recent advancements in smartphones have made OTAP become increasingly important to deliver software updates and new services. Due to the importance of OTAP, various standardization bodies are established, e.g., Open Mobile Alliance (OMA)2 . More recently, OTAP also attract a lot of attention in the field of WSNs, where the networks consist of hundreds or even thousands of wireless nodes often located in places that are either remote or difficult to access. Researchers from both academia and industries advocate applying OTA to unlicensed frequency bands (e.g., 2.4 GHz) using protocols such as 802.15.4 and ZigBee. As an example, Libelium has implemented an intelligent and efficient OTAP programming system for firmware upgrades in ZigBee WSN sensors [14].

multiple overlaid sensor networks, and eliminate collision and excessive contention delay incurred by dense node deployment. Therefore, it is natural to integrate SDR into WSNs to improve the spectrum efficiency, yielding a new sensor networking paradigm, i.e., Cognitive Radio Sensor Networks (CRSNs) [9]. CRSNs can be also regarded as SDSNs as the radio access can be dynamically adjusted on-demand according to the real-time requirements. However, SDSNs are far beyond CRSNs that SDSNs require all-layers can be software-defined while CRSNs only consider the softwaredefinability in the communication layer. B. Software-Defined Networking SDN is an emerging computer networking approach that allows network administrators to manage network services through the abstractions of low-level networking functionality. Such paradigm is realized by by decoupling the control plane and data (forwarding) plane. By such means, the functionality of the network can be defined, or reconfigured, via a standard programming interface (e.g., OpenFlow [8]) according to the transmission requirement after it has been deployed. For example, via OpenFlow, we can define the forwarding rules for different flows and the corresponding actions (e.g., drop, forward, modify, etc.) will be taken once a packet match a rule. SDNs, with the potential to dramatically simplify network management and enable innovation through network programmability, has been regarded as a “radical new idea in networking”. Luo et al. [3] propose the concept of “Sensor Openflow” and believe that SDN technique provide a promising solution to network management in WSNs.

E. Field-Programmable Gate Array Technique An FPGA is a “field-programmable” integrated circuit whose processing logics can be configured by users after manufacturing. The FPGA configuration is usually specified by a hardware description language. FPGAs contain programmable logic components called “logic blocks”, which are connected by reconfigurable interconnections. Logic blocks can be configured to perform various operations, from simple logic operations like AND or XOR to complex combinational functions, or even analog processing. The dynamic reconfiguration capability of FPGAs enable the FPGA-based system to be reconfigured at run-time via changing the content of the logic blocks as well as the interconnection configuration. The most attractive features of FPGA technique to SDSNs are the reconfigurability and energy efficiency. Other than simply data sensing, sensors are usually required with certain data processing capabilities, e.g., data compressing, aggregation, etc. In this respect, micro-controllers based sensor’s processing capability sometimes is quite limited and energy-consuming, FPGA could be a compelling solution, as indicated in [15]. Nowadays, FPGAs can be manufactured with the 28 nm CMOS technique. Various energy-efficient solutions are applied to enable FPGA run in ultra low-power mode. Moreover, stateof-the-art FPGAs are empowered with capabilities to perform high-speed multiplication and addition operations. FPGA can perform several tasks in place of the micro-controller and add auxiliary energy-efficient processing capabilities to a sensor node. For example, micro-controller can offload some heavytask onto FPGA configured special for that task, e.g., data encryption and decryption, data compression and aggregation, etc. Furthermore, FPGA can also be used for sensor unit connection. Connecting some intelligent sensor units require

C. Wireless Sensor Operating Systems In SDSNs, the resources in a sensor node shall be managed, controlled and allocated in an orderly manner in the support of various sensing tasks. Besides, the sensor node shall allow application programmers to adjust the sensor functionalities via invoking different programs. In this case, a sensor is equivalent to a miniaturized computer with various sensing capabilities. All these issues ask for the introduction of operation system (OS), just like how we do in general-purpose computers. However, wireless sensor nodes are usually equipped with capability-limited resources e.g., limited storage and computational abilities. The OS for wireless sensors shall be typically less complex than general-purpose ones. Many WSN OSs with different features have been proposed, such as TinyOS [10], Contiki [11] and LiteOS [12], as surveyed by Farooq et al. in [13]. TinyOS is a representative and widely used. It is with total footprint of 400 bytes and can be easily put into low-storage sensors. TinyOS abstract the underlying hardwares and provide a library includes packet communication, routing, sensing, actuation and storage, based on which programs can be built. WSN OS provides a fundamental support for the realization of SDSNs. D. Over-The-Air-Programming Technique OTAP is essential to SDSNs for role program delivery, control message delivery, etc. Originally, OTAP refers to various

2 http://openmobilealliance.org/

412

relatively complicated interfaces and command sequences, which can be easily realized using FPGA technique. In particular, this also allows easy alternation on the connections at runtime.

SDSNs. We also introduce an ongoing SDSN project in Japan and our initial achievements. We hope this work will inspire more effort to push forward the development of SDSNs and make SDSNs be ready for “Sensing-as-a-Service”.

IV. D EMAND -A DDRESSABLE S ENSOR N ETWORK P ROJECT

ACKNOWLEDGMENT

The promising potentials of SDSNs have inspired an SDSN project in Japan called Demand-Addressable Sensor Network (DASN), which is driven by the authors.

This work is partly supported by Strategic Information and Communications R&D Promotion Programme (SCOPE No. 121802001) and Grants-in-Aid for Scientific Research (No. 23500095).

A. Overview of DASN Project

R EFERENCES

The aim of DASN project is to construct a wide-area sensor network that interprets users’ abstract sensing demands. The network then finds the sensors that hold the data which satisfies the demand, mashes up the collected data within the network along with useful information from other systems, and finally enables the user’s terminal to display it in real time. The sensor network itself has an environmental adaptability that allows each sensor node to consider its surroundings and the userissued requests, and which will then dynamically change its role to actively acquire the desired sensing data autonomously. We focus on the development of the following two technologies, and construct a disaster site monitoring system by combining them. 1) Demand Addressable Network: Technology that transmits user requests (demands) to appropriate sensors, combines sufficient amounts of called-for data from these sensors with other relevant information, and then provides the resultant data to the user. 2) Environmental Adaptive WSN: WSN comprised of sensor nodes that can dynamically change their respective roles in accordance with changes in the environment and user requests.

[1] D. Zeng, S. Guo, and Z. Cheng, “The Web of Things: A Survey,” Journal of Communications, vol. 6, no. 6, pp. 424–438, 2011. [2] Y. Xu, S. Helal, and M. Scmalz, “Optimizing Push/Pull Envelopes for Energy-Efficient Cloud-Sensor Systems,” in Proceedings of the 14th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM). ACM, 2011, pp. 17–26. [3] T. Luo, H.-P. Tan, and T. Quek, “Sensor OpenFlow: Enabling SoftwareDefined Wireless Sensor Networks,” IEEE Communications Letters, vol. 16, no. 11, pp. 1896–1899, 2012. [4] A. Cuzzocrea, G. Fortino, and O. Rana, “Managing Data and Processes in Cloud-Enabled Large-Scale Sensor Networks: State-Of-The-Art and Future Research Directions,” in Proceedings of the 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGrid). IEEE, 2013, pp. 583–588. [5] C. Frank and K. R¨omer, “Algorithms for Generic Role Assignment in Wireless Sensor Networks,” in Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems (SenSys), ser. SenSys ’05. New York, NY, USA: ACM, 2005, pp. 230–242. [Online]. Available: http://doi.acm.org/10.1145/1098918.1098944 [6] ——, “Solving Generic Role Assignment Exactly,” in Proceedings of the 20th International Conference on Parallel and Distributed Processing (IPDPS). IEEE, 2006, pp. 177–177. [7] F. K. Jondral, “Software-Dened RadioBasics and Evolution to Cognitive Radio,” EURASIP Journal on Wireless Communications and Networking, vol. 2005, no. 3, pp. 275–283, 2005. [8] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, “OpenFlow: Enabling Innovation in Campus Networks,” ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp. 69–74, 2008. [9] O. Akan, O. Karli, and O. Ergul, “Cognitive Radio Sensor Networks,” IEEE Network, vol. 23, no. 4, pp. 34–40, 2009. [10] 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. 115–148. [11] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki-A Lightweight and Flexible Operating System for Tiny Networked Sensors,” in Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks (LCN). IEEE, 2004, pp. 455–462. [12] Q. Cao, T. Abdelzaher, J. Stankovic, and T. He, “The LiteOS Operating System: Towards Unix-Like Abstractions for Wireless Sensor Networks,” in Proceedings of the International Conference on Information Processing in Sensor Networks (IPSN). IEEE, 2008, pp. 233–244. [13] M. O. Farooq and T. Kunz, “Operating Systems for Wireless Sensor Networks: A Survey,” Sensors, vol. 11, no. 6, pp. 5900–5930, 2011. [14] D. Gasc´on, A. Bielsa, F. Genicio, and M. Yarza, “Over the Air Programming with 802.15.4 and ZigBee OTA,” http://www.libelium.com/over the air programming OTA 802.15.4 ZigBee/, 2011. [15] A. de la Piedra, A. Braeken, and A. Touhafi, “Sensor Systems based on FPGAs and Their Applications: a Survey,” Sensors, vol. 12, no. 9, pp. 12 235–12 264, 2012. [16] T. Miyazaki, D. Shitara, Y. Endo, Y. Tanno, H. Igari, and R. Kawano, “Die-hard Sensor Network: Robust Wireless Sensor Network Dedicated to Disaster Monitoring,” in Proceedings of the 5th International Conference on Ubiquitous Information Management and Communication (ICUIMC). ACM, 2011, pp. 53:1–53:10. [17] T. Miyazaki, “Dynamic Function Alternation to Realize Robust Wireless Sensor Network,” International Journal of Handheld Computing Research (IJHCR), vol. 3, no. 3, pp. 17–34, Jul. 2012.

B. Software-Defined Sensor Node Prototype We have already successfully designed and implemented a software-defined sensor node prototype, whose architecture is shown in Fig. 1 [16], [17]. It comprises a core board, a sensor board, and a 32-bit CPU card, connected to each other. The core board has a microcontroller unit (MCU), an FPGA unit, and an RF module. A number of sensors can be connected to FPGA unit through an analog-to-digital converter (ADC), or a digital-to-analog converter (DAC). Currently, we have embedded a temperature/humidity sensor, an IR sensor, a sound sensor, a light sensor, and a 3D acceleration sensor. We also adopt a 32-bit Atmark Techno Armadillo-420 CPU card to develop the initial software program, which will be then imported to the MCU on the core board. V. C ONCLUSION With the advancement and convergence of existing information technologies such as cloud computing, OTAP, SDN, SDR and FPGA, we believe that SDSNs are not only necessary but also inevitable in the next-generation sensor networks. In this paper, we present the concept of SDSNs and introduce several key enabling technologies related to the realization of

413