Dynamic Reconfigurable Hub as a Stationary Node in a Hybrid Sensor Network

Sensor network systems are being expanded with the development of technology for the design of a low-power chips and for operating sensor networks. However, it is difficult to modify or change an application for a stationary sensor node after installation in the field. Furthermore, there is a limit to installation after developing and testing a new sensor node if it needs to reconfigure the software and hardware of the existing sensor node. Therefore, not only is software reconfiguration needed but also dynamic hardware reconfiguration for various changes in requirements, such as sensor type, communication bandwidth, quality of service, or reduced power consumption depending on the changing environment and requirements of users. This paper proposes a specially designed stationary node called a SMART (system management architecture for reconfigurable technology) node, which is capable of dynamic reconfiguration of the various sensing functions or communication protocols. The SMART node can provide suitable service and change the communication protocol according to various surroundings and user requirements.


Introduction
An onsite stationary sensor node collects information about surrounding environments to provide various location-aware services [1]. During software or hardware design, these stationary sensor nodes are generally developed according to function optimized in the surrounding environment. However, when general stationary sensor nodes have been developed and installed in the workplace, it is not easy to modify the function of the software and hardware [2][3][4]. Moreover, when many mobile nodes are suddenly connected and begin transmitting to one of the stationary nodes located in a particular area, the system has to select a network guaranteed to provide high bandwidth instantly to meet all services [5]. And it needs to select a network in order to guarantee the stability of network data transfer rates even if the existing networks are damaged by fire, flood, or natural disaster [6]. If the system initially installed in the network is equipped with enormous bandwidth to guarantee required services, it is obviously inefficient due to the cost in terms of installation and maintenance [7]. This paper proposes a dynamically reconfigurable stationary hub node, called a SMART (system management architecture for reconfigurable technology) Node, combined with a device module and a host board. The device module provides various functions, such as environmental data gathering, network data transaction, and plug-and-play functionality. The host board is able to reconfigure many kinds of device modules. Entirely reinstalling sensor nodes is not necessary. The SMART node can perform dynamically based on a change of device module.
The remainder of the paper is structured as follows. Related works are discussed in Section 2. Section 3 introduces the system requirement and system outline. Section 4 describes the proposed reconfigurable system design and introduces implementation of the hardware and software. Section 5 demonstrates performance evaluation through a real test bed. Finally, conclusions are drawn in Section 6.

Related Works
The Narada [8] wireless sensor node using power amplified radios features low-voltage and adopted to achieve long communication ranges. The collected sensing data is transmitted via the 2.4 GHz IEEE 802.15.4 radio standard using the TI CC2420 transceiver. The wireless sensors can be easily and rapidly removed and reinstalled in new locations on a structural monitoring system that is proposed for monitoring short and medium-span highway bridges. However, the structural monitoring systems demand various types of sensors and communication protocols according to the environment.
The other study proposes that the framework is based on a service-oriented architecture that is modular, reusable, and extensible for structural health monitoring using networks of wireless smart sensors [9]. The wireless sensor platform used in this research is the Imote2, which is the only commercially available smart sensor platform. The Imote2 employs TinyOS [10], which is designed for sensor networks. The TinyOS updates the kernel and application code by using crossbow network programming (XNP) to support dynamic reconfiguration. However, this method has problems in that communication cost is higher, and it takes a long time because it is transmitted with the entire program via the sensor network.
The Mate [11] solved problems with TinyOS. Reprogramming a network merely requires adding a sensor node running a new propagating capsule that is a kind of command consisting of the VM-specific binary code. But Mate also has one disadvantage in that it results in overhead when running the VM background in every node and the type of Mate for the operation is limited because the capsule cannot be covered with all applications. SOS [12] is an eventdriven architecture type that supports the schedule for sensor networks. But it is more expensive to download modules when it comes to communication cost.
The RUNES [13] from the European Union is a lightweight middleware framework. Its goal is the development of various applications that will not be affected by platform. However, the RUNES system has a problem in that it builds the sensor nodes and installs again if they have to add new hardware functions.
We propose the following resolutions to solve these problems. The SMART node overcomes the limited application and inefficiency of the software update. It is possible for it to be dynamically reconfigured for alteration of hardware or software and to perform dynamically according to a change of device module adapted to the surrounding environment.

