An On-demand Scheduling Routing Protocol for IPv6 Industrial Wireless Sensor Networks based on Deterministic Scheduling

Transcription

1 An On-demand Scheduling Routing Protocol for IPv6 Industrial Wireless Sensor Networks based on Deterministic Scheduling 1 Ping Wang, 2 Fei Lan, 3 Heng Wang, 4 Min Xiang *1 Key Laboratory of Industrial Internet of Things and Networked Control (Ministry of Education), Chongqing University of Posts and Telecommunications, Chongqing , China, wangping@cqupt.edu.cn 2,3,4 Key Laboratory of Industrial Internet of Things and Networked Control (Ministry of Education), Chongqing University of Posts and Telecommunications, Chongqing , China, 2 lanyahui@126.com, 3 wangheng@cqupt.edu.cn, 4 xiangmin@cqupt.edu.cn Abstract Determinacy and reliability are significant requirements for industrial wireless sensor networks based on IPv6 protocol. To address these issues, in this paper, we propose an on-demand scheduling (ODS) routing protocol based on deterministic scheduling and channel quality. As a basis of the routing protocol, the adaptation layer protocol and the neighbor discovery protocol defined in 6LoWPAN standards are enhanced in order to support deterministic scheduling. Then we present the ODS routing protocol and evaluate its performance. The test results show that the ODS routing protocol can select out the optimal routes which satisfy the network requirements and the transmission performances of the IPv6 industrial wireless sensor network are improved effectively with the help of the proposed protocol. Keywords: Routing Protocol, 6LoWPAN, Deterministic Scheduling, Industrial Wireless Sensor Networks 1. Introduction Industrial wireless sensor networks have recently gained considerable attention owing to their nonline, application flexible and low-cost [1][2], and the industrial wireless environment based on 6LoWPAN has a huge advantage for the application of IPv6 technology. Thus, the research for IPv6 industrial wireless sensor networks has also become a hot topic. However, the industrial application environment has high requirements in determinacy and reliability, especially the deterministic demand, and in which the multi-type data has a strict application class [3]. These characteristics of industrial application environment proposed a huge challenge to the applications of 6LoWPAN. In addition, because the determinacy is one of the most important requirements of IPv6 industrial wireless sensor networks, so it is necessary to solve deterministic technology in the process of using IPv6 industrial wireless sensor networks. In IPv6 industrial wireless sensor networks, the data from sensor node must be transmitted to destination, reliably and in time. Lost or delayed data may cause malfunction for industrial applications. Because of the industrial wireless sensor networks has a certain fault tolerance, when some packets are delayed or lost, others may be transmitted continuously, and there should be another path which is available can be used to transmit packets. Thus, we should carefully design a reasonable routing protocol for the networks. In several studies, many routing protocols have been proposed for industrial wireless sensor networks [4][5] or 6LoWPAN [6][7], but there were problems in applying these routing protocols to IPv6 industrial wireless sensor networks, because the determinacy and IPv6 technologies were not considered at the same time. There have been studies about routing protocol in IPv6 industrial wireless sensor networks [8][9]. Most of these routing protocols do not provide simultaneous deterministic and reliable communication. The aforementioned IPv6 industrial wireless sensor networks require simultaneous deterministic and reliable communication. Thus, we should design a routing protocol that can provide deterministic and reliable communication in IPv6 industrial wireless sensor networks. In this paper, we propose an ODS routing protocol which is designed to achieve the aforementioned requirements in IPv6 industrial wireless sensor networks. The ODS routing protocol takes scheduling time limit and channel quality as its routing criteria [10].The packets can be sent to the destination in Advances in information Sciences and Service Sciences(AISS) Volume5, Number8, April 2013 doi: /aiss.vol5.issue

