Title: CAD-HOC
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00100850/00001
 Material Information
Title: CAD-HOC a CAD like tool for generating mobility benchmarks in ad-hoc networks
Physical Description: Book
Language: English
Creator: Shah, Subodh, 1976-
Publisher: University of Florida
Place of Publication: Gainesville Fla
Gainesville, Fla
Publication Date: 2001
Copyright Date: 2001
 Subjects
Subject: Routers (Computer networks)   ( lcsh )
Computer network protocols   ( lcsh )
Computer and Information Science and Engineering thesis, M.S   ( lcsh )
Dissertations, Academic -- Computer and Information Science and Engineering -- UF   ( lcsh )
Genre: government publication (state, provincial, terriorial, dependent)   ( marcgt )
bibliography   ( marcgt )
theses   ( marcgt )
non-fiction   ( marcgt )
 Notes
Summary: ABSTRACT: Ad-hoc networks do not require a preexisting communication infrastructure. This is particularly well-suited to real-time applications such as battlefield management, law-enforcement, and disaster recovery, to mention a few. Routing in ad-hoc networking is an emerging area of research that is vital to the operability of such networks. The most widely used tool for studying ad-hoc routing protocols is Networks Simulator (ns), which provides a proven capture of the various networking layers from PHY and MAC to the routing and transport layers. Unfortunately, ns falls short in capturing realistic mobility scenarios and situations. It currently uses random mobility scenarios, which do not provide for a reliable evaluation of the ad-hoc routing protocols. This thesis addresses this limitation and contributes a cousin tool to ns, which we call CAD-HOC. Similar in spirit to CAD/CAM tools, CAD-HOC uses an extensive GUI to aid the ns user in generating realistic mobility scenarios and benchmarks. CAD-HOC provides a great deal of realism in producing mobility scenarios, by allowing users to base their designs on particular spatial layouts. This could be an airport terminal layout, a highway map, or a layout of a section in a shopping mall. CAD-HOC also provides a great deal of flexibility by allowing ns users to specify movement constraints (e.g. can not move off the highway), movement parameters (e.g. speed, renewal), and connection modes. Finally, CAD-HOC provides for a high degree of productivity by allowing group operations, in which several or tens of nodes and their movement behavior can be minimally specified.
Summary: ABSTRACT (cont.): CAD-HOC generated benchmarks can be saved, edited, and ultimately fed to ns to drive fully-controlled simulation experiments. With realistic mobility benchmarks, researchers will be able to examine the various routing protocols (existing and proposed), and reach reliable conclusions. We hope that the ns research community can benefit from the CAD-HOC tool, which will soon be made publicly accessible.
Thesis: Thesis (M.S.)--University of Florida, 2001.
Bibliography: Includes bibliographical references (p. 85-89).
System Details: System requirements: World Wide Web browser and PDF reader.
System Details: Mode of access: World Wide Web.
Statement of Responsibility: by Subodh Shah.
General Note: Title from first page of PDF file.
General Note: Document formatted into pages; contains xiii, 90 p.; also contains graphics.
General Note: Vita.
 Record Information
Bibliographic ID: UF00100850
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: oclc - 49191636
alephbibnum - 002763029
notis - ANP1049

Downloads

This item has the following downloads:

FinalETDCopy ( PDF )


Full Text











CAD-HOC: A CAD LIKE TOOL FOR GENERATING MOBILITY BENCHMARKS
IN AD-HOC NETWORKS


















By

SUBODH SHAH


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2001

























Copyright 2001

by

Subodh Shah





















TO MY PARENTS















ACKNOWLEDGMENTS

I would like to express sincere gratitude to my advisor, Dr. Abdelsalam (Sumi)

Helal, for giving me an opportunity to work on this challenging topic and for providing

continuous guidance, motivation and feedback during the course of this work and thesis

writing.

I wish to thank Dr. Richard Newman and Dr. Joseph N. Wilson for serving on my

supervisory committee and for their careful review of this thesis.

I also would like to thank Edwin Hernandez, for his valuable guidance during the

course of this work and thesis writing. I also thank all the research students in Harris Lab

for their constant support.

I also wish to take this opportunity to thank my parents for their emotional

support and encouragement throughout my academic career.
















TABLE OF CONTENTS

page

A C K N O W L E D G M E N T S ......... .. ............. .................................................................. iv

LIST OF TABLES ......... ................................................. ............ viii

LIST O F FIG U RE S ......... ...... ............ ........ .............. ......... ix

A B S T R A C T ..................................................................................................... x ii

CHAPTERS

1 INTRODUCTION.................................. 1

1.1 T hesis G oal ....................................................................... ... .... ... .... . 3
1.2 Structure of Thesis ......................................................... ..... .......... ........ 3

2 AD -HOC NETW ORK S................. ................. ..................... ....... ..5

2.1 Characteristics of A d-H oc N etw orks .................................. ................................... 7
2.2 A applications .............................. .................................. 8
2.3 Research Roadm ap ............................................. .................. .......... 9

3 ROUTING PROTOCOLS IN AD-HOC NETWORKS ............................................ 11

3.1 Challenges and Requirements of Ad-Hoc Routing protocols.............. ............... 11
3.2 Ad-Hoc Networks Routing Protocols ........................................... ..... ......... 14
3.2.1 Classification of Existing Routing Schemes .................................................. 14
3.2.2 Table D riven Routing Protocols......................... ............................ ...... 15
3.2.3 Source Initiated Routing Protocols ........................................ ..... ......... 15
3.3 Protocols ............................. .................... . ............ 16
3.3.1 DSDV (Destination Sequenced Distance Vector)................... .......... 17
3.3.2 AODV (Ad-Hoc On-Demand Multicast Routing)................ ............. ....20
3.3.2.1 R oute D discovery ......... .............................................. ..... ... ..... 20
3.3.2.2 R oute M aintenance........... ............................ ............... .............. 21
3.3.3 DSR (Dynamic Source Routing)................................................................... 22
3.3.3.1 Route Discovery .................. .. ....................... ... .............. 22
3.3.3.1 R oute M aintenance................................................ ............................... 22
3.3.4 TORA (Temporally Ordered Routing Algorithm)................ ..................24
3.3.4.1 R oute Creation ....................................... ... ......................... 24