System Requirement and Proposed System Outline
The SMART node proposed in this paper meets the following requirements.

Connection Management in Every
Module. First, the master module, or host board (HB), detects the connection for each of the modules and decides which communication interface is to be used. Second, the host board communicates with every slave module or device module (DM) to initialize the device drivers for communication. The HB requests configuration data such as the number, type, and ID of the sensor from the DM. When the HB responds to the DM, it stores the configuration data requested from the DM in a repository and then manages the DM based on these data. Finally, when the DM disconnects from the HB, the HB disconnects the loaded device drivers and designated resources and then transmits its results to server.

Selection of Communication Protocols.
The sensor node has to transmit data to the server or other units. This transmission of data is able to use the DM equipped with a communication system or Ethernet in the HB.

A Variety of Communication Interfaces.
When the HB connects to the communication interface between each module, it can select one of the supported communication protocols. The HB also has to select the proper communication type based on the type or characteristic of the DM, such as the size of transmitting data or response data, the required data rate, and development costs. The SMART node is configured with the HB and the DM that performs suitable functions according to demand. As shown in Figure 1, the SMART node can be configured as a sensor node that supports a variety of functions and communications by combining modules that detect environment data such as fire, movement, gas, temperature, humidity and smoke. The DMs have communication capability through ZigBee or WiFi.

Detailed System Design and Implementation
The HB is based on a low-power 32 bit MCU and is composed of three layers according to features. As shown in Figure 2, Layer 1 has an Ethernet, internal peripheral port (UART, SPI, USB, I2C), and protocol used to connect the device module. Layer 2 connects Layer 1 and Layer 3. It consists of four ports, two communication interfaces per port and protocols supported by Layer 1. Layer 3 exchanges data from Layer 1 by using a protocol and communication interface supported by Layer 2 and has an MCU, many different kinds of sensors, and a communication module. The DM has an 8-bit MCU equipped with a port interface. The port interface needs to select one or more internal communication protocols according to the type of device module. Also, there are various types of DMs depending on the type of sensor.
The SMART node's features are as follows. It recognizes whether the DM is connected or not and handles data transmission to and from the DM. Also, it has to transmit the required data to select the available network protocol according to the purpose or policy of the service.
The software of the SMART node consists largely of three parts according to the functionality of the device. As shown Gas detection (c) SMART node with device modules    in Figure 3, work management stores required work from the application and divides it into internal or external work. Work transport transmits to the internal or external repository of required work. It is classified according to data of the DM which is stored in the queue designated to each port. Work management transmits the work stored in work transport to the operational DM. Port management handles four ports and detects whether the DM is connected or not. The process of connection between the device module and the host board in the port register is divided into three phases. The tasks handled in each phase are as follows.

Detect
Step. The port register detects whether the device module is connected or not by the PIO pin of the 20-pin connector. The detect phase of the port register is performed   according to schedule, such as connection between modules, detection of communication protocols, and disconnection between modules. Figure 4 illustrates the occurrence of the interrupt when both modules are connected. The PIO configuration of the HB is first set to pull-up, meaning that the initial status of the PIO is the high state. When the DM is connected, this configuration of the PIO pin changes to low from high. Thereafter, the PIO pin of the HB is kept on low. When the DM is disconnected, the current configuration of the PIO pin is changed to a floating state. It changes to the high state as the initial PIO configuration of the HB. At this point, the SMART node detects the interrupt, releases the pertinent memories, and removes the tasks in the DM.
The process for detecting the type of communication protocols for the DM is shown in Figure 5. The HB counts up the number of all interrupt signals on the pin of the connector for a period of time. This number indicates the type of communication protocol between both modules. For example, an interrupt signal counted at one for 1 second indicates the UART type, and then the HB loads the related device drivers.

