Ethersim: a simulator for application-level performance modeling of wireless and mobile ATM networks

Ž .Computer Networks and ISDN Systems 29 1998 2067–2090

Ethersim: a simulator for application-level performance modelingof wireless and mobile ATM networks

Mani Srivastava a,), Partho Mishra b, Prathima Agrawal c, Giao Nguyen d

a EE Department, UCLA, Los Angeles, USAb AT&T Laboratories, Florham Park, USA

c AT&T Laboratories, Whippany, USAd CS Department, UC, Berkeley, USA

Abstract

The paper describes Ethersim, a simulation tool to model and study the performance of multimedia-oriented integratedservice ATM networks with mobile hosts and wireless links. The key motivation behind Ethersim is to study theapplication-leÕel impact of host mobility and wireless channels. Ethersim has a discrete event based simulator core andincorporates models of user applications and transport, network and MAC layer protocols. It provides the capability tospecify a cellular wireless ATM network topology and host mobility patterns. The software architecture of Ethersim employsfive special entities: an air module, a map, a mover, mobile hosts, and basestations. We also present case-studies of usingEthersim to model and study the interaction of transport layer, connection rerouting protocol, and radio characteristics in the

wSWAN P. Agrawal, A. Asthana, M. Cravatts, E. Hyden, P. Krzyzanowski, P. Mishra, B. Narendran, M. Srivastava, J.xTrotter, SWAN: A Mobile Multimedia Wireless Network, in: IEEE Personal Commun. Mag., April 1996 mobile and

wireless ATM based multimedia network. q 1998 Elsevier Science B.V.

Keywords: Mobile ATM simulation; Wireless ATM simulation

1. Introduction

The increasing deployment of wireless accesstechnology along with the emergence of high speedintegrated service networks promises to provide mo-bile users with ubiquitous access to multimedia in-formation in the near future. However, transformingthis vision into reality poses several problems, ofwhich one of the most challenging is how to re-design the existing network protocols currently usedin wired networks so as to allow seamless end-to-endcommunication over networks with both wireless

) Corresponding author.

and wired links. This design process requires anunderstanding of how network and multimedia appli-cation performance is affected by the choice ofalgorithms and protocols at various layers of thenetwork hierarchy, the characteristics of the wirelesslinks and their differences from wired links, thepresence of mobile hosts, and the mobility patternsof these hosts.

Traditionally, wireless links characteristics andhigher layer protocols for multimedia networks havebeen studied in isolation. For example, the perfor-mance of wireless links has been studied with theprimary focus being on understanding and improvingthe performance of the physical and medium-

0169-7552r98r$19.00 q 1998 Elsevier Science B.V. All rights reserved.Ž .PII S0169-7552 97 00120-7

( )M. SriÕastaÕa et al.rComputer Networks and ISDN Systems 29 1998 2067–20902068

Ž .access-control MAC layer protocols. Similarly, theperformance of higher layer protocol suites such asATM and TCPrIP have been studied in context ofthe high speed integrated service wired networks.Only recently has there been interest in studying theimpact of wireless link characteristics and host mo-bility patterns on higher layer protocols, such asstudies by various researchers on the interactionbetween wireless communication and the TCP proto-

w xcol 11,5,26,6 . These studies have demonstrated thattemporary disruptions in the physical connectivitydue to noise and fading in wireless links, and hand-offs of a mobile user from one basestation cell toanother in a cellular network, can lead to long liveddisruption in communication at the user level be-cause of specific assumptions made by higher layerprotocols, such as TCP. Unfortunately, since most ofthese studies have been conducted using actual im-plementations, they have not been able to extensivelymodify protocol policies, host mobility patterns, orlink characteristics to generalize their conclusions.These complex systems are also analytically in-tractable, leaving simulation as often the only rea-sonable alternative methodology to extend analysisand obtain generalized conclusions.

In this paper we describe Ethersim, a tool de-signed to model application-level performance ofintegrated service networks with mobile hosts andwireless links. The tool grew out of a need to modeland study the performance of various alternativeprotocols and algorithms for a wireless and mobile

w xATM based multimedia network called SWAN 2,3that our research group previously developed at AT&T Bell Laboratories. In particular, we wanted tostudy the interaction of adaptive applications, trans-port layer protocols, connection rerouting schemes,and radio characteristics in a SWAN-like wirelessand mobile ATM system.

Ethersim has been built using a discrete eventbased simulator core and incorporates models of userapplications and transport, network and MAC layerprotocols. It provides the capability to specify net-work topology and host mobility patterns. It providesthe capability to specify network topology and hostmobility patterns. There are five special entities inEthersim relevant to modeling mobility and wirelesscommunication: an air module, a map, a mover,mobile hosts, and basestations. The air module mod-

Žels the physical air-interface effects e.g., RF power.decay, frequency collisions, etc. . The mover is a

central entity that moves the mobile hosts on themap. Ethersim allows for both random and goal-di-rected movements of mobile hosts, and also allowssynchronized goal-directed movements to modelconference room type mobility patterns. Ethersim isstructured in a modular fashion to permit functional-ity at different levels of the protocol stack to bemodified independently, thereby allowing networkprotocol designers to study the interaction betweenpolicies embedded in the protocols at different lay-ers. Ethersim also includes various performancemeasurement and graphical user interface routines tointerpret the simulation results.

1.1. Related work

By and large the available simulators that arerelevant to our work fall into two broad categories:wireless link simulators and network simulators. Theformer focus on detailed modeling of the wirelesslink characteristics such as RF propagation, noise,and fading, but provide no support for modelinghigher network layers. The latter focus on network-ing algorithms and protocols, using fixed networktopologies with static hosts, and simple link modelsthat may be adequate for wired links but are inade-quate for wireless links.

Clearly, neither of these two classes of simulatorsis adequate for modeling wireless and mobile net-works. Realizing this, various industry and academicgroups developing such networks have resorted toone of three approaches to their modeling and simu-lation. The first approach is the use of custom devel-oped C function libraries or Cqq class libraries tocre-ate stand-alone ad hoc programs that model and

w xsimulate specific networks, such as for GSM 25 .Such custom libraries, however, cannot serve thepurpose of a general simulation tool.

The second approach is to combine wireless linksimulation and network simulation using softwareenvironments that either provide a mixed-domainsimulator or allow multiple simulators to be inter-connected using a simulator backplane. As an exam-

w xple, the Ptolemy 10 software environment from

( )M. SriÕastaÕa et al.rComputer Networks and ISDN Systems 29 1998 2067–2090 2069

Berkeley provides multiple simulation domains, eachcorresponding to a different model of computation.Available domains include synchronous dataflow,dynamic dataflow discrete event, process networks,VHDL, etc. The Ptolemy simulator kernel orches-trates the schedulers corresponding to each of thedifferent domains. Different parts of a system can bemodeled using the domain that is well suited to it.For example, the wireless link may be modeled usingone of the dataflow domains while the higher net-work layers may be modeled using the discrete eventdomain. Berkeley’s Infopad wireless and mobile sys-

w xtem project 7 used Ptolemy for some of its wirelesslink simulation and modeling requirements. Overall,with their roots in block diagram simulators in DSPand communications, Ptolemy and other such simula-tors have weaker support for network models. Also,while flexibility is a strong suite of the approach ofcombining multiple simulators or multiple simulationdomains, it does come at a cost of efficiency.

The third approach is that of a single simulatorconsisting of a discrete event kernel core with enti-ties to model various elements of a mobile andwireless network, such as the mobile hosts, the wire-less link, etc. Ethersim falls into this category.

Another simulator in this category from the litera-ture is the recent mobile wireless network simulation

w xenvironment Maisie 23 used for the WAMIS mo-bile wireless multimedia system project at UCLAw x15 . Maisie is actually a general purpose discreteevent simulator capable of parallel execution onmultiprocessors. It uses a specialized message-pass-ing parallel simulation language, also called Maisie.Since Maisie has been used by various researchgroups for modeling wireless and mobile systems

w xunder DARPA’s GloMo research program 18 , avariety of models for mobile nodes, wireless chan-nels and radios, operating system, application-specific traffic source, and network algorithm havebeen created by various researchers. However, re-flecting their diverse origins and the inherent gen-eral-purpose nature of Maisie, these available modelsare not designed to all work together as a consistentlibrary.