3.3.4.2 M maintaining Routes & Route Erasures................................................... 25
3.4 Performance Comparison and Evaluation of the Protocols .............. ................. 27
3.4.1 C control M message O overhead .................................................................. .. ... 27
3.4.2 D ata Throughput ....................... ................................... .. .. ...... .... .. 27
3.4.3 End-to-End D elay ........................................... .. ...... .. .......... .. 28
3.4.4 Other Considerations.................................. .............. ............ .............. 28
3.4.5 Comparison of On-Demand v/s Table Driven Routing .............. ........... 28

4 NETWORK SIMULATOR (ns) ........................................................... 30

4.1 M obile N etw working in ns............................................ ........ ............................... 33
4.2 Specifying M obileNode M ovement..................................................................... 36
4.3 G enerating Traffic Pattern Files................................................................... ..... ... 36
4.4 C conducting Sim ulation...................................................... .......................... 37

5 T H E T O O L C A D -H O C ...................................................................... .................... 38

5.1 The Importance of CAD -HOC ...................................................... ................. 38
5.2 C A D -H O C ..................................... ................................ 40
5.2.1 System Architecture and Components..........................................................40
5.2.2 D ata O organization .................. ............................ ............. ......... 42
5.2 .3 G raphical U ser Interface ................................................................................. 44
5.2.3.1 M enu B ar...................................... ........................ ... ......... 45
5.2.3.2 Right Click Popup Menu Options .............. ........................................... 59
5.3 Perform ance M etrics Selection ...................................................... ........... ... 60
5.3.1 M obility Perform ance M etrics ................................... ..................... .. ........ 60
5.3.2 Ad-Hoc Connectivity M etrics ................................ ......................... ...... 61
5.3.3 M message Com plexity M etrics.............................. ............................ ..... 62
5.4 Im plem ented Feature List .......................... ......... .. ................ .............. 62

6 REALISTIC SCENARIOS AND PERFORMANCE RESULTS................................. 67

6.1 A airport T erm final Scenario ......... ................. ...................................................... 68
6.2 Highway Scenario ............. ........ .................... ........ .. .............. 69
6.3 Conference Scenario ...................... ...... . .. ........... .... .... ... .. ...... .. 71
6.4 P perform ance G raphs ......... ................................................................ .............. 72
6.4.1 Throughput ................... ............................................................................73
6 .4 .2 D elay ......................................................... .... ................................. . . 7 5
6.4.3 Percentage Loss...... ...................... .................. .. ........ 77

7 CONCLUSIONS AND FUTUREWORK ........................................................ 80

7 .1 C on clu sion s ...................... .. .. ......... .. .. ......... .................................. 80
7.2 Future Work ............................................ 81









APPENDIX: GUIDELINES AND RECOMMENDATIONS TO PRODUCE
S C E N A R IO S ....................................................................... ................ 8 3

R E F E R E N C E S .................. .................................................................. ............ .. .. 8 5

BIOGRAPHICAL SKETCH ....... ................................................... .............. 90
















LIST OF TABLES


Table Page

3.1: Comparison of On Demand vs. Table Driven Routing............................................... 29

6.1: Parameters Used During Realistic Scenario Simulation......................................... 68

6.2: Simulation Results for the Airport Terminal Scenario .................................................. 68

6.3: Simulation Results for the Highway Scenario .............. .............................. ....... ....... 70

6.4: Simulation Results for the Conference Scenario .................................. .............. 72
















LIST OF FIGURES


Figure Page

2.1: Example of Simple Ad-hoc Networks with Four Participating Nodes ........................ 6

2.2: Characteristics and Issues of Mobile Ad-hoc Networks ..................................... 8

3.1: Classification of Routing Protocols for Ad-Hoc Networks .................................. 16

3.2: Routing a Packet from the Source to Destination Using the Routing Table................ 18

3.3: Updating Routing Entry into the Table upon the Arrival of the Update Packet ............ 19

3.4: Route Recording During Route Discovery .......................................... ..... ......... 23

3.5: Route Reply Propagating Back with Route Record................................................ 24

3.6: Initial State, When the Path Is to Be Established, and Propagation of QRY Packet
Through the Network. .......... ......................................... ....... .............. 25

3.7: Height of Each Node Update as a Result of UPD Messages .............. .................... 26

3.8: Route Maintenance Mechanism When Node Between Node E and G Fails ............... 27

4.1: N AM Showing the N ode M ovem ent ........................................ .................. ...... 33

4.2: Schematic of a Mobilenode under the CMU Monarch's Wireless Extensions to ns..... 35

5.1: System Architecture and Components of CAD-HOC .............................................. 42

5.2: Data Organization in CAD -H OC ....................................................... .............. 43

5.3: Main Screen of CAD-HOC Showing a Conference Scenario..................................... 45

5 .4 : C A D -H O C M enu B ar .................................................................................................... 4 5

5.5: CAD -H O C GU I File M enu ............................................... .................................... 46

5.6: CAD-HOC GUI Load Subm enu ....................... ........................................................ 46









5.7: CAD -H OC GU I Edit-D raw M enu ........................................... .......................... 47

5.8: CAD-HOC GUI Image Options Submenu ......................................... .............. 47

5.9: CAD-HOC GUI Dialog Box to Set Image Editor ................................................... 48

5.10: CAD-HOC GUI Draw Beams/Moveable Area Submenu........................................... 48

5.11: CAD-HOC GUI Blocked Region Submenu..................... ..... ..... ............. 49

5.12: CAD -HOC GUI N ode M enu..................... ................................... .......................... 50

5.13: CA D -H O C G U I N ode Subm enu........................................................ .... .. .............. 50

5.14: CAD-HOC GUI Dialog Box to Change Color / Transmission Range...................... 51

5.15: CAD-HOC GUI Node Movement Parameters........................................................ 52

5.16: CAD -H O C GU I A accessible A reas M enu............................................... .... .. .............. 53

5.17: CAD-HOC GUI Move Options Submenu ....................................................... 54

5.18: CAD -H O C GU I G generate M enu............................................ ................................ 54

5.19: CAD -HOC GUI M ovem ent Code Subm enu.............................................................. 55

5.20: CAD-HOC GUI Specify Connection Submenu....................................................... 55

5.21: Snapshot of the Node Connection Specifier Interface. ........................................... 56

