A Reconfiguration Method for Preserving Network Bandwidth and Nodes Energy of Wireless Sensor Networks

Abstract

In Wireless Sensor Networks (WSNs) and even in the Internet of Things (IoT) ecosystem, the reconfiguration of sensor variables is an important problem when the role of a system (or application) program's sensor nodes needs to be adjusted in a particular situation. For example, the outdoor temperature in a volcanic zone, which is usually updated in a system every 10 s, should be updated every 1 s during an emergency situation. To solve this problem, this paper proposes a novel approach based on changing only a set of sensor variables in a part of a program, rather than modifying the entire program, in order to reduce both network congestion and the sensor nodes' battery consumption. To validate our approach, we demonstrate an implementation of a proof-of-concept prototype system and also present results of comparative studies showing the performance and effectiveness of our proposed method.

1. Introduction

The Internet of Things (IoT) constitutes the interconnection of various embedded computing devices, such as RFIDs, sensors, actuators, mobile phones, smart cars, and electronic devices, via the Internet. Tiny computers embedded in physical objects (or things) collaborate with other connected devices in the vicinity to provide intelligent services [1][2]. For example, a car driver would like to know the location of an available parking space in advance so that he or she can save his or her valuable time. In particular, Wireless Sensor Networks (WSNs) constitute a physical infrastructure that needs to embody the IoT ecosystem. In every WSN, there exist a sink node and a sensor network consisting of sensor nodes. The sink node is a type of sensor node that collects various sensing data, e.g., humidity, temperature, sound, pressure, motion, and vibration, from the sensor nodes in the sensor network. Then, based on these sensing data, a new IoT application can improve its quality of service (QoS) and mine more useful information by combining multiple heterogeneous sources, such as sensor networks, in addition to cellular networks, in an IoT environment.

First, to demonstrate the need for sensor network systems, we now show a real-world example. According to a news reports in Korea, 2 people were killed and at least 68 were injured in a pileup involving approximately 100 vehicles in foggy weather on the Incheon bridge, which connects the Incheon International Airport to the outskirts of Incheon. If the bridge had been equipped with an intelligent sensor network system, such as the Structural Health Monitoring system1, which was designed, implemented, deployed, and tested on the 4200 ft. long main span and the south tower of the Golden Gate Bridge, such a serious traffic accident could have been prevented. For instance, many sensor nodes attached to the Incheon bridge frequently gather varied information concerning foggy, windy, or surveillance states, and the time interval (or named sensing period) for collecting sensing data can be reset. The collected data, e.g., those related to a foggy state, are stored in a sensor variable. Such a sensor variable has one of two binary values, 0 or 1: a value of 1 if there is fog around the bridge, and 0 otherwise. An example of a reconfigurable sensor variable is the sensing period. Let us suppose that the sensing period is initially set to 30 s. Since frequent updates of the sensor variable can deplete batteries, this is the update interval usually set for the surveillance state. However, in the case of an emergency, the sensing period needs to be shortened, e.g., from 30 s to 1 s, to reflect the conditions in the bridge’s immediate vicinity. More importantly, when the values of reconfigurable sensor variables are changed in a sink node, the values corresponding to the sensor nodes should also be updated. This data synchronization problem is known as the reconfiguration problem in sensor networks. In this work, we first label each sensor variable either non-configurable or reconfigurable. For example, the sensor variable of the foggy state is labeled a non-configurable sensor variable. Meanwhile, if this sensor network system is connected to the cellular networks of the IoT ecosystem, additional information, such as that about sudden congestion in a particular area of the bridge, is combined with the values of all the sensor variables. Thus, a serious incident can be detected at its outset and an alarm can be given or car drivers who have just arrived at the bridge can be diverted.