On a more ad hoc basis, various researchers havealso used patches and tricks to coax popular networksimulators, such as ns from UC Berkeley and

ŽLawrence Berkeley National Labs see http:rr

www-nrg.ee.lbl.govrnsr and http:rrwww-.mash.cs.berkeley.edurnsr , to model wireless chan-

nels and mobile hosts. For example, a simple wire-less channel can be modeled in ns as a noisy sharedchannel and a CSMA based medium access protocolvia an extension written by one of the co-authorsŽ .Giao Nguyen . Host mobility can be modeled in nsby using its frontend scripting language Tcl to changethe network topology during the course of the simu-lation. In principle, more elaborate Ethersim-likenotions of host location, maps and mobility tracesmay be programmed into ns via Tcl. However, nsand similar simulators have no direct support formobility or shared wireless radio channels.

Finally, commercial simulators, such as OPNET,have also begun to provide modules for wireless andmobility added onto a conventional network simula-tor.

Ethersim, which is built on a generic discreteevent kernel, is distinguished by a much general andricher variety of network components such as hosts,links, switches, and ATM and TCPrIP protocolmodules that allow the modeling of a variety ofmixed wired and wireless network scenarios. Insteadof leaving the modeling of wireless link and themobility entirely to the various components of thenetwork defined by the user, Ethersim supports wire-less and mobility aspects in an integral fashion asfirst class citizens. The notion of an air module, amap module, and a mover module are built intoEthersim, and provide efficient modeling of wirelessand mobility. For example, the map and the movertogether provide modeling of the geographical topol-ogy of the network and a variety of mobility patternswithout burdening the user defined host models withthem. Instead, an interface in terms of pre-definedmobility events is defined to the hosts.

1.2. Paper organization

The rest of this paper is structured as follows. InSection 2 we describe the mobile and wireless net-work model that we assumed in designing Ethersim.In Section 3 we describe the software architecture ofEthersim, and the implementation and capabilities ofa few key modules. Section 4 presents case studiesmeant to illustrate the capabilities of Ethersim. InSection 5 we draw conclusions from our experience.


2. Mobile and wireless network

Ethersim uses the reference network model, shownin Fig. 1, comprised of a wired part and a wirelesspart. The wired part is composed of switches andwired static hosts, with point-to-point wired linksconnecting the hosts to switch ports, or one switchport to another switch port. This is similar to thestructure of modern high-speed switched networks,such as ATM. It must be noted that the wired part ofthe Ethersim network model is intrinsically based onswitches and point-to-point links, and does not sup-port shared medium networks such as older non-switched Ethernet where multiple hosts may be onthe same wired link. Examples of real-life systemsthat uses such networks modes include Bell Lab’s

w x w xSWAN 3 , Berkeley’s Infopad 7 , ORL’s Radiow xATM 21 , etc.

The switches and the hosts incorporate networkand lower layer protocols. These layers are responsi-

ble for the signalling functions required to setup andtear down virtual circuits in addition to the transportfunctions of packet transmission, reception and for-warding. The hosts also have transport protocol mod-ules associated with them which perform the func-tions of flow control, reliable data delivery, etc.,depending on application requirements. Hosts areassumed to have applications running on them whichact as traffic sources or sinks.

Some of the switches in the Ethersim model arespecial because they also have one or more portsequipped with radio interfaces. Such switches arecalled basestations. Basestations can be viewed asbeing located at the topological edge of the wirednetwork, with their radio ports providing access tothe wireless world. Physically, the basestations willbe distributed in a geographical region with theantenna corresponding to each basestation radio portcovering a geographical neighborhood whose sizewill depend on factors such as radio transmitter

Fig. 1. Mobile and wireless network model in Ethersim.


power, radio receiver sensitivity, free-space radioattenuation, multi-path fading, etc.

Basestations lead us to the final physical compo-nent of the network model – wireless mobile hosts.These hosts are derived from the standard wired hostby replacing the wired network link interface with aradio. Just like wired hosts, the wireless mobile hostsalso have the ability to participate in network sig-nalling and data transfer protocols. Freed from itswired tether, a radio-equipped host can geographi-cally move with the user who is carrying it. Manydifferent types of motion patterns are possible inreal-life, ranging from movements of an isolated userto ganged movements of a set of users who are goingto or leaving a meeting. Further, a variety of terrainare possible in which a user can roam. This primarilyaffects the attenuation of radio signals as they travelfrom a transmitter to a receiver. The presence ofwalls and other obstructions can render the simpleinverse-squared free space attenuation model useless.

At any moment, a mobile host is associated, orŽregistered, with a proximate basestation typically

.the nearest with which it can communicate. Themobile sends or receives all its traffic to or from thewired network through the basestation at which it isregistered. Multiple mobiles may be registered at abasestation. As a mobile host roams geographically,it may move from the vicinity of one basestation toanother, and thus change the basestation with which

it is registered. Such roaming requires the networkprotocols to be mobility aware. For example, in caseof an ATM network, the virtual connections originat-ing from or terminating at a mobile hosts need to be

w xrerouted every time a mobile host moves 9,17,19 .ŽIn general, communication using radios between

.the mobile and basestations is a much more com-plex phenomenon than simple point-to-point commu-nication using wired links. This is largely because allradio communication takes place in an inherentlybroadcast medium. Depending on factors such ascompatibility of frequency, modulation scheme, cod-ing, distance, transmitter power, receiver sensitivity,free-space attenuation, multi-path fading, etc., a ra-dio transmitter on a mobile host or a basestation cancommunicate with a radio receiver on another mo-bile host or basestation, and can cause interference inthe communication between another transmitter anda receiver.

In the Ethersim network model, a radio may havemultiple channels and the radio may be configuredto operate on one of the channels at any time. Achannel may correspond to a CDMA code in a directsequence spread-spectrum system, or to a frequencyhopping pattern in a slow frequency-hopping system,or to simply a frequency slot. In a full-duplex radiotransceiver, the channels of the receiver and thetransmitter halves can be independently set. In ahalf-duplex radio transceiver, only one half is active

Fig. 2. General multi-channel organization of a basestation in Ethersim model.


at any given time. For a radio transmitter and a radioreceiver to communicate, the two must be on thesame channel. Therefore, all the mobiles registeredat a basestation radio port must be on the samechannel. As shown in Fig. 2, a basestation may havemultiple co-located radio transceivers and can sup-port multiple channels. Basestation radio ports,whether on the same basestation or different ones,that are in the same vicinity will typically be ondifferent channels to take advantage of spatial multi-plexing. When a mobile moves, it may have toregister at a radio port at a new basestation on a newchannel in order to maintain connectivity.

Channels in the Ethersim model are intrinsicallybroadcast oriented because multiple transmitters canbe active on the same channel. If two transmitters T1and T2 are active at the same time, then T2 canpotentially cause interference at T1’s intended re-ceiver R1 if the signal strength of T2’s radio trans-mission received at R1 is high enough compared tothe strength of signals received from T1. Variousfactors such as free space attenuation, multi-pathfading, and obstructions such as walls affect thestrength with which a transmitter signal is receivedat a receiver. To coordinate such interference intra-

Ž .channel interference, medium access control MACprotocol module is associated with each radio toallow multiple transmitters to share a channel. Tokenpassing, and collision detection based multi-access

wprotocols are examples of MAC protocols 8,12,x14,16 .

While the MAC protocol helps eliminate or mini-mize interference from other transmitters on the samechannel by providing a multi-access mechanism alongthe time dimension, a second mechanism of interfer-ence is between transmitters on different channelsbut same frequency. Ethersim channels are a way todivide the spectrum in the frequency and code di-mensions. In frequency division systems, channelsoperate on different frequencies and are thus orthog-onal with no possibility of inter-channel interference.In code division spread spectrum systems, channelsoperate on same frequency but with different orthog-onal codes. Increasing transmit power in one channelraises the noise level in other channels operatingwith different codes. In slow frequency hoppingsystem, different channels cyclically hop throughdifferent sequences of frequency slots. The hopping

