Flexible Offline-Visualization for Mobile Wireless Networks

Johannes Lessmann, Tales HeimfarthUniversity of Paderborn

Faculty of Computer Science and MathematicsPaderborn, Germany

{lessmann, tales}@upb.de

Abstract

For the evaluation of wireless network protocols, simu-lation has established itself as a good compromise betweencost and complexity, on the one hand, and accuracy of re-sults, on the other hand. In order to assess and debug thesimulated protocols, visualization both in the form of tex-tual console messages and graphical representations canbe of great help. In this paper, we present a network visu-alizer which was written for the wireless network simulatorShoX. Aside from nodes, links, movements and data pack-ets, our visualizer allows to graphically display arbitrarynode and link states in an intuitive and flexible way. As op-posed to other visualization tools, it provides the possibilityto change the way in which such inner states are displayedwithout running the simulation again. This can significantlyimprove the designer’s productivity especially in complexnetwork scenarios. Further, our visualizer allows to displaytextual debug messages together with the graphical anima-tion in a synchronized form, thus combining the strengths oftextual and graphical informations.

1. Introduction

Wireless networks are composed of nodes which com-municate using wireless links. Typically, they work onachieving a common goal like environment monitoring,communication, and so on. It is in the nature of such net-works that communication between the nodes is unstablesince the quality of the wireless links is fluctuating heav-ily. While this is also the case when nodes are stationary,things get even more unpredictable when nodes move dy-namically. Further, since wireless nodes are often small andthus very resource-constrained, it is also generally not feasi-ble to implement algorithms with a large processing poweror memory footprint. All this makes designing protocolsfor wireless networks a challenging task. Combined withthe fact that such networks are often deployed for critical

missions like forest fire detection, it is inevitable to thor-oughly test protocols to be able to assess their performancein the anticipated application scenario.

In order to do so, there are two possible options (asidefrom purely theoretical observations). First, the devel-oped concepts can be implemented and deployed on actualhardware (testbed implementation). While testbeds mightyield the most accurate results, there are several drawbacks:hardware costs, difficulty to test a large number of phys-ical nodes with realistic node movements, etc. Hence,testbed implementations will generally be an option onlyfor smaller number of nodes and during the later stages ofthe implementation phase when significant changes in thecode base are not to be expected.

A second option to test network protocols is simulation.Here, the physical world is modeled in a wireless networksimulation software. This avoids the issues with testbed im-plementations outlined above. On the other hand, modelscan capture reality only to a limited extent, which impliesthat simulation results will generally not be as accurate asreal implementations. Still, simulations are the option ofchoice in many situations where limited accuracy can betolerated.

In order to assess and debug the simulated protocols, itis in most cases very helpful to be able to see what is goingon in the network during the simulated time. For that, visu-alization both in the form of textual console messages andgraphical animations each have their strengths and weak-nesses. Textual messages can easily convey a variety ofdetailed information about states and values of the simu-lated variables and objects. With text, this can be done verycompactly. On the other hand, animations allow a morehigh-level overview of the actions which take place in thenetwork as a whole. This includes node movements, avail-able links, transmitted packets, and so on.

In this paper, we present a visualizer which combinesthe strengths of textual and graphical representations. Thegraphical animations are displayed together with the cor-responding textual messages in a synchronized form. Our

Tenth International Conference on Computer Modeling and Simulation

0-7695-3114-8/08 $25.00 © 2008 IEEEDOI

404

Tenth International Conference on Computer Modeling and Simulation

0-7695-3114-8/08 $25.00 © 2008 IEEEDOI 10.1109/UKSIM.2008.33

404

Tenth International Conference on Computer Modeling and Simulation

978-0-7695-3114-4/08 $25.00 © 2008 IEEEDOI 10.1109/UKSIM.2008.33

404

visualizer is written for ShoX [1], a simulator particularlytargeted at wireless networks. It performs offline visualiza-tion based on a log file which was produced by ShoX duringthe actual simulation run. As opposed to other network vi-sualization tools, our visualizer allows to change the waycertain node or link states are displayed graphically withouthaving to run the simulation again. This can significantlyimprove the designer’s productivity especially in complexnetwork scenarios.

The remainder of this paper is organized as follows. InSection 2, we present some background on network visual-ization techniques and discuss some representatives of dif-ferent types of visualizers and their principal shortcomings.This paves the way for Section 3, where we introduce andexplain our proposed visualization tool in detail. Finally,we conclude with Section 4.

