Compact wireless control network protocol with fast path switching

,

However, TDMA has the following problems.
(1) Handling difficulty TDMA requires high synchronization accuracy. Generally, it is difficult to implement programs that can maintain synchronization accuracy in less than 10 ms because, in embedded software environments, unexpected delays of several milliseconds occur randomly, such as OS task switches and interrupts.
For example, the flooding time synchronization protocol [10], which is a general time synchronization technology, handles such random delays by including time information in the send frame under the RFLSI driver sequence. Software that crosses network layers is difficult to develop without errors. The WCN stack must operate with various types of hardware wherein processing capacity and how connected sensors are handled vary. In addition, customer requirements must be considered for each application. When using a stack with TDMA, we must adjust the stack each time the hardware changes. In particular, when using sensors that generate various interrupts or require timeconsuming operations, it is difficult to maintain accurate TDMA synchronization.
As described above, TDMA systems are difficult to implement, i.e., it is difficult to add or modify functions to such systems.
(2) High procurement cost Note that rigid hardware specifications must be satisfied to maintain high TDMA synchronization accuracy.
For example, Linear Technology's WirelessHART module maintains high synchronization accuracy by measuring temperature changes and clock error changes during the manufacturing process and writing this information to memory.
However, fabricating such hardware is difficult, and procurement costs are high.
In this paper, we propose the NES-SOURCE protocol stack for a WCN of practical size.
NES-SOURCE has compact implementation. Its code size is approximately one-quarter that of a general sensor network protocol stack and approximately one-half that of the TDMAbased WCN protocol stack. The cyclomatic complexity, which is a measure of source code complexity, of NES-SOURCE's functions is at most 10, which is less than other WSN [19] and WCN [20] protocol stacks. This indicates that NES-SOURCE stacks can be customized and adjusted quickly.
NES-SOURCE has a high-speed path-switching function, i.e., paths are switched quickly when communication failures are detected. With this function, NES-SOURCE achieves a low delay and a low PER without duplicating the communication path, which is the case with TDMA-based technology. Compared to a simple fixed-path protocol, NES-SOURCE has the following features that allow routes to be changed quickly.
(1) Reduced back-off time Sensor data and commands used in a WCN are at most several dozen bytes. By limiting the frame size to approximately 100 bytes, the random back-off time with CSMA/CA can be reduced from a maximum of approximately 15 ms to a maximum of 2.8 ms, as specified in IEEE 802.15.4g.
(2) ACK omission If the communication path comprises a single hop, when NES-SOURCE detects packet loss in the MAC layer, it resends the frame using a backup route without waiting for the network layer ACK timeout. nodes is measured and written during the manufacturing process; however, such processes cannot be performed in all factories.
WirelessHART [5] uses TSCH to enhance communication reliability by incorporating a redundant communication path. However, this protocol control network information resides on the base station side; therefore, the system will fail if nodes cannot communicate with the base station. In addition, these protocols use TDMA, and it is difficult to guarantee delay on the order of 50-100 ms [3].

Related Work
Researchers have improved the reliability of and delays in WCNs. WCN protocols can be classified as TDMA contentionfree and CSMA/CA contention-based methods.
In WirelessHART [5], the base station regularly updates the routing and channel information for the network nodes. Therefore, the system does not function if nodes cannot communicate with the base station [15]. PEDAMACS [7] solves this problem by increasing the base station's transmission power to implement single-hop transmission from the base station. However, single-hop transmission often cannot be implemented in a WCN application environment.
GinMAC [6] avoids this problem by pre-installing node routing information. However, GinMAC uses TDMA and is difficult to implement.
MMSPEED [11] guarantees delay by controlling data stream QoS attributes, and this method is effective for large-scale data streams and networks. The network scale in [11] is approximately 150 nodes, which is greater than a typical WCN (approximately 25 nodes) Dwarf [12] improves reliability by utilizing unicast-based flooding. This is effective when node density is high in a largescale network. Therefore, Dwarf is unsuitable for WCNs.