Init
Step. At this step, all data of the connected DM are stored in the HB when the Detect step is finished. First, the SMART node initializes the number of the detected port, and the device driver is fitted to the communication interface. Second, the SMART node creates a task that handles the transmission of data. Finally, all of its data are stored in internal service in port management.

Notify
Step. The previously mentioned data are transmitted to the server or other units by work transport in the SMART node. This is handled as external service because data are transmitted outside the SMART node. The SMART node is simultaneously operated by many jobs according to priority. Thus, the system needs the OS for limited system resources to preferentially handle the many tasks according to their priorities. Therefore, the system should be designed based on Ubinos [14], which is a multithreaded operating system for the resource-limited embedded system, to build the ubiquitous computing environment or sensor network. Each thread of Ubinos has priority and is scheduled preemptively according to priority.

Test Bed.
The test bed is made up of many SMART nodes and a server as shown in Figure 6 for the experiment. Nodes 1, 2, and 3 are built on the PAN 1 composed of the sensor DM gathering the environment data and the ZigBee DM transmitting the data. The data transaction between internal layers in the node is used for communication protocols such as SPI, UART, I2C, and USB. Also, the current data of the SMART node is transmitted to the SMART node as a gateway, and this gateway is transmitted to the server. The PAN 2 included in Node 4 transmits the environment data of the SMART nodes as a sensor node using Ethernet. Node 5 is in charge of the WiFi AP, and PAN 3 included in Node 5 is available to WiFi communication via smart phone.
The features of the server program are as follows. When the SMART node is connected, the server program creates the icon. Also, it displays status information such as the type of sensor, current value, and critical value, as well as whether the device module is connected or not. Finally, the server program transmits the control commands and stores the packet log file. [Gateway] ZigBee and Ethernet the Notify step. Thus, the average time it takes to report to the server after the DM is connected is about 131.1 ms. When many devices are connected to the SMART node at the same time, the time it takes to initialize is as follows. It took an average of 121 ms in the Detect step, an average of 7.5 ms in the Init step, and about 72.5 ms in the Notify step. In light of these results, we found that processing time is greater than the waiting time. The reason is that it took a longer time to sequentially handle the signal that comes to the pertinent ports. Thus, it was found that the SMART node works without any problems, even if many device modules are connected to the SMART nodes and initialized by the system. Figure 8 illustrates the measured processing time for internal and external working of the SMART node application. The process of measurement is as follows. The time it took to handle the work of bringing the value of the sensor was measured, and it took an average time of 2.4 ms. Also, the time it took to transmit the data to the server was measured, and it took an average of 26.3 ms. All tests were repeated 10 times. Figure 9 illustrates the result according to the external work policy considering data size and transmission time if the node is using Ethernet and ZigBee at the same time. If the data is transmitted by ZigBee, it takes about 6 ms per byte. In contrast, if Ethernet is used, the processing time takes about 13 ms per byte. In the figure, cost is calculated as data size * transmission time per byte * process time. If using Ethernet, there is a penalty due to wake-up time. Figure 9(a) shows the cost as changed by the size of the data. If data greater than 17 KB is transmitted by the system, it is more efficient to use Ethernet. Also, Figure 9 greater than 3.6 KB is transmitted, it is more efficient to use Ethernet.

Conclusion
In this paper, we propose an improved sensor node called SMART node, which enables dynamic reconfiguration of the network communication protocols and function of the node. The SMART node can easily perform required tasks without modifying the function of installed sensor nodes because it can reconstruct the entire system by changing the specific device module according to the changing environment and needs of the user. Therefore the SMART node is able to reduce the time and cost required for the production of a sensor node and is helpful when transmitting data when data traffic momentarily increases. Recently, demands for services using a sensor node, such as location awareness, location tracking, transaction of multimedia data, and data transmission of heterogeneous networks, have gradually increased. The proposed SMART node is expected to be effective in solving problems on the networks and handling various services.