2 Background and Related Work

Network event visualization can be categorized into of-fline and online visualization (cf. Figure 1). Online vi-sualization means that the events are displayed while thesimulation is running. With offline visualization, the eventsare recorded in a file and displayed only after the simula-tion is finished. Both have their advantages. Online visu-alization allows to see the ongoing network behavior rightaway. In case some undesired state occurs, the simulationcan be terminated by the user directly. This can save pre-cious time, since simulations are often complex and lengthy.On the other hand, offline visualization allows to “rewind”to some previous point of time. That way, specific eventswhich caught the designer’s eye but were too short to begrasped fully can be conveniently replayed as often as de-sired. With online visualization, one would have to redo thewhole simulation again and again. Even when the simula-tion tool is capable of reproducing exactly the same eventsequence (by reproducing the same number sequence in itspseudo-random number generator, for example), this takeslots of time.

Simulation Run Visualization

rewind or repeat visualization

Simulation Run Log File

Visualization

rewind or repeat visualization

Figure 1. (a) Online visualization. (b) Offlinevisualization.

OMNeT++ [10] is an example of a simulation tool withonline visualization. As can be seen in Figure 2, there is nobutton for rewinding or stepping back. On the other hand,

OMNeT++ allows to inspect the variables and states of allnetwork objects in a very detailed manner. The values caneven be changed at runtime to evaluate the impact of certainproperties on the course of the simulation.

Figure 2. OMNeT++ during a simulation run(source: [10]).

OMNeT++ also allows to define the way in which nodeor link states are graphically represented. It is possibleto adjust the color, node border thickness and color, nodeshape (rectangle or ellipse), size, label, and thickness. Thisis done by specifying a display string in the configurationfile or at runtime. A typical display string for a node mightlook as follows:

"p=100,60;b=50,30,rect;t=’active’"

This will draw the node as a rectangle of width 50 andheight 30 pixels at position (100, 60) together with a la-bel which says “active”. As can be seen from this smallexample, display commands in OMNeT++ are first of allcryptical to construct. Further, the designer must directlyspecify all graphical details. When he wants to change theappearance of network elements (because he wants to focuson different aspects, for example), he must change the ac-tual code in his configuration files and implemented classes.After that, he must run the whole simulation again. This isa very cumbersome process. However, since OMNeT++makes use of online visualization, there is no way to avoidthis problem.

As opposed to OMNeT++, ns-2’s network visualizationtool nam (which stands for network animator) is an offlinevisualizer. This implies that the simulation produces tracefiles which are visualized only after the simulation is fin-ished. In this respect, it is comparable to ShoX which alsoproduces log files. Figure 3 shows nam in action. As canbe clearly seen, there are buttons for backward animation.Using the time slider at the bottom, it is possible to select a

405405405

specific point of time directly. Using the step slider at thetop right corner, one can also change the speed of the anima-tion process. This is another feature which is not possibleusing online visualization.

Figure 3. nam during a simulation run(adapted from [7]).

Figure 3 also shows a small network topology consist-ing of four nodes. The thick colored arrows along the linksbetween the nodes represent packets which are in transmis-sion. The arrows indicate the direction of the packets. Itcan further be seen that node 2 has a considerable numberof packets in its queue (the stack of small squares). Whenthere is an overflow, packets are dropped which is visual-ized by rotating packets dropping out of the animation can-vas. In nam, nodes can have three possible shapes (circles,rectangles and hexagons). However, these have to be de-fined before the simulation starts and cannot be changed atruntime. At runtime, only the node color can be changed.Additionally, nodes may have arbitrary labels. Similarly,links can change their color dynamically and can have la-bels, as well. Hence, the set of graphical properties whichcan be manipulated by the user are rather limited comparedto OMNeT++. Further, only colors may change at runtimewhich severely restricts visualization of varying states.

GloMoSim [3] is a simulator based on the C-library par-sec [4] which allows both online and offline visualizationusing its Java based visualization tool called VT. Hence, itcombines the advantages of both categories. However, itsvisualization capabilities are very limited. It can presentlyonly change colors of network objects. As with OMNeT++and ns-2, the corresponding commands must be put in the Ccode. Aside from being a hybrid visualizer, GloMoSim VTdoes not offer any incentive compared to the capabilities ofOMNeT++ or nam.

Of course, there are many more simulation platforms