However, if the reconfiguration problem is not handled in existing sensor networks, intelligent services cannot be expected in our daily life. Recall that the primary role of the sink node is to collect and store the values of the sensor variables arriving from the sensor nodes. Users usually explore the values through monitoring the software of the sink node. If a user changes the value of a reconfigurable sensor variable, either the entire or part of the sensor nodes (called target sensor nodes) is not automatically updated according to this change. For instance, when the sensing period of a reconfigurable sensor variable for the surveillance state is changed from 30 s to 5 s, a user has to access the sensor node in person and manually change the value in the target sensor nodes. However, this is not a sensible idea if the sensor nodes are located within a danger zone. Alternatively, if the user wishes to update this value remotely, two methods are available. In the first, the entire source code is compiled, although the values of only a few reconfigurable sensor variables are altered in the sink node, and then, its binary codes are sent to the target sensor nodes. The disadvantages of this method are that the network congestion in the sensor network is increased and all the services have to be interrupted until all the execution files have been downloaded and then installed in the target sensor nodes. Hereafter, this method is called the full-image-based method. The second method is the component-based method. Typically, software usually consists of several components (or software modules), e.g., an operating system (OS) usually consists of a kernel module, networking module, etc. Thus, if the value of a reconfigurable sensor variable in a particular component is changed, e.g., the routing information is reset, the binary code corresponding to the component is transmitted only to target sensor nodes and is installed in them. In this case, the main shortcomings of the full-image-based method can be somewhat diminished. As would be expected, according to our experimental results, network congestion is mitigated in the component-based method much more effectively than in the full-image-based method. However, the component-based method still suffers from network congestion and battery requirement issues.

Therefore, to handle the limitations of these existing methods, in this paper, we propose a novel reconfiguration method in which the OS and application software contains a list of pointer variables, each of which contains an address designating its location in flash memory.2 In the location, the value of each reconfigurable sensor variable is in fact stored. Therefore, although the value of a reconfigurable sensor variable is altered in the sink node, the proposed method simply updates the changed value in the pointer variable. Thus, it is no longer necessary to compile either the entire or part (i.e., components) of the source code in the sink node, and thus, the corresponding binary code does not need to be sent to target sensor nodes. In turn, this process does not give rise to serious network congestion. The main contributions of this study are as follows. (1) A prototype of the reconfiguration method in sensor networks was developed, and (2) the empirical study showed that our proposed method outperforms other methods in terms of the network congestion and battery issues that challenge sensor networks.

The rest of this paper is organized as follows: In Section 2, we summarize related work. In Section 3, our proposed reconfiguration method is presented in greater depth. Next, a prototype of the proposed method is described in Section 4 and the experimental results for three methods are discussed in detail in Section 5. Finally, in Section 6 the concluding remarks are presented, followed by our future research plan.

 

2. Related Work

A significant amount of research has been conducted on sensor network reconfiguration. Deluge [3] is the most popular application in the full-image-based method category. Deluge is an application for replacing a monolithic binary image. The large size of a monolithic binary image (30–40 KB) incurs a high energy overhead for code transmission. Reinstallation of the full application also disrupts the running application, resulting in a loss of recent data and resources. Additionally, small frequent updates in the code, such as bug fixes, cause only minor differences between the new and old system images.

FlexCup [4] is a flexible code-updating mechanism that minimizes the energy consumed at each sensor node for installing arbitrary code changes. FlexCup requires a reboot after reconfiguration. OpenCOM [5] is a component model that can be explicitly tailored for diverse domains and environments. The component model is supported by a reflective runtime architecture that is itself built from components. OpenCOM is a generic model that was developed for resource-rich platforms. Gridkit [6] is sensor middleware that can be customized to suit different sensor application types, providing a reflective approach for a coordinated network-wide dynamic reconfiguration of sensor behavior. Figaro [7], a programming model supported by an efficient run-time system and distributed protocols, focuses on a code distribution algorithm for WSNs. The LooCI [8] component model imposes minimal additional overhead on developers, and uses an event-based binding model that enables them to model rich component interactions. Finally, RemoWare [9] mitigates the cost of post-deployment software updates on sensor nodes through the notion of in situ reconfigurability and provides a component-based programming abstraction to facilitate the development of dynamic WSN applications. Contiki [10] enables partial code updates through the linking and loading of native code in the ELF file format. The partial code updates require OS support.

