This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE Globecom 2010 proceedings.
NetViewer: A Universal Visualization Tool for Wireless Sensor Networks Longhui Ma1 , Lei Wang1 , Lei Shu2 , Jing Zhao1 , Suran Li1 , Zhuxiu Yuan1 , Ning Ding1 1
School of Software, Dalian University of Technology, Dalian, China, 116022 Nishio Lab., Department of Multimedia Engineering, Osaka University, Japan 1
[email protected], 1
[email protected], 2
[email protected], 1
[email protected], 1
[email protected] 2
Abstract—Visualization tools make it easier for users to observe the status of the wireless sensor networks (WSNs). So far, developers of WSNs have created various visualization tools under certain project/research backgrounds. These tools, however, are limited in certain application scenarios, since the underlying packet formats are hard coded into the programs. For this purpose, we present NetViewer, a universal visualization tool for all the applications, and we provide many useful data services to fulfill different needs of various fields, such as Replay lets researchers and developers debug their WSNs easily, Server gives user a method to disseminate data through Internet. To achieve better compatibility, NetViewer allows the user to set the application-related packet format through an XML file. Based on the packet format defined, users can also extract the desired fields from the packets. Furthermore, NetViewer provides a rich set of interfaces as well as a well defined API for future improvements. Index Terms—Visualization; Wireless Sensor Networks;
I. I NTRODUCTION Visualization tools [1] [2] [3], which gather information from sensor nodes and present them in graphs or other forms on screen, are used for monitoring. WSNs are always application-specific and heavily dependent on environment [4], which require different packet formats to be designed for different application scenarios [5]. Most existing visualization tools today are developed under specialized applications, they cannot verify with the change of application scenarios. Take this drawback into account, designing and implementing a universal tool for visualizing WSNs is essentially necessary. Moreover, this tool is motivated by the following concrete scenarios: 1) In academic researches, researchers often use visualization tools help them evaluate the algorithm design of WSNs. 2) During the development of WSNs, such tools are used for testing and debugging of WSNs. 3) In the actual applications, they are needed for monitoring the environment parameters and providing friendly GUI. We generalize the needs of analyzing packets by adopting semantic technologies [6] [7], which means that we define the needs of analyzing packets in an XML file, then let our visualization tool translate packets according to the XML file. In this way, the development of WSNs and visualization tool could be separated, which makes the universal visualization possible. Additionally, this tool should provide easy ways for users to view packets. Based on the idea, we implemented NetViewer, a universal visualization tool for WSNs, which can
be used for different application scenarios. No matter what the node programs are, which protocols the sink node uses to communicate with the host, NetViewer can be used for the visualization, such as EtheReal (A network packet sniffing tool) [8] and WildPackets [9]. II. R ELATED W ORK Till now, there have been many visualization tools for WSNs, here we present several of them: Surge Network Viewer [10] is a java application that comes standard in the TinyOS tools distribution. It visualizes topology and network statistics, meanwhile it provides graphical tool for viewing logged data. Yield, predicted yield and link quality of each node compose the statistics. The Surge Network Viewer is limited to these features mentioned above. It is designed to support only Crossbow sensor nodes, thus it is not extensible, and custom-made visualizations are not feasible too. TinyViz [11] visualization tool is part of TOSSIM package of TinyOS. It not only visualizes sensor readings, LED states and radio links available, but also allows direct interaction with running TOSSIM simulations. However, these interactions are often specified, laborious and difficult to reproduce. Octopus [12], a modular visualization and control tool for sensor networks, developed by the PRISM group, provides many useful functions, e.g., viewing the topology and controlling the behavior of WSNs. If you want to use these functions of Octopus, you either should download the program provided by Octopus to your own nodes, or develop your node program following the packet format and the criteria established by Octopus. The limitation is obvious, once you want to test your own node program, Octopus cannot help you any more. NetTopo [13] is developed as an integrated framework for providing both simulation and visualization functions of WSNs. It enables interactive communication between simulated WSNs and visualized test beds. However, it pays much more attention on simulation than visualizing. Thus the visualizing functions in the NetTopo are limited for real test beds. III. D ESIGN OF N ET V IEWER A. Architecture of NetViewer NetViewer is designed and divided into five layers (Fig.1) and each is highly independent, and can achieve certain
978-1-4244-5638-3/10/$26.00 ©2010 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE Globecom 2010 proceedings.
phase for visualization [14]. The architecture allows removing/adding component without further influence on other layers. In the following part, we will explain the responsibility of each layer and the components that we have implemented in each layer.
Fig. 1.
The first three components provide ways to display data continuously in various forms while the last component allows user to examine each packet by displaying the packet in a stepover form.
Architecture of NetViewer
1) Packet Access Layer: This layer is mainly responsible for sending/receiving packets. Currently, we have developed three approaches for communication: through a sink node that is connected to a host, through the Internet and through a log file recorded by NetViewer. The three approaches correspond with three components that lie within this layer: the serial communication component, the Internet service component and the log file analyze component. 2) Protocol Parser Layer: Protocols are responsible for parsing the valid packets received and discarding the bad packets. Here we implement the simple mote-PC protocol of TinyOS, and provide simple interface for developers. Users can realize their own protocols following these interfaces. 3) Data Analyzer and Logger Layer: As the name indicates, this layer is responsible for properly translating packets received from the packets access layer into meaningful information following the packet format. This layer also undertakes the task of setting packet formats. Logger layer can record the packets received and their arriving time to the file system. Data analyzer layer is composed of two modules: Information Translator and Packet Format Setter. Packet Format Setter first defines the packet in an XML file and Packet Parser translates raw data accordingly. 4) Node Abstraction Layer: In this layer, the information translated by Data Analyzer Layer will be classified according to node. This layer abstracts virtual nodes by using the information and their meanings, these meanings act as the property of node while the information are the property value. Then these virtual nodes as a whole are abstracted as virtual node set. In this way, these nodes can be got easily as a value of node set, and the information can be easily accessed by the applications as node property. 5) Application Layer: The application layer provides an interface for users to interact with the data collected. With the function currently implemented at lower layer, we are able to provide many data visualizing services. Currently, we have implemented four components for this layer: coordinate graph component, data table component, topology display component and replay component.
Fig. 2.
Component Interaction of NetViewer
B. Components interaction We divide the procedure of visualization into several steps, as Fig. 2 shows, each step can finish some special function. In step 1, Packet Format Setter helps users produce an XML file (such as Fig.3) to indicate their packet formats. This XML file will later be used by Information Translator for translating information. Step 2 is finished by Packets Receiver, it gets packets from specified source provider, Sink node (a node receives packets from WSN, and send them to the host), Internet or File (data log file, used for replay), and then deliver these packets to Protocol Parser. Protocol Parser, in step 3, will follow the communication protocol to parse packets, it discards the bad packets and lefts the valid packets to Information Translator in step 4, and at the same time, these valid packets are recorded in data log file by Data Logger. Then following the packet format XML file, Information Translator translates the valid packets into meaningful information. After translation, such information are collected and classified according to node and abstracted as node property values by Node Abstracter, and finally they are dispatched to applications that need them. If user starts a server for data dissemination through Internet, the Server will directly get packets from Protocol Parser and disseminate them through Internet. IV. S CEMANTICS E NABLED PACKET F ORMAT A BSTRACTION A. Packet Analyzing WSNs can be used for measurement of volcanic activities, monitoring the status of forests, testing the environment of dams and so on. In these scenarios, the information provided by WSN are not the same, and their packets are different. Here, we abstract the common features for translating packets: 1) Endianess: Different endianess lead to different interpretation. Such as (01 00) and (00 01), they are not the same, and
978-1-4244-5638-3/10/$26.00 ©2010 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE Globecom 2010 proceedings.
stand for different value. 2) Contents: A packet can contain many information, the number and position of them should be known for getting their location. 3) Length: The lengths of information can be various, and they are necessary for intercepting information data. 4) Type: We should know the type user want to translate to, for example, temperature can be translated to a float number or an integer number, this depends on the users’ definition. 5) Meaning: Only obtaining the value of information is not enough, we should give it a name (meaning) which is used for distinguishing it from other information.
Fig. 3.
An example packet format XML file
According to above reason, we abstracted an XML style to describe packet formats, Fig.3 is an example. As clearly shown, the fields “information meaning” (e.g., AMPacket, DestinationAddress), “type” (e.g., Unsigned-Int) and “length” (e.g., 8 bits,16 bits) are all included in a tag. We can follow the packet format setting (as Fig.3) to translate the packets received. For instance, if we get the following packet (in Hex):
2) Topology Monitor: Topology Monitor serves two purposes: showing which nodes are active and demonstrating the topology of the network. The second function needs the support of the node program to include the ParentID of a node in the transferred packet. 3) On-line data dissemination: When building this tool, we want to create a full functioned one which can suit general needs of WSN applications. Data share is a crucial one [15]. The data collected by the base station should not only be available at one host. NetViewer has two modes: server mode and client mode. In server mode, NetViewer directly collects data from specified source provider and can be accessed by other hosts in client mode. In client mode, NetViewer receives data from the server. 4) Replay: The speed of receiving and sending packets are often fast, users cannot easily found the detail variations inside the network. However, researchers and designers often want to observe the behavior of nodes, and verify algorithms programmed to the real nodes. In this situation, Replay module can help them to review historical network activities step by step off-line. When the packets arrive at the host, NetViewer not only displays them on the screen but also keeps a record of them. Fig.4 shows what is recorded in the data log file. Packet arriving time, it means the packet received time starting from the first packet. Replay module uses the system timer to simulate this time value and calculates the time interval between two packets, then it could be able to replay the dynamic procedure of historical network activities almost the same as actual.
00 ff ff 00 00 0b 00 93 00 06 00 00 02 68 16 and want to know the “Counter” information as shown in Fig.3, according to the location and length we can intercept data: 02
68
then following “Big-Endian” and “Unsigned-Int” to translate it, we get 580 (02 68) in decimal. Similarly, we know the temperature is 22 and nodeID is 6 and so on. B. Data Services NetViewer defines four kinds of data services: data display, topology monitor, on-line data dissemination and replay. In the following section, we will explain these services in details. 1) Data Display: As a basic function for all data visualization tools, the data should finally be displayed in a way that is easy for human to read. Currently we have defined two forms of data presentation: data table and coordinate graph. Data table is often used for users wants to see the translated value of their packets, and coordinate graph is used under the condition that users want to view the variation of specified values against time.
Fig. 4.
Information recorded in a Log
V. H IGH L EVEL C OMPARISON WITH R ELATED W ORK NetViewer vs Octopus: We compared the topology module with Octopus, and the node program we use is designed for Octopus. Both of them can show us the topology of WSN, and Octopus can provide user with more information, which are realized in its own node program. However, the limitation is obvious, Octopus cannot show the topology if users use node programs developed by themselves. On the other hand, NetViewer can draw the topology of users own WSN. Besides, Octopus depends on SerialForwarder, which means that if users want to use Octopus, they should start SerialForwarder first. But NetViewer is an independent tool, it could be used separately. NetViewer vs Oscilloscope: Here we compared Oscilloscope (a TinyOS tool) with NetViewer. Both of them can achieve the goal of drawing coordinate graph of information against time. Fig.5 (a) is Oscilloscope and Fig.5 (b) is Coordinate Graph module of NetViewer. As the token in Fig.5 (b) shows, NetViewer provides more flexibility than Oscilloscope: 1) It lets user choose a single
978-1-4244-5638-3/10/$26.00 ©2010 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE Globecom 2010 proceedings.
(a) Serialforwarder (a) The user graphical user interface of Oscilloscope
(b) Server of NetViewer (b) The graphical user interface of Coordinate Graph module Fig. 5.
Fig. 6.
Comparison Between Serialforwarder and Server module
Comparison Between Oscilloscope and Coordinate module
node to display. 2) Display mode presents two ways for display, single line or multi-lines. 3) Any information could be selected to display. 4) Current information value can be shown (on the upper right). NetViewer vs Serialforwarder: Fig.6 shows Serialforwarder (a TinyOS tool) and Server module of NetViewer. Fig.6 (a) is the Serialforwarder while Fig.6 (b) is NetViewer. Both Serialforwarder and NetViewer have the function of creating a data server at the specified port for data disseminating. But they have many differences. Serialforwarder is mainly used for serial communication and data dissemination, and it can give some information about connection, such as the number of clients, the packets read from serial port and starting information. However, as Serialforwarder does not provide visualization tools for WSNs, users have to develop such tools (such as Octopus) by themselves. And in this way, developers have to follow the protocol of Serialforwarder. Server of NetViewer, as shown in Fig.6 (b), gives users more information about clients (on the left of Fig.6 (b)), such as the IP addresses and connection status of them, and it provides users with more flexibility to control these connections. VI. C ASE S TUDIES FOR T EST A. Visualization of Two Specified Applications The compatibility of NetViewer allows it to be used in different application scenarios. Here we test it on two different application scenarios.
The first one (Test1) is used for monitoring temperature. The packet format for this application (Fig.7 (a)) is simple, which just contains packet head, temperature and two other information like moteID and couter (The number of packets sent to the host). The second test (Test2) that we take
(a) Main Part Packet Format of Test1
(b) Main Part Packet Format of Test2 Fig. 7.
Packet Formats of two Test Cases
is Octopus node program, which is developed for its own visualization. It provides more information and needs a more complex packet format, as shown in Fig.7 (b), to carry out more information. As shown in Fig.9 (a), NetViewer translates the packets received from Test1 following the packet formats of Fig.7 (a), and provides us the information table. In Fig.9 (b), packets sent by Octopus, which have different packet formats, are also translated into meaningful information by NetViewer. From the two tests, we can see that NetViewer can be used for different applications and different packet formats.
978-1-4244-5638-3/10/$26.00 ©2010 IEEE
This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE Globecom 2010 proceedings.
Fig. 8.
Replay of network activities
research in this paper was partially supported by Grant-inAid for Scientific Research (S)(21220002) of the Ministry of Education, Culture, Sports, Science and Technology, Japan.
(a) Received data of Test1
R EFERENCES (b) Received data of Test2 Fig. 9.
Data Received by NetViewer of the Two Cases
B. Test of Replay Here we use Replay module to replay the historical network activities, the packets used are from a historical data log file. In order to use it, first we should specify the data log file, as the “Historical data” indicates in the Replay window of Fig.8, and we should set the packet format file for analyzing the packets, as “Packet Format”. Then we load these two settings. After that, we can click “Run” button to replay, and click “Stop” button to stop. “Forward” button let user observe the network activities at the speed of one step per packet, and “Backward” button let user step backward to the previous packet. After started, packets are then dispatched to other modules as Coordinate graph, Topology and so on. These packets are treated as real packets. Replay module uses a timer to simulate the time of interval between the packets arriving. VII. C ONCLUSION In this paper, we present NetViewer, a java based visualization tool for WSNs. It can perform all the necessary procedure of visualization [14], namely, get packets, store packets, transform them into information and display the information. Furthermore, the friendly GUI of NetViewer makes it easy to use and the modular components enable it easy to extend for specific applications. VIII. ACKNOWLEDGMENT The authors would like to thank colleagues in WiLNA laboratory for their support and helpful suggestions. Lei Shu’s
[1] C. Buschmann, D. Pfisterer, S. Fischer, S. P. Fekete, and A. Kr¨oller, “SpyGlass: A wireless sensor network visualizer,” SIGBED Review, pp. 1–6, 2005, special Issue on the Best of Sensys 2004 Work-in-Progress. [2] J. Antonio, Castillo, A. L. T. O. Manuel, Ortiz, Vicente, and L. OrozcoBarbosa, “Wiseobserver: a real experience with wireless sensor networks,” in International Workshop on Modeling Analysis and Simulation of Wireless and Mobile Systems. ACM, 2008, pp. 23–26. [3] M. Turon, “Mote-view: A sensor network monitoring and management tool,” in The Second IEEE Workshop on Embedded Networked Sensors, pp. 11–17. [4] Y. Zhao, “Measurement and monitoring in wireless sensor networks,” Ph.D. dissertation, Los Angeles, CA, USA, 2004, adviser-Govindan, Ramesh. [5] L. Shu, X. Hui, X. Wu, L. Zhang, J. Cho, and L. Sungyoung, “Vip bridge: Integrating several sensor networks into one virtual sensor network,” in Internet Surveillance and Protection, 2006. ICISP ’06., 2006. [6] C. R. Amit P. Sheth, “Semantic (web) technology in action: Ontology driven information systems for search, integration and analysis,” in IEEE Data Engineeting Bulletin. IEEE Data Engineering, 2003, pp. 40–48. [7] K. Aberer, M. Hauswirth, and A. Salehi, “Infrastructure for data processing in large-scale interconnected sensor networks,” in MDM 2007: the 8th International Conference on Mobile Data Management, Mannheim, Germany, 2007. [8] “Ethereal.” [Online]. Available: http://www.ethereal.com/ [9] “Wildpackets.” [Online]. Available: http://www.wildpackets.com/ [10] C. Company, “Surge network viewer,” 2009. [Online]. Available: http://www.cmt-gmbh.de/surge network viewer.htm [11] P. Levis, N. Lee, M. Welsh, and D. Culler, “Tossim: accurate and scalable simulation of entire tinyos applications,” in SenSys ’03: Proceedings of the 1st international conference on Embedded networked sensor systems. New York, NY, USA: ACM, 2003, pp. 126–137. [12] A. Barbirato, S. Boivineau, M. Dragone, R. Jurdak, and A. Ruzzelli, “Octopus: A dashboard for sensor networks visual control,” 2009. [13] S. Lei, W. Chun, Z. Yan, C. Jiming, W. Lei, and M. Hauswirth, “Nettopo: beyond simulator and visualizer for wireless sensor networks,” in ACM SIGBED Review, 2008. [14] P. Oldengarm and A. v. Halteren, “A multiview visualization architecture for open distributed systems,” in COMPSAC ’98: Proceedings of the 22nd International Computer Software and Applications Conference. Washington, DC, USA: IEEE Computer Society, 1998, pp. 294–301. [15] S. Lei, M. Hauswirth, C. Long, M. Jian, Reynolds.V, and Z. Lin, “Sharing worldwide sensor network,” in Proceedings of the 2008 International Symposium on Applications and the Internet - Volume 00, 2008.
978-1-4244-5638-3/10/$26.00 ©2010 IEEE