than the ones mentioned in this section. Excellentoverviews can be found in [8, 6, 9]. However, OMNeT++and ns-2 were taken as examples for the general categoriesof online and offline visualization. Regarding their featureset, they represent fairly advanced prototypes of their re-spective categories. We chose these two particular simula-tors because they are well-known in the research commu-nity and also freely available to experiment with. In thefollowing, we present our visualization tool and explain itsimprovements over the concepts presented here.

3 Flexible Offline-Visualization

Like nam, our visualization requires the actual simula-tion data to be recorded in a log file (or trace file, in ns-2terminology). The format of ns-2’s trace files is comparableto that of ShoX. It captures movements, packet transmis-sions (also between layers within one node) and node andlink states. Actually, ShoX has two different log formatversions, a compact one and an XML based version. TheXML variant is especially advantageous for users who wantto manually scan through the logged data. Another advan-tage of the XML version is that it can be parsed and trans-formed easily using standard XML tools. Since the XMLformat itself is defined by an XML Schema [5], even typeparsing can be automated. Also, the ShoX XML log file canbe easily translated into some other format like nam’s in or-der to make use of other visualization tools. On the otherhand, the XML log file can become very large because ofthe considerable tagging overhead. That is why the com-pact format was introduced as an alternative. The user caneasily decide and switch between the two format variants.Both are supported by our visualization tool.

MonitorCanvas

<<Thread>>Painter

VisualizationMapping

EventList NetState

<<Thread>>VisualizationManager

NetStateManager

LogFile

View

Model

Controller

Figure 4. Architecture of our visualizer.

Figure 4 gives an overview of the individual componentsof our visualizer and their dependencies. The basic archi-

406406406

tecture follows the model-view-controller paradigm. First,the log file is parsed into an event list. The event list is acollection of events sorted by time. The events themselvesare visualization events like NodeMovement, PacketTrans-mission, NodeStateChange, etc. In order to construct them,the log file parser must generally assemble different piecesof information from the log file since aggregated informa-tion of multiple logged simulation events will typically berequired for one visualization event. Once the visualiza-tion process is started, the VisualizationManager repeatedlyfetches the current event from the EventList. It then obtainsthe event’s delivery time, i.e. the simulation time when theevent (e.g. a node movement) is to be executed. This isbecause ShoX is a discrete-event simulator. Based on thedelivery time, the VisualizationManager computes the cor-responding real-world time, i.e. the time when the eventshould be visualized according to the speed which the userselected for visualization. At the computed visualizationtime for the current event, the VisualizationManager in-forms the NetStateManager to update the NetState.

The NetState thus always represents the current state ofthe visualized network. The fact that the current networkstate is captured in one central entity has the advantage thata snapshot of it can be easily memorized by cloning and ref-erencing the NetState object in a dedicated variable. Thisgreatly helps when the user wants to jump back to a previ-ous network state (i.e. visualization time). Normally, in or-der to go backwards in the visualization process, the wholelog file would have to parsed again up to the desired pointof time, since all information in the log file (and thus in theEventList) is only incremental. When the log file is huge,reparsing it can take a long time. Hence, a more efficient so-lution is to regularly store NetState snapshots. When jump-ing back, the log file must be parsed only starting from thelast snapshot before the desired point of time.

The Painter thread (cf. Figure 4) periodically polls thecurrent NetState and asks the MonitorCanvas to display it.As can be seen in Figure 4, the NetState information un-dergoes a so-called VisualizationMapping process before itis displayed. The VisualizationMapping is responsible foradjusting the graphical appearance of the network objects(nodes, links, packets) at runtime. Like OMNeT++ andns-2, our visualizer supports to change the way in whichnetwork objects are displayed to convey some informationabout certain node or link states which could normally notbe seen. Imagine, a user implements a clustering algorithm.In this case, he might want to get an impression of the sizeand distribution of the individual clusters in his network.Thus, it would be helpful, if he could define the color of anode, for example, to reflect its current cluster ID. Then, bylooking at the network, he could directly and easily get anoverview of the clustering.

As mentioned in Section 2, OMNeT++ and ns-2 allow