5.22: CAD-HOC GUI Dialog Box to Specify Parameters for Each Connection................ 57

5.23: CAD-HOC GUI Node Connection Parameters Dialog Box .............. .................. 57

5.24: CAD-HOC GUI Complexity Gauges Submenu................................. .................... 58

5.25: C A D -H O C G U I H elp M enu ........................................................................................ 58

5.26 CAD -H OC GUI Right Click Popup M enu............................................... ... ................. 59

6.1: CAD-HOC Generated Airport Terminal Scenario............................... .................... 69

6.2: CAD -H OC Generated H ighw ay Scenario............................................... ... ................. 70

6.3: CAD -H OC Generated Conference Scenario............................................ .... .. .............. 71

6.4: Graph of Throughput vs. Nodes-Airport Terminal ............................................... 73

6.5: Graph of Throughput vs. Nodes-Conference Terminal.............................................. 74









6.6: Graph of Throughput vs. Nodes-Highway Scenario .............................................. 74

6.7: Graph of Delay vs. Nodes-Airport Terminal ........................................ ...........75

6.8: Graph of Delay vs. Node-Conference Scenario................................... .................... 76

6.9: Graph of Delay vs. Nodes-Highway Scenario............... ......... ........ ........... 76

6.10: Graph of Percentage Loss vs. Nodes-Airport Terminal .................... ............. 77

6.11: Graph of Percentage Loss vs. Nodes-Conference Scenario .................................. 78

6.12: Graph of Percentage Loss vs. Nodes-Highway Scenario .............. ................... 78















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

CAD-HOC: A CAD LIKE TOOL FOR GENERATING MOBILITY BENCHMARKS
IN AD-HOC NETWORKS


By

Subodh Shah

August, 2001


Chairman: Abdelsalam Helal
Major Department: Computer and Information Science and Engineering

Ad-hoc networks do not require a preexisting communication infrastructure. This

is particularly well-suited to real-time applications such as battlefield management, law-

enforcement, and disaster recovery, to mention a few. Routing in ad-hoc networking is an

emerging area of research that is vital to the operability of such networks. The most

widely used tool for studying ad-hoc routing protocols is Networks Simulator (ns), which

provides a proven capture of the various networking layers from PHY and MAC to the

routing and transport layers. Unfortunately, ns falls short in capturing realistic mobility

scenarios and situations. It currently uses random mobility scenarios, which do not

provide for a reliable evaluation of the ad-hoc routing protocols. This thesis addresses

this limitation and contributes a cousin tool to ns, which we call CAD-HOC. Similar in

spirit to CAD/CAM tools, CAD-HOC uses an extensive GUI to aid the ns user in

generating realistic mobility scenarios and benchmarks.









CAD-HOC provides a great deal of realism in producing mobility scenarios, by

allowing users to base their designs on particular spatial layouts. This could be an airport

terminal layout, a highway map, or a layout of a section in a shopping mall. CAD-HOC

also provides a great deal of flexibility by allowing ns users to specify movement

constraints (e.g. can not move off the highway), movement parameters (e.g. speed,

renewal), and connection modes. Finally, CAD-HOC provides for a high degree of

productivity by allowing group operations, in which several or tens of nodes and their

movement behavior can be minimally specified. CAD-HOC generated benchmarks can

be saved, edited, and ultimately fed to ns to drive fully-controlled simulation

experiments.

With realistic mobility benchmarks, researchers will be able to examine the

various routing protocols (existing and proposed), and reach reliable conclusions. We

hope that the ns research community can benefit from the CAD-HOC tool, which will

soon be made publicly accessible.














CHAPTER 1
INTRODUCTION

Ad-hoc networks are infrastructure-less networks in which each node

participating in the network acts as a host and router, forwarding packets to other nodes,

emphasizing on a routing protocol different from traditional routing protocols. Ad-hoc

networks are characterized by limited battery life, transmission range, CPU capacity and

bandwidth as well as by decentralized administration, dynamic topology, and mobile

nodes, to mention a few features. These characteristics place a new demand on routing

protocols. Its foremost characteristic is the dynamic topology, a direct consequence of

mobility of nodes. Routing protocols should be able to adapt to topology changes. Nodes

in ad-hoc networks are usually laptops, PDAs (Personal Digital Assistant) or smart

phones. These nodes are limited in resources as mentioned above. This tends to

emphasize minimizing control traffic such as periodic updates, constraining the routing

protocol to be reactive in nature. Internet Engineering Task Force (IETF) [IETF]

currently has a working group named Mobile Ad-Hoc Networks (MANET) [MANE] that

is working on routing specifications for ad-hoc networks. Some of the applications of ad-

hoc networks include, disaster recovery situations, places with nonexistent infrastructure

or damaged communication, law-enforcement, parking lots, conference.

The Network Simulator (ns), one of the most used tools for studying Ad-Hoc

routing protocols comes with the implementation of DSDV [JOH96, BRO98, ROY99],

AODV [ROY99, MIS99, PER99], TORA [ROY99, MIS99, SIV96] and DSR [ROY99,









MIS99] in its installation package. Simulation process in ns requires expert use of the

TCL scripting language to produce mobility and connection scenarios. The difficulty to

visualize scenarios increases with the size of the scenario. Mobility scenarios specify the

way nodes will be moving, while connection scenarios specifies the way messages will

be transmitted and received between nodes using CBR (UDP) or TCP traffic.

Unfortunately ns lacks the ability to capture realistic scenarios and situations. Literature

on ad-hoc networks shows that mobility and connection scenarios used for simulation and

performance evaluation are unrealistic (randomly generated). A way to standardize

mobility scenarios is to use mobility models, but mobility models alone only won't help.

Mobility models yield best results when used in coordination with appropriate real-time

situations, which emphasizes a way to capture mobility scenarios from mobility model

generated movement patterns. For example, an airport terminal, which depicts a real-time

scenario, having medium mobility, can be used in conjunction with mobility models like

pursue, nomadic capturing mobility scenarios and benchmarks to get best results from

mobility models.

This thesis presents CAD-HOC, a cousin tool to ns, similar in spirit to

CAD/CAM, which addresses the limitation of unrealistic scenarios. CAD-HOC is a java-

based application using Graphical User Interface (GUI) to support ns users generate and