WCN Requirements
According to Zandra et al. [3], control applications can be categorized into three levels depending on the importance of message timing. Wired network communication is reasonable for applications with high-level requirements (e.g., control of lifethreatening emergency stop devices). On the other hand, applications with low-level requirements (e.g., applications that safely allow manual intervention and/or monitoring) can use general WSNs.
WCNs can be used for applications with medium-level requirements. Table 1 lists the requirements generally assumed for WCNs. Note that the information given in Table 1 is based on the requirements provided by Samarasinghe et al. [6] and Kumar et al. [2]. The main application of a WCN that satisfies the requirements in Table 1 is assumed to be "a network for automatic control requiring responsiveness on the order of one second from measurement to response." [2,15]. Note that "automated valve control at the factory" is often given as an example [15].
NES-SOURCE is assumed for use in environments wherein people and equipment move frequently, such as manufacturing plants. When a person or piece of equipment enters the communication path, the communication environment changes, and packet loss can occur. A WCN node cannot use an obstructed path until the obstruction is removed. Therefore, a WCN protocol requires a route-changing function.
As mentioned previously, in the general sensor network protocol, each node changes the communication path autonomously. In contrast, in the general WCN protocol, nodes do not construct routes autonomously. For example, in WirelessHART, nodes use duplicate communication paths simultaneously to transmit packets rather than changing routes.
In WirelessHART and comparable technologies that adopt TDMA, collisions do not occur even if the communication path is duplicated because TDMA is collision-free. However, when using CSMA/CA, collisions tend to occur if communication paths are duplicated because packets are transmitted to the same destination at essentially the same time. In this case, transmission and ACK packet collisions cause contention. Most nodes will be located 1 hop from the station node and at most a distance of 3 hops will be observed.
Therefore, when considering a WCN stack using CSMA, we must also consider a method to detect communication failure and switch communication paths quickly.

NES-SOURCE Features
We designed and developed NES-SOURCE to satisfy the conditions listed in Table 1  Therefore, NES-SOURCE adopts the random back-off time of IEEE 802.15.4d. Our experimental results demonstrate that communication delay is improved by 6.5 ms (an average improvement of 27%) when transmitting 20 bytes by reducing the random back-off time [18].


Network layer Similar to GinMAC, NES-SOURCE routing is a source routing method that uses an input fixed route. With NES-SOURCE routing, it is possible to set multiple paths to a single destination node, and these paths can have predetermined priorities.
When NES-SOURCE receives transmission requests from the upper layer, it first transmits the packet using the highest priority path. When a packet transmission failure is detected at the network layer, NES-SOURCE retransmits the packet using the next priority path. NES-SOURCE only uses ACK communications from the MAC layer, i.e., it does not use ACK communications from the network layer when the communication path to the destination node is a single hop. In this case, NES-SOURCE retransmits using the next priority path when the ACK communication of the MAC layer fails. As a result, an average communication delay improvement of approximately 9 ms is confirmed for a single-hop communication path [16].

 Software