to adapt certain graphical features. However, both of themrequire the user to encode the desired graphical representa-tion directly through the configuration file or at runtime. Inorder to change the graphical representation, the simulationmust be run again. This can be very time-consuming whenthe user wants to visualize different things with the samegraphical features, or, if he wants to visualize the same thingusing different graphical features. He could choose, for ex-ample, to visualize a clustering using the nodes’ color. Butin another visualization run of the same simulation data hemight want to use the nodes’ color to mark their being clus-terhead. In that case, he might use the nodes’ shape to indi-cate their cluster ID. With OMNeT++ or ns-2 (and others),this will require to change the actual simulation code (re-place the old graphical commands with the new ones) andrun the simulation again. With our visualizer, however, onecan redefine the graphical appearance of nodes and links asoften as necessary without touching code or running simu-lations again. This can save a great amount of time and isalso much more intuitive.

ns-2 simulation visualizationtracefilemapping

ShoX simulation visualizationlogfile mapping

change of mapping

change of mapping

Figure 5. Visualization mapping in ns-2 andShoX.

As depicted in Figure 5, the difference between ns-2’svisualization and ours is that the mapping between states ofnetwork objects and their graphical representation is doneat different times in the process. With ns-2, the mapping isdone mentally when coding the display commands whichare written to the trace file. In order to visualize a cluster-ing by node color, the user inserts the corresponding colordisplay commands at the appropriate places into the simu-lation code. The fact that and the question how these colorsrepresent inner states is not present in the code, but only inthe user’s head. With our ShoX visualizer, the user does notdefine graphical display commands in the code. Rather, helogs the respective node or link states themselves. After thesimulation is finished, the states are recorded in the log file.Using the code

SimulationManager.logNodeState(nid, "clusterID","int", cid);

407407407

in his clustering implementation code, for example, the fol-lowing line would be added to the log file (assumed that thenode ID “nid” was 1 and the cluster ID “cid” was 8):

<nodestate id="1" name="clusterID"type="int" value="8"/>

For the subsequent visualization, the user can then de-fine a mapping between the recorded states and the desiredgraphical representation. This can be repeated and changedas often as necessary, even during a visualization run. Themapping is supported by ShoX’s GUI as shown in Fig-ure 6. Analogously to node states, link states can also berecorded and mapped. For the future, the range of networkobjects to be mapped will be extended to also include pack-ets, etc. The graphical features to which network objectscan be mapped include node color, size, shape, border color,border thickness and up to five labels, further link color, pat-tern, thickness and up to two labels.

Figure 6. Mapping dialog in our visualizer.

The mapping shown in Figure 6 comprises just the do-mains that are mapped, i.e. which node or link state ismapped to which graphical feature. We must also definehow exactly a state value is mapped to some specific valuein the graphical feature domain. For the example we gaveabove, it is not clear yet to which specific color value acluster ID of “8” would be mapped. In order to do so, wefirstly distinguish between continuous and discrete state val-ues. The distinction is done by the type attribute of the statevalue which can be either “int” (discrete) or “float” (con-tinuous). In the clustering example, the cluster ID will cer-tainly be a discrete value, hence we set the type to “int”.“Remaining Battery Time” would be an example for a con-tinuous state value.

In order to map discrete values, each graphical featureoffers a (limited) number of distinct options. The numberand specific values are fixed by our visualizer. In the future,

we might provide a GUI option to let the user change them,for now, however, the user has no access to this information.This is no real limitation, as generally it does not matter atall which particular color, for example, represents a certaincluster ID as long as the colors (and thus clusters) can beclearly distinguished. Hence, we chose the values of theindividual graphical features in a way that they are easilydistinguishable. The mapping of state values is now fairlysimple. Given a specific state value v and a maximum num-ber n(g) of distinct options for a selected graphical featureg, v is mapped to v modulo n(g).

The mapping to continuous values is also fixed by ourvisualizer internally. Continuous state values are supposedto be in the range between 0 and 1. Let us consider thegraphical feature “color” as an example. Currently, we havechosen the color representing “0” to be (0,255,0) in termsof RGB values, i.e. green. The color representing “0.5”is (255,255,0), i.e yellow, and “1” is mapped to (255,0,0),i.e. red. This means that a state value v ∈ {0, . . . , 1} cangenerally be mapped to a color value of (v · 2 · 255, 255, 0)if v ≤ 0.5, and (255, 255− (v− 0.5) · 2 · 255, 0) if v > 0.5.

Figure 7. Visualization panel in ShoX.