Recently, the dynamic reconfiguration issue has attracted increasing research attention. Dynamic reconfiguration involves the automatic configuration of sensor nodes, and many dynamic reconfiguration methods have been proposed. In [11], a framework called Fennec Fox for dynamic reconfiguration to support heterogeneous applications was proposed. The framework comprises a runtime infrastructure and a programming language to specify the various WSN configurations. Leligou et al. [12] presented use cases that can exploit the reconfiguration feature. In this study, a sample application, an urban surveillance case based on a set of different sensors, was analyzed. The analysis identified communication modules and parameters that can be reconfigured. Hughes et al. [13] proposed an energy-aware software evolution model for WSNs. The model uses LooCI middleware and the authors proposed a generic model for calculating the energy cost of the reconfiguration in WSN. Yeh et al. [14] presented a framework for reconfigurable techniques on a WSN at the node and the network level. The framework develops a structure for optimization problems and classification of an energy optimization function. In [15], an approach called MoRE was proposed for developing autonomic systems in smart homes, reusing variability models at runtime to provide a semantic base for decision making. In this paper, the model-based reconfiguration engine to implement model-management operations was introdiced. Ortiz et al. [16] proposed a runtime variability mechanism that can modify the structural variability of a dynamic software product line. In this study, a super-type-enabled runtime variability mechanism was introduced and the previous feature models were extended. Mouronte et al. [17] proposed a high-level architecture that exploits runtime software variability techniques to manage the context-aware information dynamically. In [18], a family of configurable middleware with a flexible architecture, called FamiWare, was proposed. The middleware provides a single interface for accessing all those services that can operate in heterogeneous devices. The architecture uses a software product line. In [19], a family of middleware for a WSN, called Family, that can be customized according to the imposed constraints was proposed. The middleware uses the software product line approach and feature model.

In addition, there are several issues related to WSNs, one of the most important of which is the collection, aggregation, lifetime enhancement and use of sensor data from various WSNs. Jung et al. [20][21], Zhang et al. [22] and Liu et al. [23] addressed this issue but it needs to be further investigated and improved..

There has been considerable research on the reconfiguration of WSNs, but several issues remain to be resolved. One of the main issues is that these approaches still suffer from network congestion and battery requirement issues. We propose a novel reconfiguration method based on sensor variables. The proposed method simply updates the changed value in the pointer variable.

 

3. Main Proposal

Fig. 1 shows an overview of the proposed method. For example, when a user changes the value of the reconfigurable sensor variable “sensing period” from 1 s to 5 s, the reconfiguration manager in the sink node creates a sensor variable packet (SVP), which includes the target sensor node identifier and the changed value of the reconfigurable sensor variable. Then, it sends this packet to the target sensor node. After the packet is received in the target sensor node, it is analyzed, and then, the value of the corresponding sensor variable in the non-volatile memory is changed from 1 s to 5 s. In our approach, not all the binary image data need to be sent to the target node. Instead, only a small packet is sent to update the corresponding sensor variable in the target sensor node. In addition, a changed valued is not lost when a sudden blackout occurs, because it is stored in non-volatile memory.

Fig. 1.Sensor variable-based reconfiguration method overview

3.1 Sensor Variable

As mentioned previously, the goal of this study was to devise a new reconfiguration method that supports a sensor variable-based reconfiguration. First, in our definition, a “sensor variable” contains the value that should be synchronized between the sink node and target sensor nodes. In other words, the value of the sink node should be always the same as that of the target sensor nodes. The sensor variables that are mentioned in ATaG [24][25][26] are similar to our sensor variable in that they represent the capability of a node and are used to determine the type of a node. Our approach is to modify the behavior by changing the sensor variable of the sensor node.