2 prescriptive time and channel through the routes generated by the ODS protocol. It reduces the ratio of the packets delay and loss, and finally saves energy and resources. 2. Frame format improvements In order to realize the ODS routing protocol, we consider improving the frame format of messages in existing protocols. Because the messages which are used in routing are mainly request messages and response messages, so this paper mainly improves the adaptation layer protocol and neighbor discovery protocol. The detailed improvement methods are presented in this section Frame format improvements in adaptation layer protocol When the link layer uses TDMA and deterministic scheduling mechanism, its scheduling period exists in the form of time slot, while the adaptation layer which is in the upper of the link layer is not based on the time slot. Therefore, it must be associated with the time slot in dealing with the interaction process between adaptation layer and link layer. Besides, user may have some special deterministic requirements for the application data, such as marking the characteristics of determinacy on data so as to select and recognize the route which meets its requirements. According to the all above, it is necessary to improve the adaptation layer protocol in order to support the deterministic scheduling. For the improvements of the adaptation layer protocol, we designed scheduling header, in this way, user can set scheduling to mark the characteristics of determinacy for data. In IPv6 header stack, scheduling header following mesh header, and other headers following scheduling header, the last field is payload. An improved frame format of IPv6 header stack is described in figure.1. Figure 1. An IPv6 header stack that contains scheduling header Because there is a header type description field before all types header in adaptation layer, so there is a scheduling dispatch before the scheduling header, look at figure 1. According to the existing standard documents, such as RFC4944 and RFC6282, we set the value of scheduling dispatch to by excluding the header type description values which have been used in other standards. Associated information is described in figure 2. Figure 2. The type value of scheduling header and scheduling header In this paper, we add the scheduling header to improve the adaptation layer protocol. It is not only defined the scheduling dispatch value, but also designed the frame format of the scheduling header. The frame format of the scheduling header is shown in figure 3. Figure 3. The frame format of the scheduling header Look at figure 3, the scheduling header contains sequence number, scheduling ID and scheduling time limit. The following will describe these options in detail. Sequence Number: its value will be added 1 when it sends a packet. When its value is added up to 255, it will be recounted with 0. Scheduling ID: it is used to express the route information, and it is also used to support routing of deterministic scheduling. When there is no path that meets the requirements, the value of scheduling ID should be initialized to 0; while it has found a path that meets the requirements, the value of scheduling ID should be set to path ID, and forwarding the packet through the path which is designated by the path ID. 1040

3 Scheduling Time Limit (STL): it is a threshold value which is the sum of all nodes scheduling time in the packet transmission path. It is set by user. The scheduling time limit is in milliseconds, and its maximum can reach milliseconds Frame format improvements neighbor discovery protocol In this paper, improvement of neighbor discovery protocol is based on optimized 6LoWPAN neighbor discovery protocol. By analyzing the optimized 6LoWPAN neighbor discovery protocol, we know the protocol is mainly for applications of LLNs network. However, the requirements of industrial application environment are more strict, especially the determinacy. Therefore, it is necessary to improve the 6LoWPAN neighbor discovery protocol. For the improvement of the 6LoWPAN neighbor discovery protocol, because of the protocols used the message in neighbor discovery are all the ICMP protocol, and it is specially to solve the transmission of control information between router and host, so we consider extend ICMP message. Facts have proved that the method is not only expanded the application range of the existing protocol, but also easier to realize compared with others, and it suitable for any protocol layer based routing. In this paper, we add two new ICMP messages to the original message. They are scheduling routing request message (SRR) and scheduling routing confirm message (SRC). The format of two messages is corresponded with basic format of neighbor discovery ICMP message. The format is shown in figure 4. Byte:1 1 2 Type Code Checksum undefined Other domains of ICMP message Figure 4. ICMP message s basic format of 6LoWPAN neighbor discovery protocol The five basic ICMP messages type value defined in IPv6 neighbor discovery protocol are , and 6LoWPAN neighbor discovery protocol provisions of its new-added options type value of TBD1- TBD5, and the value of code is 0. Thus, this paper provisions of its SRR type value of TBD6 and its SRC type value of TBD7, and provisions of the code in SRR and SRC of 1. The frame format of SRR is shown in figure 5. Figure 5. The frame format of SRR The detailed description of the each field in SRR as follows. Type: TBD6. Code: 1, it indicates that the scheduling routing is implemented in adaptation layer. Checksum: the ICMP checksum. Request ID: it is a local counter maintained by source. When the source requests find a route to the destination, the counter is incremented by 1. Source Number: when the source sends a SRR to the destination, the counter is incremented by 1. Scheduling Time Limit: the STL value must be consistent with the STL that is provided by user in scheduling header. Channel Quality: it is used to accumulate the value of channel quality on route. Reserved: it is used to add new functions to the message in future. Options: it can add new options in order to support the extension of scheduling routing. Now, we introduce the format of SRC. The frame format of SRC is shown in figure 6. Figure 6. The frame format of SRC The detailed description of the each field in SRC as follows. Type: TBD7. Code: 1, it indicates that the scheduling routing is implemented in adaptation layer. 1041