Figure 7 shows our visualizer displaying a network ofnodes running a clustering algorithm. In accord with Figure6, the state “clusterhead” (which actually holds the clusterhead’s cluster ID) was mapped to “border color”, “clustermember” was mapped to “color”, and “cluster tree” (a linkstate) was mapped to “color” as well. In Figure 8, the samescenario is shown, albeit with a different visualization map-ping. There, the state “clusterhead” was mapped not to the“border color” feature, but rather to a “label” which displaysthe cluster head’s cluster ID. To change the appearance fromthe one depicted in Figure 7 to the one from Figure 8, all thatis required by the user is to open the mappings dialog shownin Figure 6 again and adjust the settings. As was mentionedearlier, this might even be done at runtime, i.e. while the

408408408

animation is running.

Figure 8. Visualization panel with differentmapping.

Generally, our visualizer is divided into three panels. Atthe bottom are the controls. It is possible to start, pause,resume, stop and reset the visualization process. Addition-ally, one can step back and forward and also select a specificpoint of time by dragging the time slider accordingly. Fur-ther, there are several zoom and speed levels. An interestingfeature is the possibility to capture the animation in an mpegvideo. When pressing the “REC ON” button, a screenshotfrom the animation area is taken in fixed intervals. The in-dividual screenshots are then assembled into a video usingthe transcode utility [2]. In the future, we might make useof an external Java library to produce videos right away.

The area at the top displays the actual network anima-tion. It shows nodes, links and packets. Packets are rep-resented by small rectangular shapes and animated on theirway from sender to receiver. The sender of a packet is al-ways highlighted by temporarily coloring the node red witha smaller black circle in it to catch the user’s eye before thepacket is actually sent. The left area contains textual debugmessages. This is helpful since textual messages can conveymuch information in a compact form. The messages mustalso be logged during the simulation by the user. Duringthe visualization process, animation and messages are dis-played in a synchronized form. That way, the advantages oftextual and graphical representation can be combined.

4 Conclusion

In this paper, we have presented a tool for flexible offlinevisualization of network simulations. It offers the basic fea-ture set of a typical visualizer as known from other toolssuch as nam or OMNeT++. As an offline visualizer, it al-

lows to rewind and repeat the visualization as often as nec-essary without running the simulation again. As opposed toother visualization tools, it provides the possiblity to maplogged node or link states to a wide range of graphical fea-tures. Since we do not log graphical commands directly, itis possible to change the state-to-visualization mapping ar-bitrarily many times without the need to run the simulationagain. This greatly increases flexibility and productivity forthe network designer. It also combines textual and graphicalrepresentation in one user interface.

For the future, we would like to extend our visualizer(and ShoX’s logging facilities) to provide ways to visual-ize more inner variables which cannot be easily of usefullydisplayed by the graphical features presented in this paper.Particularly, we think of tooltips which pop up when theuser hovers over or clicks on an animated object (nodes,links, or packets). That would give even more insight intothe inner processes of the simulation without cluttering theanimation canvas to the point of being unusable.

References

[1] ShoX - A scalable ad hoc network simulator. http://shox.sourceforge.net.

[2] Transcode wiki. http://www.transcoding.org/cgi-bin/transcode.

[3] University of California at Los Angeles, Parallel ComputingLaboratory. GloMoSim - Global Mobile Information Sys-tems Simulation Library. http://pcl.cs.ucla.edu/projects/glomosim/.

[4] University of California at Los Angeles, Parallel Comput-ing Laboratory. Parsec - Parallel Simulation Environmentfor Complex Systems. http://pcl.cs.ucla.edu/projects/parsec/.

[5] World wide web consortium (w3c). xml schema. http://www.w3.org/TR/xmlschema-0/.

[6] L. Begg, W. Liu, K. Pawlikowski, S. Perera, and H. Sirisena.Survey of simulators of next generation networks for study-ing service availability and resilience. In Technical ReportTR-COSC 05/06, Department of Computer Science & Soft-ware Engineering, University of Canterbury, Christchurch,New Zealand, February 2006.

[7] DARPA/NSF. Nam: Network animator. http://www.isi.edu/nsnam/nam/.

[8] L. Hogie, P. Bouvry, and F. Guinand. An overview ofmanets simulation. In Electronic Notes in Theoretical Com-puter Science, Proc. of 1st International Workshop on Meth-ods and Tools for Coordinating Concurrent, Distributed andMobile Systems (MTCoord 2005), LNCS, pages 81–101,Namur, Belgium, April 2005. Elsevier.

[9] P. Novak. Simulation of network structures. Master’s thesis,Department of Software Engineering, Charles University inPrague, August 2006.

[10] A. Vargas. Omnet++ - discrete event simulation system.http://www.omnetpp.org.

409409409