Sensor variables comprise a network, scheduler, device driver, sensor type, and other components. WSN application systems contain various sensor variables [27][28][29]. Table 1 shows the reconfigurable sensor variable classification as defined in this paper and examples of sensor variables and descriptions according to category. The reconfigurable sensor variables are classified into four categories: network, scheduler, device driver, and sensor type. The network category includes sensor variables for network configuration, the scheduler category consists of sensor variables for schedule configuration, the device driver category consists of device sensor variables for sensor drivers, and the sensor type category includes sensor variables for sensors and actuators action.

Table 1.Sensor variable classification and description

3.2 Code Description for Sensor Variable-based Reconfiguration

The code description of the sensor variable-based reconfiguration method uses sensor variable-based programming [30], which supports value updates and does not require a system reboot. A non-volatile memory of a sensor node enables a flash memory, e.g., EEPROM. Non-volatile memory has a storage area for non-volatile data, which are not lost even when the power is turned off suddenly. A reconfigurable sensor variable connects to the non-volatile memory. In the proposed method, we redesign OS and application software such that it includes a list of pointer variables, each of which contains an address designating its location in the memory. When the value of a reconfigurable sensor variable is changed in a sink, the value corresponding to a sensor node should also be updated. In the proposed method, the value of the reconfigurable sensor variable is in fact stored in the non-volatile memory of the sensor node.

Fig. 2 shows the logical structure connecting the sensor variable and the non-volatile memory. A sensor node consists of sensor variables, such as Node ID, Sensing_Period, and Humidity_Enable. The sensor variable values are stored in non-volatile memory by linking the corresponding code descriptions. When a sensor node changes its actions, the method proposed in this paper updates the sensor variable values by using the reconfiguration method. This feature supports a dynamic reconfiguration in WSNs.

Fig. 2.Logical structure between sensor variable and non-volatile memory

Fig. 3 shows an example sensor variable-based code description in TinyOS [31]. The code description is connected to the reconfigurable sensor variable in a binary image and the non-volatile memory.

Fig. 3.Sensor variable-based programming in TinyOS

3.3 Sensor Variable-based Reconfiguration Method

In this section, we describe the proposed method, which supports sensor variable-based reconfiguration. First, the sink node sends an initial communication packet to target sensor nodes to set the communication channel between the sink node and the target sensor nodes and then to hold the ongoing service of the target sensor nodes. Then, the sink node transmits an SVP to the sensor node for the reconfiguration. Each target sensor node updates the value of the reconfigurable sensor variable in the non-volatile memory.

Fig. 4 depicts an overview of the sensor variable-based reconfiguration method proposed in this paper. A user sends the reconfiguration information to the sink node. The reconfiguration information consists of the changing information of the target sensor node, i.e., the sensor node ID, sensor variable name, and value. The sink node checks the sensor variable list for validation of the reconfiguration information. The sensor variable list includes an available sensor variable list of the WSN and the unit of reconfiguration. The sink node creates SVPs using the reconfiguration information. The sensor node in general collects data and transmits the data to the corresponding sink node. If the sensor node executes the reconfiguration during sensor data collection, data collection errors may occur. Therefore, before executing the reconfiguration operation, the mode of the target sensor node changes to a waiting mode for error prevention. The sink node transmits the SVP after initial communication checking. The sensor node executes the reconfiguration operation using the SVP analysis.

Fig. 4.Overall reconfiguration process in proposed method

Fig. 5 illustrates the structure of the sink node and sensor node. The following points summarize the module:

Fig. 5.Structure of the sink node and sensor node