visualize scenarios. CAD-HOC offers immense flexibility to ns Researchers. Its key

features include ability to use any image (easily obtained from web) like an airport

terminal, museum, theme park, train station, bus station or restaurant. Features enabling

scenario generation support overlaying mobility constrained and supported regions,

placing of nodes on mobility supported areas, generating mobility and connection









scenarios using mobility models, and feeding the resultant data to ns simulations. CAD-

HOC generated mobility scenarios and the desired section of scenario can be saved and

edited with great ease, making CAD-HOC more robust than existing scenario generators.

CAD-HOC features a timer-based interface, which allows the researchers to visualize the

mobility and connection scenarios prior to the actual simulation. The tool's most valuable

asset is presenting an estimated analysis of the scenario being generated like ad-hoc

mobility, ad-hoc connectivity, message-complexity, thus aiding researchers to mold

generation of mobility scenarios and benchmarks to the desired level of complexity.


1.1 Thesis Goal

The goal of this thesis is to semi-automate the specification and generation of

non-trivial mobility scenarios to aid simulations in ns of ad-hoc routing protocols by

establishing a tool to be used in conjunction with ns. The tool, which is called CAD-

HOC, focuses on presenting a novel way of benchmarking mobility scenarios by

allowing the user to base scenario generation on particular real-world spatial layout. The

secondary goal of this thesis is to make the tool open source. This allows others to

enhance the tool with more features enabling researchers to conduct more meaningful and

close-to reality experiments.


1.2 Structure of Thesis

Chapter 2 introduces ad-hoc networks and discusses some issues, applications and

research scopes of ad-hoc networks.

Chapter 3 presents challenging requirements of ad-hoc routing protocols,

taxonomy of classification of ad-hoc networks, explanation of several ad-hoc routing









protocols and shows a comparison table of table-driven routing protocols vs. source

initiated routing protocols.

Chapter 4 introduces Network Simulator (ns), a widely used tool for studying ad-

hoc routing protocols. It discusses the architecture and organization of ns, simulation

requirements for ad-hoc networks and discusses the architecture of mobile nodes in ns. It

also explains the method of conducting simulations.

Chapter 5 starts with realizing the need for the tool CAD-HOC. It explores the

problem of using random and unrealistic scenarios for evaluating the performance of ad-

hoc routing protocols and introduces CAD-HOC as a solution. It also discusses the

architecture of the tool CAD-HOC, its functions, data organization, GUI and issues

regarding selection of models for analysis.

Chapter 6 presents two examples of real-world scenarios generated using the tool,

a highway and an airport terminal. The results obtained from ns by applying these

generated scenarios are presented.

The thesis ends drawing conclusions and providing a brief description of future

work that can be done to make the tool more flexible, perform some script optimizations

and address issues that are not in the current scope of CAD-HOC.














CHAPTER 2
AD-HOC NETWORKS

A collection of wireless mobile nodes gets together to dynamically form a

temporary infrastructure-less network having no centralized administration, thus forming

an ad-hoc network. As the mobile nodes have limited transmission range, it's necessary

that multi hop routing be used by one node to exchange data with other nodes in the same

or another network, so each mobile node acts as a host and also as a router, thus

forwarding packets for other nodes, that are not within the direct transmission range of

each other. These intermediate nodes acting as routers are useful in discovering routes to

other nodes on the networks. The primary reason ad-hoc networks are also called

infrastructure-less networks is that the mobile nodes in the network dynamically establish

routes to other nodes in the network on fly (while moving).

Ad-hoc networks are often called ubiquitous computing, which means that

computers are everywhere and information is anywhere anytime. In wireless

communication one global bandwidth is to be shared by all users. It is radio based having

low bandwidth/ high latency radio communication links and has fading problems.

Portable computers are less reliable and secure and have limited resources like battery

life, CPU speed, and memory. Each node has a wireless interface and communicates with

other nodes over either radio or infrared. Some of the examples of the nodes of ad-hoc

networks are Laptop computers and personal digital assistants that communicate directly

with each other. Nodes in the ad-hoc network are often mobile, but can also consist of

stationary nodes having access to the Internet. Figure 2.1 below shows a simple ad-hoc








network with four nodes. The dotted circles show the transmission range. Node A cannot

communicate directly with node C or D. It must use the service of node B to have

communication with node C or D.