4 Checksum: the ICMP checksum. Request ID: it is indirectly copy the request ID of SRR. Path ID: it is maintained by the destination, its initial value is 1. When the node found a path that meets the requirements, the path ID is incremented by 1. Target Number: it is maintained by the destination. When the sender sends a SRC to the receiver, the target number is incremented by 1. Hop Number: it is an accumulation. It records the hop value from each intermediate node to the destination of SRR. Channel Quality: it is indirectly copy the channel quality of SRR. Reserved: it is used to add new functions to the message in future. Options: it can add new options in order to support the extension of scheduling routing. 3. ODS routing protocol 3.1. Route discovery The ODS routing protocol is a routing protocol specially designed for IPv6 industrial wireless sensor networks, which supports the deterministic scheduling. The key criteria of ODS routing protocol is scheduling time and channel quality, but the scheduling time is the principal criteria that should be considered. When the routes which have been selected out are all satisfied the STL, then the channel quality should be considered [11][12]. To describe the ODS routing protocol, we consider the IPv6 industrial wireless sensor networks as figure 7, in which a process in node A wants to send data with character of time limit to node K. F F F B G B G B G A C D E K A C (a) (b) (c) (d) (e) Figure 7. A network example of node sends SRR D E K A C D E K To implement the ODS routing protocol, each node needs to maintain some options. All devices maintain neighbor table and reverse route table; router maintains route table and local history table; source maintains scheduling path history table. Scheduling path history table contains some information, such as destination, scheduling ID, STL and so on. Look at figure 7, when A intends to send a data with time limit to K, it looks up its scheduling path history table. If A has found that there is no path which meets STL to K in its scheduling path history table, it has to find a path which is meets STL to K. To locate K, A constructs a SRR and sends it to its neighbors (B and C in this case). In deterministic scheduling mechanism, each node works in a specific time slot, and the channel of each time slot may be different. Thus, A takes unicast rather than multicast and broadcast. Figure 8 shows the format of SRR fields related to the route discovery. It has omitted the ICMP header and reserved which have nothing to do with routing. In addition, the (Source address, Request ID) pair uniquely identifies a group of SRR. Node can determine and discard the duplicate SRR according to the (Source address, Request ID) pair. Figure 8. SRR fields related to the route discovery Each node needs to maintain sequence counter and request ID counter. In any circumstance, when it sends a SRR or responses to others for SRR, the sequence counter is incremented by 1. Hop limit is used to terminate the expansion of SRR when its route hop number has beyond the hop limit. Besides, STL field is an important field to express the determinacy. It should be set by user, and the initial STL value of the source is equal to the STL value of the scheduling header. When each intermediate node is 1042