Fig. 6 shows a sequence diagram of the overall proposed method process. The diagram shows the interaction between the modules. A user sends reconfiguration information for the sensor variable-based method (1). The reconfiguration information includes the sensor node ID, sensor variable name, and sensor variable value. The registry contains the sensor variable list of the WSN. The SVC checks the reconfiguration information using the registry manager (2). The selector selects the reconfiguration elements together with the SVC (3). The selector sends the result to the RM, which then executes a sensor variable-based reconfiguration (4). The RM requests a change in the initial communication at the target sensor node (5). The PA of the target sensor node analyzes the received packet and calls the RC, which changes the initial communication in the sensor node and sends the PA the result of the initial communication change (6) and (7). The PA transmits the result of the initial communication change to the RM (8). If the change result of the initial communication is true, the RM calls the APC (9). The SVPC creates a sensor variable-based reconfiguration packet, and transmits it to the target sensor node (10). The PA of the target sensor node analyzes the received the packet and calls the SVA (11). The SVA adapts the SVP for the reconfiguration and sends the PA the adaptation result (12). The PA transmits the result of the adaptation to the selector and the selector sends (13) the result to the SVC (14).

Fig. 6.Overall reconfiguration process: sequence diagram

Fig. 7 shows the reconfiguration process for the sink node. The user sends any reconfiguration information for the target sensor node. The reconfiguration information includes the target sensor node ID, the sensor variable name, and the sensor variable value. The sink node receives the reconfiguration information from the user and checks the sensor variable list for validation of the reconfiguration information using the registry. The list includes a set of available sensor variable lists of all the sensor nodes and the unit of reconfiguration. The sink node creates an SVP on the basis of the reconfiguration information. The SVP includes the target sensor node ID, the sensor variable name, and the sensor variable value. If there is no relevant reconfiguration information, the sink node requests new reconfiguration information from the user. The sink node requests the initial communication change before transmitting the SVP. The initial communication is ready for the reconfiguration execution for the target node. The sensor node in general collects sensor data and transmits the data to the sink node. If the sensor node executes the reconfiguration operation during sensor data collection, data collection errors may occur. The initial communication prevents sensor node errors during the reconfiguration. The sink node transmits the SVP after the initial communication checking is complete. Finally, the sink node transmits the SVP to the corresponding sensor node.

Fig. 7.Sink node process in the proposed method

Fig. 8 shows the reconfiguration process for the sensor node. First, if the sensor node receives initial communication packets from the sink node, it changes its initial communication. The sink node waits to receive the SVP and execute sensor variable-based reconfiguration. Finally, the sensor node transmits the results of the reconfiguration to the sink node.

Fig. 8.Sensor node process in the proposed method

 

4. Implementation

This section describes a prototype of the sensor variable-based reconfiguration method proposed in this paper. The prototype was used to test the proposed method. We configured the nodes to use the 2.4 GHz band IEEE 802.15.4 physical layer and the beaconless mode action. The implementation used two TelosB nodes [32] running on TinyOS.

The prototype implementation used the flash memory of the non-volatile memory in the TelosB. The flash memory and EEPROM of the non-volatile memory enable the sensor node for sensor variable-based reconfiguration. Some parts of the flash memory and EEPROM can be read and written by the developer.

A sensor variable is connected to a source code with the flash memory. The proposed method changes the sensor variable values of the flash memory for changing the action. The reconfiguration information set, including the node ID, sensor variable name, and sensor variable value, is given to the prototype. The prototype implementation executes the changing operation for the sensor node.

Fig. 9 illustrates an implementation scenario to show the contributions of the proposed method. The sensor node supports the LED_Enable and Sensor_Temperature_Enable sensor variable. A user provides reconfiguration information containing the node ID, sensor variable name, and sensor variable value. The scenario comprises three steps for the action change in the sensor node. In the first step, the user sends information about the LED sensor variable and Temperature sensor variable to the sink node. The sink node checks the sensor variable list and the sensor node creates an SVP. The packet includes the target sensor id, reconfigurable sensor variable name, and sensor variable value. The sink node requests an initial communication change from the target sensor node and transmits the SVP. The LED and Temperature elements of the target sensor node are deactivated. In other words, the LED light is turned off and the temperature sensor is not activated. In the second step, the LED action on the target sensor node is changed. The target sensor node is changed. After the change operation, the LED action is activated by using the LED_Enable sensor variable and the LED light is turned on. Finally, the temperature sensor action using the Sensor_Temperature_Enable sensor variable is changed as the activation status. In this scenario, in the proposed method only the SVP is requested for the reconfiguration.