sequences are chosen from a weakly orthogonal setto reduce the chance of different channels collidingby hopping to the same frequency. But, clearly,frequency collisions cannot be eliminated whenasynchronously hopping transmitters are in the sameneighborhood.

The wireless part of the Ethersim network modelis quite complex, with crucial roles being played bythe division into multiple channels, medium accesscontrol, intra-channel and inter-channel interfer-ences, and radio signal attenuation. This is quiteunlike the simple wired link.

2.1. Factors in application-leÕel performance

From the discussion of the network model above,it is clear that a number of factors unique to mobileand wireless networks can potentially effect the ap-plication-level performance. First are the mobile net-work protocols, such as mobile-IP and mobile-ATM.Second are the characteristics of wireless links, in-cluding bandwidth, large-scale and small-scale prop-agation loss, receiver sensitivity, multiplexing tech-

Žnique FDM, TDM, frequency hopping, direct-se-.quence spread spectrum, etc. , medium-access proto-Ž .cols, and hand-off protocols hard vs. soft hand-off .

The third factor is the flexible patterns of hostmobility, which may include patterns such as randomand directed movements of mobile users, and con-vergence and divergence of roaming mobile torfroma meeting location. The interaction of these mobilitypatterns with geographies with a large number ofcells can have serious impact on application perfor-mance that would need to be modeled. Finally, cru-cial to modeling application performance are theapplication models themselves. Many applications,particularly multimedia applications, adopt sophisti-cated adaptive control mechanisms to combat timevarying conditions such as in a radio channel. Thesecontrol techniques include adaptation of play-outcontrol mechanism at the receiver, and a propermodeling of such application behavior is importantin an overall modeling of mobility and wireless.

3. Ethersim software architecture

The Ethersim software provides a modular simu-lator which supports all aspects of the wireless and


mobile network model described in the previoussection, while allowing functionality at different lev-els of the protocol stack to be modified. At the coreof the simulator is an efficient and generic discreteevent kernel. The kernel manages the scheduling ofevents using an event queue. The core functionalityis similar to any discrete event kernel – an entity canrequest an event to be sent to another entity at a

Ž .future time simulator time , and the kernel arrangesfor the delivery of the right event at the right time.

The interesting part of the simulator consists ofthe built-in software modules in Ethersim that usethe discrete event kernel core to provide standardservices for user defined and instantiated simulationentities. These standard services take the form ofpre-defined events and messages to be generated orhandled by the user code. The main software mod-ules are: wired static host, switch, wired link, basestation, wireless mobile host, air, map, moÕer, traffic

( )sources statistical and trace driÕen , protocol mod-(ules transport, connection establishment, and packet

)scheduling , measurement modules, and graphicaluser interface modules. The wired static host, switch,basestation, and wireless mobile host, incorporateuser customizable protocol sub-modules for connec-tion setuprteardown, packet scheduling and data

transport functions. The wired static host and wire-less mobile host modules have associated transportprotocol modules, including ones that accuratelymodel the TCP transport protocol and an experimen-tal video transport protocol. Both wireless and wiredhosts also have associated statistical and trace-driventraffic sources. The basestation and the mobile hosthave attached to them user customizable MAC pro-tocol modules. In addition to these primary modules,there are two supporting modules, measure and GUI,to provide performance statistic gathering and graph-ical IrO services to user code. User customization ofthe various protocol modules takes the form of writ-ing C functions. The protocols in different layers canbe modified independently, thereby allowing net-work protocol designers to study the interaction be-tween policies embedded in the protocols at differentlayers.

Of the main software modules, only the basesta-tion, wireless mobile host, air, map, moÕer, and

(selected protocol modules connection rerouting,)MAC, and location management are relevant to

wireless communication and mobility, and will bethe focus of our discussion. The global relationshipof all these software modules and sub-modules isshown in Fig. 3. The following subsections describe

Fig. 3. Relationship between software modules in Ethersim.


the key mobility and wireless related software mod-ules.

3.1. Map: models of geography

The map module is used to define a geographicalregion, and the placement of various wireless entitiesŽ .basestations and mobile hosts in it. The map isconstructed using an undirected graph data structurewhose nodes represent arbitrarily sized geographicalregions referred to as rooms or cells, while edgesrepresent inter-cell topological adjacency relation-ship. There is at most one edge between a pair ofnodes. Nodes in the graph represent radio regionsthat correspond to geographical areas that are eitherdead-spots or have one main basestation, or are inthe overlapping region within coverage of more thanone basestation. The graph need not be planar, sothat 3-dimensional adjacency relationships can easilybe described. This representation provides a simpleand efficient representation for modeling cellularradio coverage that is detailed enough for studyingapplication-level performance impact without beingso detailed as one would expect in a low-levelsimulation.

Associated with the map are several parameters.One parameter, associated with each edge in the

Ž .map, is the RF loss coefficient L, where L a,brepresents the attenuation of an RF signal generated

Žin cell a and received in cell b, and vice versa i.e.Ž . Ž ..L a,b ssL b,a . By using suitable values of the

loss coefficient and cells representing suitably smallgeographical regions, the effect of walls and obstruc-tions is modeled – one is not restricted to free spaceattenuation. Attenuation between two non-adjacentcells is calculated by finding the path between thetwo cells with minimum loss coefficient, where theloss coefficient of a path is the product of the losscoefficients associated with the edges constitutingthe path. Clearly, Ethersim’s approach of modelingsignal loss is a simple abstraction of the complexphysical world where signal loss is a result of acomplex mix of static and dynamic factors such asfree space attenuation, shadowing, multipaths, slowfading, fast fading, etc. However, such abstractionsare needed when one is trying to study the interac-tions of various layers from the physical layer all theway up to the transport and applications layers.

Otherwise the simulation time would be unreason-able.

Other parameters associated with the map arerelated to the mobility aspect of the network model.Each edge connecting a node to another node isviewed as a door from one cell to another. A door,therefore, is a node-edge pair. Associated with each

Ž .door d is a probability P d of a mobile hosteŽ .entering the door i.e. using the door to exit the cell .

Clearly, the sum of probabilities of entering all theŽ . Ž . Ž .doors in a cell, P d qP d q PPP qP de 1 e 2 e n

Ž Ž .should be less than 1, and the difference 1- P d qe 1Ž . Ž ..P d q PPP qP d corresponds to the probabil-e 2 e n

ity of the mobile host staying in the cell. The proba-bility of staying, in turn, can be used to determinethe time a mobile spends in a cell. Also associated

Ž .with each edge is a distance D, where D a,brepresents the distance that needs to be travelled by amobile going from cell a to cell b.

The basestations are associated with a cell in themap, thus modeling the effect of placing the radioport of a basestation at a specific geographic loca-tion. The mobile hosts are also associated with a cellin the map, but this association changes with time asa mobile moves from one cell to another via door-ways.

3.2. MoÕer

The map specifies where the mobiles can be, andthe paths they can take. The mover is a behind-the-scene entity which moves the mobile hosts on themap. It does so taking into account both the mapparameters, and the moÕement policy. Several move-ment policies are currently implemented. One israndom moÕement, where the transition probabilitiesin the graph associated with the map determinewhere and when to move. A mobile host repeatedlydraws a uniform random variable and based on theprobabilities of entering the various doors decideswhether to exit a cell through one of the doors or tostay in the cell. Another policy is goal-directedmoÕement where a mobile host is given a goal cell,

Žand it moves towards it via the shortest path asdefined by the distances associated with the map

.edges . The speed of movement is decided by theŽ .speed of the mobile host a mobile host attribute

Ž .and the edge distances map attributes . The thirdpolicy is group moÕement which is intended to


Ž .Fig. 4. Structure of the basestation software module with 2 wired ports and 2 wireless ports .

model meeting room scenarios. A subset of mobilesare designated to belong to a group, and they alleither move towards a common goal such as a

Ž .meeting room at the same time converging mobilesusing a synchronized goal-directed movement, or allmove away from a node in a mix of random and

Ž .goal-directed movements diverging mobiles .The mover maintains all the necessary per-host

state on behalf of each mobile host, and decideswhen and where to move each mobile host. The perhost state includes speed, destination, and group.When the mover moves a mobile host, it generates a

Žsequence of pre-defined events HOST_ENTER,.HOST_LEAVING, and HOST_LEAVE to the mo-

