4. Simulation Model. this section, the simulator and the models used for simulation are discussed.

Transcription

1 4. Simulation Model In this research Network Simulator (NS), is used to compare and evaluate the performance of different ad-hoc routing protocols based on different mobility models. In this section, the simulator and the models used for simulation are discussed Network Simulator NS is a discrete event simulator developed for networking research at University of California, Berkley (McCanne and Floyd 2003; Fall and Varadhan 2003). The goal of NS-2 is to support research and education in networking. It is suitable for designing new protocols, comparing different protocols and traffic evaluations. NS-2 was developed as a collaborative environment. A large number of institutes and personnel in research and development maain use NS-2. It provides support for wired and wireless networking. The simulator is written using C++. The accompanying OTCL script language is based on Tcl/Tk. The network components such as nodes, links, protocols and traffic requirements are defined using OTCL scripts. The simulator uses this script and outputs the trace at different selective layers. This output is used to calculate delays, throughput and other performance measures. NS can be used to simulate ad-hoc routing protocols. The wireless model has a mobile node at the core. The Mobile node has the ability to move within a given topology, ability to transmit and receive signals from a wireless channel. 86

2 Physical Layer Model Propagation models are used to determine whether the data transmitted through the air has been successfully received. These models consider propagation delays, carrier sensing and capture effects. In NS, for power attenuation of a signal, 1/r 2 free space model for short distances (r ) and 1/r 4 ground reflection model for distances above 100 meters are usually used, which are suitable for low-gain antennas located 1.5 meters above the ground and operating in the 1-2 GHz band (Broch et al 1998). When a packet transmission is requested, the sender object computes the propagation delay from the sender to every other erface on the channel and schedules the packet reception event for each node MAC Implementation IEEE MAC (IEEE Computer Society) is implemented within NS. MAC layer handles collision detection, fragmentation and acknowledgements. The protocol may also be used to detect transmission errors is a CSMA/CA protocol. It avoids collisions by checking the channel before using it. If the channel is free, it can start sending. If the channel is not free, it waits for a random amount of time before re-trying. For each retry, exponential backoff algorithm is used. In a wireless medium, it cannot be assumed that all stations hear each other. If a station seizes the medium by assuming that it is available, it may not necessarily be so. This problem is known as the hidden terminal problem and to overcome these problems, the collision avoidance mechanism and 87

3 positive acknowledgement schemes are used together. Positive acknowledgement requires peers to retransmit data and acknowledge each other until both are successful. ARP (Plummer 1982) is implemented in NS. It translates IP addresses to hardware MAC address before the packets are sent down to MAC. The antenna gain and receiver sensitivity parameters are available in NS. There are different types of antennas available for simulation. The channel implementation is based on a shared media model. All mobile nodes have one or more network erfaces that are connected to a channel. A channel has a particular radio frequency with a particular modulation and a coding scheme. Channels are orthogonal, i.e., packets sent on one channel do not erfere with transmission and reception in adjacent or any other channels. A packet is received if the transmission range is within the radio propagation model calculation and allowed by the bit error correction/detection system Mobile Node This is the basic object with added functionalities such as mobility, transmit and receive on a channel. Mobility features include node movement, periodic position updates and maenance of topology boundary. These are implemented using C++. Creation and attachment of network components like classifiers, demultiplexer, link layer (LL), MAC, channel within mobile node have been implemented in OTCL. Each mobile node is attached to a routing agent, which calculates the routes to other nodes in the network. Packets sent from the application are received by the routing agent as shown in 88

4 Figure 4.1. The agent determines a routing path for the packet and stamps it. It then sends the packet down to the link layer. The link layer uses ARP to determine the hardware addresses of neighbouring nodes and maps IP addresses to their correct erfaces. The packet is then sent to the erface queue and stays there until a signal from MAC is received. It leaves the erface queue (IFQ) and waits for the MAC to send when the channel is available. The packet is copied to all erfaces at the same time when the first bit of the packet would begin arriving at the erface in a real physical system. Each network erface stamps the packet with its own properties and invokes the propagation model. Note that the propagation model is invoked at the receiver. The propagation model uses transmit and receive stamps to determine the power at which the erface will receive the packet. The receiving network erface is left to decide whether the packet is received successfully or not. If successful, the packet is passed to MAC layer. If the MAC layer receives this packet as error-free and collision-free, it passes the packet to the node s entry po. The packet then reaches a demultiplexer, which decides whether the packet should be forwarded again or if it has reached its destination node. If the arrived po is the destination node, the packet is sent to the demultiplexer that decides the application to which it should be delivered. If the packet is forwarded, this operation is repeated (Fall and Varadhan 2003). 89