The NES-SOURCE source code is more compact compared to the protocol stacks for WSNs and WCNs. A source code size comparison is shown in Figure 1.
As an implementation of a general sensor network protocol, we refer to zboss [19], which is an open-source implementation of ZigBee PRO. The zboss code size (excluding the PHY driver) is 11217 steps in total (the NW layer code is 8366 steps).
As an implementation of the control radio protocol stack, we refer to OpenWSN [20], which is an opensource implementation of TSCH. The OpenWSN code size (excluding the PHY driver) is 4833 steps (the NW layer code is 1859 steps).
For NES-SOURCE, the total code size (excluding the PHY driver) is 2403 steps (the NW layer code is 727 steps). Even if only the number of code steps is compared, NES-SOURCE is a very compact implementation compared to other implementations.  Figure 2 compares the function complexity of each protocol stack. The complexity of a function can be measured by its cyclomatic complexity [21]. Note that adding new code to a function is difficult if the cyclomatic complexity is large. Generally, there is no problem if the cyclomatic complexity is 10 or less. Figure 2 compares the cyclomatic complexity of the top 40 functions in the source code of each protocol stack. For example, zboss has 35 complex functions (the cyclomatic complexity is greater than or equal to 10), and OpenWSN has 10 complex functions. In contrast, NES-SOURCE has only one complex function. Thus, we consider that NES-SOURCE stacks can be customized and adjusted faster than general WSN and WCN protocol stacks.
A size comparison of the highly complex functions in each protocol stack is shown in Figure 3. Generally, fewer steps per function result in better code readability, which makes the code easier to maintain. As can be seen, NES-SOURCE has fewer steps per function than the other stacks; thus, NES-SOURCE is easy to maintain.

Evaluation on Actual Machine
To evaluate and verify NES-SOURCE, we implemented it on an OKI MH 920-Node-232. The MH 920-Node-232 is a sensor node that supports IEEE 802.15.4g and is equipped with a Cortex-M3 processor. Here we adopted FreeRTOS [22] as the embedded OS, and we developed the stack using the C programming language. The other experimental variables are shown in Table 3.
We implemented NES-SOURCE to measure communication delay and PER. The experiment attempted to clarify the effects of NES-SOURCE's path-switching function on PER and communication delay. The path-switching function is executed when the communication environment changes. Therefore, we performed the experiment in a room wherein people entered and exited the environment (i.e., the communication environment changed).
In this experiment, receiving nodes were arranged to form a hexagon, and the transmitting node was installed at the center of the hexagon. The transmission packet was 53 bytes (including overhead), the distance between nodes was 2 m on average, the communication system's transmission frequency was 1 Hz, the number of people in the room was always approximately 10 people, and the number of trials was 10000 for each node (approximately 16 hours).
The experiment evaluated the following packet loss management methods.

Method 1: Retransmission by the same route
The transmission node retransmits using the same singlehop route if communication fails. Here, the maximum number of retransmissions is four (Figure 4).

Method 2: Retransmission by another route
The transmission node retransmits using a two-hop route if single-hop communication fails. Here, the maximum number of retransmissions is one ( Figure 5).

Method 3: Retransmission by the same and another route
The transmission node retransmits using a two-hop route if singlehop communication fails five times. Here, the maximum number of retransmissions for two-hop communication is one ( Figure 6).    Figure 7 shows the maximum communication delay for each method (i.e., 55.37, 51.84, and 95.93 ms for Methods 1, 2, and 3, respectively). Figure  8 shows the PER for each method (8.71 × 10 −3 , 5.83 × 10 −4 , and 5.33 × 10 −4 for Methods 1, 2, and 3, respectively).
The number of single-and two-hop communication routes for Method 2 was 58138 and 1827, respectively. The number of single-and two-hop communication routes for Method 3 was 59422 and 546, respectively.