bile host as well as to the air module. The latter issent the events so that mobility related wireless linkrecalculations can be triggered, and appropriateevents generated for basestations and mobile hosts.

3.3. Basestation: a switch with radios

Basestation, as mentioned earlier, is a switch withradios on a subset of its ports. Like any switch, itmaintains a routing table using which it routes pack-ets coming in on an input port to an output portwhere they are queued in a buffer for eventualtransmission. Some of the packets may be signallingmessages, which are routed to a signalling sub-mod-ule instead of being sent to an output port. Thesignalling sub-module realizes various protocol statemachines, such as for connection set-up. This de-scription is true of an ordinary switch as well. A

basestation, however, has two enhancements. First,the signalling sub-module has to be mobility awareand execute protocols that can deal with mobile

Žhosts. Second, a basestation also has MAC medium.access control protocol sub-modules associated with

each radio port. Fig. 4 shows the structure of thebasestation software module.

3.3.1. Connection manager sub-moduleThe Connection Manager sub-module, shown as

CM in Fig. 3, implements several alternative proto-cols for connection management and rerouting in thepresence of mobility. This allows, for example, themodeling of a variety of mobile ATM scenarios. Theimplemented protocols include those proposed by us

w xin 19 and being used in the SWAN wireless andw xmobile ATM system 2,3 , as well as various other

approaches. While new protocol modules for connec-tion management and rerouting can be written by theuser, Ethersim defines the basic interface. When amobile host registers at a new basestation via aREGISTER signalling message, a REROUTE sig-nalling message is sent by the new basestation to theold basestation, along with a list of connection idswhich need to be rerouted. The CM at the oldbasestation selects and takes appropriate actions toreroute the said connections to the mobile hosts newbasestation. This is done in cooperation with the CMat other interested basestations, switches, and hosts.The cooperation takes the form of more signallingmessage exchange. Some of the rerouting schemes


which are available in Ethersim include: total con-nection rebuild, partial connection rebuild to a fixedanchor basestation or switch, partial rebuild to asuitably chosen ancestor basestation or switch, con-nection extension from old to new basestation, etc.

Ž .In addition, there are options to i remove connec-tion loops in the wired network in the connection

Ž .extension scheme, ii either throw away packets intransit during rerouting, or to buffer the packets in

Ž .transit at basestations and switches, and iii allowmobile host to trigger a partial rebuild based onconnection-level performance measurements. Thecomplexity of the implementation lies in the need toensure that packet ordering is maintained throughoutthe process – this is mandated by connection ori-ented networks such as ATM. The detailed finitestate machines for some of the rerouting schemes of

w xEthersim are described in 19 .

3.3.2. MAC sub-moduleWhen an incoming packet is routed by the base

station to an output port with a radio, the packet isput in a transmit queue associated with the outputport. The MAC sub-module associated with the radioat that output port serves the transmit queue byattempting to transmit the packets in accordance to a

Ž .medium access control MAC protocol which coor-dinates access to the wireless channel on which theremay be other radio transmitters. On the incomingside, the MAC sub-module passes to the basestationall packets received from a radio transmitter, exceptfor MAC signalling messages which are interceptedand acted on. The MAC protocol may be user de-fined, and involves exchange of signalling messages

Žwith other MAC sub-modules at basestations and.mobiles on the same channel.

3.4. Mobile host

The mobile host is derived from the wired host,and subsumes all its functionality. In addition, how-ever, it has three additional enhancements. First, thesignalling sub-module is mobility aware and imple-ments the host side of the rerouting protocols such asconnection rebuild, connection extension, etc. Sec-ond, it has an associated MAC sub-module throughwhich all the incoming and outgoing packets pass.The MAC sub-module implements the host-side of

MAC protocols such as token passing. Third, themobile host needs to handle mobility. This first twoenhancements are similar to the corresponding en-hancements in the basestation. We focus on the third:mobility. As mentioned earlier, the mobile hosts aremoved on the map by the mover. The mobile hostscarry some state data and parameters, such as speed,to allow the mover to move the hosts meaningfully.In addition, associated with each mobile host is acurrent basestation, which is the strongest basestationheard by the mobile host. After moving a mobilehost, the mover and the map together recalculate thestrongest basestation and update the current basesta-tion. In addition, HOSTLEAVE and HOSTENTERevents are sent to the old current basestation and thenew current basestation. These events are madeavailable to allow simulation of rerouting protocolswithout necessarily having low level MAC handoffprotocols available – HOSTLEAVE and HOSTEN-TER can be used in lieu of a handoff protocol.Actually, the mover and map also provide aHOSTLEAVING event which is sent to a basestationwhen the mobile host enter a geographical areawhere the radio ranges of two basestations overlap.In this overlap area the mobile host communicatewith either basestation, although it is registered withonly one of them. In real systems such overlapregions are used to implement soft handoffs. TheHOSTLEAVING event allows simple emulation ofsoft handoffs for purposes of high level simulation.In short, the HOSTENTER, HOSTLEAVING, andHOSTLEAVE events which are generated by themap and the mover based solely on radio considera-

Ž .tion transmit power and attenuation can be used asan abstraction of a low level handoff protocol. Suchabstractions simplify and speed up the simulationwhen the focus is the performance and interaction ofhigher layer protocols.

3.5. Air: modeling of the wireless link

Ž .The Air module Fig. 5 is the key module re-sponsible for the wireless aspects of Ethersim. Func-tionally, the Air module can be viewed as a giantMAC level switch. It receives as input packets fromthe sending MAC sub-modules at various basesta-tions and mobile hosts, and routes them to appropri-ate receiving MAC sub-modules. Every incoming


Fig. 5. Air module in the Ethersim simulator.

packet carries with it information about the fre-Ž .quency, spread-spectrum code optional , and power

with which it was transmitted. Every outgoing packetdelivered to a receiver carries with it informationabout the signal strength at the receiver. Also, asso-ciated with the radios is the wireless link data rate,from which the transmit duration of a packet iscalculated by the Air module. In addition to theswitch-like functionality, the air module also de-grades packet signal strength to model large scalepropagation loss, introduces noise errors to modelwhite gaussian noise, and detects and marks collid-ing packets on same frequency at each receiverlocation. A packet is delivered by the air module to areceiver if it is on the same frequency band andspreading code, if signal-strength is greater thanreceiver sensitivity, if signal-to-interference ratio isgreater than a threshold value, and if there is a MACaddress match at the recover or if the receiver isoperating in a promiscuous mode.

The key concern in the Ethersim implementationis minimizing the number of events generated fortasks that need to be done on a per packet basis.Tasks at larger time scales have only second ordereffects, and are therefore less important. For exam-ple, map recalculations done after a mobile hostmove are at much larger time scales and need not beoptimized much. However, since the Air module

does per-packet processing and is meant to model abroadcast medium, it is crucially important to have asmart filtering policy in the Air module itself to cutdown on the number of events generated by eachpacket transmission. This is implemented by pruningthe number of receivers to whom a packet is deliv-ered based on considerations such as frequency,

Ž .received signal strength RSS , interference, noise,etc.

For example, if a packet is sent in frequency slotf , then only receivers tuned to frequency slot f willget that packet. Similarly, a packet corrupted by

Žnoise the Air module includes channel noise mod-.els is just dropped. Finally, if signals from more

than one transmitters on the same frequency overlapin time with high enough strengths at a receiver, theyinterfere and only garbage can be heard. This mightbe the case, for example, in frequency hopping ra-dios where two transmitters may transiently hop onto the same frequency. Air module arranges forpackets that suffer from such interference to bedropped as well. This filtering process is an imple-mentation optimization which is a key to the effi-ciency of the Air module. To further avoid checkingall the receivers for matching criterion during filter-ing, a dynamically updated centralized table is main-tained to point to all receivers that are listening on agiven frequency at a given time. This table is in-dexed by frequency, and is updated only when thefrequency is updated due to, for example, frequencyhopping. The first filtering criterion is therefore thetransmit frequency of a packet, and the central tableis used to get a list of eligible receivers. Eachreceiver in this set is then checked to see if theremaining criteria, such as the RSS) receiver sensi-tivity, are satisfied.