( A B6 C D



Figure 2.1: Example of Simple Ad-hoc Networks with Four Participating Nodes.


Ad-hoc networks do not have centralized administration to make sure that the

networks doesn't get partitioned (or collapsed) if the mobile node moves out of the

transmission range of other nodes. Mobile nodes as the name indicates should have

mobility allowing the nodes to enter/leave the networks as they wish, which may or may

not affect the performance of the network. A node can be imagined as an abstract entity

consisting of a router and a set of affiliated mobile hosts. A router is an entity, which,

runs on a routing protocol, a mobile host in an ad-hoc network is simply an IP

addressable node.

Ad-hoc networks dynamically handle topology changes, which means that they

reconfigure the network topology if and when needed. If it happens that a node leaves the

network and causes link breakages, affected nodes can easily request new routes and the

problem will be solved. This increases delay slightly, but the network is still be

operational.









2.1 Characteristics of Ad-Hoc Networks

The characteristics of ad-hoc routing protocols mentioned previously are now

discussed. These characteristics include dynamic topology, limited capacity and power,

unidirectional links and power requirements.

1. Dynamic topology: Nodes in ad-hoc networks are mostly mobile, which

means that nodes will move around changing their physical location. So

mobility routing protocols that discover routes dynamically should be

used. This leads to a requirement to modify the distance vector and link

state.

2. Limited CPU capacity, storage capacity, battery power and bandwidth:

Each mobile node has limited CPU capacity, storage capacity, battery

power and bandwidth. Such nodes are also referred as thin clients. Limited

capacity and battery power implies limited transmission range.

3. Unidirectional links: Unidirectional links may be formed because different

mobile nodes have different transmission range. These links arise when,

for example, two nodes have transmitters of different strength, allowing

only one of the hosts to hear the other, but they can also arise from

electromagnetic disturbances from the surroundings.

4. Squared power requirements with distance: Power used is squared with the

increase in the distance that is traveled in propagation of signal in radio

environment. Ad-hoc environment leads to a gain in the overall transmit

capacity and power if nodes are densely concentrated. By using multihop,

nodes can transmit the packets with a much lower output power.









Figure 2.2 shows some of the characteristics and issues involved in Mobile Ad-hoc

wireless networks [LES98].


Figure 2.2: Characteristics and Issues of Mobile Ad-hoc Networks1


2.2 Applications

In areas where no infrastructure such as the internet is available an ad-hoc

network could be used by a group of wireless mobile hosts. This can be the case in areas

where a network infrastructure may be undesirable due to reasons such as cost or

convenience. Examples of such situation include disaster recovery personnel or military

troops in cases where the normal infrastructure is either unavailable or destroyed.

Other examples include business associates wishing to share files in an airport

terminal, or a class of students needing to interact during a lecture, business associates

sharing information during a meeting.


1 C 1998 The MITRE Corporation. All Rights Reserved. Used with permission of the MITRE corporation









Soldiers relaying information for situational awareness on the battlefield,

Emergency disaster relief coordinating efforts after a hurricane or earthquake, local

parking lot availability, layout of a building, train and bus station information, local

traffic information, weather information, local news service wide area services e.g. stock

market information, real time multimedia applications like tele-medicine, telecommuting,

and collaborative environments.

If each mobile host wishing to communicate is equipped with a wireless local

area network interface, the group of mobile hosts may form an ad-hoc network. Access to

Internet and access to resources in networks such as printers are features that also can be

supported.

Wireless ad-hoc networks could be useful for any wireless personal

communications. One of the main uses of ad-hoc networks would be in disaster recovery

situations, like fire, hurricane, earth quakes, floods, riots, desert storm, bombing where

there are chances that the normal mode of communication may come to stand still. In

such cases ad-hoc networks would be of great help.


2.3 Research Roadmap

Research is being done in hardware in reducing power consumption, reducing

size, improving user interface, reducing cost, energy efficient memory technology.

Research is also being done in software in communication protocols for mobile

hosts like Mobile-IP, locating an MH, multicasting maintaining host view and at-most

once, at-least once, or exactly once delivery. In addition to all this research is being done

to find energy-efficient algorithms, which includes bandwidth saving techniques, context

aware computing, supporting CODA distributed file system, latency hiding and pre

fetching techniques






10


Extensive research is being done on ad-hoc networks addressing wireless

technology using high frequency signals preserving the privacy of mobile users. Research

is also carried out in multimedia, mobility, and multihop issues of ad-hoc wireless

networks.














CHAPTER 3
ROUTING PROTOCOLS IN AD-HOC NETWORKS

Ad-hoc networks, require a new routing protocols that have some special features

as compared to the conventional routing algorithms. Some of the desired challenges and

requirements to be fulfilled by the ad-hoc routing protocols are listed below. If an ad-hoc

routing protocol has all the below mentioned features than it can be said to be a complete

ad-hoc routing protocol.

The wish list (ideal qualities) that an ad-hoc routing protocol should have is to be

followed.


3.1 Challenges and Requirements of Ad-Hoc Routing protocols

Ad-hoc routing protocols are different from conventional routing protocols as

mentioned above. These protocols should have the following protocols to be considered

as an ideal protocol. The protocols often are the results of trade-off of these

characteristics.

* Distributed Operation

The protocol should of course be distributed. It should not be dependent on a

centralized controlling node. This is the case even for stationary networks. In an ad-hoc

network the mobile nodes enter/leave the network very easily. As a result of this

mobility, networks may be partitioned.

* Freedom of Loops









Frequent update of messages may result in stale routes being formed in the

network, which degrades the performance. Thus to improve the overall performance, the

ad-hoc routing protocol should guarantee that the route supplied is loop-free, so that it

avoids any waste of bandwidth or CPU power consumption.

* Demand Based Operation:

In ad-hoc networks control updates are produced even if there are no changes in

routes (to inform about it being alive). This means that the protocol should be reactive.

Reactive means that the protocol should only react when a route is needed.

* Unidirectional Link Support:

The radio environment can cause the formation of unidirectional links because

each mobile node in the networks may have different transmission range. Utilization of

these unidirectional links improves the routing protocol's performance. It may also

degrade the performance if the protocol designed doesn't take in to account the

unidirectional Link support.

* Security:

In ad-hoc networks communication occurs through multi hops. Thus a kind of

trust is needed from the intermediate nodes that they won't temper the packets or data.

Thus the radio communication used in ad-hoc environment is vulnerable to

impersonation attacks. Some form of prevention and precaution can be used.

Authentication and encryption can be used for security but the main problem in this case

is distributing the keys among the nodes in the networks because that distribution also has

to pass through multiple hops.

* Power Consumption:









Mobile nodes in ad-hoc networks are often thin clients, laptops, PDAs. These

kinds of nodes have limited battery life and thus should use minimum power as possible

to communicate longer and remain alive in the network. Thus routing algorithms should

support sleep modes. For example most users would check mail often, when emails are

down loaded soon after that the node should go in power saving mode because the user

would then check and read the mails, which would save a lot of power.

* Multiple Routes:

Often multiple routes exist from a source to destination. These multiple routes

should be used to reduce the number of reactions to topological changes and congestion.

If a route becomes invalid the alternative route from the multiple route can be chosen.

* Shortest v/s Stable Route Selection:

A routing protocol may have to make a decision between the shortest path that is

available and the most stable route that is available. Shortest path may lead to prompt

delivery but the route may not last long, while if its known that a route is stable then at-

least its assured that the delivery will be done even though it takes a bit long.

* Quality Of Service Support:

QoS support is one of the important feature that ad-hoc network should have, it

more probable that ad-hoc networks may be used for voice communication. QoS is

becoming one of the most important features in routing protocols. QoS could for instance

be real-time traffic support.

Other challenge is that wireless has slow data rates, ad-hoc routing protocols must

minimize bandwidth overhead at the same time as they enable proper routing to take









place. The primary function is still to find a route to the destination, not to find the

best/optimal shortest path route.


3.2 Ad-Hoc Networks Routing Protocols

Both academic and industrial efforts are currently being done in the development

of the routing protocols for ad-hoc networks, The academic research has been carried out

on developing new routing protocols for ad-hoc networks, and its implementation.

Industrial efforts have helped to have some widely accepted routing protocols for ad-hoc

networks. Blue Tooth supported devices have implementations of ad-hoc routing

protocols like DSR and DSDV.

3.2.1 Classification of Existing Routing Schemes

Existing wireless routing schemes can be classified as

* Global, pre-computed routing:

Routes to all destinations are computed in prior and are maintained in the

background via a periodic update process as they are done in Distance Vector [ATAP,

JOH94, ROY99] and Link State (LS) [ATAP, JOH94, ROY99].

* On-Demand routing:

Route to specific destinations is computed only when needed.

* Location based Routing:

GPS system is used to locate the destination for routing.

* Flooding:

A packet is broadcasted to all destinations, with the expectation that at least one

copy of the packet will reach the intended destinations.

The routing protocols can be classified in to two categories:









1. Table Driven Routing 2. Source Initiated Routing

3.2.2 Table Driven Routing Protocols

Table driven routing protocols also called proactive routing protocols that attempt

to maintain consistent, up-to-date routing information from each node to every other node

in the network. For this each node maintains one or more tables to store routing

information, and whenever there is a change in the network topology, the nodes sends the

updated table to its neighbors in order to maintain a consistent view of the network. The

main difference in the table driven routing protocols is the number of tables that each

routing protocol maintains, and the technique the protocol uses to broadcast the updated

table. Some of the examples of the table driven protocols are DSDV (Destination

Sequenced Distance Vector), CGSR (Cluster-head Gateway Switch Routing) and WRP

(Wireless Routing Protocol).

3.2.3 Source Initiated Routing Protocols

Source initiated routing creates routes only when desired by the source node. The

route discovery phase is initiated by the source node when a route to the destination is

required. This process is completed once a route is found or all possible route

permutations have been examined. Once a route has been established, it is maintained by

a route maintenance procedure until either the destination becomes inaccessible along

every path from the source or until the route is no longer desired. Source initiated routing

protocols are also called reactive protocols. Some of the examples or source initiated

routing protocols are AODV (Ad-Hoc On-Demand Distance Vector Routing), DSR

(Dynamic Source Routing), TORA (Temporally-Ordered Routing Algorithm), ABR

(Associativity Based Routing) and SSR (Signal Stability Routing)










Before describing the routing protocols in detail, the following taxonomy is

offered to organize the routing protocols study in a meaningful way.

Roung Protocok for Ad Hoc Netwos


Table Driven Routing


Source Initiated Routing


AODV DSR TORA ABR GeoTORA ODMRP SSR CBRP


FPRP
(TDMA
Based)









LAR
LAR


Figure 3.1: Classification of Routing Protocols for Ad-Hoc Networks



Not all the routing protocols shown in Figure 3.1 will be discussed. DSDV, AODV,

TORA and DSR will be explained, as they are the most used for simulations. Details on

other routing protocols can be obtained from references.


3.3 Protocols

Ad-hoc routing protocols DSDV, AODV, DSR and TORA are discussed as they

are mainly used in simulations and come with ns as previously mentioned.


IP/TDMA









3.3.1 DSDV (Destination Sequenced Distance Vector)

DSDV [JOH96, BRO98, ROY99] is a table driven, hop-by-hop distance vector

routing protocol in which each node has a routing table that stores the next-hop and

number of hops for that destination. Like distance-vector, DSDV requires that each node

periodically broadcast routing updates. DSDV solves the problem of the conventional

distance vector routing by promising loop free paths.

DSDV used a sequence number for each route to guarantee loop-free paths. There

are two types of update messages: full and incremental dump. The full dump carries all

available routing information and the incremental dump that only carries the information

that has changed since the last dump.

DSDV requires some time to converge before a route can be used because DSDV

is dependent on periodic broadcasts. In static wired networks, where the topology in not

frequently changing, this time is negligible. On the other hand, in ad-hoc network, where

the topology is expected to be very dynamic, this high converging time will probably

mean a lot of dropped packets before a valid route is detected. The periodic broadcasts

also add a large amount of overhead in to the network.

Couple of figures are shown below that explain the working of DSDV, i.e. how

routes are discovered and how updates are considered. Figure 3.2 shows that a packet has

to be routed from node 1 to node 5. For forwarding this packet, each intermediate host

maintains a table, in which it checks for the destination and finds the next hop to which it

has to forward the packet.













Next Hop Destination
C 4 13
| Node1 I


a) Node 1 transmits packet to node 4 for forwarding