Fig. 9.Proposed reconfiguration method scenario

Fig. 10 shows the reconfiguration scenario execution. Fig. 10(a) shows the LED light on the sensor node is activated and blinking after the LED_Enable sensor variable is updated. Fig. 10(b) shows the On-state of the temperature sensor through the updating of the Sensor_Temperature_Enable sensor variable. The oscilloscope tool shows the temperature values sensed by the temperature sensor. The oscilloscope snapshot shows the values collected after the corresponding sensor variable change.

Fig. 10.Prototype of the sensor variable-based reconfiguration method

 

5. Experimental results

In this section, we present experimental evidence that our proposed method is superior to two other existing methods: (1) a full-image-based method and (2) a component-based method. For the experiments, Deluge and RemoWare were selected from among several full-image-based and component-based methods, respectively. In most cases, sensor networks suffer considerably from the network congestion problem and rapid consumption of the sensor node batteries. Therefore, the experiments were divided into two different types, as follows:

5.1 Network Congestion

Network congestion frequently occurs when sensor nodes carry an excessive amount of data and leads to deterioration in an application’s QoS, since the throughput of the sensor network is rapidly diminished by the network congestion problem. In our evaluation of Deluge3 and our proposed method in terms of network congestion, to quantitatively measure the extent of the network congestion, we considered both the network bandwidth and the updated time. The network bandwidth constitutes the channel capacity of a logical communication path in a sensor network. For instance, to transmit 10 kilo bytes in a file to a target sensor node n2 from a sink node n1, first a channel is set up between n1 and n2. Assuming that the channel has a capacity of 512 bytes per second, it will take about 20 s for n2 to receive the entire file. However, if the file is only 1 kilobytes in size, it will take approximately 2 s. In addition, the update time is defined as the total amount of time it takes to send a file from n1 to n2 and then to install and render it ready for use in n2.

Fig. 11 shows the experimental results about the total size of data (S) to be transmitted to a target sensor node (n2) from the sink node (n1) using Deluge and our approach. Formally, the total size of data sent by the Deluge and our approach can be computed by the following equations:

, where i means the i-th pair of sensor variable name and value. SDeluge is composed of two terms, SOs and SApplication, for reconfiguration. SOs is the size of operating system for n2, such as TinyOS and contiki, and SApplication is the size of the re-compiled version for n2. Deluge always sends to n2 a ROM file including both SOs and SApplication. On the other hand, SProposed method is only a few bytes for sending a sensor ID followed by pairs of reconfigurable sensor variable names and values. In Deluge, suppose that the size of the entire operation system is about 10KB, and the size of the application is 5KB or so. SDeluge is 15 KB. In our approach, if there are about 256 sensor nodes and variables in a wireless sensor network, each of SSensor_Node_ID, Sreconfigurable_Sensor_Variable_Name, and Svalue is 1 byte. If 12 pairs of reconfigurable sensor variable names and values, Σi(SReconfigurable_Sensor_Variable_Name+SValue) is 24 bytes. In this set-up, SDeluge is about 600 times larger than SProposed_Method. This outcome is similar to our empirical results in Fig. 11.

Fig. 11.Total size of data and average updated time results

For the experiments, we prepared three test cases. One case constituted updating the configuration value of the blinking light period in a target sensor node, the second constituted updating the configuration value of the LED blinking On/Off state in a target sensor node, and the third constituted updating the configuration value of the temperature On/Off state in a target sensor node. For clarification, we hereafter call the three cases Blinking_Period, LED_Enable, and Sensor_Temperature, respectively. We also used 12 TelosB nodes running on TinyOS. We modified Deluge and implemented our method using benchmark data sets given by TinyOS. In our approach, the configuration information was updated on the flash memories of the TelosB nodes.