Ž .The receiver signal strength RSS is calculatedby the Air module for each eligible receiver bymultiplying the packet transmit power by the totalpath loss between the transmitter and the receiver.

ŽThe path loss is obtained from the map using the RF.loss coefficients . To speed up the RSS calculation

for each packet, Ethersim pre-computes a table of thetotal path loss between any two cells by using ashortest path algorithm with the minor modificationthat the cost of a path is a product instead of a sum.Since each radio has a cell id associated to it by

ŽEthersim the id is dynamically updated by the mover


.in the case of mobile hosts , the total path loss isquickly obtained by indexing into the path loss tablewith the cell ids.

After the frequency and signal strength criteria aresatisfied, the Air module next checks for interferencewith an earlier transmission. To do this, each re-ceiver has associated with it the latest end time of allthe packet transmissions on each frequency slot. Ifthe transmission time of the packet under considera-tion starts before all previous transmissions are fin-ished on that frequency at the receiver, both the newpacket and the previous packets with which it iscolliding are declared corrupted for that particularreceiver. Since RECEIVE events might be generatedfor packets that are later corrupted by colliding witha new packet, these receive events are recorded bythe Air module and later deleted when necessary.Associated with every packet is a MAC address forthe intended radio receiver, with a special MACbroadcast address also being available. As is obviousfrom the preceding discussion, the air medium isinherently broadcast. A packet with a non-broadcastŽ .unicast MAC address can be heard by other re-ceivers as well and cause interference. Clearly thepacket itself is of no use to receivers other than theintended one. Therefore, the Air module considersall packets for calculating interference and collisions,but generates actual RECEIVE events only for thosereceivers that match the MAC address criterion. Thisis another form of packet filtering by the Air modulewhich further improves its efficiency.

The final filtering step in the process of packetdelivery is for the Air module to decide whethernoise has corrupted the packet. Using a noise modelbased on a single bit error rate parameter, the Airmodule emulates a random process that possiblycorrupts a packet. If the packet is corrupted by noiseat a particular receiver, then the packet is droppedand no RECEIVE event is generated. However, thepacket continues to be taken into account for inter-ference and collision.

3.6. Connection manager: parameterized modelingof Õirtual circuit rerouting schemes

An important protocol module in Ethersim is theConnection Manager, that runs at the mobile hosts,the basestation, and mobility-aware switch nodes to

allow establishment and rerouting of ATM virtualcircuits. Clearly, as would be clear from the litera-

w xture 1,4,9,13,17,19,22,24,27 , there are a variety ofpossible virtual circuit rerouting schemes. Some ob-vious and not-so obvious ones are listed below:1. Extension. Extend a VC from the old to the new

basestation.2. Extension with Loop Removal. In this enhance-

ment to extension, one removes VC loops thatmight get formed when a mobile revisits a base-station. This requires tearing down a VC segment,and short circuiting the VC at the switch wherethe loop is formed.

3. Total Rebuild. Tear down the entire VC andestablish a new one in its place.

4. Partial Rebuild to a Fixed Anchor Switch.Define a fixed known anchor switch throughwhich all VCs must pass, both before and afterrerouting. To reroute a VC, tear down the VCsegment from the anchor switch to the old base-station, and establish a new segment from theanchor to the new basestation. As a special caseof this scheme, the anchor switch may be thebasestation at which the mobile host was locatedat the time of VC establishment.

5. Partial Rebuild to a Dynamically SelectedCross-over Switch. Select a cross-over switchalong the path of the current VC such that a pathalso exists from this switch to the new basesta-tion. Tear down the VC segment from the cross-over to the old basestation, and establish a newsegment from the cross-over to the new basesta-tion.

6. Multicast to Neighboring Basestations. Createall VCs as multicast VCs, and configure themsuch that all neighboring basestations to which areceiving mobile host may move to are part of themulticast group for that VC. When the mobilehost does move, the data is already available. Themulticast group is modified after the move.

These schemes need not be used alone. For example,w x19 proposed a hybrid strategy whereby a fast but

Žless optimal scheme VC extension with optional.loop removal is used as the default, and a slow but

Žmore optimal scheme Partial Rebuild to a Dynami-.cally Selected Cross-over Switch is triggered on a

per VC basis by the mobile hosts based on connec-tion-level performance measurements. Whatever be


Fig. 6. Some schemes for rerouting of virtual circuits.

the scheme, one must emphasize that any reroutingscheme must maintain in-sequence delivery of cellsas required by ATM.

Fig. 6 shows some of these rerouting schemes.In order to implement these rerouting protocols in

Ethersim, we took a unique approach. Instead ofimplementing these schemes separately, we imple-mented a single parametrized Connection Managermodule. This is based on an observation from our

w xrelated research 20 that a common structure under-lies all uni-cast rerouting schemes. Specifically, inw x20 it was observed that all uni-cast virtual circuitrerouting schemes can be viewed as being composedof the following three steps in context of Fig. 7:

Ž1. Selection of a suitable rebuild switch or a base

.station SW , which may be selected basedrebuildŽeither on a static topological criterion e.g. the ith

switch from one end of the current VC, or a fixed.known switch through which VC must pass , or

Ž .on a dynamic criterion to optimize some metric .2. Establishment of a new VC segment from the

rebuild switch SW to the new basestationrebuildw xBS 0 .

3. Tear-down of the old VC segment from the re-build switch SW to the old basestationrebuild

w xBS y1 .To illustrate their composition in terms of the threeprimitive operations, let us consider the various

w xschemes when BS y1 is the old basestation, andw xBS 0 is the new basestation. The extension scheme


Fig. 7. A parametrized view of ATM virtual circuit rerouting.

w xfixes the rebuild switch to be BS y1 , establishes aw x w xnew segment from BS y1 to BS 0 , and does not

tear down any VC segment. The total rebuild schemefixes the rebuild switch SW to be the basesta-rebuild

tion or switch of the peer host, establishes a new VCw xsegment from it to BS 0 and tears down the existing

w xVC segment from it to BS y1 . The partial rebuildto fixed anchor scheme designates some knownswitch SW , through which the VCs must pass,anchor

to be the rebuild switch SW , establishes a newrebuildw xVC segment from it to BS 0 and tears down the

w xexisting VC segment from it to BS y1 . The partialrebuild to a dynamically selected cross-oÕer switchscheme is similar except that SW is pickedrebuild

Ž .dynamically an operation that adds to the latency toŽ . Ž .be a switch that: a optimizes some metric, b is on

Ž . w xthe current VC, and c has a path to BS 0 .The Connection Manager protocol module in

Ethersim implements the above three-step parameter-

ized process, and allows the following aspects to becustomized to create a unique instance of a reroutingprotocol:1. Policy for selecting SWrebuild

w x Ž .SW ssBS y1 extensionrebuildŽSW ssBS total rebuildrebuild peer

ŽSW ss intermediate node partial rebuildrebuild

SW : fixed vs. ‘‘oracle’’ vs. backtrackingrebuild

2. Packets arriving at SW from BSrebuild peer

discard vs. bufferw x3. Packets on SW lBS y1 segmentrebuild

discard vs. salvage and deliver in order4. Removal of loops at basestations and switches

4. Case studies

In this section we will demonstrate the utility ofEthersim via two case studies. These case studies aredesigned to examine how wireless access and hostmobility affect the achievable user and network per-formance, as measured by the throughput, per-packetdelays and link utilization levels. In particular, wefocus on the interplay between the congestion con-trol and error recovery policies in the transport layer,the connection rerouting policies in the network layer,and the wireless radio link characteristics.

4.1. Effect of frequency hopping on performance

In the US, the 2.4 GHz industrial, scientific, andŽ .medical ISM band, which has 83 available 1 MHz

wide slots, is commonly used for a wide variety ofwireless applications. Legal requirements specify thatthe maximum period of transmission in any one slotis limited to 0.4 seconds every 30 seconds, for radiosoperating in this band. In addition radios need tocycle through at least 75 of the 83 slots in this bandusing a pseudo-random frequency hopping policy topick the frequencies visited. This pseudo-randomhop policy precludes any synchronization betweenradios operating in physically adjacent or overlap-ping areas thereby increasing the possibility of inter-ference and data corruption between two or moreradios that attempt to simultaneously transmit on thesame or adjacent bands.