5 Figure 4.1 Schematic of a mobile node in NS 4.2. Structure of NS-2 NS-2 is built using object oriented methods in C++ and OTcl (object oriented variant of Tcl). As shown in the Figure 4.2, NS-2 erprets the simulation scripts written in OTcl. A user has to set the different components (e.g event scheduler objects, network components libraries and setup module libraries) in the simulation 90

6 environment. The user writes the simulation as a OTcl script, plumbs the network components together to complete the simulation. Figure 4.2 Simplified User s View of NS The user can setup and implement new network components required for the simulation. The event scheduler along with the network components trigger the events of the simulation (e.g. sends packets, starts and stops tracing). Some parts of NS-2 are written using C++ for efficiency reasons. The data path (written in C++) is separated from the control path (written in OTcl). Data path objects are compiled and then made available to the OTcl erpreter through an OTcl linkage (tclcl) which maps methods and member variables of the C++ object to methods and variables of the linked OTcl object. The C++ objects are controlled by OTcl objects. It is possible to add methods and member variables to a C++ linked OTcl object. A linked class hierarchy in C++ has its corresponding class hierarchy in OTcl as shown in Figure 4.3. Results obtained by NS-2 have to be processed by other tools, e.g. the Network Animator (NAM), a perl or an awk script and gnuplot (Gnuplot, 2003). 91

7 Figure 4.3 OTcl and C++: the duality Functionalities of NS-2 Functionalities for wired, wireless networks, tracing and visualization are available in NS-2. Support for the wired networks include o Routing DV, LS, PIM-SM o Transport protocols: TCP and UDP for unicast and SRM for multicast o Traffic sources: web, ftp, telnet, cbr (constant bit rate), stochastic, real audio o Different types of Queues: Drop-Tail, RED, FQ, SFQ, DRR o Quality of Service: egrated Services and Differentiated Services o Emulation Support for the wireless networks include 92

8 o Ad hoc routing with different protocols, e.g. AODV, DSR, DSDV, TORA o Wired-cum-wireless networks o Mobile IP o Directed diffusion o Satellite o Senso-MAC o Multiple propagation models (Free space, two-ray ground, shadowing) o Energy models Tracing Visualisation o Network Animator (NAM) o TraceGraph Utilities o Mobile Movement Generator Set dest n <num of nodes> -p <pause time> s <maxspeed> -t <sim time> -x <max x> -y <max y> Generating Traffic Patterns (CBR/TCP traffic) n s cbrgen.tcl [- type cbr tcp] [ nn nodes ] [ seed seed][ mc connections] [ rate rate] Trace Files There exists two different trace file formats (old and new) (Griswold, 2003; Fall and Varadhan 2003). A new trace file format was roduced apart from the 93

9 wireless trace format with the idea of joining the tracing in wired and wireless networks Old Wireless Trace File Format A trace in this format always begins with one of the characters in table 4.1. This character is succeeded by a white space separated list of values specific for the used protocol and the type of the message. For all wireless traces the values specified in table 4.2 are recorded. The values for the protocols used in the simulation are listed in tables 4.3, 4.4 and New Wireless Trace File Format The structure of the new wireless trace file format is changed so that it can be egrated o the new trace file format of the entire simulator. The lines of the trace files begin with the same action flags as in the old format and listed in table 4.1and followed by flag/value pairs. The flags begin with a dash and a letter that specifies the flag type (refer table 4.6). The trace format of a wireless event is shown in table 4.7. S Send R Receive D Drop F Forward Table 4.1: These four characters specify the action that can be processed at the packet 94

