Figure 1: EXAMS User Interface
EXAMS Example (AODV)
In a common usage scenario the following steps enable the user to fully exploit EXAMS capabilities:
- Export to NS-2 trace file all the information which is to be visualized by EXAMS like protocol’s values or other NS-2 specific data not included by default.
- Develop Java code which handles the visualization details about the protocol specific issues.
- Load the trace file to EXAMS.
Now we will show an extensive example of EXAMS based on the well known routing protocol for mobile ad hoc networks AODV, as it is implemented in the NS-2 simulator. Throughout this example NS-2 version 2.34 will be used.
More specific we want to visualize the following points:
- General network data (network event types, network level, packet’s size, nodes’ positions, ip source and destination, current hop etc).
- AODV data provided in standard NS-2 trace files (see NS-2 manual for the exact trace data format).
- AODV internal state data, not provided in standard NS-2 trace files.
The first two points have the advantage that the data are included in standard NS-2 trace files, so the only thing should be done is a proper parsing of the trace file. As regards the third point this needs modifications at the NS-2 code in order to export internal AODV data structures to the trace file. For the sake of simplicity we populate only the routing table of each AODV node. Each record of the routing table is exported as the tuple <destination address, sequence number, number of hops, next hop for the destination>. Table 1 depicts an example of the part of the trace file that is related to the routing protocol, according to the “newtrace” file format (see NS-2 manual). At the end of the modified trace there is the “Prt” directive which carries information about the entries of the routing table for the corresponding node.
|Original part of the NS-2 trace file
||-P aodv -Pt 0x2 -Ph 1 -Pb 1 -Pd 8 -Pds 0 -Ps 7 -Pss 4 -Pc REQUEST
|Part of the NS-2 trace file after the modifications
||-P aodv -Pt 0x2 -Ph 1 -Pb 1 -Pd 8 -Pds 0 -Ps 7 -Pss 4 -Pc REQUEST -Prt (8,0,255,0)(1,5,255,0)
Table 1 : Comparison of NS-2 trace file before and after AODV extensions for internal data introspection
In order to implement these changes to the NS-2 trace file we have modified the trace/cmu-trace.cc file as well as the aodv implementation so as to make it possible the serialization of the routing table inside the trace file. You can download the changes in the download page.
As has been shown in section EXAMS - How it works we should encapsulate all the functionality for the visualization of the AODV protocol in a Java class being named with the same name (AODV.class). This class should implement the Protocol interface, or equivalently subclass the DummyProtocol class. We opt for the second one, and override the methods createNode, copyNode, updateNode, getName and notifyEvent. Moreover it would be convenient to subclass the MobileNode class to provide a customized class for AODV nodes. This class will include the internal AODV data being exported in NS-2 trace files (the routing table in case of our example) as well as the parser for the AODV part of NS-2 trace file. Finally the classes should be put inside the java package extensions.routing.aodv. You can download the aodv extension implemenation from the download page.
Next figure depicts an NS-2 simulation for the AODV routing protocol of 40 nodes at 1000*1000m terrain. The figure shows node 6 receiving a data packet from node 4.
Figure 2: EXAMS terrain screenshot of an AODV network
Figure 2 is a screenshot from the various tables with data which are available to the EXAMS user at the event depicted in Figure 1. Figure 2 is separated into four parts and each one represents four tables with data about the current event (see Figure 1 for the exact layout of EXAMS tables). In part 1 we can see the network statistics. It includes the total number of bytes sent in the routing and agent layer. In case of the agent layer EXAMS further analyzes it either to CBR or to TCP/ACK packets. In part 2 we can see some general data about the current node. As seen it includes the node’s address, its current location and its internal counters for the layers described before. The “Last update” field refers to the last event concerning the current node, so it is an indication of the freshness of the data about that node. In part 3 the properties of the current transmission are shown. This includes the direction and the network level of the packet, its flow id, ip source and destination, current and next hop and finally packet size and type. Eventually in part 4 the routing protocol specific data are shown. As we can see, it involves the type of the packet according to the AODV semantics, the source and destination address, the source and destination sequence number and the hop counter. Up to this point all these data are provided by the standard trace files. However after the modification we have made to AODV tracing, it is possible to see the routing table of the current node. It is shown in the last lines of part 4. Each record is a tuple according to Table 2. For instance we can see that at current event, node 6 has a known route for node 39 which is 2 hops away and the next hop should be node 23.
Figure 3: Simulation properties
Another characteristic of the network is the partitions it is split. Figure 3 illustrates each partition of the network with a different color which covers the whole area of the partition. As nodes are moving around, the partitions are recalculated and the user is able to see the whole radio range coverage. Summing up, we saw how we can use EXAMS to study the mobile ad-hoc protocol AODV. As AODV had already been implemented in NS-2, we added some extra code to its tracing module in order to include current node’s routing table at the trace file. At a newly developed protocol this step could be part of the initial implementation and thus don’t comprise an extra burden. Then we implemented the AODV Java class which handles the AODV specific issues inside EXAMS and the AODVNode class which incarnates an AODV node. It is interesting to mention that the Java code needed for the protocol implementation classes is about 160 lines for both the two classes. Figures 5, 6 and 7 provide some idea of the plenty of data provided about the simulation process as well as the visual environment of EXAMS. We believe that EXAMS is a useful tool which can exploit the human visual system and help the researcher to understand how a wireless protocol behaves under the NS-2 simulator while on the same time provides him all the vital information to conclude about the protocol internals. This information is crucial when each step of the simulation process should be investigated in detail as in case of debugging an under development protocol or making a rigorous study of an existing one.
Figure 4: Network partitions
Next » Download EXAMS