b) Node 4 looks up the destination in its routing table


c) Node 4 retransmits the packet to the next hop
Figure 3.2: Routing a Packet from the Source to Destination Using the Routing Table2


2 Credited to and used with permission of B. Cameron Lesiuk


Node 4


I Node 5 1


I Node 1 I


I Node5 I


I Node 5


I Node 1 I


















Routing Table


Update
Ignored






Update
Ignored


Metre

4
6
1


Next
Hop
1
1
7


Seq #

24
20
56


Figure 3.3: Updating Routing Entry into the Table upon the Arrival of the Update Packet3


3 Credited to and used with permission of B. Cameron Lesiuk


Update Pkt









Figure 3.2 and Figure 3.3 are pretty self explanatory, Figure 3.2 shows how a

packet is routed using DSDV. Figure 3.3 shows how an update packet is processed to

update the routing tables.

3.3.2 AODV (Ad-Hoc On-Demand Multicast Routing)

ADOV [ROY99, MIS99, PER99] is reactive i.e. its source initiated. AODV

creates a route only when requested. As long as the endpoints of a communication

connection have valid routes to each other, AODV does not play any role. AODV is loop

free and when link breakages occur, immediate notifications are sent to the affected

nodes. AODV uses destination sequence numbers to provide a fresh route.

A RREQ (Route Request) packet is broadcasted to all its neighbors whenever a

node wants to try and find a route to another node. The RREQ propagates through the

network until it reaches the destination. The route reply (RREP) packet is then sent back

to the source. Hello messages are broadcasted periodically to the immediate neighbors;

this acts as an advertisement of the presence of the node and neighbors using routes

through the broadcasting nodes will continue to mark the routes as valid. If hello

messages doesn't come from a particular node, the neighbor can assume that the node has

moved away and mark that link to the nodes as broken and notify the affected set of

nodes by sending a link failure notification to that set of nodes.