10 Event Abbreviation Type Value Wireless Event s: Send r: Receive d: Drop f: Forward %.9f %d (%6.2f %6.2f) %3s %4s %d %s %d [%x %x %x %x] %.9f _%d_ %3s %4s %d %s %d [%x %x %x %x] double Time Node ID double X Coordinate (If Logging Position) double Y Coordinate (If Logging Position) string Trace Name string Reason Event Identifier string Packet Type Packet Size hexadecimal Time To Send Data hexadecimal Destination MAC Address hexadecimal Source MAC Address hexadecimal Type (ARP, IP) Table 4. 2 Format of a wireless event 95

11 Event Type Value [%s %d/%d %d/%d] string Request or Reply ARP Trace Source MAC Address Source Address Destination MAC Address Destination Address %d [%d %d] [%d %d %d %d->%d] [%d %d %d %d->%d] Number Of Nodes Traversed Routing Request Flag Route Request Sequence Number Routing Reply Flag Route Request Sequence Number DSR Trace Reply Length Source Of Source Routing Destination Of Source Routing Error Report Flag (?) Number Of Errors Report To Whom Link Error From Link Error To Table 4.3 Additional trace information according to the used protocol Part I: ARP, DSR 96

12 [0x%x %d %d [%d %d] [%d %d]] (REQUEST) hexadecimal Type Hop Count Broadcast ID Destination Destination Sequence Number Source AODV Trace Source Sequence Number [0x%x %d [%d %d] %f] (%s) hexadecimal Type Hop Count Destination Destination Sequence Number double Lifetime string Operation (REPLY, ERROR, HELLO) Table 4.4 Additional trace information according to the used protocol Part II: AODV 97

13 IP Trace TCP Trace CBR Trace IMEP Trace Char Char Char hexadecimal [%d:%d %d:%d %d %d] Source IP Address Source Port Number Destination IP Address Destination Port Number TTL Value Next Hop Address, If Any [%d %d] %d %d Sequence Number Acknowledgment Number Number Of Times Packet Was Forwarded Optimal Number Of Forwards [%d] %d %d Sequence Number Number Of Times Packet Was Forwarded Optimal Number Of Forwards [%c %c %c 0x%04x] Acknowledgment Flag Hello Flag Object Flag Length Table 4.5 Additional trace information according to the used protocol Part III: IP, CBR, IMEP N I H M P Node Property IP Level Packet Information Next Hop Information MAC Level Packet Information Application Level Packet Information Table 4.6 Flag types new wireless trace format 98

14 Flag Type Value s-r-d-f action type -t Double Time -Ni Node ID -Nx Double X Coordinate -Ny Double Y Coordinate -Ne Double Node Energy Level -Nl String Trace Name (AGT, RTR ) -Nw String Drop Reason -Hs Node ID -Hd Node ID For Next Hop -Ma hexadecimal Duration -Ms hexadecimal Source Ethernet Address -Md hexadecimal Destination Ethernet Address -Mt hexadecimal Ethernet Type -P String Application Type (arp, dsr, cbr, tcp ) Table 4.7 Wireless event using the new trace format 99

15 4.3. Mobility models Mobility management faces many challenges in ad-hoc networks. Routing enhancement can be achieved by seeking a node and by exploiting all the mobility profiles for the nodes. The ad-hoc networks routing performance is strongly influenced by the nature of nodes mobility pattern. Most of the simulation work in ad hoc network evaluates the routing performance using only the Random Waypo (RWP) (Camp et al 2002) model. This model provides limited scenarios, where all the mobile nodes move randomly in an area which is not realistic in emulating mobile nodes movements in the real world. Varying the mobility characteristics are expected to have a significant impact on the routing protocols performance. The following section contains a brief description of the existing mobility models in ad-hoc networks Entity and Group Mobility Models Since MANETs are often analyzed through simulations, their performance results depend slightly on the simulation network parameters. Thus the evaluation of an ad-hoc routing protocol depends on the selected mobility model. Entity mobility models represent mobile nodes whose movements are independent of each other. On the other hand, group mobility models represent mobile nodes whose movements are dependent on each other and they tend to be more realistic in applications involving group communication. 100