5 forwarding SRR, it will recount the STL field. The last field is channel quality, which is used to accumulate value of channel quality so that the optimal path will be selected out. When A unicasts SRR to its neighbors, it firstly calculates the scheduling time to its neighbor (B in this case), and then gets new STL value by using STL subtracts the scheduling time of A to B. When the new STL value is not zero, it will add the channel quality field to the channel quality of A to B, and then send out the SRR. When the SRR arrived at routers (B and C in this case), it is processed by the routers as following steps. Step 1: Look up the (Source address, Request ID) pair in the local history table to see if this SRR has already been seen and processed. If it is a duplicate, it will be discarded and processing stop. If it is not a duplicate, the pair enter into the local history table so future duplicates can be rejected, then processing continues. Step 2: Receiver looks up its neighbor table, and calculates the scheduling time to each neighbor and new STL. If the STL value is larger than zero, it will accumulate the value of channel quality to this neighbor, and reduce the hop limit and increase the source sequence, and then send the SRR to the neighbor. Meanwhile, the receiver also extracts data from the SRR and stores it as a new entry in its reverse route table. This information will be used to construct the revere route so that the SRC can back to the source later. The arrows in figure 7 are used for building the reverse routing route. A timer is started for the newly-made reverse route entry. If it expires, the entry is deleted. Neither B nor C knows where K is, so each of them creates a reverse route entry pointing back to A, as shown by the arrows in figure(b), and forwarding the SRR to its neighbors after processing it, and it must ensure the value of new scheduling time is still a positive value. For the unicast from B to C, D and F, D and F will send the SRR to their neighbor after processing it and create a reverse route entry pointing back to B, while C rejects the SRR as a duplicate. Similarly, C s unicast is rejected by B. However, C s unicast is accepted by E, and it creates a reverse route entry pointing back to C, as shown in figure(c). After D, E and F received the SRR, it is the first time that the SRR arrives at K, as shown in figure (d). When the node which is not a destination received the SRR, it will discard the SRR and does not any processing. When E received the SRR, it creates a SRC to confirm the path. Figure 9 shows the format of SRC fields related to the route discovery. It has omitted the ICMP header and reserved which have nothing to do with routing. Figure 9. SRC fields related to the route discovery The source address, destination address, request ID and channel quality in SRC are all directly copy the SRR s. SRR completes the process of accumulating channel quality because of the channel that is used by SRC in reverse route is not the channel that is used by SRR. Destination sequence is maintained by destination, which is increment by 1 when the destination has sent out a SRC, and when the intermediate node forwarding SRC, the destination sequence is also increment by 1. The hop count should be initialed to zero. Path ID is used to mark route. When the destination received a SRR which is sent by a new node, the path ID is increment by 1, and it shows that there is an available route. In this way, it can ensure that the path ID to the same node is unique. Because K received the SRR from G, D and E, so it unicasts the SRC to G, D and E following the reverse path, and then the SRC arrives at C from E and finally to A. On another path, the SRC follows the reverse path to A via D and B. On each node, hop count is increased so the node can see how far from the destination (K in this case) it is. Each intermediate node should inspect the SRC on the way back and store the information which contains source and destination address, path ID, next hop address and hop count in the local history table as a route to K. In this way, the source (A in this case) acquired a route which meets STL to the destination (K in this case). Now, we need to write the path ID of route into the scheduling ID field of scheduling header, and then forwarding data through the route which is signed by scheduling ID. The route can be used to communicate as long as the STL, the time slot of device and the configuration of channel do not changed. Nodes that got the SRR but do not on the route (F and G in this case) which is signed by path ID should discard the reverse route table entry when the associated timer expires. As described above, source selects route according to the STL which is set by user. If the restriction of STL is not very strict, many routes satisfied the restriction of STL will be selected out, in this case, 1043

6 we take channel quality of each hop as another metrics, in order to select a route with higher reliability. If the channel quality of i to j iscq, we can calculate the total channel quality CQ of route according ij sum n 1 to the formula of CQsum CQ, then source takes formula of CQ sum CQ sum ij CQav (the route contains i 1 n 1 m n nodes and has m hops) to calculate the average channel quality CQ of each hop on route, and finally av selects the route which has larger CQ as the optimal route to transmit data Route maintenance av Route maintenance refers to source determines whether the existing route is available by detecting the network topology s change. The route maintenance of ODS routing protocol can be implemented with hello packet, link repair and resend SRR after link disconnected. The detailed process as follows. Each node sends hello packet to its neighbors periodically. If the neighbors do not receive the hello packet after a certain period of time, it will start the process of link repair, and unicast the SRR to the unreachable node. When there are intermediate nodes located on effective route to the unreachable node or the unreachable node itself received the SRR, it will reply SRC to the source, until the route to the unreachable node is rebuild. If the process of link repair is failed, node unicasts the SRR to its neighbors, the unreachable node table in SRR contains neighbors located on disconnect link and destination which is the next hop of the neighbors. Through the unicast of the SRR, the nodes tell their neighbors, and so on, recursively. Finally other nodes know the link is disconnected. 4. Simulation-based analysis In this section, we describe the results of a simulation-based routing protocols performance study. To evaluate the performance of the ODS routing protocol, we consider comparing the ODS routing protocol with the classic AODV protocol [13]. We consider a subnet which contains 1 gateway, 11 routers and 1 end device into OPNET simulation platform, and set the STL to 500ms and the network maximum depth to 5. The ODS routing protocol selects route by scheduling time and channel quality, while the AODV protocol selects route by distance vector. To clarify the scheduling time and the channel quality between one node and another node, we abstract the network topology in simulation platform to the weighted graph as shown in figure 10. (a) (b) Figure 10. The weighted graph In figure 10, figure 10(a) is a graph whose weighted value is scheduling time, while figure 10(b) is a graph whose weighted value is channel quality, and the channel quality has been evaluated and processed. By simulating the ODS routing protocol and the AODV protocol, we get some routes which are found by these protocols, as shown in figure (a) (b) Figure 11. The routes generated by protocols 1044