Discussion
The experimental results indicate that the route change function in the proposed NES-SOURCE stack works effectively. In the experimental environment, Method 2 was more advantageous relative to PER ( Figure 5) than Method 1 as a measure against packet loss. Furthermore, Method 2 was clearly superior to Method 3 relative to maximum delay ( Figure 4). However, when compared relative to PER (Figure 5), the difference between Methods 2 and 3 is small.
These results demonstrate that the effect of link retransmission on packet loss was low in our experimental environment.
Thus, in a changing communication environment (e.g., a person enters the communication path), changing the path is more   Table 2 Simulation parameter values aUnitBackoffPeriod [8] 200 usec aCCATime [8] 100 usec macMinBE [8] 3 macMaxBE [8] 4 macMaxCSMABackoffs [8] 5 The number of peripheral nodes 25 Frame send period 3.5 msec Frame send interval 1 sec Measurement time 30000 sec×50 Table 3 Variable for calculating the PER As stated previously, changes in a communication environment cause packet loss and collision. Note that our experiment did not consider packet collisions. Thus, to calculate a more realistic PER, the collision occurrence rate in WCN traffic was calculated in a simulation.
The simulation was created based on the communication frequency assumed by a WCN (Table 1) and the communication device settings given in Section 4. The simulation parameters are shown in Table 2.
The simulation results show that, for 25 nodes in the vicinity and a packet transmission frequency of 1 Hz for each node (i.e., a WCN general data transmission environment; The PER of each method in a collision-free environment (PER m1_nc , PER m2_nc , PER m3_nc ) can be expressed as follows.
According to Zandra et al. [3], the PER request of a WCN is on the order of 10 −4 , and the delay request is on the order of 50-100 ms. Therefore, NES-SOURCE can be used in an experimental environment if the given WCN application has a slightly lower PER requirement.
When we construct WCN systems, we cannot predetermine traffic conditions or the frequency of communication problems. To mitigate this uncertainty, NES-SOURCE can flexibly change the packet loss countermeasure depending on the application's requests and the environment. For example, if the network traffic is assumed to be high, Method 1 is reasonable. On the other hand, when the network is constructed in an environment where people frequently enter the communication path, Method 2 is reasonable. Method 3 is appropriate if the goal is to increase the PER, even at the expense of the maximum delay.
"When a person enters the communication path, packet loss occurs." "Packet loss due to a person can always be avoided by changing the communication path." Assuming the above points are correct, the relationship between the probability that a person is within the communication path ( ) and the PER of each method can be expressed as follows.
For example, Figure 10 shows the relationship between P ps and PER when ℎ 1 = 0.8 × 10 −3 ， ℎ 2 = 1.59 × 10 −3 ，and ℎ 3 ＝ 0 (this is the same as the simulation results). In this case, when a person's appearance rate in the communication path exceeds 0.8%, it is better to adopt Method 2 relative to PER.

Conclusions
In this paper, we have proposed, implemented, and clarified the effectiveness of NES-SOURCE as a WCN protocol that adopts CSMA/CA, which is easy to handle. WSN protocol stacks must be customized and adjusted for each application, and the same is true for a WCN protocol stack, which is a WSN protocol stack with strict delay and PER requirements.
Many WCN stacks are implemented using TDMA. However, TDMA is difficult to handle; thus, customization and adjustment are difficult. Therefore, we have developed the compact NES-SOURCE WCN protocol stack. The proposed NES-SOURCE employs the CSMA/CA method rather than the TDMA method. As a result, NES-SOURCE's code size is approximately 2700 steps, which is less than one-half the size of the TDMA-based WCN stack. In addition, NES-SOURCE has a lower code complexity than conventional WCN stacks and can be customized and adjusted quickly.
The WCN protocol with TDMA ensures communication reliability by duplicating the communication path. In contrast, the proposed NES-SOURCE ensures communication reliability by fast path switching when communication fails.
We conducted experiments in an environment where people entered and exited the communication path, and we confirmed that NES-SOURCE's fast path-switching function works effectively. The experimental results demonstrate that NES-SOURCE's communication failure detection and path-switching mechanism are fast and that communication delay was within general WCN requirements.
We have also clarified the relationships between the probability of a person entering the communication path and the PER due to the occurrence of collisions relative to each of the PER of the path-switching methods that the proposed NES-SOURCE employs. Thus, when designing systems that use NES-SOURCE, it will be possible to predetermine the optimum path-switching method relative to communication frequency and the varying degrees of obstructions in the physical environment.
Conventionally, TDMA must be adopted in WCN systems; however, this is difficult to customize and incurs high costs. In contrast, according to our experimental and simulation results, we can construct less expensive CSMA/CA-based WCN systems that can be customized quickly.