Route table in AODV keeps track of the following information: Destination IP

address, destination sequence number, hop count, next hop, life time, active neighbor list,

request buffer.

3.3.2.1 Route Discovery

A node broadcasts a RREQ when it needs a route to a destination. After

broadcasting a RREQ, the node waits for a RREP. If the reply is not received within a









certain time, the nodes may rebroadcast the RREQ or assume that there is no route to the

destination. The node also creates a temporary reverse route to the source IP address in its

routing table with next hop equal to the IP address field of the neighboring node that sent

the broadcast RREQ. This is done to keep track of a route back to the original node

making the request, might be used for an eventual RREP to find, its way back to the

requesting node. When the RREQ reaches a nodes that earlier is the destination node or a

node with a valid route to the destination, a RREP is generated and unicasted back to the

requesting node. While this RREP is forwarded, a route is created to the destination and

when the RREP reaches the source node, there exists a route from the source to the

destination.

3.3.2.2 Route Maintenance

When a node detects that a route to a neighbor no longer is valid, it will remove

the routing entry and send a link failure message to its neighbors. For this purpose AODV

uses an actively neighbor list to keep track of the neighbors that are using a particular

route. Since flooding is used in this case the, link failure message will be received by the

affected nodes. Triggered route replies are reduced in number by sending the triggered

route replies to affected senders. And it may take many hops to send these messages.

AODV sends on triggered RREP for every active neighbor. The active neighbor could

receive multiple RREP informing about the same link failure. AODV does not support

unidirectional links. When a node receives a RREQ, it will setup a reverse route to the

source by using the node that forward the RREQ as next hop. This means that the route

reply, in most cases is unicasted back the same way as the route request used.

Unidirectional link support would make it possible to utilize all links and not only the bi-

directional links.










3.3.3 DSR (Dynamic Source Routing)

Dynamic source routing (DSR) [ROY99, MIS99] is a source initiate routing

protocol. Source routing means that each packet in its header carries the complete ordered

list of nodes through which the packet must pass. DSR does not use periodic routing

messages, thus reducing network bandwidth overhead, conserving battery power and

avoiding large routing updates throughout the ad-hoc network. Instead DSR relies on

support from the MAC layer (the MAC layer should inform the routing protocol about

link failures).

3.3.3.1 Route Discovery

When a route is desired from node P, it requests a route by broadcasting a route

request (RREQ) packet. Every node receiving this RREQ searches through its route

cache for a route to the requested destination. DSR stores all known routes in its route

cache. If no route is found, it forwards the RREQ further and adds its own address to the

recorded hop sequence. This request propagates through the network until either the

destination or node with a route to the destination is reached. Upon reaching the

destination a route reply (RREP) is sent back to the originator, using that path that has

been recorded in the request packet received.

Figure 3.4 below shows how a route is created from node A (source node) to node

H (destination node), and the Figure 3.5 shows the reply packet being sent back.

3.3.3.1 Route Maintenance

Route maintenance is the mechanism of link failure detection. A failed link is

detected by earlier actively monitoring acknowledgements or passively by running in









promiscuous mode, overhearing that a packet is received, the hop in error is removed

from this hosts route cache, and all routes that contain this hop are truncated at this point.

DSR uses the key advantage of source routing. Intermediate nodes do not need to

maintain up-to-date routing information in order to route the packets they forward. There

is also no need to periodic routing advertisement messages, which will lead to reduce

network bandwidth, overhead, particularly during periods when little or no significant

host movement is taking place. Battery power is also conserved on the mobile hosts, both

by sending the advertisements and by not needing to receive them; a host could go down

to sleep instead.

DSR has the advantage of learning routes by scanning for information in packets,

which means setting the nodes in promiscuous mode. Running the interface in

promiscuous mode is a serious issue and can lead to security issues. Applications have to

provide the security by encrypting their data packets before transmission.




BG Destination

Su c EJ C E, G>
Source
c .< H
A



Fige 3: R e A,R D>

Figure 3.4: Route Recording During Route Discovery

















Source G Destination

A C H



OF




Figure 3.5: Route Reply Propagating Back with Route Record



3.3.4 TORA (Temporally Ordered Routing Algorithm)

TORA [ROY99, MIS99, SIV96] is a link reversal algorithm designed to minimize

reaction to topological changes. The control messages are typically localized to a very

small set of nodes ensuring loop-free paths and typically providing multiple routes for

any source /destination pair. TORA uses directed acyclic graph (DAG) rooted at the

destination for each route. TORA has the following phases:

3.3.4.1 Route Creation

TORA associates a height with each node in the network. All messages in the

networks flow downstream, from a node with higher height to a node with lower height.

Routes are discovered using query and update packets. When a node with no

downstream links needs a route to a destination, it will broadcast QRY packet. This

QRY packet will propagate through the network until it reaches the destination. The

destination node will send a UPD packet, which will be propagated back. This process









can result in multiple routes. Figure 3.6 shows a route creation in TORA. It shows the

initial states of the nodes and how the QRY packet is propagated through the network.

Figure 3.6 shows the state after the route has been established and the DAG has been

formed.

3.3.4.2 Maintaining Routes & Route Erasures

Route maintenance is done by link reversals, meaning that the directed portions

return to a destination-oriented graph within a finite time. The erasing of routes is done

using clear (CLR) messages.

The protocols underlying link reversal algorithm will react to link changes

through a simple localized single pass of the distributed algorithm as a result control

packets will not be able to propagate too far in the network. The graph is rooted at the

destination, which has the lowest height. However, the source originating the QRY does

not necessarily have the highest height. This can lead to the situation, where multiple

routes are possible from the source to the destination, but only one route will be

discovered. The reason for this is that the height is initially based on the distance in

number of hops from the destination.


B G
Source (_, )

A C


Destination
S F ) (0,0)

C,-)

Figure 3.6: Initial State, When the Path Is to Be Established, and Propagation of QRY
Packet Through the Network.














Source (0,3) O,

A C H

0,3) (0,3) destination
SF (0,3)

(0,2) (0,1)
Figure 3.7: Height of Each Node Update as a Result of UPD Messages




Figure 3.6 above shows that a route is to be determined from a source node A to

destination node H. Initially the destination has height as zero, and all intermediate nodes