7 Look at figure 11(a), the AODV selected out 3 routes, they are P1, P2 and P3, respectively, and the P1={1,(1,5),5,(5,8),8,(8,13),13}; P2={1,(1,5),5,(5,9),9,(9,13),13}; P3={1,(1,3),3,(3,7),7,(7,10),10,(10, 13),13}. The hop number of the three routes is 3, 3 and 4, respectively, and the total scheduling time of them is 510, 520 and 500, and the average channel quality is 57, 35 and -47. While the ODS routing protocol selected out 2 routes, as shown in figure 11(b). They are P4 and P5, respectively, and the P4={1,(1,2),2,(2,4),4,(4,8),8,(8,13),13};P5={1,(1,3),3,(3,6),6,(6,10),10,(10,12),12,(12,13),13}. The hop number of the two routes is 4 and 5, and the total scheduling time of them is 480 and 490, and the average channel quality is 78 and 63. They are shown in figure 12. (a) (b) Figure 12. The parameter line graph of protocols Look at figure 12(a), it is the parameter line graph generated by AODV protocol, and the total scheduling time of P1 or P2 is larger than the STL that is 500ms, and the average channel quality of P3 is negative which represents the bad channel forwarding the data on the route, so the three routes selected by AODV protocol cannot satisfy the deterministic requirement of the IPv6 industrial wireless sensor networks. While in the figure 12(b), where the parameter line graph generated by ODS routing protocol, the total scheduling time of P4 or P5 is lower than the STL which is 500ms, and the average channel quality of P4 or P5 is positive and much better, so the two routes selected by ODS routing protocol satisfy the deterministic requirement of the IPv6 industrial wireless sensor networks. Because the ODS routing protocol is based on the time slot and channel, so it uses unicast rather than broadcast that is used by AODV protocol to transmit data, in this way, it can save more resources and energy. In addition, it can also cut costs and avoid wasting packets. It is very useful for the energy limited network, such as the IPv6 industrial wireless sensor networks. 5. Implementation This section focuses on the implementation of the ODS routing protocol. It describes how the routing protocol selects the optimal route satisfied the deterministic requirement in detail. To test and verify the feasibility of the ODS routing protocol in practical applications, we consider a 6LoPWAN test system, as shown in figure 13. The hardware platform of this system is wireless communication module based on the CC2430 and some sensor devices, and the software platform of the system is IAR compiler, the protocol analyzer software of Texas Instruments packet sniffer and serial debugging assistant. Figure 13. The 6LoWPAN test system 1045