The likelihood of collision may be reduced byallocating a frequency hop sequence, i.e. the list offrequency slots visited, to each transmitter such thatall transmitters in a physically adjacent area useweakly orthogonal hop sequences. Each sequence ina family of weakly orthogonal sequences is a list of

Ž .N frequency slots 75FNF83 that a transmittercycles through such that the maximum number ofcollisions with any other sequence in that family isbounded, for any phase 1 relationship between thetwo sequences. For example, if the minimum dis-tance between contiguous hops is 6 slots, it is possi-ble to generate 3 families, with 22 hop sequences ineach family, such that Sequence i and Sequence j,within a family, are guaranteed to have at most oneexact collision 2. Therefore when there are severaltransmitters active, the best case for a particulartransmitter is when it collides with all of the othertransmitters on the same frequency in its hop se-quence. Similarly, the worst case occurs when itcollides with each of the other transmitters on sepa-rate frequency slots.

It is possible to derive an average case collisionprobability via Monte Carlo simulations in each runof which every transmitter is assigned a randominitial phase and all transmitters are assumed to haveperfectly synchronized hop times. Table 1 shows thebest, average and worst case collision probabilities asthe number of transmitters is increased up to themaximum number possible in the family. When all22 transmitters are active, there are collisions in23.47 out of the 79 slots in the worst case. Thiscollision probability results in a loss of almost 30%of the channel capacity due to the frequency hopcollisions, for applications generating traffic at aconstant rate that equals the channel capacity.

1 The term phase denotes the position of a transmitter in its hopsequence.

2 We use exact collision to describe the interference thathappens when two sequences hop such that they are both in thesame frequency slot at the time. In real life, radio often causeemissions into neighboring frequency slots because filter are neversharp. Therefore radios using different sequences may interfereeven when they have hopped to adjacent or close by frequencyslots. We shall refer to such interference as approximate colli-sions.

Table 1Time spent in collision as a function of number of transmitters forexact collisions

Ž .a Transmitters Time in collision %

Best Worst Average

2 1.27 1.27 1.273 1.27 2.53 2.524 1.27 3.80 3.755 1.27 5.06 4.966 1.27 6.33 6.157 1.27 7.59 7.378 1.27 8.86 8.519 1.27 10.13 9.69

10 1.27 11.39 10.8111 1.27 12.66 11.9912 1.27 13.92 13.0713 1.27 15.19 14.2214 1.27 16.45 15.2515 1.27 17.72 16.2816 1.27 18.99 17.4217 1.27 20.25 18.4818 1.27 21.52 19.4519 1.27 22.78 20.5620 1.27 24.05 21.5521 1.27 25.32 22.4922 1.27 26.58 23.47

The reduction in application level throughput as aresult of frequency hop collisions can be much greaterfor applications that use transport protocols such asTCP to ensure reliable data delivery. Since theseprotocols typically use some form of window flowcontrol to limit the maximum number of unacknowl-edged packets, the loss of packets due to collisionscan cause the throughput to reduce until the lostpackets are retransmitted. Moreover, the loss of ac-knowledgment packets flowing in the reverse direc-tion can also adversely affect throughput even if thedata packets are successfully transmitted over the air.Finally, the congestion control mechanism in TCPcauses a reduction in the window size when there ispacket loss – this also leads to a reduction in theaverage throughput.

Ethersim allows us to accurately measure theeffect of frequency hop collisions on the averagethroughput of applications that run on top of TCP,since it exactly models the dynamic behavior of TCPand the frequency hopping protocol. The simulationconfiguration used is shown in Fig. 8 and models a


Fig. 8. Simulation configuration for TCP throughput in the pres-ence of frequency hopping.

situation where mobile hosts are sending or receivingdata torfrom a host across a wide-area-network. Themaximum transmission rate over each 1 MHz wide

frequency slot is assumed to be 1 Mbrs, in theabsence of collisions. An application is modeled asan infinite data source with the rate of transmissionbeing controlled by the TCP protocol. Each TCPpacket is of size 500 bytes and the TCP window size

Ž .is 32 Kbytes 64 packets . The TCP timeout intervalis 500 ms and the default frequency hop interval is50 ms. Each TCP connection generates a duplex datastream with data and acknowledgments flowing inopposite directions and hence two separate hop se-quences are assigned for each TCP connections: onefor the basestation transmitter forwarding data pack-ets and one for the mobile host transmitter forward-ing ack packets.

Fig. 9 plots the throughput seen by the TCPconnection labeled TCP Src a1, when it is the onlyactive connection among the 22 connections shownin Fig. 8. For this scenario, the effect of the fre-quency hop collisions is to cause the data and ackpackets for this connection to interfere with eachother. During the hop interval of 50 ms, a maximumof 12 data packets can be sent out over the air by theBS. Since an ack packet is generated only when adata packet is successfully received, each alternatedata packet and all the ack packets are lost – for atotal of 6 data packets and 6 ack packets. ExistingTCP implementations, which use cumulative ac-knowledgment policies, can only recover from multi-ple packet losses via a coarse-grained timeout, typi-

Ž .Fig. 9. Oscillation in TCP throughput due to frequency collision with only TCP Src a1 active .


Ž .Fig. 10. Oscillation in TCP throughput due to frequency collision with TCP Src a1–a22 active .

cally 500 ms. The timeout-based recovery causes theTCP transmitter to idle for almost the entire lengthof the timeout interval, with the throughput droppingto near-zero. The packet losses also trigger the con-gestion control algorithm to reset the TCP windowsize to 1 packet–500 Kbytes. Subsequently, the TCPconnection takes a few seconds to build its windowsize up to a high enough value to fully utilize the 1Mbrs channel. Since the hop interval is 50 ms, thecollision interval is 4 seconds and hence by the timethe TCP connection builds up its throughput, thenext collision causes the throughput to drop again.Fig. 9 illustrates the resultant oscillation in the TCPthroughput over time. This dynamic behavior resultsin the TCP connection being able to utilize only

Žabout 50% of the available channel capacity 515.Kbitsrsec , even though the collision probability is

only 1.27%.In the next set of experiments, all 22 TCP connec-

Ž .tions Src a1–Src a22 are active. If all 22 radiochannels, used to transport the traffic for each ofthese connections, have the best-case phase relation-ships, then each connection loses data for 50 msevery 4 seconds, as in the previous set of experi-ments. However, in these experiments each activeradio transmitter sends out both data and ack pack-ets. As a result, the number of data packets lostduring a collision interval is slightly higher thanbefore because of the greater volume of traffic on

each channel. Consequently the average throughputŽ .for Src a1 490 Kbitsrsec is slightly lower than in

the previous set of experiments. On the other hand,when all the transmitters have the worst-case phaserelationships, each connection loses data for 21 50ms intervals every 4 seconds. Due to the morefrequent collisions, a connection is unable to everincrease its transmission rate to match the full chan-nel capacity of 1 Mbrs and is able to utilize only

Žabout 12.9% of the average channel capacity 129.Kbitsrsec . This is illustrated in Fig. 10.