16 Entity Mobility Models In Random Waypo (RWP) Model (Bettstetter et al 2002) all nodes are uniformly distributed around the simulation space and movement of nodes can be paused according to the pause time specified. A mobile node begins by staying in a one location for a fixed pause time. After that it selects a random destination and moves towards that destination with a speed uniformly distributed over [0, speedmax]. Upon reaching the destination the node pauses and then repeats the process throughout the simulation time. This model is memory less where current locations are independent of the previous ones. Unfortunately the simplicity of this model cannot be adapted to describe complex mobility behaviour of users Manhattan Grid Mobility Model Manhattan Grid Mobility Model (ETSI ) is proposed to model a city section with streets crossing each other perpendicularly. Each mobile node starts from a random po on a certain street. It then chooses a random destination and moves toward this destination within a predefined speed range. Upon reaching the destination the node pauses for a certain time before repeating the process. It is assumed that the nodes move only in the vertical and horizontal directions on the map. 101

17 Group Mobility Models Reference Po Group Mobility (RPGM) Model (Hong et al 1998) it encompasses a random motion of a group of mobile nodes as well as random motion of each mobile node within a given group. Each group has its own mobility behaviour. There is a logical centre for each group such that the centre s motion defines the entire group s motion behaviour (including location, speed, direction and acceleration) and it follows the RWP model. Every node within a specified group follows this logical centre. The motion of the groups is explicitly defined by giving a motion path for the centre which is viewed as a sequence of check pos. Individual mobile nodes belonging to a group randomly move about their own pre-defined reference pos whose movements depend on the group movement Related Work In this chapter, details of previous research on Ad-Hoc networks and how this work inspired this thesis work is discussed. This begins with the discussion of significance of mobility models. It can be seen that reactive ad-hoc routing protocols will have different optimal connectivity levels with the difference in the mobility pattern. In (Turgut et al 2001), the authors claim that if the movement pattern of the nodes is absolutely deterministic then the route life time can be exactly determined. On the other hand a chaotic mobility pattern brings in uncertay to the route life time. The authors highlighted the important role of mobility models on the route life time. They have 102

18 shown that this highly depends on the speed and direction of movement of all the involved nodes. In this thesis a performance study is made (Chen and Chang 2003) for on demand ad-hoc routing protocols with different mobility models Emerging Tools/Frameworks Indeed the Random Waypo model which is used in most of the ad-hoc simulation is studied under NS-2 does not consider some significant mobility characteristics. Firstly spatial dependency is not considered where each mobile node moves independently of others ignoring the neighbourhood influence on the nodes movements. Also temporal dependency is not considered such that mobile nodes velocities are independent. However in reality the mobile node velocity should not change abruptly due to the physical constras of the mobile entity itself. Furthermore the Random Waypo model does not include the geographic restrictions where the movement of mobile node may be restricted by a street map or city boundaries. To thoroughly study the effect of mobility on MANET protocol performance some tools and frameworks have emerged developing a set of mobility models in order to provide a richer environment for routing protocols evaluation. One such tool is the Bonn-Motion tool Bonn-Motion Tool: A mobility scenario generator and analysis tool. It supports Manhattan Grid Mobility, Reference Po Group Mobility and Random Waypo models. 103

19 4.4. Summary: From the study, it is evident that the field of ad-hoc mobile networks is rapidly growing and changing and there are many routing challenges that need to be met. The validation of the routing propositions is being mainly conducted through simulation results. In this chapter, roduction was given on the major challenges in the design of routing protocols in ad-hoc network. It is noticed that the major challenges to be addressed in any routing protocol design are the nodes mobility, dynamic topology, limited battery power and limited bandwidth. Different classifications of the routing protocols according to the routing approach, routing architecture and communication reliability are provided. The most common classification considered for almost all protocols, divides the protocols according to the used routing approach o proactive (on-demand) and reactive (table driven). Since MANETs are not widely deployed, most of the research in these networks is based on simulation. The Random Waypo model is the most commonly used mobility model in these simulations. This model is not sufficient to capture some important mobility characteristics in MANET scenarios. Consequently there is a need for considering the impact of different mobility models in the evaluation of routing performance. 104