Abstract
The conformance testing on the wireless sensor networks (WSNs) is fundamental for the functional large-scale deployment and interconnection with the global Internet. The WSN protocols based on the Internet Protocol version 6 (IPv6) are the major trends of the future applications, which include IEEE 802.15.4, 6LoWPAN, and RPL. These protocols are not only diverse for various applications, but also volatile in the future. Moreover, sensor nodes are resource constrained, application related and lack the standardized test interface. Hence the corresponding conformance testing is seriously insufficient and needs urgently research. In this paper, the IPv6-based WSN protocols are analyzed and the conformance testing techniques and methods for IPv6-based WSNs are investigated towards the standardization of WSNs. A novel conformance test system for IPv6-based WSNs is designed and implemented, which is open, flexible, full featured, and practical. The conformance test system is suitable for the protocol evolution and the various hardware interfaces for the sensor nodes. The related outcomes will promote the standardization and commercialization of WSNs.
1. Introduction
Wireless sensor networks (WSNs) are the emerging research areas in the current international academia and industry, which can be widely used in many fields, such as intelligent transportation, environmental monitoring, and industrial automation. WSNs have received widespread attention, with a great prospect for economic and social value.
It is fundamental to consider the interconnection between WSNs and Internet for the large-scale application of WSNs. As the core of next-generation Internet protocols, IPv6 has many advantages which include the richness in address resource, the autoconfiguration of address, supporting real-time business, higher security, and better mobility. With the combination of IPv6 and WSNs, IPv6-based WSNs can meet the demands of the current WSNs in the address, security, mobility, and the integration with the existing networks, which will greatly promote the development of WSNs and has become a hot research field of WSNs. Some lightweight IPv6 protocol standards and draft for WSNs have successively been developed in industry, such as IEEE 802.15.4 in MAC (Media Access Control) layer, 6LoWPANs (IPv6 over Low-power Wireless Personal Area Networks) in the adaptation layer, and routing protocol RPL (IPv6 Routing Protocol for Low-power and Lossy Networks) in the network layer. The IETF is accelerating the standardization process of the above-mentioned protocols.
IEEE 802.15.4 is one of most widely used protocol standards in the field of WSNs, which describes the technical specifications suitable for the low-power devices and the short-range wireless communication. The 6LoWPAN group was established by the IETF (the Internet Engineering Task Force) in November 2004, which is dedicated to the IPv6 protocol over IEEE 802.15.4 based networks and has submitted several copies of RFCs (Request for Comments) and the drafts. 6LoWPAN adds an adaptation layer between the IPv6 network layer and the IEEE 802.15.4 MAC layer, which will realize ultimately the seamless connectivity between the IPv6 technology and WSNs. The IETF is also promoting the standardization process of RPL routing protocol on the top of 6LoWPAN adaptation layer.
In the development of WSNs and their protocol stacks, it must be considered whether the protocol implementations in different sensor devices are consistent to the protocol specifications, that is the protocol conformance testing. Conformance testing is verification that an implementation meets the formal requirements of the referenced standards and, more precisely, that it meets the conformance clauses contained in the standards ISO/IEC 9646. In order to ensure the interconnection and interoperability between protocol implementations, the protocol conformance testing must be conducted. Therefore, with the development of WSNs, the key technologies of the protocol conformance testing must be broken to assure the coincidence between protocol implementation and the protocol specifications.
Specifically, the conformance testing on protocols for IPv6-based WSNs is to execute a group of targeted conformance test cases of IPv6-based sensor network protocols (e.g., 6LoWPAN), observe the output behaviors of SUT (System Under Test), analyze the test results, and determine whether the functionality or performance of SUT to meet the specifications of IPv6-based WSN protocols.
At present, there is a serious shortage of research on protocol conformance testing and the equipment development for IPv6-based WSNs. Although some related work exists, the standardized conformance testing specifications on protocols for IPv6-based WSNs have not still been established; the conformance test suites and the engineering conformance test system have not been designed and developed so far. So it is very meaningful and important to carry out the related research and development of the protocol conformance testing in order to promote the commercialization of WSNs. However, there are many difficulties and challenges to face, as follows.
Firstly, at present IEEE 802.15.4 contains five standards, 6LoWPAN contains two RFCs and five drafts, and the RPL contains five RFC and nine working group drafts. The preparation of the comprehensive conformance test specifications and the development of the conformance test suites for IPv6-based WSN protocols are tedious and the workload is very large. Therefore, it is the key issue how to combine the technology of the automation and the manual to reduce labor costs, improve the preparation speed of test specifications, and to choose a reasonable test description language for the efficient development of the conformance test suites for IPv6-based WSN protocols.
Secondly, most of IPv6-based WSN protocols are in the draft stage and the content of the protocols will continue changing and form a new draft version, which requires that the conformance test system is open and has the good adaptability and scalability. It is best that the test system does not depend on the specific protocol test suites, and the ETS (Executable Test Suite) in the test system can be added and updated dynamically.
Thirdly, the application of WSNs is extensive and diverse; there are many node manufacturers which generate node devices with different appearances and communication interfaces. The typical communication interfaces of nodes include the air interface, serial interface, and Ethernet interface. The air interface is used for wireless communication between nodes and is relatively uniform, but the latter two interfaces, which are used for the edge nodes to communicate with the existing wired network, are usually different in appearance. Faced with the difference of the WSN hardware and software, the uncertainty of the evolution of the tested IPv6-based WSN protocol standards, the diverse needs of users, and the test system need designing with the extensible hardware and software architecture to support multiple interfaces.
Fourthly, the practical test system requires the hardware to be compact and appropriate. In the specific conformance testing of the target nodes, combining with different test requirements and the system hardware volume, the test system needs to virtualize different wireless environment, to simulate multiple nodes to virtualize larger-scale networks with different network topologies, and to virtualize various events between nodes to simulate different application scenes.
In this paper, to address the above challenges, the conformance testing techniques and methods are studied, the conformance test suites are stipulated and developed, and the open conformance test system is designed and implemented towards the standardization of IPv6-based WSNs. This paper is organized as follows. Section 2 reviews related work. Section 3 describes the design and generation of protocol conformance test suites for IPv6-based wireless sensor networks. Section 4 describes the design and implementation of conformance test system for IPv6-based wireless sensor networks. Conclusions are finally drawn in Section 5.
2. Related Work
As the basic and important aspect of the protocol testing, the protocol conformance testing is the primary concern of all the protocol developers and there has been a lot of related work in different communication network areas.
In the 1990s, ISO (International Organization for Standardization) specially formulated a set of international standards ISO/IEC 9646, which provide the theoretical framework and test methods for protocol conformance testing, the design steps and description methods for developing the test suites, and the guidance on the implementation of the test system.
In the conformance testing of Internet, the conformance test suite for the RIPng protocol was developed in [1] using TTCN-3. The mobile IPv6 protocols specification, validation, and testing were dealt with using a formal approach [2]. In China, Tsinghua University has caught out the conformance testing of TCP/IP protocol from the 1990s, gotten a number of research results, and developed different versions of the protocol conformance test systems including the PITS [3] and PITSv3 [4].
In the protocol conformance testing of mobile communication network, [5, 6] developed the TTCN-3-based conformance testing tools for OMAMMS (Multimedia Messaging Service) and Push-to-talk service over Cellular in 3G or 4G networks, respectively. [7] studied the conformance testing methodology of MBBMS (Mobile Broadcast Business Management System) and designed and implemented an MBBMS protocol conformance testing tool based on TTCN-3. DTmobile developed the TD-SCDMA Terminal protocol conformance tester ECT6210. Equipped with the latest instrument hardware platform of DTmobile, ECT6210 can provide customers with a complete TD-SCDMA terminal protocol conformance testing solution.
In the wireless sensor networks, many methods are usually used to verify the effectiveness and feasibility of the proposed protocols and algorithms, which include the basic theoretical analysis, the computer simulation methods [8, 9], the small-scale testbeds for actual system test [10, 11], and the sniffer tools for real-time monitoring WSNs [12, 13]. However, the related work in conformance testing on protocols for WSNs (especially IPv6-based WSNs) is rare.
ZigBee is a low-power personal area network protocol based on the IEEE 802.15.4 standard, which is characterized by short-distance, low-complexity, self-organizing, low-power, and low-data rate. In order to ensure the reliability of ZigBee products and the stability of wireless networking, the ZigBee Alliance announced the ZigBee certified program in 2007 and is specifically responsible for the implementation and management of the certification testing. At present, the ZigBee Alliance has sanctioned certification testing by three qualified international test service providers, including TRaC Global, National Technical Systems, Inc., and TUV Rheinland Group. The official ZigBee test specification for the certification of ZigBee products uses the special test suite to test and certify whether ZigBee platform equipments meet the requirements of ZigBee specification. The ZigBee Alliance offers two levels of standard compliance which include ZigBee compliant platforms (ZCPs) and ZigBee certified products. ZCP testing includes application layer, network layer, IEEE 802.15.4 Physical, and MAC layer, as well as security testing required in the test specification. In addition to the above test content, ZigBee Certified Products testing also includes the application profile testing.
RealProct [14] is presented to use a few low-cost real sensor nodes to mimic large-scale real WSNs and then perform protocol conformance testing for WSNs. A part of the test suite is developed by the handwritten method to test the protocol implementation of the μIP TCP/IP stack in Contiki-2.4. However, RealProct mainly emphasizes the software bug detection and there are some cases which cannot be virtualized; for example, it cannot virtualize the wireless environment when interference caused by simultaneous transmissions happens. The fundamental components of conformance testing on protocols for IPv6-based WSNs are simply described in [15, 16]. Conformance testing methodology and system design of the 6LoWPAN protocol is studied in [17], but the standardized conformance testing specification on protocols for IPv6-based WSNs has not still been established; the conformance test suite and the engineering conformance test system have not been designed and developed. The industrial wireless standard ISA100.1la is studied in [18], which may provide references for conformance testing on protocols for IPv6-based WSNs.
3. Design and Generation of Protocol Conformance Test Suites for IPv6-Based WSNs
In the conformance testing on protocols for IPv6-based WSNs, the tested protocols include IEEE 802.15.4 in MAC layer, 6LoWPAN in the adaptation layer, and routing protocol RPL in the network layer, which are characterized by a wide variety of species and quite different contents. For the protocol conformance testing, the protocol conformance test specification is the basis and key, and it is used for providing the abstract test suite (ATS) and regulating the test methods. However, there have not been still the corresponding conformance test specifications for IPv6-based WSNs. Therefore, in accordance with the characteristics of WSNs and the specific content of IPv6-based WSNs protocol specifications, the specific protocol conformance test suites for IPv6-based WSNs are described and the automatic generation technology of the abstract test suite based on the formal methods is studied in this paper.
In the programming of ATS, it is important to choose a generic programming language for the testing requirements [4]. The programming language directly determines the description methods of the test suite, whose expression ability determines the quality of the written test suite and affects the ease of use and efficiency. In addition, the programming language also directly determines the test structure and execution mechanism of test systems and affects the characteristics of test system. According to the testing requirements of the IPv6-based WSNs protocols, we choose TTCN-3 [19] as the programming language.
TTCN is developed and maintained by ETSI (European Telecommunications Standards Institute) as the internationally standardized language for defining test suite. The latest version, TTCN-3, is a modern and flexible language and can be used to describe the black-box testing of a variety of interactive systems, whose typical application fields include protocol testing, system testing, interaction testing, service testing, and module testing. Compared with other programming languages (such as C/C++, JAVA, Tcl/tk, and Perl), TTCN-3 is the programming language dedicated in protocol testing. With the characteristics of the platform independence and the special testing capabilities, TTCN-3 has been used for developing the conformance test suites for many protocols, such as GSM, 3G, and Bluetooth protocols.
3.1. Design of Protocol Conformance Test Suites in the Conformance Test Specifications
In order to integrate IPv6 and WSNs, the IETF has set up three working groups to study the key technologies and carry out the standardization of the low-power IPv6 network. The 6LoWPAN Working Group mainly discusses how to adapt IPv6 protocol to IEEE 802.15.4 based networks. The ROLL (Routing Over Low-power and Lossy Networks) Working Group focuses on the routing protocols in the low-power network and develops the routing requirements in every scene. The CoRE (Constrained Restful Environment) Working Group is providing a framework for resource-oriented applications intended to run on constrained IP networks.
At present, 6LoWPAN group has completed two RFC manuscripts: “IPv6 over Low-power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals” (RFC4919, Informational) and “Transmission of IPv6 Packets over IEEE 802.15.4 Networks” (RFC4944, Proposed Standard). ROLL Working Group has developed the routing requirements for four scenarios, including “Home Automation Routing Requirements in Low-power and Lossy Networks” (RFC5826), “Industrial Routing Requirements in Low-power and Lossy Networks” (RFC5673), “Routing Requirements for Urban Low-power and Lossy Networks” (RFC5548), and “Building Automation Routing Requirements in Low-power and Lossy Networks” (draft). On the basis of the routing requirements and the quantitative indicators in the link selection, ROLL Working Group has developed the RPL.
By studying the above protocol specifications, we can understand their basic functions and the relationship between the various functions and know the essential and optional features. Thus the test cases with different testing purposes are generated.
In order to try to cover all the technical requirements of the protocol specifications, it can be implemented by both of the manual writing and the automatic generation for identifying and describing the test suites in the test specifications as follows.
(1) Manual Writing
Defined by the functions, the protocol specifications contain the following.
Firstly, according to different functions of the protocols, the technical requirements are divided to determine the large function sets. Secondly, the large function sets are refined to form the individual test cases in the light of different equipment, different implementations, and the specific function process.
Defined by the transfer of the state machine or the protocol process, we have the following.
Firstly, according to the description of the protocols, the complete state machine and/or the protocol process is established. Secondly, the transfer between any two states or any step in the protocol process could be taken as an independent test case.
Defined by the data format (frame format) stipulated in the protocols
Rather than providing the function, status, and the protocol process, some protocol specifications define the data, signals, and frame format in the data exchange. At this time, the test cases could be established according to different fields or different requirements of the data signal and the frame format.
(2) Automatic Generation
The abstract test suites may be generated automatically by the formal methods and then the test specifications are formed, as shown in Figure 1.
Firstly, the IPv6-based WSN protocol specifications in the natural language are described by the formal models, such as FSM (Finite-State Machine) model, EFSM (Extended Finite-State Machine) model, SDL (Specification and Description Language), and UML (Unified Modeling Language).
Secondly, the abstract test sequences are generated with the test generation technology, according to the protocol formal models. In the generation process, the coverage of the generated test sequences is ensured by the test coverage technology. For example, the coverage criteria (such as state coverage, change coverage, and path coverage) are used for the FSM model; the coverage criteria (e.g., all-du-path coverage) are used for the EFSM model.
The automatic generation of the abstract test suites.
Finally, the abstract test sequences are used as the basis and reference to develop the conformance testing specifications of IPv6-based WSNs protocols and can also verify the test specification by the manual writing.
In describing the test suites in the test specifications, the various parameters and primitives in each test case need defining, as well as the correct response results in the protocol exchange. As a part of the test specification, the correct judgment is not only given when the test cases succeed in passing the test, but also the judgment of failure is given against the wrong response. In the actual testing process, a lot of test cases begin with a particular state, which requires that in the beginning of each test case, the initial states of the test system and the devices under test are given to ensure that the test cases will start from the correct state machine.
According to the above generation methodology of the test specifications and test suites of IPv6-based WSN protocols, the main content of the test suites of IEEE 802.15.4 in MAC layer, 6LoWPAN in the adaptation layer, and routing protocol RPL in the network layer is as follows
(1) The Conformance Test Suite of IEEE 802.15.4 Protocol in MAC Layer
IEEE 802.15.4 is a standard which specifies the physical layer and MAC layer for low-rate wireless personal area networks and is maintained by the IEEE 802.15 Working Group. The specification in MAC layer belongs to the data link layer and is one of the goals of protocol conformance testing for IPv6-based WSNs in this paper.
Based on the function requirements of the MAC section in IEEE 802.15.4, the test suite is expected to include the following: channel scanning, building networking, beacon synchronization, association and disassociation, channel access, indirect data transmission, direct data transmission, super-frame management, GTS management, CSL mechanism, RIT mechanism, subbeacon network, and security mechanisms, as shown in Figure 2.
The test suite of IEEE 802.15.4 in MAC layer.
For example, in the test cases of “association and disassociation”, the “association” function allows the device to request the association through the PAN (Personal Area Network) coordinator and join in the WPAN (Wireless Personal Area Network). The association includes four primitive interfaces: the association request, the association response, the association instruction, and the association confirmation. Two devices are used for the test of the associated function in the test suite. If the PAN coordinator wants an associated device to leave the PAN, or an associated device wants to leave the PAN, the “disassociation” function will be implemented by the upper of MLME (MAC Sublayer Management Entity). The disassociation consists of three primitive interfaces: the disassociation request, the disassociation indicates, and the disassociation confirmation. Two devices are also used for the test of the disassociation function in the test suite. The test cases are divided into two kinds of the beacon-enabled network and the nonbeacon-enabled network, which are, respectively, divided to the positive disassociation and the passive disassociation. The specific test cases include IUT (Implementation Under Test) as the device sends an association request (in the beacon-enabled network or the nonbeacon-enabled network); IUT as the coordinator receives the association request (in the beacon-enabled network or the nonbeacon-enabled network); IUT as the device takes the initiative to issue the disassociation in the beacon-enabled network; IUT as a coordinator in the beacon-enabled network, the device takes the initiative to issue the disassociation; IUT as a coordinator in the beacon-enabled network, the device is asked with the disassociation; IUT as the device in the beacon network, the coordinator asks the device with the disassociation; IUT as a coordinator in the nonbeacon-enabled network, the device is asked with the disassociation; IUT as the device in the nonbeacon-network, the coordinator asks the device with the disassociation.
(2) The Conformance Test Suite of 6LoWPAN Protocol in the Adaptation Layer
The minimum packet length IPv6 requires and supports are much greater than the maximum frame length of IEEE 802.15.4 protocol. In order to implement the transmission of IPv6 data packets over the data link layer, the construction of an IPv6 link-local address, and the autoconfiguration of the stateless address, the adaptation layer must be defined. The 6LoWPAN has defined encapsulation and header compression mechanisms that allow IPv6 packets to be sent to and received from IEEE 802.15.4 based networks.
According to the function modules of the 6LoWPAN protocol specifications, the test suite is expected to include the following: the examination of packet format, fragmentation and reorganization, IPv6 address configuration, IPv6 address resolution, packet compression and decompression, neighbor discovery, and security mechanism, as shown in Figure 3.
The test suite of 6LoWPAN in the adaptation layer.
For example, in the test cases of “adaptation layer and its frame format”, 6LoWPAN defines the package head, of which the first byte indicates the distribution type. The head expressed includes IPv6 header, IPv6 compression head, mesh head, and slice head, with enough room for the expansion in future. When multiple header types appear in the same packets, they are arranged with the order of the mesh header, broadcast header, and slice header. The testing of the packet format needs to verify whether the packet format is inline with one defined in the protocol specification. The specific test cases include encapsulating the IPv6 header format and processing; encapsulating the IPv6 compression head format and processing; encapsulating the mesh head format and processing; encapsulating the broadcast head format and processing; encapsulating the slice head format and processing; the order of the encapsulated head and processing; processing of the abnormal distribution value.
(3) The Conformance Test Suite of RPL Protocol in the Network Layer
RPL is the IPv6 routing protocols based on distance vector in connection with the characteristics of the LLN network. DAG (Directed Acyclic Graph) is constructed through nodes exchanging the distance vectors and consists of one or more goal-oriented DODAG (Destination-Oriented DAG). DODAG distinguishes between the upward routes and the downward routes based on the different routing direction to or from the root node. RPL supports three different communications means, including the mobile peer-to-peer (MP2P) communication from the network node to the central control device, the point-to-multipoint (P2MP) communication from the central control device to multiple nodes, and the point-to-point (P2P) communication between nodes, to effectively avoid the problem of routing loops.
Based on the function modules of the RPL protocol specifications, the test suite is expected to include the following: control message format, construction and repair of topology, the operation of sequence counter, uplink routing, downlink routing, loop detection and avoidance, and security testing, as shown in Figure 4.
For example, in the test cases of “uplink routing”, the root node broadcasts the DIO packet to the node around. After a node receives multiple DIO packets, it selects another node as its parent node and joins the DODAG topology; thus an upstream routing pointing to the root node is built, according to the requirement of the target function. The DODAG node can communicate with other DODAG nodes through the root node. The new node can send the DIO information request to the neighbor nodes through the DIS information and select the parent node to join in the network. The specific test cases include the basic rules of the DIO information; uplink route discovery and maintenance in the same DODAG; uplink route discovery and maintenance in the different DODAG; the DIO information trigger and transmission; DODAG selecting; the local DODAG operation; data path validation; leaf node operation; management in the node level.
The test suite of RPL in the network layer.
3.2. The Generation Methods and Test Structures of Protocol Conformance Test Suites
The development of the test suite is to program ATS described in the natural language into ETS with TTCN-3. The corresponding steps include the following. Firstly the test structure and test configuration are determined according to the established test specifications and the protocol specifications. Secondly, the test data in the test specifications are refined and described with TTCN-3. Thirdly, each step of the test cases in the natural language is mapped to the corresponding TTCN-3 statement. Finally, the test judgment is given in the TTCN-3 code, according to the judgment basis of each test case with succeeding in passing the testing. The final TTCN-3 codes are formed through the above steps. The detailed process is as follows.
Before developing the TTCN-3 code, the test structure and test configuration are determined by the test specification. The test structure and test configuration of the single test component or multiple test components is used with the characteristics of the protocols under test.
For example, the Reduced Function Device (RFD) in IEEE 802.15.4 acts as the host node in the 6LoWPAN network, which does not relay packets and interacts only with the router in its own 6LoWPAN network. When the RFD device is tested, the test structure of single test component is used for testing, shown in Figure 5(a). The test system connects with the DUT (device under test) through a main test component (MTC) and simulates the router nodes to interact with and test the device under test.
Several test structures and test configuration.
The Full Function Device (FFD) in IEEE 802.15.4 acts as a router in the 6LoWPAN network, which relays packets to perform the routing function and may interact with the host nodes or router nodes in its own 6LoWPAN network. When the FFD device is tested, the test structure of multiple test components is used for testing, shown in Figures 5(b) and 5(c), which are, respectively, the test structures of the double test components and the three test components. The test system (logically) connects with the device under test through multiple simulated nodes (test components) and simulates the neighbor nodes to interact with and test the device under test.
After fixing the test structure, the appropriate test configuration will be defined in the description of the TTCN-3 test cases. For the test structure of multiple test components, each PTC (Parallel Test Component) is created and implemented by using “create” and “start” statements, and the test ports are mapped and connected by using “map” and “connect” statements.
Then, the test data in the test specification are refined to determine the protocol packet format and content of the TTCN-3 test data. The structure type of the corresponding protocol packet is given with the definition of type in TTCN-3. The specific protocol packet data are defined with the “template” statement.
Each test step in the test specifications is mapped to the corresponding TTCN-3 statements. For example, when a test message is sent or received on the test interface, the “send” or “receive” statements can be adopted, respectively. If the test configuration of multiple test components is adopted, the function needs defining in the TTCN-3 code to realize the test behavior of PTC. If necessary, the synchronized messages between each test component also need adding.
Finally, according to the judgment of test specifications, the “setverdict” statement is adopted in TTCN-3 code to set the test decisions, including a variety of pass and fail situations.
In addition to the above manual methods for developing the test suite, the automatic generation technology may be adopted to improve the efficiency of generating ETS described with TTCN-3, on the basis of the foregoing formal methods of generating the test specifications.
At present, some companies (such as Conformiq, Elvior, and All4tec) have provided the commercial tools for automatically generating the TTCN-3 test cases based on the formal models and they have had some successful applications, such as the All4tec's MaTeLo generates TTCN-3 test cases based on the Markov chains, but the application of this model is relatively rare. The Conformiq's Conformiq Designer and the Elvior's TestCast Generator adopt more popular UML (Unified Modeling Language) state diagrams with the text programming language describing the model, and the TTCN-3 test suite automatically generated can be applied to the test execution with less modification, which have some successful applications in communications, medical equipment, and even the aerospace industry. The working principle of these autogeneration tools is basically the same and the process is as follows. Firstly, the protocol specification is modeled with the formal methods. Secondly, the model is inputted into the autogeneration tools and ATSs are automatically generated. Finally, with the required coverage conditions specified, ATSs are automatically transformed into ETS which is described with TTCN-3 in the background.
The automatic generation of test suite can effectively reduce the development time and the errors introduced by the manual programming. However, the methods of automatically generating test cases also have their limitations. Firstly, due to the abstract model, the generated test cases are difficult to run directly and need some adjustments by hand. Secondly, the parts requiring the strengthen testing are difficult to describe in the models. Finally, the generated test suite may not be ideal in aspects of naming, organization, and management.
In order to realize the optimal generation, the combination of the automatic generation and the manual programming is used, as shown in Figure 6. The first is to generate the test suite with the automatic generation tool. And then the test suite is complemented and modified with the manual programming based on the test specification. For example, the test cases, which require the strengthen testing and failed in the automatic generation, are added. Meanwhile, the existing test specification is verified by the automatically generated test suite. The test cases which are not covered in the test specification are supplemented and the irrational norms or the errors introduced artificially are corrected.
The combination of the automatic generation and the manual programming for generating TTCN-3 test cases.
In addition, because most of IPv6-based WSN protocols are in the draft stage and the content of the protocols will continue changing and form a new draft version, the automatic generation method will greatly reduce the overhead of the ETS development. When the content of the protocols varies, the formal models of protocols will only be adjusted on the basis of the changes and then inputted into the automatic generation tools to regenerate the corresponding test suite, instead of programming all the test cases by the manual method. Therefore, it is the method of combining the automatic generation and the manual programming that is more suitable for the evolving IPv6-based WSN protocols.
3.3. A Test Case Is Taken as an Example
The building process of DODAG (Destination-Oriented Directed Acyclic Graph) is taken as an example to explain how to use TTCN-3 to write the test cases. The RPL's high-level goal is to provide efficient routing paths for three traffic patterns (multipoint to point, point to multipoint, and point to point) in low-power and lossy networks. Specifically, once an RPL node obtains a proper global IPv6 address, it tries to join a DODAG by exchanging ICMPv6-based DODAG Information Solicitation (DIS) or DODAG Information Object (DIO) messages [20].
As shown in Figure 7, we assume that the network has five nodes: root, nodes A, B, and C, and E. In the building process of DODAG, the root node advertises DIO message as a parent node for other nodes in its neighborhood. If the nodes A, B, and C receive the DIO message, they will process the DIO, and then join in the DODAG and set the root node as their parent node. The nodes A, B, and C compute their own “rank” value within the DODAG from the root. It is easy to calculate
The construction process of DODAG.
The above protocol interaction is present in a graph, as shown in Figure 8(a). After the root node finishes sending the DIO messages, the upward routing of node B points to the root node; therefore the data from B are directly forwarded to the root node. After node A finishes sending the DIO messages, the upward routing of node B becomes root A; therefore the data form B are again directly forwarded to root A.
The protocol interaction between nodes.
Therefore, through the analysis of the protocol interaction, if the IUT is the node B, the part of the red box is the behavior of the test system, as shown in Figure 8(b). P_root, P_A, and P_C are the node interfaces the test system tries to simulate, and the communication between the three interfaces does not need to be reflected in the testing process. The test case is written with the TTCN-3 language as follows (Algorithm 1) (with the clock behavior and the Alt optional steps omitted).
(1) P_root.send(DIO_root); (2) P_C.send(Data); (3) P_root.receive(Data); (4) P_C.send(DIO_C); (5) P_A.send(DIO_A); (6) P_C.send(Data); (7) P_A.receive(Data){ (8) setverdict(pass); (9) }
4. Design and Implementation of Conformance Test System for IPv6-Based WSNs
When designing the protocol conformance test system for IPv6-based WSNs, a number of technical factors must be taken into account, such as the versatility, extensibility, and standardization.
The first is the versatility of the test system. IPv6-based WSN protocols under test include IEEE 802.15.4 in MAC layer, 6LoWPAN in the adaptation layer, and routing protocol RPL in the network layer. The types of the protocols are various and their content is very different, but it is inefficient and uneconomical to, respectively, develop the appropriate test system for each protocol. The conformance testing of IPv6-based WSNs needs a universal solution necessary. In addition, the test system needs to simulate and adapt different scenarios, such as different topologies and events.
The second is the extensibility of the test system. In future, the conformance test system may add new test cases and new air interfaces and implement the automated interconnect testing between multiple test systems, which requires that the conformance test system should be scalable, such as the upgraded test cases, the modular system components and the networked interconnection of the systems.
The last is the standardization of the test system. The marketing promotion of the conformance test system needs the certification license of the authoritative department; so the system itself must comply with relevant standards of conformance testing and the related equipment norms in industry.
4.1. Design of Conformance Test System for IPv6-Based Wireless Sensor Networks
Based on the above consideration, a networked protocol conformance test system for IPv6-based WSNs is designed in this paper. The system logically consists of two component units, which are the remote control unit in the user side and the test unit in the equipment side. The composition of the conformance test system and the connection with the device under test is shown in Figure 9.
The protocol conformance test system for IPv6-based WSNs.
The remote control unit is implemented on a general computer, which remotely controls the test system through the common LXI (the LAN eXtensions for Instrumentation) bus interface. The remote control unit can provide the friendly remote user interface for conformance testing, a convenient and practical test message window, the flow control window for test execution, the window for analysis of test results, smart decisions, and report formation.
The test unit is the main unit for providing the conformance test capability, which includes system control unit, system interface, and TTCN-3 execution environment. The system control unit provides the management capabilities for the component units of the test system and receives the protocol information from the LXI bus. The system interface provides users with the use of the interface window of the system, realizing configuration, management, and operation. TTCN-3 execution environment is the main functional module of performing the conformance testing, whose design refers to the framework of the TTCN-3 runtime environment to support the running of ETS. The PA (platform adapter) provides the clock and other underlying support for the TTCN-3 runtime system. The SA (SUT adapter) and the corresponding test components provide the adapter between the test system and the system under test. SA includes the physical layer interface components of 780 MHz and 2.4 GHz and other testability interface components, as well as a set of benchmark protocol stacks. TTCN-3 core runtime system can perform the calls of the benchmark protocol stacks to form the peer-level protocol testing capability.
The system control unit is the main control part of the component modules in the test system and implements the collaborative work between the components, whose main functions include receiving the user input request from the system interface, adjusting and controlling the basic status and working modes of the system, receiving the protocol information from the remote LXI bus, executing the corresponding test operation, submitting the test results to the user, completing the LXI bus synchronization to ensure the timing of the TTCN-3 operation, automatically detecting and configuring the system components, and providing the correct power supply, the clock, and resources configurations for the hardware components. In addition, the system control unit also provides the remotely upgrading capability for the system and allows the user to update the test suites to ensure the extensibility of instrument.
The system interface is the interactive window between the test system and the users. The user-entered information and the information outputted by the test system will be shown in the system interface. In the beginning of the test execution, the users can select the tested protocol, configure the test parameters, select the test execution mode and the ETS, and start the testing process by the user interface. In the testing process, the system interface can display the test log in real time. In the end of the testing process, the system interface can generate the test result and reproduce the execution process of test cases to facilitate the analysis of the test result.
TTCN-3 running environment (including the ETS of the relevant protocols) is the core part of the software in the test system, which provides the ETS and the supporting environment, including TM (test management), T3RRTS (TTCN-3 runtime system), CD (coding and decoding), PA (platforms adapter), and SA (SUT adapter).
TM conducts the comprehensive management of the test system. Most of IPv6-based WSN protocols leave a lot of options, which may or may not be implemented in an implementation. The process of conformance testing requires a combination of the specific implementation of protocols. PICS (the Protocol Implementation Conformance Statement) and PIXIT (Protocol Implementation eXtra Information for Testing) are provided by the supplier of an implementation and jointly maintained by the test administrator, which describes protocol requirements and the supplier's support for these requirements, as well as the additional information regarding parameters and values or their ranges. According to PICS and PIXIT provided by the supplier, the test administrator selects the test cases and deploys the test parameters in the system interface to perform the initialization of test system.
After the initialization of test system, TM will maintain the list of test cases selected by the user in the testing process, transfer the parameters of the external modules set by the user to the ETS, and start to run the selected test cases. In the testing process, TM will fulfill the information exchange between the system interface and the ETS. After the end of the test execution, TM is responsible for generating the test logs and displaying them in the system interface. In addition, TM has the function of operating the database which may store/read the finishing test information (such as the configuration and the test results) into/from the database.
T3RRTS provides the support for the execution of the TTCN-3 ETS, including defining and implementing the TTCN-3 test data types that the ETS needs; during the execution of ETS, providing TCI (test control interface) to complete the interaction between ETS and other modules (e.g., TM, CD, etc.); providing the TRI(test run interface) to complete the interaction between the ETS, the clock, and SA. In short, the execution of ETS must be supported by T3RRTS.
In order to realize the seamless transition of the test data between the TTCN-3 format and the actual transmitted bit strings, the CD module is designed in the test system. TTCN-3 test data can be converted into a bit string suitable for the transmission to the SUT and the data received by SA are also converted into the corresponding TTCN-3 format data with CD.
The PA module provides the ST (System Timer) module for the TTCN-3 running environment, which can provide the unified clock and the associated operations for each test component, including the starting and stopping of the clock, reading, and querying the clock state.
SA mainly provides the communication between the TTCN-3 running environment and the underlying hardware platform of the test system and can complete the sending and receiving of the related protocol test data by controlling the underlying test components. In the test system, different SA modules need realizing the different tested protocols.
In the scheme, the TI (test interface) component, which is the core of hardware modules in the test system, is connected to SA and provides the test system with the access to the various testability interface components of the DUT (device under test). TI is closely related with the interface types of typical sensor nodes. The sensor nodes generally have the air interfaces (the wireless communication interfaces). Some nodes at the edge of WSNs act as the role of routing forwarding and usually also have an Ethernet interface or serial interface based on the PPP (Point to Point Protocol). In addition, in order to initialize the testing environment and set the nodes into a known test status, the power and reset signal interfaces of nodes need to been controlled. Some typical network interfaces of nodes in IPv6-based WSNs are shown in Table 1.
The typical testability interfaces.
For the frequency bands of 780 MHz and 2.4 GHz, there are the mature and certified integrated circuits in the market. Therefore the test system can be designed based on the above-integrated circuits. In order to support the protocols in MAC layer, the collisions of multiple RF (Radio Frequency) packets and power superposition need simulating. So the multichannel RF output needs supporting in the same TI. The RF test interface component is designed as shown in Figure 10. The designed scheme can support full-duplex testing of RF receiving and sending. At the same time, the RF can simulate to produce the superimposed waveform of two RF signals to ensure the testing capability in MAC layer. The sending time in the air of IEEE 802.15.4 protocol packets is about hundreds of microseconds. In order to simulate a variety of situations, the timing control logic module in the scheme will be generated by the FPGA timing to ensure providing microsecond-level synchronization timing control for different RF modules. Two TI components will be, respectively, implemented for 780 MHz and 2.4 GHz bands. With multiple RF test interface components, the test system can realize different wireless environment.
RF test interface component for 780 MHz and 2.4 GHz.
Serial test interface and Ethernet test interface are the more mature technology. However, in the conformance testing, some test cases need to precisely understand the delay between the events in the protocol interaction, which requires implementing the precise timing control of the protocol packets, sending a packet at the particular time, and obtaining the accurate timestamp of the received packet. Therefore, the timing control logic needs designing with FPGA to realize the precise timing control and the timing analysis for the serial transceiver control and Ethernet transceiver control. The serial test interface and Ethernet test interface component are designed as shown in Figure 11.
Wired test interface components.
The analog switch and the sequential logic are, respectively, used for the power interface and the resetting interface to control the power supply and reset the node status. The power interface and the resetting interface are designed as shown in Figure 12.
The power interface and the resetting interface.
Based on the RF test interface supporting 780 MHz and 2.4 GHz bands in physical layer, the test system provides a set of benchmark protocol stacks for conformance testing, which include IEEE 802.15.4 in MAC layer, 6LoWPAN in the adaptation layer, and routing protocol RPL in the network layer. Different levels of the protocol stacks can be accessed by the SA, so as to enable data communication between the peer levels, to facilitate carrying out the conformance testing layer by layer, and to simplify the complexity of programming with TTCN-3.
4.2. Conformance Testing Methods for IPv6-Based Wireless Sensor Networks
Combined with the specific IPv6-based WSN protocols, different test methods are used for different protocol levels and different roles of nodes; so multiple test methods are designed in the test system in this paper. Taking 6LoWPAN as an example, the remote test method of the single test interface and the TTM (Transverse Test Method) of multiports are, respectively, used for testing the nodes within the network and the edge nodes (namely, the boundary router node in RPL protocol).
For the internal nodes of WSNs, the air interface usually is used for communicating with other nodes. When testing such nodes, the test structure of the remote test method and the single test node is used, as shown in Figure 13. The test system connects with DUT through the air test interface components.
The remote test method with single test interface.
If the edge nodes undertake the Internetwork forwarding of packets, they usually have the wired interfaces in addition to the air interfaces to realize data forwarding between the air interfaces and the wired interfaces. When testing such nodes, the test structure of TTM and multiple test nodes is used, as shown in Figure 14. TI components (air test interface and wired test interface) in the test system are connected with the DUT. With packets flowing through the DUT, the protocol conformance testing of the DUT is executed.
Transverse test method with multiple test nodes.
4.3. Implementation of Conformance Test System for IPv6-Based Wireless Sensor Networks
In order to verify and evaluate the feasibility of the proposed design of conformance test system, we have built an initial prototype of conformance test system for IPv6-based WSNs on the basis of HINT test platform [21]. HINT is a high-accuracy nonintrusive networked testing platform for WSNs, which was designed and developed by our own laboratory. With the help of HINT, users can gather information of internal signals on the sensor nodes, measure the energy consumption of sensor nodes, parse the interconnect signal for the radio packets, obtain precise timestamps of events for fine-grained phases, evaluate the network performance parameters, program and debug the sensor nodes remotely, and store the runtime data to trace files. Most of these features are disturb free and transparent to the applications.
Based on the design of the conformance test system, the main test unit of the conformance test system we have implemented is shown in Figure 15. In the prototype of conformance test system, the tested nodes adopt the SensHoc nodes, which are exploited by our own laboratory. SensHoc node is compatible to TelosB produced by Crossbow Technology. The actual picture and block diagram of SensHoc are shown in Figure 16. The micro-controller of SensHoc is TI MSP430, and the RF transceiver is CC2420. SensHoc node supports the TinyOS operating system, which is the open source operating system developed by UC Berkeley and designed specifically for wireless sensor networks. We use BLIP and TinyRPL in TinyOS 2.1, the TinyOS implementation of 6LoWPAN, and RPL protocols, which are also tested protocol implementation.
The main test unit of the conformance test system.
SensHoc sensor node.
In order for the preparation and implementation of TTCN-3 test cases, the TTworkbench [22] developed by Testing Technologies GmbH is used and its operation interface is shown in Figure 17. The JAVA virtual machine is adopted as a TTCN-3 execution environment to execute the ETS. With the support of the JAVA virtual machine, the executable TTCN-3 test cases can run on different hardware and software platforms.
The operation interface of TTworkbench.
In the software design of the prototype system, the one-stop processing mode with data acquisition, analysis, and result processing is adopted to realize test cases as the center of the software architecture. In the management of test case information, we have designed information structure, including the basic information of the test cases (e.g., number and name), the test information (e.g., test conditions, test steps), and the configuration information (e.g., equipment configuration information). In the management of test equipment and the conjunction of test cases, we have designed the information constitution of test equipments, the conjunction modes, and management behavior patterns between test cases and test equipment. In the management of test data, the usage patterns, the flow, and the format conversion requirements of test data in the different test cases are designed, based on the collection, processing, and analysis of test data. In the processing of the test analysis results, the kernel module for matching and analysis is designed; the test data are analyzed by the automatic means of filtering, comparing, matching, and finding to obtain the test results. The test results and test logs are generated and outputted based on the test analysis results. The correct judgment is not only given when the test cases succeed in passing the test, but also the judgment of failure is given against the wrong response.
At present, the prototype of conformance test system has implemented the decomposition and reconstruction of the 6LoWPAN protocol packets, the conformance testing for the 6LoWPAN protocol header compression function, and so on, based on the nonintrusive signal capturing and automatic matching and analyzing technology. The actual operation screenshot of prototype system in conformance testing for the 6LoWPAN protocol is shown in Figure 18. At a later time, the prototype of conformance test system will be upgraded and expanded to the full realization of the protocol conformance testing for IPv6-based Wireless Sensor Networks.
The actual operation screenshot of test system.
4.4. Characteristics of Conformance Test System
Based on IPv6-based WSN protocol specifications, the conformance test system for IPv6-based WSN protocols proposed in this paper focuses on the versatility, extensibility, and standardization of the system. The test suites are designed according to the specifications and the standardized development program is adopted to ensure the extensibility of the test system. Thus the normative, practical, open, and configurable test system is established. The conformance test system for IPv6-based WSN protocols in this paper has the following characteristics.
(1) Opening and Flexible Extensibility
TTCN-3 is used in this paper for the transform from ATS to ETS. The scheme not only efficiently supports the development of ETS, but also facilitates the user to add dynamically the test suite. TTCN-3 also does not make the test system depend on the specific protocol test suite; thus it provides the test system with the good extensibility and adaptability.
In addition, in the hardware design, the component design and the slot structure are used for providing the unified extensible hardware architecture to support the additional test interfaces in future.
(2) Rich Configurability
Based on the universal conformance testing scheme with TTCN-3, the test system can flexibly configure different test suites and patch up the new test cases. Following the LXI design, the test system can realize the seamless interconnection with different system and upper software. With the TI components, the test system can support multiple testability interfaces and test configuration. The testing content and testing reports can be flexibly set by TM. The test system has multiplex test interface components and can realize different wireless environment and meet different test requirements. The above means provide the test system with rich configurability, which makes the test system adjust to the supplier's different support for protocol requirements in the specific implementation, combined with PICS and PIXIT.
(3) High Standardization
The scheme of the test system for IPv6-based WSN protocols in this paper is in strict accordance with ISO/IEC 9646. In addition, in the technology choices, the test system conforms with the related instrument design standards and the protocol test specifications in order to ensure that standardization and comparability of the test system.
(4) Engineering Practicality
In the hardware design, the test system designed in this paper emphasizes the practicality of system and the combination of theoretical study and practical application, stipulating the engineering design, such as mechanicalness, electricity, ventilation, power supply, and electromagnetic compatibility. In the software design, the convenient and practical test message windows provide the users with the accurate record of the message flow and the intelligent judgment of the test results. A variety of system configuration and the easy-to-read judgment solutions are offered to meet the testing requirements of different users. The above means provide the test system with engineering practicality.
5. Conclusion
For the large-scale application of WSNs, the interconnection between WSNs and the existing Internet based on IP protocols must be considered. The WSN protocols based on IPv6, which integrate IPv6 protocol into WSNs, are the major trends of the future applications. With the development of WSN devices and their protocol stacks, as well as the network integration of WSNs and Internet, it must be considered whether the protocol implementations in different sensor network devices are or not consistent to the referenced standards, which is the protocol conformance testing. As an important aspect of the protocol testing, the conformance testing is mainly used for testing and verifying the conformity between the protocol implementations and the standards. At present, there is a serious shortage of research on protocol conformance testing and the equipment development for IPv6-based WSNs. In this paper, faced with difficulties and challenges in the protocol conformance testing for IPv6-based WSNs, the conformance testing techniques and methods for IPv6-based WSN protocols (including IEEE 802.15.4 in MAC layer, 6LoWPAN in the adaptation layer, and routing protocol RPL in the network layer) are studied, the protocol conformance test suites are stipulated and developed, and the open conformance test system is designed and implemented towards the standardization of IPv6-based WSNs. At present, the prototype system has been developed and the development of the complete test system is in progress. We believe that the related outcomes can fully validate the IPv6-based WSN nodes and promote the process of large-scale commercialization of WSNs.
Footnotes
Acknowledgments
This work is supported in part by the National Natural Science Foundation of China (Grant no. 60903211), the State Key Development Program for Basic Research of China (Grant no. 2011CB302902), and the National Science and Technology Major Project (Grant no. 2011ZX03005-002).