One of the design parameters that controls theeffect of the frequency collision on the TCP through-put is the duration of the frequency hop intervalvis-a-vis the packet size. As the duration of the`frequency hop interval becomes greater, more pack-ets are dropped during each collision interval but thefrequency of collisions decreases. The first effectcauses transport protocols such as TCP which do notuse selective acknowledgments to take longer todetect and retransmit packets resulting in a loss ofthroughput. On the other hand the lower frequencyof collisions causes the TCP congestion control algo-rithm and the subsequent window size reduction tobe triggered less often, leading to an increase inthroughput. Further, since a smart MAC protocolwill only transmit a packet if it is assured that it cantransmit the entire packet before it is time to hopfrequencies, a smaller fraction of the link capacity is


Fig. 11. Effect of hop interval length on TCP throughput.

wasted when the frequency hop interval is largerelative to the size of a packet. Fig. 11 which plotsthe TCP throughput for Configuration 2 for fre-quency hop intervals values of 10 ms and 50 ms,illustrates these different effects.

4.2. Effect of host mobility on performance

Networks that provide wireless access typicallyalso support host mobility by providing support forhost lookup and data rerouting as a host movesaround. In networks using a cellular architecture, akey issue is the degree of degradation in user-levelperformance as a mobile host moves from one cell toanother. Since mobile computing is still in its in-fancy, it is hard to precisely characterize the perfor-mance requirements of applications while a host is inmotion – e.g. is it realistic to assume that a personcan interact with his computer while walking down ahallway? However, it would appear that for someapplications, such as voice telephony, there is a clearneed to minimize the disruption time caused by ahandoff. For other applications, such as file transfers,it appears to be desirable to minimize the reductionin throughput caused by a handoff.

The degradation in user-perceived performancedepends on the duration of the handoff interval. Thisin turn depends on the time taken by the MAC layerprotocols at a mobile host to discover and register at

a new basestation, and the time taken by the networklayer protocols to establish a new path through thenetwork. For a virtual circuit oriented network, thisinvolves modifying or rebuilding existing virtual cir-

Ž .cuits. Additionally, the reliable transport layer pro-tocols operating end to end may create additionaldelays by attempting to discover and retransmit anypackets lost during handoff. Ethersim allows us tostudy these effects, as the policies and parametersused in the MAC, network and transport layer proto-cols are varied.

The simulation configuration used to study theeffect of host mobility is shown in Fig. 12 andmodels an office corridor type layout with basesta-tions laid out at regular distances. The 8 basestationscomprise two groups with 4 members, each of whichis assumed to be connected directly by a switch. Thetwo groups are in turn connected by another switch.As with the previous group of simulations, mobilehosts are assumed to be sending or receiving datatorfrom a host across a wide-area-network.

Two traffic sources are modeled. A file transfertype application is modeled as an infinite data sourcewith the rate of transmission being controlled by the

Ž .TCP protocol. A audiorvideo constant bit rate CBRtype application is modeled as a source which injectsdata periodically with an average rate of 900 kbrs,thereby utilizing about 90% of the capacity of thelast hop wireless link. In all of the experiments a


Fig. 12. Simulation configuration to study performance impact of host mobility.

mobile hosts moves from Cell 1 to Cell 8 over theduration of the simulation, with an average stay of 2seconds in each cell. In these simulations, the trans-mission frequencies are statically picked and thefrequency hopping is disabled to avoid any data lossdue to frequency collisions.

Our first set of experiments compares the perfor-mance of two rerouting policies – Extend and Re-build. In the Extend policy, an existing virtual circuitis extended from the old basestation to the newbasestation following a handoff. In the Rebuild pol-icy, an existing virtual circuit is completely torndown and a new virtual circuit constructed from thesource to the destination. The Extend policy is meantto minimize the handoff time since it only involvessignaling and virtual circuit setup between adjacent

basestations. On the other hand, the Rebuild policy ismeant to construct a minimal cost end to end pathevery time a host moves. For both of the policies, weassume that the network attempts to forward all datain transmission on the old virtual circuits onto thenew virtual circuits. These two policies are both verysimple and are meant to illustrate the trade-offsinherent with one policy versus the other.

Fig. 13 illustrates the per-packet delay, and Fig.14 illustrates the throughput, of a CBR source, withthe Extend and Rebuild policy. With the Extendpolicy the time taken to complete an extension istypically less than 10 ms, except when the MHmoves from Cell 4 to Cell 5. As a result the through-

Žput is barely reduced due to the handoffs see Fig..14 . However, because the extension causes longer


Fig. 13. Effect of rerouting policy on per-packet delay with CBR source.

paths to form the delay increases gradually overtime, with sharp jumps whenever domain boundariesare crossed. The spikes in the delay plot correspondto the delays suffered by packets which are in trans-mission at the time of the handoff and are buffered atswitchesrhosts until the virtual circuits are rebuilt.In contrast with the Rebuild policy the time taken torebuild the virtual circuits is almost 100 ms. As aresult, the packets which were in transmission at thetime of the handoff incur delays of as much as 250ms. Moreover, since we assume that in-transit pack-

ets are buffered rather than dropped, and since thesource continues to inject packets at a rate of 900kbrs during the handoff interval, a large queuebuilds up at the wireless link between the basestationand the host. This causes even packets transmittedafter the handoff to incur large queueing delays, untilthe queue is flushed. Subsequently, the per-packetdelays reduce to about 50 ms, which comprisesmostly of the end to end propagation delay.

Fig. 15 shows the per-packet delay, and Fig. 16shows the throughput, for the two rerouting schemes

Fig. 14. Effect of rerouting policy on throughput with CBR source.


Fig. 15. Effect of rerouting policy on per-packet delay with TCP source.

with TCP sources. In this case, the insights are quitedifferent because of the interaction of the reroutingpolicy with the error control and congestion controlmechanisms used in TCP. Fig. 16 shows that for the

Žinitial set of handoffs S1™S2, S2™S3 and S3™.S4 the throughput reduces slightly immediately fol-

lowing the handoff, with both policies. This happensbecause of two reasons. First, TCP uses a windowcontrol mechanism to restrict the maximum amountof ‘‘unacknowledged’’ data that can be outstandingat any time. At the time of the handoff, the window

size is at the maximum possible value of 32 K andTCP has a full window worth of data in transit.Subsequently while the virtual circuits are beingrewired, the flow of data and acknowledgmentstorfrom the mobile host, and hence TCP is unable tosend any additional data. Additionally, due to thehandoffs there are packet losses – for the resultsshown here only a single packet is lost becausepackets in-transit are buffered and not dropped. Thepacket loss causes the congestion control mechanismof TCP to reduce the window size by 50% down to

Fig. 16. Effect of rerouting policy on throughput with TCP source.


about 16 K. This value is not large enough to keepthe wireless link fully saturated and hence there is adrop in throughput, until TCP increases its windowsize back to 32 kbytes.

The dynamic behavior is more complicated fol-lowing the transition from S4™S5. Since it takessomewhat longer for the REROUTE message topropagate from S4 to S5, more packets are lost overthe air. The loss of multiple packets necessitates atimeout based recovery as pointed out earlier. Fol-lowing the timeout, TCP reduces its window sizedown to a single packet. Due to this sharp reductionin the window size and the 500 ms idling thethroughput reduces significantly. When the Extendpolicy is used the round trip delays are much longer

Ž .than with the Rebuild policy see Fig. 15 . Thiscauses the TCP connection to increases its windowsize more slowly over time. As a result, after theS4™S5 transition, the throughput is lower with theExtend policy than with the Rebuild policy.

These results suggest that it may be possible toget the best of both worlds, i.e. low latency handoffand bounded end to end delays by performing exten-sions when handoffs are local and doing a rebuildotherwise. Moreover, the cost of doing a rebuild maybe reduced by only rebuilding from a common an-cestor rather than one end of a connection. Ourresults also suggest that for CBR traffic it may bemore useful to drop packets rather than bufferingthem, specially if handoff intervals are large. Theseissues are examined in greater detail in a separatepaper.

5. Conclusions

We have described Ethersim, a network simula-tion tool that integrates mobility and wireless linksas first class citizens. Ethersim allows better model-ing of mobile wireless networks than is allowed byconventional network simulators with only ad hocsupport for mobility and wireless links. Ethersimaddressed these problems by incorporating five spe-cial entities: an air module, a map, a mover, mobilehosts, and basestations. The air module models thephysical air-interface effects such as radio signalattenuation and interference. The mover is a key

central entity that moves the mobile hosts on themap, and allows for random movements, goal-di-rected movements, and synchronized goal-directedmovements to model conference room type mobilitypatterns. We have also described the application ofEthersim to study the interplay of transport, reroutingdue to mobility, and frequency-hopping based wire-less link characteristics.

The current implementation attempts to strike abalance by abstracting the low level physical charac-teristics of the wireless link, which are computation-ally intensive to model in full detail, to a highenough level so as meaningfully study the interactionwith logically complex network protocols. Therefore,instead of bit-by-bit simulation, Ethersim resorts tothe higher level approach of associating a transmitfrequency or power with an entire packet. Someimportant wireless link level phenomena, such asmultipath interference, are however still not modeledin Ethersim. Also, while Ethersim includes a richmenu of protocol modules for higher network layers,the choices for lower level wireless protocols such asMAC are still limited. Properly addressing limita-tions such as these, without sacrificing the efficiencyof high level modeling, is the subject of on-goingwork. Finally, we found the parametrized connectionrerouting approach to the connection manager proto-col module to be elegant and powerful, considerablysimplifying the modeling of the protocols for ATMmobility.

References

w x1 A. Acampora, M. Naghshineh, An architecture and method-ology for mobile-executed handoff in cellular ATM net-

Ž . Ž .works, IEEE J. Selected Area Commun. 12 8 1994 1365–1375.

w x2 P. Agrawal, A. Asthana, M. Cravatts, E. Hyden, P.Krzyzanowski, P. Mishra, B. Narendran, M. Srivastava, J.Trotter, A testbed for mobile networked computing, in: Proc.

Ž .1995 IEEE Int. Conf. on Communications ICC ’95 , June1995.

w x3 P. Agrawal, A. Asthana, M. Cravatts, E. Hyden, P.Krzyzanowski, P. Mishra, B. Narendran, M. Srivastava, J.Trotter, SWAN: a mobile multimedia wireless networ, IEEE

Ž .Personal Commun. Mag. April 1996 .w x4 B.A. Akyol, D.C. Cox, Rerouting for handoff in a wireless

ATM network, in: Proc. ICUPC ’96, September 1996.


w x5 A. Bakre, B.R. Badrinath, Handoff and system support forindirect TCPrIP, in: Proc. 2nd Usenix Symp. on Mobile andLocation Independent Computing, April 1995.

w x6 H. Balakrishnan, S. Seshan, E. Amir, R.H. Katz, ImprovingTCPrIP performance over wireless networks, in: Proc. 1stAnnual Int. Conf. on Mobile Computing and NetworkingŽ .MobiCom ’95 , November 1995.

w x7 B. Barringer, T. Burd et al., Infopad: a system design forportable multimedia access, in: Wireless 1994, Calgary,Canada, July 1994.

w x8 V. Bharghavan, A. Demers, S. Shenker, L. Zhang, MACAW:a media access protocol for wireless LANs, in: Proc. SIG-COMM ’94, 1994.

w x9 S. Biswas, A. Hopper, A connection management scheme fora mobile radio LAN, in: Proc. IEEE Int. Conf. on PersonalWireless Communications, Bangalore, India, August 1994.

w x10 J. Buck, S. Ha, E.A. Lee, D.G. Messerschmitt, Ptolemy: aframework for simulating and prototyping heterogeneous sys-

Ž .tems, Int. J. Comput. Simulation 4 1994 155–182.w x11 R. Caceres, L. Iftode, The effects of mobility on reliable

transport protocols, in: Proc. Int. Conf. on Distributed Com-puting System, Cracow, Poland, June 1994.

w x12 K.-C. Chen, Medium access control of wireless LANs forŽmobile computing, IEEE Network SeptemberrOctober

.1994 50–63.w x13 R. Cohen, A. Segall, Connection management and rerouting

in ATM networks, in: Proc. INFOCOM ’94, April 1994.w x14 W. Diepstraten, G. Ennis, P. Belanger, Distributed founda-

tion wireless medium access control, IEEE P802.11-93r190.w x15 R. Jain, J. Short, S. Nazareth, L. Kleinrock, J. Villasenor,

PC-notebook based mobile networking: algorithms, architec-tures, and implementation, in: Proc. 1995 IEEE Int. Conf. on

Ž .Communications ICC ’95 , June 1995.w x16 P. Karn, MACA – A new channel access method for packet

radio, in: Proc. ARRLrCRRL Amateur Radio 9th ComputerNetworking Conf., September 1990.

w x17 K. Keeton, B. Mah, S. Seshan, R. Katz, D. Ferrari, Providingconnection-oriented services to mobile hosts, in: Proc.USENIX Symp. on Mobile and Location-Independent Com-puting, Cambridge, Mass., August 1993, pp. 83–102.

w x18 B.M. Leiner, R.J. Ruth, A.R. Sastry, Goals and challenges ofŽthe DAPRA GloMo program, IEEE Personal Commun. De-

.cember 1996 34–43.w x19 P.P. Mishra, M.B. Srivastava, Call establishment and rerout-

ing in mobile computing networks, AT&T Bell LaboratoriesTechnical Memorandum BL011384-940906-13TM, Septem-ber 1994.

w x20 P.P. Mishra, M.B. Srivastava, Evaluation of virtual circuitrerouting strategies for mobility support in ATM networks,Lucent Bell Laboratories Technical MemorandumBL011340H-960723-06TM, July 1996.

w x21 J. Porter, A. Hopper, D. Gilmurray, O. Mason, J. Naylon, A.Jones, The ORL Radio ATM system, architecture and imple-mentation, Olivetti and Oracle Research Labs TechnicalReport TR.96.5, 1996. Available from ftp.orl.co.uk:rpubrdocsrORLrtr.96.5.ps.Z.

w x22 B. Rajagopalan, Mobility management in integrated wireless-

ATM networks, in: Proc. 1st Int. Conf. on Mobile Comput-Ž .ing and Networking MobiCom ’95 , November 1995, pp.

127–135.w x23 J. Short, R. Bagrodia, L. Kleinrock, Mobile wireless network

system simulation, in: Proc. 1st Annual Int. Conf. on MobileŽ .Computing and Networking MobiCom ’95 , November 1995.

w x24 C.-K. Toh, The design and implementation of a hybridhandover protocol for multi-media wireless LANs, in: Proc.1st Int. Conf. on Mobile Computing and NetworkingŽ .MobiCom ’95 , November 1995, pp. 49–61.

w x25 C.F. Yarnell, High-level and detailed design specification forCqq implementation of a GSM TRU simulator, AT&TBell Laboratories Technical Memorandum ITD-94-22041H,May 1994.

w x26 R. Yavatkar, N. Bhagwat, Improving end-to-end performanceof TCP over mobile internetworks, in: Proc. Mobile ’94Workshop on Mobile Computing Systems and Applications,December 1994.

w x27 O. Yu, V. Leung, Extending B-ISDN architecture to supportuser terminal mobility over an ATM-based personal commu-nications network, in: Proc. GLOBECOM ’95, December1995.

Mani Srivastava received his B.Tech.in EE from IIT Kanpur in India, andM.S. and Ph.D. from Berkeley. From1992 through 1996 he was a Member ofTechnical Staff at Bell Laboratories,Murray Hill, in Networked ComputingResearch. Currently, he is an AssistantProfessor of Electrical Engineering atUCLA. His research interests are in mo-bile and wireless networked computingsystem; low power systems; and, hard-ware and software synthesis for DSP

and embedded systems.

Partho Mishra received the B.Tech.degree from the Indian Institute of Tech-nology, Kharagpur, in 1988, and theM.S. and Ph.D. degrees from the Uni-versity of Maryland, in 1991 and 1993,all in Computer Science. He is currentlya Senior Member Technical Staff in theNetworking and Distributed System Re-search Center at AT&T Labs-Research.His research interests include trafficmanagement, mobile networking andpacket video services. His email address

is [email protected].


Prathima Agrawal is head of the net-worked computing technology depart-ment at AT&T Labs in Whippany, N.J.,USA. She previously worked in BellLabs as head of the networked comput-ing research department of Murray Hill,N.J. Dr. Agrawal received her B.E. andM.E. degrees in electrical communica-tion engineering from the Indian Insti-tute of Science, Bangalore, India, and aPh.D. degree in electrical engineeringfrom the University of Southern Califor-

nia. Her research interests are computer networks, mobile comput-ing, parallel processing and VLSI CAD. Dr. Agrawal is a Fellowof the IEEE.

Gia Nguyen is a Ph.D. student in Elec-trical Engineering and Computer Sci-ence at the University of California atBerkeley. His research interests includewireless networking and mobile comput-ing. He received a Bachelor of Sciencein Computer Science and Engineeringfrom the University of California at LosAngeles in 1994, and a Master of Sci-ence in Computer Science at the Univer-sity of California at Berkeley in 1996.

Documents

Ethersim: a simulator for application-level performance modeling of wireless and mobile ATM networks