In all three test cases, when we used Deluge, the total data size was about 20 kilobytes on average, while data of about 25 bytes needed to be sent to n2 when our method was used. The data size to be sent using Deluge is thus about 800 times bigger than that using our method. Such relatively large data cause or exacerbate the network congestion problem in sensor networks. In Deluge, the binary code of all the source codes, including OS and application software, should be sent to a target sensor node. In contrast, in our scheme, the only data to be sent contain the identifier of a target sensor node, reconfigurable sensor variable name, and reconfiguration value. If there are about 512 sensor nodes in a given sensor network, only 9 bits are required to identify each of all the sensor nodes. In addition, suppose that the total number of reconfigurable sensor variables is 64. In this case, only 6 bits are needed to identify each of the sensor variables. In most cases, the reconfiguration information of sensor variables constitutes, for example, turning a particular sensor on/off and changing the sensing period.

Thus, 1 byte is sufficient to represent the reconfiguration value. As a result, when our approach is used, the total size of data to be transmitted to n2 is at most 3 bytes. In Deluge, if the capacity of the channel between n1 and n2 is 512 bytes, n1 has to divide the total data into 20 parts of data, and then, each part of the data is sent to n2. Therefore, the network bandwidth is occupied and cannot be used by other nodes until n2 has received all the data. In contrast, when our method is applied to the sensor network, all the data are simultaneously sent to n2 and the used channel is quickly available. Based on these experimental results, we suggest that our approach outperforms the existing methods such as Deluge in the aspect of network bandwidth. Therefore, using our approach ameliorates the network congestion problem that frequently occurs in sensor networks.

We also measured the updated time (T) of Deluge and our method. Regardless of the Deluge or our approach, the updated time for the reconfiguration is defined as