have height as null. The QRY will be forwarded until it reaches a node with higher

height, i.e. when the QRY packets reach the destination node the UPD packet will be sent

back to the next higher node, and the height will be increased, as the UPD packet reaches

back to the source node as shown in Figure 3.6. And the directed links will be set from a

node of higher height to lower height. Figure 3.7 shows the complete graph formed for

routing packets from nodes A (source) to nodes H (destination).

Figure 3.8 shows the new DAG formed when the link between node E and node

G breaks, as node E doesn't have any outgoing so both the links of node E will be

reversed, now as node B and node C doesn't have any out going link then the other links

of the node B and node C is reversed. Now as node A has one outgoing link the link

reversal is stopped. In TORA link reversal only occurs when there is no outgoing link.













Source / (1 -1) (0,1)
(1,0)
A C

(0,3) (1, -1)
() ( ) Destination
-@
D F I (0,0)
(0,2) (0,1)
Figure 3.8: Route Maintenance Mechanism When Node Between Node E and G Fails



3.4 Performance Comparison and Evaluation of the Protocols

To compare the performance of the table driven like DSDV and source initiated

routing protocols like DSR, TORA, and AODV, the parameters often used are a) control

overhead, b) data throughput, c) end-to-end propagation delay.

3.4.1 Control Message Overhead

Source initiated protocols like DSR and AODV have less control overhead than

table driven protocols like DSDV. The control message overhead for table driven

protocols are very high in high mobility conditions. In Source initiated protocols, the

control overhead would be the time required to establish routes between the source and

destination. The table driven routing protocols have control message overhead because of

periodic updates normally and triggered updates in the high mobility condition.

3.4.2 Data Throughput

Data throughput means that the number of packets that can be pushed through the

nodes. The throughput will usually be constant. It decreases somewhat when the









mobility factor increases because of the dropped packets. The throughput for both the

table driven and source initiated protocols are almost same.

3.4.3 End-to-End Delay

Source initiated protocols have higher end to end delay than the table driven

routing protocols under low mobility conditions while opposite is true when the mobility

increases as a result of which queuing delay increases, The packets that are dropped in

table driven protocols will successfully get through when using source initiated routing

protocols. In a packet based radio network, a packet that do not have a route will be

buffered until a route is found. Its important to evaluate how long a packet must be in a

buffer before a route is established.

3.4.4 Other Considerations

Some other criteria that should be taken in to account when selecting the routing

scheme for a specific application, are table storage overhead, problem with shortest path

on power consumption, mobility, networks size, buffering capacity. Different routing

metrics should also be studied, like hop count, delay, etc. Sending route updates

periodically and triggering up dates when the topology changes result in excessive

control message overhead, which is unacceptable in a wireless environment with limited

bandwidth.

3.4.5 Comparison of On-Demand v/s Table Driven Routing

The table below shows the performance comparison of table driven v/s on

demand protocols in general [BRO98].









Table 3.1: Comparison of On Demand vs. Table Driven Routing
Parameters On Demand Table Driven
Availability of Routing Available when needed Always available
Information regardless of need
Routing Philosophy Flat Mostly Flat except for
CGSR
Periodic Route Updates Not Required Yes
Coping with Mobility Using Localized route Inform other nodes to
Discovery (ABR) achieve consistent
routing tables
Signaling Traffic Grows with increasing Greater than that of
Generated mobility of active nodes On Demand Routing
QoS Support Few Can Support QoS Mainly Shortest Path
as QoS Metric


The conclusion drawn is that source initiated routing protocols (reactive) hold an

upper hand on table-driven routing protocols (proactive). It has been shown that source

initiated routing protocols work better in case of high mobility, while table driven routing

protocols scale better in case of low mobility.














CHAPTER 4
NETWORK SIMULATOR (ns)

Network Simulator [OFFI, NSDO, MGTT] is a discrete event based simulator

targeted at research in networking. ns was developed as a variant of the REAL network

simulator in 1989. Currently research in ns is being supported actively by DARPA, NSF

and is now a part of VINT project. CMU Monarch Projects have contributed to ns

research with wireless extensions. ns provide substantial support for simulation of TCP,

routing, and multicast protocols over wired and wireless (local and satellite networks).

ns is completely object-oriented as it uses both C++ / Otcl, Otcl means Object

oriented TCL (Tool Command Language). The use of C++ and Otcl is explained below.

C++ is used for data per packet events.

Otcl is used for periodic and triggered events.

The TCL interpreter (TclCL) is the language used to provide a linkage

between C++ and Otcl.

The primary reason to use both the languages is that C++ is used for per packet

action, while otcl if used to control periodic and triggered action. ns is a compromise for

composibility and speed.

The ns tool requires tcl/tk, otcl, tclcl, ns-2 and nam-1 (Network Animator) to run

successfully. NAM is used to visualize the scenario of the simulation, thus allowing the

users to visualize the way nodes moved and were connected to other nodes. Effect of new

protocol designs and algorithms can be studied using ns by implementing those new

protocols and algorithms. Study on scalability of wireless networks, integrated services,









components and their interaction is also done. ns has almost all the desirable properties

that a simulator should have. It is easy to extend, robust, efficient and has many

integrated components. Most importantly ns has earned large user and developer

community with in a short period of time. Some of the existing components in ns are:

Applications/Traffic: Several applications layer supports are web (HTTP), ftp,
telnet, constant bit rate (CBR)

Transport Protocols: Some transport protocols are TCP, UDP, Rapid
Transport Protocol (RTP), Scalable Reliable Multicast (SRM).

TCP: Several versions of TCP are listed. They are Tahoe, Reno, Vegas,
Selective ACK, Forward ACK. More information can be obtained from ns
manual.

Routing: Can do both static and dynamic routing, support multicast protocols.

Queueing: Several queuing standards are Drop Tail, Random Early Detection
(RED), Class Based Queueing (CBQ), Stochastic Fair Queueing (SFQ),
Deficit Round Robin (DRR).

Network Emulation: tap to the real network.

Tracing of simulation.

ns-2 is used for creation of event scheduled functionalities, compute routes, create

connection, create traffic, insert errors and trace of simulation. The main component of ns

the event scheduler is used to create an instance of the simulator by using the "set ns

[new Simulator]." An event can be scheduled by inputting the time and event "$ns at

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs