A network is an interconnection of different host and consists of different network entities like routers, data links, nodes and packets. For research purpose and communication schemes, it is an important criterion to understand how the packets are routed and the various properties associated with data transfer across different host in a network. To analyze such properties we use network simulations with the help of any software packages. Simulation is defined in [1] as "the process of designing a model of a real system and conducting experiments with this model for the purpose of understanding the behavior of the system and/or evaluating various strategies for the operation of the system." Some packages used are NS2, OPNET, NetSim, GloMoSim. Simulation consists of entities which interact with simulation program to create an event in a system. It also consists of activities, scheduler, global variables (track values in simulations), Random Number Generator (RNG) (to introduce randomness) and statistics gatherer (to collect data generated). Here we use Network Simulator 2 [2] in which we could model the devices, traffic and analyze the performance. NS2 is a discrete event network simulator that is events occur at instance of time. NS2 is used for routing, multicasting and ad-hoc research. Simulations are done on wired and wireless systems using TCP or UDP protocols. It also helps to create networks such as WLAN. The architecture of network simulator is shown in Fig. 1.
Figure 1: NS Architecture [2]
NS2 uses two kinds of language C++ and Object-oriented Tool Command Language (OTcl). This is because class hierarchies can be either standalone or linked between C++ and OTcl interface called TclCL [3] as illustrated in Fig. 2. The function of C++ is to define internal mechanism of simulation objects i.e. when dealing with packets whereas OTcl schedule discrete events and assembles and configures the object to set up a simulation. OTcl defines its own variables and procedures to help the interactions. A simulator is created by the code "ns Simulator" and use finish procedure to end a simulation. Some important commands in NS2 are "ns node" (to create a node), "duplex/simplex-link" (to create a link between two node, either simplex or duplex), "new Agent/TCP or UDP]" (to create a tcp or udp source), "new Agent/TCPSink or Null" this is to create a tcp or udp sink and "new Application/FTP" / "new /Application/Traffic/CBR" is to create ftp session for tcp and cbr traffic source for udp. All these commands are implemented in wired scenario. Finally we run the instance using "ns run". In wireless scenario we avoid the link between nodes and set the axis for nodes. We also add the channel and antenna parameters and finally specify the routing protocol used. The paper in [4] explains the commands used in wired and wireless scenarios. The NS2simulation can be invoked by using the command "ns [<file>] [<args>]. At the end, simulation results are traced on trace files and with these files one can trace NAM (Network AniMation) i.e. the trace files shown in animation. It shows visually when the packet are transmitted and received by the nodes created in a network. To analyze certain network pattern, users can extract required information from the trace file and plot using XGraph.
Figure 2: C++ and OTcl linkage [5]
4.2 NS-MIRACLE
NS2 was the most common tool used for simulation but it lacked multiple radio interface and tools for cross layer communications. The implementation of wireless channels and other radio interfaces where not standard which made studies on wireless coexistence and spectrum sharing a difficult task. Multi InteRfAce Cross Layer Extension (MIRACLE) for NS2 [6] was developed to support multi -technology and cross layering. It consists of dynamic libraries for supporting cross layer and also uses the dynamic libraries of NS2. This is done so that users could develop add-ons for ns which help in introducing new agents, packet types and tracers, protocols, inter module communication. Dynamic libraries are loaded during simulation and there is no need for recompiling which made it simpler and easier for users to operate. The dynamic libraries make ns2 more modular and scalable. MIRACLE can reuse the code of NS2 and introduces the concepts of a unique, general purpose node which act as a container for arbitrary protocol stack architectures [7].
4.2.1 MIRACLE Architecture
MIRACLE helps in interconnection of different nodes of the protocol stack while simultaneously, uniforming the procedure by which multiple layers are plugged into same node [7]. The architecture of MIRACLE is shown in Fig. 3. There are basically four parts for the architecture namely Module, NodeCore, PlugIn and Connector. A layer in architecture may consist of a single module or multiple modules which are connected upstream or downstream. Each module has a specific protocol on PHY, MAC, routing, transport and application. All modules within the stack are connected to nodecore. The main aim of nodecore is to enable communication among modules so as to provide cross layering and, providing function information management for the modules. The technique used for cross layer communication is adapted from interlayer communication through the bus [3cl]. This helps in exchanging messages between modules at any time without interleaving them with the data flow. Since this method is standardized, modularity and extensibility is achieved by the system thereby allowing communication between different entities by discovering them during runtime. For example, routing layer can discover radio interfaces owned by terminal, by sending required broadcast control message and receiving response from available modules during simulation. Another important part of the MIRACLE architecture is the plugin class. Pligins are attached to nodecore and provide a means for sharing cross layer algorithms. With the help of nodecore, plugin can easily share control messages with protocol modules. MIRACLE also introduces a technique for tracing packets and control messages as it is processed, with the help of connectors. Connector can be tuned on or off from the tracing functionality which makes the tracing function tunable. Also the output of the trace file can be programmed by the user. Implementing a module or plugin defines its own tracing pattern which can be worked on for statistics collection and debugging.
Figure 3: NS MIRACLE Architecture [7]
4.2.2 Modules in MIRACLE
NS2 Libraries: The architecture is designed with libraries imported from NS2. This done by declaring Module class as the child class of NsObject class thereby encapsulating MIRACLE module over ns2 modules. This helps in reusing of existing ns2 code.
IEEE802.11 Library: The libraries for IEEE802.11 is ported to MIRACLE framework with extended functionalities like multiple transmission mode and coding and modulation schemes in IEEE802.11b/g. also an interference model is employed to compute the interference and noise ratio in any communication. The packet error rate is obtained as the function of noise ratio which appears to be more realistic.
MIRACLE Physical Layer Module: Evaluation of wireless and packet errors is done using simple interference model in ns2 which created issues problems with physical layer and this led to the development of MIRACLE Physical Layer Module (MPhy). All MPhy components are implemented as parent class. It is mainly used for the implementation of different radio technologies. Packets received by the system are recorded by MPhy and provides some tools for calculating the corresponding noise ratio. Noise ratio obtained for the packets is a function of [x] interference due to transmissions, correlation factor due to channel overlapping and propagation gains.
UMTS Library: MPhy and the eurane extensions for NS2 [4] developed the libraries for UMTS. A physical layer is employed using MPhy for accounting multi-user interface, scrambling or spreading and power control operations. Packet error rates are approximated using noise ratio. The architecture is has also imported acknowledge mode radio link control (AM)RLC from eurane which provides data concatenation, selective ARQ and packet fragmentation. Also, to avoid infinite retransmission loops, an SDU discard functionality is added. The UMTS architecture used is illustrated in Fig. 4.
Figure 4: UMTS Architecture in MIRACLE [7]