8 The 6LoWPAN test system contains one TD/WSN gateway, 5 routers and 14 sensor devices. In this system, the gateway sends the data which is in the 6LoWAPN subnet to remote PC, and the software on PC shows the data information. Figure 14 shows the PC monitoring interface of the 6LoWAPN network. Figure 14. 6LoWAPN network monitoring interface In this paper, the test case is that the temperature and humidity sensor needs to send the temperature and humidity values to the coordinator located in the gateway. The application data STL is set to 500ms by user. To clarify the behavior of the sensor device, we can print the route information in the process of data transmission via serial. Figure 15 shows the process of the temperature and humidity sensor node searching for optimal route when it needs to send data to the gateway. (a) (b) (c) Figure 15. The process of the node searching for optimal route In figure 15, figure 15(a) represents the print information of the temperature and humidity sensor sends data, figure 15(b) represents the print information of the router 4 forwarding data, and figure 15(c) represents the print information of the coordinator in the gateway receives data. According to the test results, the optimal route of the temperature and humidity sensor node (address is 0x0402) to the gateway (address is 0x0000) is path P, and P = {0x0402, (0x0402, 0x0400), 0x0400, (0x0400, 0x0000), 0x0000}. Through analyzing, the path P meets the requirement of the network, and the channel quality of it is also much better. 6. Conclusion In this paper, an ODS routing protocol based on deterministic scheduling is proposed to meet the requirement of determinacy for IPv6 industrial wireless sensor networks. We adopt the scheduling time and the channel quality as the routing criteria via combining the existing 6LoWPAN related protocols with the whole network s data communication mechanism. Besides, the network can save more energy and resources due to the use of the packets unicast mechanism. The process of routing about ODS routing protocol is captured in the implementation. Simulation results show that, compared with the AODV protocol which cannot select out the route that meets the deterministic requirement, ODS routing protocol is able to select out the route that meets the deterministic requirement of the network and achieved higher energy utilization efficiency. 1046

9 7. Acknowledgement This work was supported in part by the Foundation for University Youth Key Teacher of Chongqing, the National Science and Technology Major Project of China under Grant 2012ZX , 2013ZX and 2011ZX , and supported by the Chongqing Engineering Research Center Construction Project of cstc2011ptgc40006 and Natural Science Foundation Project of CQ CSTC2011jjA References [1] J. Yick, B. Mukherjee, D. Ghosal, Wireless Sensor Network Survey, Computer Networks, vol. 52, no. 12, pp , [2] Andreas Willig, Recent and Emerging Topics in Wireless Industrial Communications: A selection, IEEE Transactions on Industrial Informatics, vol. 4, no. 2, pp , [3] K. Al Agha, M.-H. Bertin, T. Dang, A. Guitton, P. Minet, T. Val, J.-B. Viollet, Which Wireless Technology for Industrial Wireless Sensor Networks? The Development of OCARI Technology, IEEE Trans. Ind. Electron., vol. 56, no. 10, pp , [4] Myung Kyun Kim, Hoai Phong Ngo. A Reliable and Energy Efficient Routing Protocol in Industrial Wireless Sensor Networks, International Conference on Advanced Technologies for Communications (ATC), pp.32-35, [5] A. Ali, R. A. Rashid, Optimal Forwarding Probability for Real-time Routing in Wireless Sensor Network, In Proceedings of IEEE International Conference on Telecommunications and Malaysia International Conference on Communications, pp , [6] G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, Transmission of IPv6 Packets over IEEE Networks, IETF Internet Draft draft-ietf-6lowpan-format-13 (work in progress), [7] Jonthan W. Hui, David E. Culler, Extending IP to Low-power Wireless Sensor Network, IEEE Computer Science., vol.12, no. 4, pp , [8] JP Vasseur, Navneet Agarwal, Jonathan Hui, The IP Routing Protocol designed for Low Power and Lossy Networks, Internet Protocol for Smart Objects (IPSO) Alliance, [9] A. Weaver, Survey of Industrial Information Technology, In Proceedings of the IEEE Annu(Conference) on Industrial Electronics Society, pp , [10] V. C. Gungor, G. P. Hancke, Industrial wireless sensor networks: Challenges, design principles and technical approaches, IEEE Trans. Ind. Electron., vol. 56, no. 10, pp , [11] Zhanmao Cao, Limin Peng, Destination-oriented Routing and Maximum Capacity Scheduling Algorithms in Cayley Graph Model for Wireless Mesh Network, JCIT: Journal of Convergence Information Technology, AICIT, vol. 5, no. 10, pp , [12] Ali Modirkhazeni, Norafida Ithnin, Othman Ibrahim, Empirical Study on Secure Routing Protocols in Wireless Sensor Networks, IJACT: International Journal of Advancements in Computing Technology, AICIT, vol. 2, no. 5, pp , [13] C. E. Perkins, E. M. Royer, Ad-hoc On-Demand Distance Vector Routing, Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, pp ,