, where j means the distance to the target sensor node from the sink node. The communication between sensor nodes is made by UDP protocol. The sink node first sends a segment to the nearest neighbor of the sensor nodes in a wireless sensor network. The neighbor node stores and forwards it to its nearest neighbor again. In this way, the segment is arrived to the target sensor node. The UDP protocol is connectionless without providing any control scheme for end-to-end network flow. Thus, the updated time can be defined as the combination of the data transmission time and the install time. The data transmission time is computed by SFile_Size / SBandwidth. For example, SDeluge / SBandwidth in the Deluge method, but SProposed_Method / SBandwidth in our method. Please note that the transmission time is the dominant term in TUpdate equation. Compared to our approach, the size of Deluge is considerably larger than that of our method. This indicates that the TUpdate time of Deluge is also much slower than ours. In addition, another term, TInstall_Time is the amount of time taken to install the binary image in the target sensor node using the Deluge method. However, in our method, it means the amount of time taken to simply update the values of the sensor variables. In Deluge, if SDeluge is about 15KB, and SBandwidth is 250 kbps (please, refer to TelosB in http://www.memsic.com), then it takes about 60 seconds to send SDeluge to the target sensor node. Further, if the distance from the sink node to the target sensor node is 5, then it takes about 65 seconds by Σj(SFile_Size / SBandwidth). Supposing that TInstall_Time is about 3 seconds, the TUpdate time is 68 seconds. In case of our method, if SProposed_Method is 25KB, and SBandwidth is 250 kbps, it takes about 1 second to send to the target sensor node by SProposed_Method / SBandwidth. In addition, if the distance is 5, it takes about 2 seconds by Σj(SFile_Size / SBandwidth). If TInstall_Time is 1 second, the TUpdate time is 3 seconds. As a result, the TUpdate time of the proposed method is about 23 times faster than that of Deluge. Figure 11 also shows the similar patterns between the analytical and empirical studies.

In the set of experiments, the average update time of Deluge was more than 1 m. In contrast, the update time required by the proposed method was at most 2 s on average. The experimental results show that our proposed method is about 30 times faster than existing full-image-based methods such as Deluge. Interestingly, the update time consists of transmit time and installation time. The transmit time is defined as the amount of time it takes to send all data to a target sensor node from a sink node. The install time is the amount of time it takes to install the data in the target sensor node. In Deluge, the transmit time and the installation time were about 61 s and 4 s, respectively. That is, the transmit time is dominant in the update time. Similarly, in our approach, the transmit time is about 2 s, whereas the installation time is at most 1 ms. A comparison of the transmit time of our scheme and of Deluge reveals that the proposed method is also about 30 times faster than Deluge. This result is consistent with the experimental results for the network bandwidth.

5.2 Battery Consumption

By referring to IEEE 802.15.4 multihop networks [33], we implemented a simulator for estimating the energy consumption of Deluge, RemoWare, and our approach. In the simulation, we focused on updating the configuration value of the LED blinking On/Off state in a target sensor node. In addition, we used OMNet++ [34], a well-known component-based C++ discrete even simulator jointly with the MiXiM and OMNet++ frameworks created for various types of mobile and fixed wireless networks (e.g., WSNs, body area networks, ad-hoc networks, and vehicular networks) [35]. The simulated network nodes were located in a uniformly random spatial distribution in two-dimensional square areas. The nodes were configured to use the 2.5 GHz band IEEE 802.15.4 physical layer and parameters in CC2420 [36]. We conducted experiments and activated the parameter settings of the simulator on the basis of experimental results and similar simulation environments [37]. Thirty sensor nodes were randomly deployed in a 500 m * 500 m field.

Fig. 12 shows a screen-shot image of our simulation based on OMNeT++. In the figure, node[0] represents a sink node and the remaining nodes are sensor nodes. Each sensor node has a borderline of a circle-shape within which it can only communicate with other sensor nodes. The arrows between the nodes represent the routing information. Data are transmitted to sensor nodes based on the routing information.

Fig. 12.Screen-shot image of our simulation based on OMNeT++

Fig. 13 illustrates the experimental results for the battery consumption of sensor nodes when each method, Deluge, RemoWare, or our approach, was employed. In the figure, the x-axis represents each of the 30 sensor node identifiers and the y-axis represents the battery consumption per sensor node. The average energy consumptions of Deluge, RemoWare, and our approach are 108.5 mWs, 47.4 mWs, and 6.1 mWs, respectively. According to these experimental results, our proposed method is 17 times and 7 times more energy-efficient than Deluge and RemoWare, respectively. This implies that our method can save battery consumption efficiently, as compared with the existing methods. The reason is that only data of 3 bytes are sent to a target sensor node in our approach and therefore the target sensor node tends to consume less energy because it is handling a small size of data. In contrast, the other methods are likely to require large batteries to handle the relatively large data. For instance, each sensor node has a receiver and a transmitter. The receiver and transmitter consume a battery energy of 0.6391 mA and 0.6845 mA per (receive and transmit) operation. In the example in the previous section, when we used Deluge, the receiver of a target sensor node (n2) had to be activated 20 times to receive all the data. Then, it needed to consume 20 × 0.6391 mA = 12.782 mA to receive every data item. In contrast, in our approach, the receiver can be activated only one time and therefore it consumes only 0.6391 mA.

Fig. 13.Experimental results for battery consumption

 

6. Conclusion

In this paper, we proposed a novel approach for resolving the reconfiguration issue that is a significant challenging problem in sensor networks and the IoT ecosystem. Whenever configuration values are updated in a sink node (e.g., a certain sensor is turned on or off), the updated information should also be updated in the target sensor nodes. In existing methods, such as full-image-based (e.g., Deluge) and component-based (e.g., RemoWare) methods, the binary code of either the entire or part of the source code should be sent to the target sensor nodes, although only the configuration information in the entire source code is changed in the sink node. For this reason, the existing methods frequently result in both the network congestion problem and battery requirement issues, which are very important in sensor networks. In contrast, since our approach is based on updating only configuration information, it can ease the limitations of the existing methods.

In future work, we plan to study the autonomous reconfiguration problem. To address this problem without human intervention, configuration information should be automatically updated in the target sensor nodes to provide flexibility in handling a situation.